On 25 August 2010 22:23, Rahul Akolkar <rahul.akol...@gmail.com> wrote: > On Wed, Aug 25, 2010 at 4:51 PM, Jacob Beard <jbea...@cs.mcgill.ca> wrote: >> Hi, >> >> I've completed initial integration of Maven with the Ant build script. >> Maven's compile phase now builds the combined js file and the single class >> file. The package phase is then able to successfully create an executable >> jar. >> > <snip/> > > Cool. > > >> My next question is, is it important to phase out getDeps.xml, the ant >> script that downloads required JavaScript and Java libraries for the >> project, in favor of a Maven solution? >> >> Many of the required libraries downloaded in getDeps.xml do not have a maven >> repository, but at the same time, many do, including commons-cli and xalan. >> These could perhaps be downloaded by Maven. Is a hybrid solution the best >> approach? >> > <snap/> > > I'd say so, there is value to having the Java deps listed in the pom > rather than elsewhere, so they get taken care of as part of the > Maven's management of dependencies. The binaries distros in Commons > don't actually contain dependency jars so there is no need to download > (beyond being in the m2 local repo) or copy them into distros. > > Seems like the JavaScript deps that aren't in the repo will > necessitate the hybrid approach. One way would be to fetch these > during another antrun execution tied to one of the earlier phases.
Maybe also add the dependencies to the POM as "provided"? > -Rahul > > > >> Let me know what you think. Thanks, >> >> Jake >> >> On 10-08-25 01:41 AM, 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 >>> >>> 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
