On Sun, Aug 29, 2010 at 7:24 AM, Jacob Beard <jbea...@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<jbea...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
