commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <>
Subject Re: [scxml-js] working toward a release
Date Wed, 25 Aug 2010 05:41:17 GMT
On Wed, Aug 25, 2010 at 12:24 AM, Jacob Beard <> 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
> <>, seems to talk
> about releases components /for/ Maven, as opposed to those that simply use
> Maven as the build system.

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

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.

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



> 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message