ANT build and maven bundle

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

ANT build and maven bundle

Holger
James, Jesse,

to harmonize the ANT and Maven worlds a bit,
how about the following suggestions:

I) maven bundles

the maven upload bundle contains the project description (pom.xml),
the main artifact and optionally secondary artifacts like source and javadoc jars.
The naming convention is:
<artifactId>-<version>.jar
<artifactId>-<version>-sources.jar
<artifactId>-<version>-javadoc.jar

I would suggest to follow these conventions with Glazed Lists and to change
the build artifact names to:

glazedlists_java14-1.6.1.jar
glazedlists_java14-1.6.1-sources.jar
glazedlists_java14-1.6.1-javadoc.jar

glazedlists_java15-1.6.1.jar
glazedlists_java15-1.6.1-sources.jar
glazedlists_java15-1.6.1-javadoc.jar

So we would have two upload bundles for Java 1.4 and Java 1.5 with
artifactIds glazedlists_java14 and glazedlists_java15, both having version 1.6.1
for example.

Is this acceptable ?
Should the Glazed Lists jars deployed to java.net follow these conventions too,
or stick to the old names?

Version info is currently not in the build file. I think this could be a property, for example
'project.version' you pass on the command line:

ant -Dproject.version=1.6.1 jar
- or -
ant -Dproject.version=1.6.1 bundle

If you omit the version you would produce a latest build:
glazedlists_java14.jar or glazedlists_java15.jar

But to make a bundle, version info *must* be supplied.

II) one common build output directory
With Maven, all generated artifacts are stored in one output directory named 'target'.
So you would have something like:

target/classes
target/test-classes    <-- new
target/reports
target/docs
target/demojar
...

I think this convention makes sense because it simplifies cleaning the build
and CVS handling. You only have to add the 'target' dir to cvsignore.
Separating the compiled test classes prevents them from being included into the
jar by an oversight.

What do you think?

Holger

_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000071

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ANT build and maven bundle

Jesse Wilson
On 7/17/06, Holger Brands <[hidden email]> wrote:
> I would suggest to follow these conventions with Glazed Lists and to change
> the build artifact names to:
> glazedlists_java14-1.6.1.jar
> glazedlists_java14-1.6.1-sources.jar
> glazedlists_java14-1.6.1-javadoc.jar

When I see '.jar' I usually assume it contains
.class files and a MANIFEST. I don't think it's
good to use the .jar extension for sources or docs.
On most desktops, when you double click a .zip
file, it lets you extract the data inside, which is
what we want to do with sources and docs. But
when you double click a .jar, it tries to execute
it using java. So I feel strongly that .jar for source
or docs is a bad pattern. We can support this
approach for our Maven friends but the rest of our
users should still get source in a .zip.

We could do this by creating a 'maven' target
in our ant file that produces the regular .zip
source file using the existing dist target, then
tweaks it so that it looks good to Maven users,
using copy or rename tasks.

> So we would have two upload bundles for Java 1.4 and Java 1.5 with
> artifactIds glazedlists_java14 and glazedlists_java15, both having version 1.6.1
> for example.

That's great, I like that.

Does Maven have any special metadata facility
for build information? I'd imagine that it might
have a place where we can put build-specific
information like Target VM, just like how say
Ubuntu apt-get supports different build architectures
like x86, PowerPC, Sparc etc.

If not, the names you propose work for me.

> Should the Glazed Lists jars deployed to java.net follow these conventions too,
> or stick to the old names?

We'll leave the java.net files as-is, and use different
naming schemes for the Maven repository.

> Version info is currently not in the build file. I think
> this could be a property, for example
> 'project.version' you pass on the command line:
> ant -Dproject.version=1.6.1 jar
> If you omit the version you would produce a latest build:
> glazedlists_java14.jar or glazedlists_java15.jar

That's reasonable. If you double click any build
of a Glazed Lists jar, you get a cute little dialog
box that tells you build information. I'd like to avoid
breaking this dialog box but for anything else
it's fair game.

One thing I'd like to avoid is having a static file
with build properties. The problem with this is that
it becomes easier to build multiple .jars with the
same version. We need to prevent accidentally
creating multiple builds with the same version, since
that makes diagnosing problems much harder.

> II) one common build output directory
> With Maven, all generated artifacts are stored in one output directory named 'target'.
> So you would have something like:
> target/classes
> target/test-classes    <-- new
> target/reports
> target/docs
> target/demojar
> ...

I don't think this is much better than what we do
now with our classes and docs/javadoc folders.
We can use Ant's zip task's basedir attribute to
move things around as necessary so Maven is
appeased.

> I think this convention makes sense because it
> simplifies cleaning the build and CVS handling. You
> only have to add the 'target' dir to cvsignore.
> Separating the compiled test classes prevents them
> from being included into the jar by an oversight.

