commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <rahul.akol...@gmail.com>
Subject Re: [scxml-js] working toward a release
Date Wed, 25 Aug 2010 21:23:43 GMT
On Wed, Aug 25, 2010 at 4:51 PM, Jacob Beard <jbeard4@cs.mcgill.ca> wrote:
> Hi,
>
> I've completed initial integration of Maven with the Ant build script.
> Maven's compile phase now builds the combined js file and the single class
> file. The package phase is then able to successfully create an executable
> jar.
>
<snip/>

Cool.


> My next question is, is it important to phase out getDeps.xml, the ant
> script that downloads required JavaScript and Java libraries for the
> project, in favor of a Maven solution?
>
> Many of the required libraries downloaded in getDeps.xml do not have a maven
> repository, but at the same time, many do, including commons-cli and xalan.
> These could perhaps be downloaded by Maven. Is a hybrid solution the best
> approach?
>
<snap/>

I'd say so, there is value to having the Java deps listed in the pom
rather than elsewhere, so they get taken care of as part of the
Maven's management of dependencies. The binaries distros in Commons
don't actually contain dependency jars so there is no need to download
(beyond being in the m2 local repo) or copy them into distros.

Seems like the JavaScript deps that aren't in the repo will
necessitate the hybrid approach. One way would be to fetch these
during another antrun execution tied to one of the earlier phases.

-Rahul



> Let me know what you think. Thanks,
>
> Jake
>
> On 10-08-25 01:41 AM, 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
>>
>> 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


Mime
View raw message