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 > Let me know what you think. Thanks, > > Jake > > On 10-08-26 05:24 PM, Rahul Akolkar wrote: >> >> On Thu, Aug 26, 2010 at 4:52 PM, Jacob Beard<jbea...@cs.mcgill.ca> wrote: >> >>> >>> Hi, >>> >>> I've brought up a question on the maven list which I was wondering if >>> others >>> could weigh on. Basically, the question is what is the best way to deal >>> with >>> JavaScript library dependencies for which no Maven repository exists. One >>> person has encouraged me to set up a Maven repository on my personal >>> server >>> using Apache Archiva, and provide these libraries there, then simply link >>> to >>> them as dependencies in the main project pom.xml. Another person has said >>> that I can simply call AntRun from an early phase to download these >>> dependencies using my current Ant script. >>> >>> >> >> <snip/> >> >> The latter will work better. The former sets you up to do an undue >> amount of work, serve as a point of distribution as well as failure >> and relies on adding a reference to the repo you host into the project >> pom -- downsides galore. >> >> I will make some general comments about feedback from Maven lists in >> this context: >> >> * While figuring out how the Maven central repo (or some other) >> should host popular JavaScript libraries of the day is a good goal in >> itself, for the purpose of the [scxml-js] build that is not the >> problem we are trying to solve for everyone else. >> * More generally, the lists are understandably drunk on Maven >> cool-aid (very well-intended too, no doubt) to the point where the >> pragmatic view of getting the [scxml-js] build set up using the >> Commons release infrastructure could get lost in the theoretical >> arguments of the Maven way. >> * Many of the proposed solutions will make more sense for work type >> settings (such as setting up a maven repo manager etc.) but are not >> very applicable to Apache Commons components. >> >> After talking to Maven lists, its best to make final Maven-related >> decisions on the Commons list as with this thread. So thanks for >> asking here. >> >> -Rahul >> >> >> >>> >>> I'd appreciate hearing others' opinions on this. Thanks, >>> >>> Jake >>> >>> On 10-08-25 06:58 PM, Rahul Akolkar wrote: >>> >>>> >>>> On Wed, Aug 25, 2010 at 6:13 PM, sebb<seb...@gmail.com> wrote: >>>> >>>> >>>>> >>>>> On 25 August 2010 22:23, Rahul Akolkar<rahul.akol...@gmail.com> >>>>> wrote: >>>>> >>>>> >>>>>> >>>>>> On Wed, Aug 25, 2010 at 4:51 PM, Jacob Beard<jbea...@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"? >>>>> >>>>> >>>>> >>>> >>>> <snip/> >>>> >>>> If you're talking about the JS deps, no. These aren't on central (and >>>> don't have their own repos either). >>>> >>>> -Rahul >>>> >>>> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