Except that existing tools (like IDEs) and developers
expect a ./classes/ folder, not at ./target/test-classes/ dir.
I like that Maven is introducing all these new conventions,
but they are 10 years too late since different Java conventions
are already in place.

As for cvsignore, I haven't used it, and it's never been
much of a problem.

> What do you think?

One of the biggest things holding me back is not
your ideas, but the fact that moving things around
in directories has big negative consequences since
we're using CVS for our version control. You cannot
delete directories in CVS. So suppose we moved to
a target/ folder strategy. Then we'd still have our
existing classes/ folder, but it would be empty. This
will really confuse anyone who tries to build our system
and can't find the expected classes in the classes folder.

Similarly, if we moved source to say source/java, then
we'd still have our source/ca folder which makes things
really nasty.

Hopefully java.net comes out with a new version that
supports Subversion, so we can really refactor our
directory structure.

I apologize that our directory layout isn't ideal, it's
grown organically and we have avoided moving things
around for CVS' sake. I really appreciate your effort
on this Holger. Let me know how it goes, and if you'd
like to point out the errors in my arguments I can be
persuaded!

Cheers,
Jesse

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: ANT build and maven bundle

Jesse Wilson
Wait a sec Holger, the classes/ folder isn't in CVS,
so we might be able to make a change. I'm going to
think on this!

Cheers,
Jesse

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ANT build and maven bundle

Charlie Groves
In reply to this post by Jesse Wilson
On 7/18/06, Jesse Wilson <[hidden email]> wrote:
> On 7/17/06, Holger Brands <[hidden email]> wrote:
> Does Maven have any special metadata facility
> for build information? I'd imagine that it might
> have a place where we can put build-specific
> information like Target VM, just like how say
> Ubuntu apt-get supports different build architectures
> like x86, PowerPC, Sparc etc.

The pom.xml that Maven uses to build the code in the first place is
versioned and uploaded with the file as well.  It contains all the
info needed to produce the build that made the jars, so it has all of
that in there.  I guess you guys could build a dummy pom to upload
with your jars but that seems kinda dangerous to me.

> > Should the Glazed Lists jars deployed to java.net follow these conventions too,
> > or stick to the old names?
>
> We'll leave the java.net files as-is, and use different
> naming schemes for the Maven repository.

Maybe it's just because I'm too inured to the maven way of thinking,
but I've always been made uncomfortable by the lack of version
information in the glazed list jar names.  I had some awful
experiences losing track of exactly which version of a jar I was using
so having it right in the filename seems like a good thing to me.
You've mitigated it to some degree with your neat launching version
displayer, but I would've never thought to do that to double click on
the jar to get the version.  Once you get the rest of the Java world
to use that convention you can drop the version number on the jar
filename.

> > I think this convention makes sense because it
> > simplifies cleaning the build and CVS handling. You
> > only have to add the 'target' dir to cvsignore.
> > Separating the compiled test classes prevents them
> > from being included into the jar by an oversight.
>
> Except that existing tools (like IDEs) and developers
> expect a ./classes/ folder, not at ./target/test-classes/ dir.
> I like that Maven is introducing all these new conventions,
> but they are 10 years too late since different Java conventions
> are already in place.

Actually, Eclipse puts compiled classes in a bin directory by default.
 I've had no trouble configuring it to compile test classes in to
target/test-cases and regular classes in to /target/classes.  I'm sure
IDEA has the same capabilities.

> As for cvsignore, I haven't used it, and it's never been
> much of a problem.

You're missing out!  The ability to run cvs up and see no output if
nothing has changed is invaluable.  One more little task I'd rather
let the computer handle instead of my brain.

Sounds like you guys are on the right path though.  I'll definitely be
glad not to have to do the maven stuff myself from now on.

Charlie

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: ANT build and maven bundle

Jesse Wilson
> The pom.xml that Maven uses to build the code in the first place is

Does pom.xml have a facility to run Ant? We could
make it work, even if it isn't leveraging mavenness.

> Maybe it's just because I'm too inured to the maven way of thinking,
> but I've always been made uncomfortable by the lack of version
> information in the glazed list jar names.  I had some awful

There's a version number in all Glazed Lists releases.
We don't put version numbers in snapshot builds
'cause there isn't really a distinct version number.
If we really wanted to we could put a datestamp in
these, but I think that would make upgrading from
one snapshot .jar to another more of a headache
since you'd need to update all your classpaths.

Hopefully the snapshots are only being used by a
small group of developers who want the latest features
or bugfixes.

> You're missing out!  The ability to run cvs up and see no output if
> nothing has changed is invaluable.  One more little task I'd rather
> let the computer handle instead of my brain.

