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 22:13:50 GMT
On 25 August 2010 22:23, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
> 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.

Maybe also add the dependencies to the POM as "provided"?

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

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


Mime
View raw message