commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
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 <rahul.akolkar@gmail.com> wrote:
> On Wed, Aug 25, 2010 at 12:24 AM, Jacob Beard <jbeard4@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).

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] 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message