Sounds okay. I've been using CVS from within IntelliJ
mostly lately, so the output is automagically broken into
appropriate groups anyway.

Yeah, regrettably neither myself nor James is using Maven
so it's good to have Charles, Holger and Geoff to steer us
in the right direction.

Cheers,
Jesse

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: ANT build and maven bundle

Charlie Groves
On 7/18/06, Jesse Wilson <[hidden email]> wrote:
> > The pom.xml that Maven uses to build the code in the first place is
>
> Does pom.xml have a facility to run Ant? We could
> make it work, even if it isn't leveraging mavenness.

I'm not sure what you mean by "a facility to run ant".  pom.xml is the
main file in maven 2.  It's supposed to be a clean representation of
the structure, content and build necessities of a project so it has
things like where the source is and what plugins to run to build a
certain phase.  When you run any maven command it reads in that file
to figure out what's in the current project and builds stuff
accordingly.  Ant tasks can be hooked into it as a plugin, but doing
that would mean driving everything from Maven.

> > Maybe it's just because I'm too inured to the maven way of thinking,
> > but I've always been made uncomfortable by the lack of version
> > information in the glazed list jar names.  I had some awful
>
> There's a version number in all Glazed Lists releases.

I'm looking at your download page(http://tinyurl.com/nason) and don't
see a version number.  Am I missing something?

Charlie

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ANT build and maven bundle

Holger
In reply to this post by Holger
Hey Jesse,

I've extended the ANT build file with the ability to
produce maven upload bundles.
First of all, this is a pure add-on, the existing build file
behaviour is unchanged.

To create a bundle you do for example:

ant -Dversion=1.7.0 maven-bundle

The ANT target 'maven-bundle' does the following:
- it first checks the existence of the property 'version' and fails if it's not defined
- it then creates the contents of the bundle in a temporary directory 'maven_bundle':
 - it creates the source distribution and copies the zip to a jar in the 'maven_bundle' dir
 - it creates the javadocs and creates a jar for it in the 'maven_bundle' dir
 - it creates the main jar and copies it to the 'maven_bundle' dir
 - it copies the pom.xml to the 'maven_bundle' dir and inserts the correct artifactId and version
- then it creates the bundle jar with the contents from the 'maven_bundle' dir
- it deletes the temp dir 'maven_bundle'

So, the above call would create in the 'maven_bundle' dir:
pom.xml
glazedlists_java15-1.7.0.jar
glazedlists_java15-1.7.0-sources.jar
glazedlists_java15-1.7.0-javadoc.jar

and in the base dir:
glazedlists_java15-1.7.0-bundle.jar

This bundle jar should then be uploaded to the central maven repo.
As it must be downloadable via an URL, I would suggest to create
a maven_upload directory in the Documents and Files section on java.net,
where the bundle jars could be placed until they are actually uploaded to
the maven repo.

I have checked in the pom.xml file as required by the upload bundle.
It contains the project description and is pretty much self-explanatory.
The required contents are listed here: http://maven.apache.org/guides/mini/guide-ibiblio-upload.html
I didn't list the optional dependencies mainly because not all of them are
available in the central maven repository.

Please check it out and let me know any problems, corrections or enhancements.

I have not changed the build output directories, yet.
Please let me know, if you want the 'target' directory convention.
I still think it's worthwhile.
I don't expect CVS related problems as generated build artifacts should not be
put under version control anyway.

Hope you like it,
Holger

