Return-Path: Delivered-To: apmail-commons-dev-archive@www.apache.org Received: (qmail 23357 invoked from network); 29 Aug 2010 11:25:48 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 29 Aug 2010 11:25:48 -0000 Received: (qmail 92327 invoked by uid 500); 29 Aug 2010 11:25:48 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 91276 invoked by uid 500); 29 Aug 2010 11:25:44 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 91264 invoked by uid 99); 29 Aug 2010 11:25:43 -0000 Received: from Unknown (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 29 Aug 2010 11:25:43 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jbeard4@cs.mcgill.ca designates 132.206.51.234 as permitted sender) Received: from [132.206.51.234] (HELO mail.cs.mcgill.ca) (132.206.51.234) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 29 Aug 2010 11:25:18 +0000 Received: from [10.59.1.32] (tru75-2-82-67-205-224.fbx.proxad.net [82.67.205.224]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.mcgill.ca (Postfix) with ESMTP id 02246BF90B8 for ; Sun, 29 Aug 2010 07:24:56 -0400 (EDT) Message-ID: <4C7A4387.5080305@cs.mcgill.ca> Date: Sun, 29 Aug 2010 07:24:55 -0400 From: Jacob Beard User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Commons Developers List Subject: Re: [scxml-js] working toward a release References: <4C732B11.9010400@cs.mcgill.ca> <4C73E795.3000705@cs.mcgill.ca> <4C749B07.6010901@cs.mcgill.ca> <4C75823C.4020901@cs.mcgill.ca>

<4C76D3FE.4010905@cs.mcgill.ca> <4C780DA9.1080803@cs.mcgill.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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. 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. 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. / >> >> > > > 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? >> >> > > > 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. >> >> > > > 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 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. >>>> >>>> >>>> >>> >>> >>> 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 wrote: >>>>> >>>>> >>>>> >>>>>> On 25 August 2010 22:23, Rahul Akolkar >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On Wed, Aug 25, 2010 at 4:51 PM, Jacob Beard >>>>>>> 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. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> 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? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> 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"? >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> 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-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