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 Sun, 29 Aug 2010 17:43:21 GMT
On Sun, Aug 29, 2010 at 7:24 AM, Jacob Beard <jbeard4@cs.mcgill.ca> 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.
<snip/>

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.
>
<snap/>

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

-Rahul

* - 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<jbeard4@cs.mcgill.ca>  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
>>> <http://maven.apache.org/ant-tasks/index.html>  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
>>
<snip/>

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


Mime
View raw message