> On 7/17/06, Holger Brands <[hidden email]> wrote:
> > I would suggest to follow these conventions with Glazed Lists and to change
> > the build artifact names to:
> > glazedlists_java14-1.6.1.jar
> > glazedlists_java14-1.6.1-sources.jar
> > glazedlists_java14-1.6.1-javadoc.jar
>
> When I see '.jar' I usually assume it contains
> .class files and a MANIFEST. I don't think it's
> good to use the .jar extension for sources or docs.
> On most desktops, when you double click a .zip
> file, it lets you extract the data inside, which is
> what we want to do with sources and docs. But
> when you double click a .jar, it tries to execute
> it using java. So I feel strongly that .jar for source
> or docs is a bad pattern. We can support this
> approach for our Maven friends but the rest of our
> users should still get source in a .zip.
>
> We could do this by creating a 'maven' target
> in our ant file that produces the regular .zip
> source file using the existing dist target, then
> tweaks it so that it looks good to Maven users,
> using copy or rename tasks.
>
> > So we would have two upload bundles for Java 1.4 and Java 1.5 with
> > artifactIds glazedlists_java14 and glazedlists_java15, both having version 1.6.1
> > for example.
>
> That's great, I like that.
>
> Does Maven have any special metadata facility
> for build information? I'd imagine that it might
> have a place where we can put build-specific
> information like Target VM, just like how say
> Ubuntu apt-get supports different build architectures
> like x86, PowerPC, Sparc etc.
>
> If not, the names you propose work for me.
>
> > Should the Glazed Lists jars deployed to java.net follow these conventions too,
> > or stick to the old names?
>
> We'll leave the java.net files as-is, and use different
> naming schemes for the Maven repository.
>
> > Version info is currently not in the build file. I think
> > this could be a property, for example
> > 'project.version' you pass on the command line:
> > ant -Dproject.version=1.6.1 jar
> > If you omit the version you would produce a latest build:
> > glazedlists_java14.jar or glazedlists_java15.jar
>
> That's reasonable. If you double click any build
> of a Glazed Lists jar, you get a cute little dialog
> box that tells you build information. I'd like to avoid
> breaking this dialog box but for anything else
> it's fair game.
>
> One thing I'd like to avoid is having a static file
> with build properties. The problem with this is that
> it becomes easier to build multiple .jars with the
> same version. We need to prevent accidentally
> creating multiple builds with the same version, since
> that makes diagnosing problems much harder.
>
> > II) one common build output directory
> > With Maven, all generated artifacts are stored in one output directory named 'target'.
> > So you would have something like:
> > target/classes
> > target/test-classes    <-- new
> > target/reports
> > target/docs
> > target/demojar
> > ...
>
> I don't think this is much better than what we do
> now with our classes and docs/javadoc folders.
> We can use Ant's zip task's basedir attribute to
> move things around as necessary so Maven is
> appeased.
>
> > I think this convention makes sense because it
> > simplifies cleaning the build and CVS handling. You
> > only have to add the 'target' dir to cvsignore.
> > Separating the compiled test classes prevents them
> > from being included into the jar by an oversight.
>
> Except that existing tools (like IDEs) and developers
> expect a ./classes/ folder, not at ./target/test-classes/ dir.
> I like that Maven is introducing all these new conventions,
> but they are 10 years too late since different Java conventions
> are already in place.
>
> As for cvsignore, I haven't used it, and it's never been
> much of a problem.
>
> > What do you think?
>
> One of the biggest things holding me back is not
> your ideas, but the fact that moving things around
> in directories has big negative consequences since
> we're using CVS for our version control. You cannot
> delete directories in CVS. So suppose we moved to
> a target/ folder strategy. Then we'd still have our
> existing classes/ folder, but it would be empty. This
> will really confuse anyone who tries to build our system
> and can't find the expected classes in the classes folder.
>
> Similarly, if we moved source to say source/java, then
> we'd still have our source/ca folder which makes things
> really nasty.
>
> Hopefully java.net comes out with a new version that
> supports Subversion, so we can really refactor our
> directory structure.
>
> I apologize that our directory layout isn't ideal, it's
> grown organically and we have avoided moving things
> around for CVS' sake. I really appreciate your effort
> on this Holger. Let me know how it goes, and if you'd
> like to point out the errors in my arguments I can be
> persuaded!
>
> Cheers,
> Jesse
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


______________________________________________________________________
XXL-Speicher, PC-Virenschutz, Spartarife & mehr: Nur im WEB.DE Club!
Jetzt gratis testen! http://freemail.web.de/home/landingpad/?mc=021130

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: ANT build and maven bundle

Holger
In reply to this post by Holger
Hey Charlie,

>
> > > Maybe it's just because I'm too inured to the maven way of thinking,
> > > but I've always been made uncomfortable by the lack of version
> > > information in the glazed list jar names.  I had some awful
> >
> > There's a version number in all Glazed Lists releases.
>
> I'm looking at your download page(http://tinyurl.com/nason) and don't
> see a version number.  Am I missing something?

That's the directory for the latest builds, snapshots from CVS head.

Here is the latest official release with version numbers:
https://glazedlists.dev.java.net/servlets/ProjectDocumentList?folderID=5473&expandFolder=5473&folderID=3916

Holger

_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000071

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ANT build and maven bundle

James Lemieux
In reply to this post by Holger
Holger,

   I think a "maven-bundle" target is ideal. Piggy-backing all prior ant work and simply shuffling jars around / making a bundle jar is ideal. The process of sending that bundle jar to the maven repository should be left as a manual process, which I think we're all in agreement for.

   One thing that would probably make Maven burst into flames is our "java14" ant target in which we actually run all of our source code through "declawer", a customized form of javac, which lowers the source code from java15 syntax to java14 syntax and dumps it all in a subfolder of the main build. The build.xml then actually modifies a copy of ITSELF (by setting different values in for some env. variables) located in that subfolder to make it appropriate for java14 builds. In this way our build system is actually *recursive*. Since maven supports custom tasks, to my knowledge, it would be possible to do this, but would require some heavy lifting.

   For the record, since \classes is NOT in CVS, I have NO problems supporting the \target idea to make maven configuration a little more standard. Of course IDEA supports separate source and test target directories...

   Also for the record, I'm not a fan of version numbers in the jar name for the reason stated by Jesse: classpaths must change when inserting new jar versions. I acknowledge Charlie's irritation that you can't tell the version number at a glance, but on that judgement call I error on the side of easier "jar replacement."

   As for hosting the maven bundle on glazedlists.dev.java.net until it "makes its way into the maven repository"... meh... I'm less excited by that. I'd hope it doesn't take more than 24 hours to become available through the normal Maven channels, so I'd rather just let it happen organically. If people really want the latest build, let them get it by hand through our system or via our website.

