On 25 August 2010 06:41, Rahul Akolkar <rahul.akol...@gmail.com> wrote: > On Wed, Aug 25, 2010 at 12:24 AM, Jacob Beard <jbea...@cs.mcgill.ca> wrote: >> Hi, >> >> I have a Maven question which seems appropriate for this list. >> >> I'm having some trouble understanding how precisely Maven is used in the >> release process. I think CreatingReleases doesn't really describe it, except >> in the bottom section "Procedure for creating a release using M2 (outdated >> by above)". The article it links to, Releasing A Maven Project >> <http://maven.apache.org/developers/release/releasing.html>, seems to talk >> about releases components /for/ Maven, as opposed to those that simply use >> Maven as the build system. >> > <snip/> > > Releasing at Commons is geared towards achieving two aspects: > (a) adding the necessary jar(s) to the maven central repository > (b) adding the source and binary distros to all the Apache mirrors > > Maven helps in generating the above artifacts while taking care of > most details needed to make the artifacts release-worthy. > > Part of the Maven setup at Commons (the bits captured in the parent > pom) is towards making (a) a lot easier (it does things like building > additional source and javadoc jars, adding good jar manifests etc.) -- > this will help with building the [scxml-js] jar. So of the two > [scxml-js] release artifacts, the jar can be mostly covered by Maven > setup in place for other components. > > For alpha/beta releases, sometimes (a) may be skipped. We may want to > do this (skip) for the first [scxml-js] release (if and when it is > promoted out of sandbox). > > We achieve (b) using Maven assemblies [1]. Maven will help with > creating checksums and signatures that are needed for the distros (and > would otherwise have to be done by hand). (b) is never optional. > > >> Basically, I think the first subtask involved in setting up a a Maven build >> for my project is to determine what are the precise tasks and goals that are >> called in the Maven build in the release lifecycle (I'm attempting to use >> Maven terminology here; if I'm getting this wrong, please correct me). >> > <snip/> > > If the standard directory layout is used for any Java code and jar > resources, generating the jar release artifact won't need any more > prodding (as indicated above, the commons-parent pom will do most of > the work). > > >> The next subtask would then be to delegate these Maven goals, where needed, >> to the ant build script. This may involve overriding Maven's default >> behaviour. >> > <snap/> > > The minimized JavaScript artifact will likely need ant scripting to > produce. Look at the maven antrun plugin [1] for details on this > (potentially tied to the package phase). > > If you haven't tried this yet, to see what Maven does in terms of > producing artifacts for potential release, run something like 'mvn > -Prc install' in Commons SCXML trunk as an example of what artifacts > gets generated (they will be added to the local ~/.m2 repo).
And if you want to test what deploy does: mvn deploy -Ptest-deploy -Prelease -Dgpg.skip This will deploy the files to target/deploy Make sure the pom is using commons parent v17 first. > -Rahul > > [1] http://maven.apache.org/plugins/maven-assembly-plugin/ > [2] http://maven.apache.org/plugins/maven-antrun-plugin/ > > > > >> The second subtask is one that I will ask about on the Maven mailing list, >> but the first subtask (what tasks and goals are called in a Commons release >> lifecycle) is better for this list. >> >> Let me know what you think about this. Thanks, >> >> Jake >> > <snip/> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
