commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [scxml-js] working toward a release
Date Wed, 25 Aug 2010 21:31:30 GMT
On 25 August 2010 06:41, Rahul Akolkar <> wrote:
> 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.
> <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).

And if you want to test what deploy does:

mvn deploy -Ptest-deploy -Prelease -Dgpg.skip

This will deploy the files to target/deploy

Make sure the pom is using commons parent v17 first.

> -Rahul
> [1]
> [2]
>> 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:
> For additional commands, e-mail:

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

View raw message