I was assuming just    For the record, are we considering that only release builds will go to the maven repo, or you guys thinking that even nightly / snapshot builds will be uploaded to the maven repo? releases, but thought I'd ask.

James

On 7/18/06, Holger Brands <[hidden email]> wrote:
Hey Jesse,

I've extended the ANT build file with the ability to
produce maven upload bundles.
First of all, this is a pure add-on, the existing build file
behaviour is unchanged.

To create a bundle you do for example:

ant -Dversion=1.7.0 maven-bundle

The ANT target 'maven-bundle' does the following:
- it first checks the existence of the property 'version' and fails if it's not defined
- it then creates the contents of the bundle in a temporary directory 'maven_bundle':
- it creates the source distribution and copies the zip to a jar in the 'maven_bundle' dir
- it creates the javadocs and creates a jar for it in the 'maven_bundle' dir
- it creates the main jar and copies it to the 'maven_bundle' dir
- it copies the pom.xml to the 'maven_bundle' dir and inserts the correct artifactId and version
- then it creates the bundle jar with the contents from the 'maven_bundle' dir
- it deletes the temp dir 'maven_bundle'

So, the above call would create in the 'maven_bundle' dir:
pom.xml
glazedlists_java15-1.7.0.jar
glazedlists_java15-1.7.0-sources.jar
glazedlists_java15-1.7.0-javadoc.jar

and in the base dir:
glazedlists_java15-1.7.0-bundle.jar

This bundle jar should then be uploaded to the central maven repo.
As it must be downloadable via an URL, I would suggest to create
a maven_upload directory in the Documents and Files section on java.net,
where the bundle jars could be placed until they are actually uploaded to
the maven repo.

I have checked in the pom.xml file as required by the upload bundle.
It contains the project description and is pretty much self-explanatory.
The required contents are listed here: http://maven.apache.org/guides/mini/guide-ibiblio-upload.html
I didn't list the optional dependencies mainly because not all of them are
available in the central maven repository.

Please check it out and let me know any problems, corrections or enhancements.

I have not changed the build output directories, yet.
Please let me know, if you want the 'target' directory convention.
I still think it's worthwhile.
I don't expect CVS related problems as generated build artifacts should not be
put under version control anyway.

Hope you like it,
Holger

> On 7/17/06, Holger Brands < [hidden email]> wrote:
> > I would suggest to follow these conventions with Glazed Lists and to change
> > the build artifact names to:
> > glazedlists_java14- 1.6.1.jar
> > glazedlists_java14-1.6.1-sources.jar
> > glazedlists_java14-1.6.1-javadoc.jar
>
> When I see '.jar' I usually assume it contains
> .class files and a MANIFEST. I don't think it's
> good to use the .jar extension for sources or docs.
> On most desktops, when you double click a .zip
> file, it lets you extract the data inside, which is
> what we want to do with sources and docs. But
> when you double click a .jar, it tries to execute
> it using java. So I feel strongly that .jar for source
> or docs is a bad pattern. We can support this
> approach for our Maven friends but the rest of our
> users should still get source in a .zip.
>
> We could do this by creating a 'maven' target
> in our ant file that produces the regular .zip
> source file using the existing dist target, then
> tweaks it so that it looks good to Maven users,
> using copy or rename tasks.
>
> > So we would have two upload bundles for Java 1.4 and Java 1.5 with
> > artifactIds glazedlists_java14 and glazedlists_java15, both having version 1.6.1
> > for example.
>
> That's great, I like that.
>
> Does Maven have any special metadata facility
> for build information? I'd imagine that it might
> have a place where we can put build-specific
> information like Target VM, just like how say
> Ubuntu apt-get supports different build architectures
> like x86, PowerPC, Sparc etc.
>
> If not, the names you propose work for me.
>
> > Should the Glazed Lists jars deployed to java.net follow these conventions too,
> > or stick to the old names?
>
> We'll leave the java.net files as-is, and use different
> naming schemes for the Maven repository.
>
> > Version info is currently not in the build file. I think
> > this could be a property, for example
> > 'project.version' you pass on the command line:
> > ant -Dproject.version=1.6.1 jar
> > If you omit the version you would produce a latest build:
> > glazedlists_java14.jar or glazedlists_java15.jar
>
> That's reasonable. If you double click any build
> of a Glazed Lists jar, you get a cute little dialog
> box that tells you build information. I'd like to avoid
> breaking this dialog box but for anything else
> it's fair game.
>
> One thing I'd like to avoid is having a static file
> with build properties. The problem with this is that
> it becomes easier to build multiple .jars with the
> same version. We need to prevent accidentally
> creating multiple builds with the same version, since
> that makes diagnosing problems much harder.
>
> > II) one common build output directory
> > With Maven, all generated artifacts are stored in one output directory named 'target'.
> > So you would have something like:
> > target/classes
> > target/test-classes    <-- new
> > target/reports
> > target/docs
> > target/demojar
> > ...
>

