On Sun, Aug 29, 2010 at 12:02 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > Rahul Akolkar 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 > > Sorry to come into this late; but it is important to note that (b) > *is* the release. We do (a) as a convenience for users and it is > not IMO a *required* release step; <snip/>
Indeed, I mention things along those lines below, good to clarify upfront. > nor is it strictly required that > Commons components use Maven as their build tool. <snap/> Sure, but the chances of me fully supporting (i.e. +1'ing) a sandbox promotion increase when "mvn install" (with a profile or two thrown in) produces the distros and any Maven repo artifacts without much other work. Similarly, any component-specific build or release process reduces those chances. -Rahul > The only thing > that is really required is a maven-generated site. > > Phil >> >> 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 >> > > > --------------------------------------------------------------------- > 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
