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