> I don't think this is much better than what we do
> now with our classes and docs/javadoc folders.
> We can use Ant's zip task's basedir attribute to
> move things around as necessary so Maven is
> appeased.
>
> > I think this convention makes sense because it
> > simplifies cleaning the build and CVS handling. You
> > only have to add the 'target' dir to cvsignore.
> > Separating the compiled test classes prevents them
> > from being included into the jar by an oversight.
>
> Except that existing tools (like IDEs) and developers
> expect a ./classes/ folder, not at ./target/test-classes/ dir.
> I like that Maven is introducing all these new conventions,
> but they are 10 years too late since different Java conventions
> are already in place.
>
> As for cvsignore, I haven't used it, and it's never been
> much of a problem.
>
> > What do you think?
>
> One of the biggest things holding me back is not
> your ideas, but the fact that moving things around
> in directories has big negative consequences since
> we're using CVS for our version control. You cannot
> delete directories in CVS. So suppose we moved to
> a target/ folder strategy. Then we'd still have our
> existing classes/ folder, but it would be empty. This
> will really confuse anyone who tries to build our system
> and can't find the expected classes in the classes folder.
>
> Similarly, if we moved source to say source/java, then
> we'd still have our source/ca folder which makes things
> really nasty.
>
> Hopefully java.net comes out with a new version that
> supports Subversion, so we can really refactor our
> directory structure.
>
> I apologize that our directory layout isn't ideal, it's
> grown organically and we have avoided moving things
> around for CVS' sake. I really appreciate your effort
> on this Holger. Let me know how it goes, and if you'd
> like to point out the errors in my arguments I can be
> persuaded!
>
> Cheers,
> Jesse
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


______________________________________________________________________
XXL-Speicher, PC-Virenschutz, Spartarife & mehr: Nur im WEB.DE Club!
Jetzt gratis testen! http://freemail.web.de/home/landingpad/?mc=021130

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Re: ANT build and maven bundle

Charlie Groves
In reply to this post by Holger
On 7/18/06, Holger Brands <[hidden email]> wrote:
>
> Here is the latest official release with version numbers:
> https://glazedlists.dev.java.net/servlets/ProjectDocumentList?folderID=5473&expandFolder=5473&folderID=3916
>

This makes a great case for an official maven jar being created so
it'll save people like me who can't  be bothered to read the links
they're clicking from downloading a nightly build and renaming it to
'glazedlists-1.6' and uploading it for everyone else on the team to
use.

Charlie

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ANT build and maven bundle

Holger
In reply to this post by Holger
Hi James,

see my comments inline.

> Holger,
>
>    I think a "maven-bundle" target is ideal. Piggy-backing all prior ant work and simply shuffling jars around / making a bundle jar is ideal. The process of sending that bundle jar to the maven repository should be left as a manual process, which I think we're all in agreement for.

Actually, you're not allowed to upload the maven bundle to the central maven repository yourself.
Please see
http://maven.apache.org/guides/mini/guide-ibiblio-upload.html
for a howto.
After creating an upload bundle you file a JIRA issue with the upload request.
It contains an URL where the upload bundle can be found and downloaded.
If the JIRA request is accepted by the "central maven repo managers", they will download the bundle from the
supplied URL and deploy it to the repo.

Here comes the 'maven_upload' directory in the Documents and file section on glazedlists.dev.java.net
into play. It's a location where we could place a new upload bundle and provide its URL in the
JIRA upload request. When the maven repo managers have downloaded the bundle and deployed it to
the central maven repository, they'll close the JIRA issue.
Then you'll know that the deployment is complete and you couild remove the uploaded bundle from the
Documents and file section again.

So the 'maven_upload' directory is only meant to provide a stable URL for the upload requests.
If you or Jesse favour another URL for the upload bundles, please let us know.

