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). -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
