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