>
>
>    One thing that would probably make Maven burst into flames is our "java14" ant target in which we actually run all of our source code through "declawer", a customized form of javac, which lowers the source code from java15 syntax to java14 syntax and dumps it all in a subfolder of the main build. The build.xml then actually modifies a copy of ITSELF (by setting different values in for some env. variables) located in that subfolder to make it appropriate for java14 builds. In this way our build system is actually *recursive*. Since maven supports custom tasks, to my knowledge, it would be possible to do this, but would require some heavy lifting.
>

Maven 2 supports the notion of profiles. You could define a profile for java 1.4 builds and one for java 1.5 builds.
You can enable a profile for example by setting a specific property.
The profile would contain the special configuration and instructions for the particular build requirements.
For example, the profile for java 1.5 would configure the compiler plugin to compile with source and target version 1.5.
The profile for java 1.4 would configure the compiler plugin to compile with source and target version 1.4.
In addition, it would trigger the Declawer tool to convert the source files.

The integration of the Declawer tool could be done with
- calling a target with the antrun plugin
or
- writing a maven 2 plugin for the Declawer functionality

BTW, an introduction to Maven 2 can be downloaded for free here
http://www.mergere.com/m2book_download.jsp
(after registering)

>
>    For the record, since \classes is NOT in CVS, I have NO problems supporting the \target idea to make maven configuration a little more standard. Of course IDEA supports separate source and test target directories...
>

Jesse, you have the last word on this one ;-)

>
>    Also for the record, I'm not a fan of version numbers in the jar name for the reason stated by Jesse: classpaths must change when inserting new jar versions. I acknowledge Charlie's irritation that you can't tell the version number at a glance, but on that judgement call I error on the side of easier "jar replacement."

As Jesse already pointed out, official Glazed Lists releases have a version number in the jar name.
I have no problems, if the latest build jars have *no* version information in the jar name.

>
>
>    As for hosting the maven bundle on glazedlists.dev.java.net until it "makes its way into the maven repository"... meh... I'm less excited by that. I'd hope it doesn't take more than 24 hours to become available through the normal Maven channels, so I'd rather just let it happen organically. If people really want the latest build, let them get it by hand through our system or via our website.
>

See my comments above. There must be some URL where the bundle jar can be dowloaded by the mystical central maven repo managers.

>
>  I was assuming just    For the record, are we considering that only release builds will go to the maven repo, or you guys thinking that even nightly / snapshot builds will be uploaded to the maven repo? releases, but thought I'd ask.

The central maven repo is hosted at www.ibiblio.org/maven2/ and contains only official releases as far as I know.
I think it'll suffice to provide maven upload bundles only for official Glazed Lists releases.

Holger

_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000071

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: ANT build and maven bundle

Holger
In reply to this post by Holger
Charlie,

> On 7/18/06, Holger Brands <[hidden email]> wrote:
> >
> > Here is the latest official release with version numbers:
> > https://glazedlists.dev.java.net/servlets/ProjectDocumentList?folderID=5473&expandFolder=5473&folderID=3916
> >
>
> This makes a great case for an official maven jar being created so
> it'll save people like me who can't  be bothered to read the links
> they're clicking from downloading a nightly build and renaming it to
> 'glazedlists-1.6' and uploading it for everyone else on the team to
> use.
>

That's what I have in mind:
to create a minimal upload bundle for the last official release 1.6.1.

If Jesse and James agree, I would take the Glazed Lists java 1.5 jar
from the Documents and file section on glazedlists.dev.java.net,
rename it to glazedlists_java15-1.6.1.jar and bundle it with the pom.xml
to form the final bundle jar.
This would then be the target for the upload request in the maven JIRA for
version 1.6.1.

Please let us know, if someone needs the java 1.4 version of
Glazed Lists 1.6.1 in the maven repo, too.

Further official releases of Glazed Lists will use the new 'maven-bundle'
target to create complete bundles including sources and javadocs.

Holger

_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000071

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: ANT build and maven bundle

Jesse Wilson
Hey Holger ---

maven_upload/ folder in our documents & files area? sure.
We'll probably want either a maven/ folder in the root
or one in each release version folder.

A target/ folder to put compiled files? sure.

Java 1.4 as a maven profile? sure. I suspect that most Maven users
are on Java 1.5, so this might not be necessary. Of all
the Maven projects on ibiblio, what percentage are Java 5 only?
If it's a strong majority, we can be Java 5 only too.

Releasing 1.6.1 into ibiblio? Sure. 1.6.1 is identical to 1.6
except it contains the JXTable sorting support class.
Remember to build this from the source .zip, not the
CVS code!

It all sounds good to me Holger & Charles.

Cheers,
Jesse



On 7/19/06, Holger Brands <[hidden email]> wrote:

