commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [scxml-js] working toward a release
Date Sun, 29 Aug 2010 16:02:31 GMT
Rahul Akolkar 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

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; nor is it strictly required that
Commons components use Maven as their build tool. 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-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