commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <>
Subject Re: [scxml-js] working toward a release
Date Sun, 29 Aug 2010 17:43:21 GMT
On Sun, Aug 29, 2010 at 7:24 AM, Jacob Beard <> wrote:
> Hi,
> I've checked in.
> I'm in Paris now for the SVG Open conference, so I'm probably not going to
> have time to work on this for the next week.

Have fun at the paper presentation (and elsewhere too :-).

> After that, I think I'll change
> tactics, and start investigating how to do this the "Maven way", probably
> writing a set of custom plugins rather than delegating to Ant.

Obviously, you are welcome to investigate. I will note that the Maven
way may actually not be a good way to proceed here. Firstly, a set of
custom plugins will require they have a release first (we can't depend
on unreleased plugins) and introduces more dependencies for [scxml-js]
releases. Secondly, I don't think we want to host component-specific
Maven plugins (*) at Commons. I also don't think we want to host
generic utility Maven plugins here, so say you came up with a plugin
that handles some JavaScript dependency foo, that probably needs
hosting elsewhere (messier to coordinate).


* - we have a commons-build plugin, but that is very Commons specific
and applies across all components

> Jake
> On 10-08-27 04:47 PM, Rahul Akolkar wrote:
>> On Fri, Aug 27, 2010 at 3:10 PM, Jacob Beard<>  wrote:
>>> Hi Rahul,
>>> There's another thread on the Maven list which could use your attention.
>>> See
>>> subject "question on capabilities of AntRun plugin".
>>> Basically, it seems several people on the Maven list are of the opinion
>>> that, in general, it's very bad to delegate to AntRun. One of the last
>>> comments that was made was this:
>>> /If you can actually assert that your project is totally unlike a
>>> "normal"
>>> application, you probably should stick with Ant. /
>> <snip/>
>> May be true in isolation, but as a Commons component doing so might
>> increase the liability factor as you rightly put it below.
>>> I'm  now wondering if this might actually be good advice. Rather than
>>> using
>>> Maven and the AntRun plugin to hook into Ant, it might instead be better
>>> to
>>> use Ant and the Maven Ant Tasks
>>> <>  to hook into Maven.
>>> Specifically, the Maven Ant Tasks would facilitate dependency management,
>>> artifact deployment, and POM processing. If this were able to provide
>>> reasonable integration with the Commons parent pom.xml, then this might
>>> be
>>> something to consider. Are you aware of any Commons projects that do
>>> this?
>> <snap/>
>> No, I don't think any component uses the Maven Ant tasks.
>>> My main concern is to bring the build system into a state where it will
>>> not
>>> be a liability when I propose a vote to promote scxml-js. If using Ant
>>> and
>>> the Maven Ant Tasks is likely to be a liability, then I should probably
>>> stick with Maven and AntRun. But it may be difficult to move forward with
>>> Maven in a significant way, as it seems like it will be difficult to get
>>> support for AntRun on the Maven list.
>> <snip/>
>> Right, ideal scenario is where the build and release mechanics of
>> [scxml-js] are no different than other Commons Proper components
>> (which use Maven2 for build+release tasks). By necessity, Commons is
>> more focused on standardizing how components are built, sites are
>> deployed, releases are cut etc. Having said that, if there are
>> technical reasons why the ant run plugin won't work for [scxml-js],
>> then lets make those reasons clear, confirm they can't be fixed (or
>> fixed without much effort) and explore other avenues. Do you have
>> changes to the pom to get closer to the goal of using m2 for
>> build+release (incomplete as they may be)? If so, can you commit it?
>> That way the rest of us can take a look -- I don't think I'll have
>> time immediately for this, but I will take a look when I can.
>> -Rahul

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

View raw message