> Charlie,
>
> > On 7/18/06, Holger Brands <[hidden email]> wrote:
> > >
> > > Here is the latest official release with version numbers:
> > > https://glazedlists.dev.java.net/servlets/ProjectDocumentList?folderID=5473&expandFolder=5473&folderID=3916
> > >
> >
> > This makes a great case for an official maven jar being created so
> > it'll save people like me who can't  be bothered to read the links
> > they're clicking from downloading a nightly build and renaming it to
> > 'glazedlists-1.6' and uploading it for everyone else on the team to
> > use.
> >
>
> That's what I have in mind:
> to create a minimal upload bundle for the last official release 1.6.1.
>
> If Jesse and James agree, I would take the Glazed Lists java 1.5 jar
> from the Documents and file section on glazedlists.dev.java.net,
> rename it to glazedlists_java15-1.6.1.jar and bundle it with the pom.xml
> to form the final bundle jar.
> This would then be the target for the upload request in the maven JIRA for
> version 1.6.1.
>
> Please let us know, if someone needs the java 1.4 version of
> Glazed Lists 1.6.1 in the maven repo, too.
>
> Further official releases of Glazed Lists will use the new 'maven-bundle'
> target to create complete bundles including sources and javadocs.
>
> Holger
>
> _____________________________________________________________________
> Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> http://smartsurfer.web.de/?mc=100071&distributionid=000000000071
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: ANT build and maven bundle

Holger
In reply to this post by Holger
Hey Jesse,

> Hey Holger ---
>
> maven_upload/ folder in our documents & files area? sure.
> We'll probably want either a maven/ folder in the root
> or one in each release version folder.

If we decide to keep the bundle jars after deploying them to the
central maven repo, then I would opt for one in each release version
folder.
If we decide to remove them after successful deployment
then I would create a maven_upload folder in the root just like
the latest_build directory.
The latter has the additional advantage to have a stable base URL
and is probably less confusing for non-maven users who download
Glazed Lists from glazedlists.dev.java.net manually.
So I tend to the second option.

>
> A target/ folder to put compiled files? sure.

Ok, I'll send a separate mail, if this is done. I guess you mean all
generated build artifacts including japex reports and javadocs for example,
as I suggested in a previous mail?

>
> Java 1.4 as a maven profile? sure. I suspect that most Maven users
> are on Java 1.5, so this might not be necessary. Of all
> the Maven projects on ibiblio, what percentage are Java 5 only?
> If it's a strong majority, we can be Java 5 only too.

This would only be relevant if we choose to switch to Maven 2 in the future.
I think we would have to plan this carefully.
The best point in time to switch would be, when we have the chance to
reorganize the project structure, for example when changing to SVN or the like.

If you intend to switch to maven earlier, we can further discuss possible approaches.

>
> Releasing 1.6.1 into ibiblio? Sure. 1.6.1 is identical to 1.6
> except it contains the JXTable sorting support class.
> Remember to build this from the source .zip, not the
> CVS code!

I intend to take the jar directly from the Glazed List download folder, so I
am 100% certain to deploy the same contents to ibiblio.

If you have some time, please have a look at the pom.xml
in CVS and let me know if it's ok for you.
If you agree, I'll file the maven upload request for 1.6.1 ...

Thanks,
Holger

______________________________________________________________________
XXL-Speicher, PC-Virenschutz, Spartarife & mehr: Nur im WEB.DE Club!
Jetzt gratis testen! http://freemail.web.de/home/landingpad/?mc=021130

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: Re: ANT build and maven bundle

Jesse Wilson
On 7/19/06, Holger Brands <[hidden email]> wrote:
> The latter has the additional advantage to have a stable base URL
> and is probably less confusing for non-maven users who download
> Glazed Lists from glazedlists.dev.java.net manually.
> So I tend to the second option.

We'll use a maven_upload/ folder, and files there
will be periodically cleaned out after they've been
picked up by the ibiblio guys.

> > A target/ folder to put compiled files? sure.
> Ok, I'll send a separate mail, if this is done. I guess you mean all
> generated build artifacts including japex reports and javadocs for example,
> as I suggested in a previous mail?
Yup. Sounds great. target/ for everything: Javadocs, japex
classes etcetera etcetera.

> > Java 1.4 as a maven profile? sure. I suspect that most Maven users
> This would only be relevant if we choose to switch to Maven 2 in the future.
> I think we would have to plan this carefully.

We won't need to switch to Maven for a while, probably not at least
until it's really really stable. So we can keep the Java 1.4 support,
it costs us nearly nothing to provide.

> If you have some time, please have a look at the pom.xml
> in CVS and let me know if it's ok for you.
Loogs good to me. I added my email and timezone.
My email address is public, I'm sure for most of us
that won't be the case.

Looks good Holger. I'm really liking having you on the team!

Cheers,
Jesse

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]