On Sun, Aug 29, 2010 at 3:55 PM, Jacob Beard <jbea...@cs.mcgill.ca> wrote: > On 10-08-29 07:51 PM, Rahul Akolkar wrote: >> 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. >> > > Well, at the moment it is possible to build the release JAR with Maven and > AntRun. > > I was most recently investigating how to use Ant to download dependencies > that do not have a Maven repo, as is the case for several of the JavaScript > libraries I'm using; and how to integrate the unit testing targets that > currently exist in the [scxml-js] Ant build into the Maven build. This last > task was where I really felt I was seeing the limits of the possible > integration between Maven and Ant, and unfortunately, I didn't feel I could > ask about it on the Maven list. But if running all unit tests using Maven is > not a strict requirement (they would still be runnable by directly calling > Ant), then it sounds like the best approach would be to continue using Maven > and AntRun. This means that Maven will be used for some things, and Ant for > other things, but Maven would still be used for (a) and (b), which seems to > be the most critical. > > I'll put aside my investigations into integrating the unit tests, and > instead focus on getting the Maven assembly phase to work, as it sounds like > this is more important. > <snip/>
Sounds reasonable to me. Things other than (a) and (b) can continue to be documented here [1] (while those two follow the Commons m2 recipe). -Rahul [1] http://commons.apache.org/sandbox/gsoc/2010/scxml-js/guide.html > Let me know how this sounds. Thanks, > > Jake > >> -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
