commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Beard <jbea...@cs.mcgill.ca>
Subject Re: [scxml-js] working toward a release
Date Fri, 27 Aug 2010 19:10:33 GMT
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. /

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?

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.

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<jbeard4@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<sebbaz@gmail.com>    wrote:
>>>
>>>        
>>>> On 25 August 2010 22:23, Rahul Akolkar<rahul.akolkar@gmail.com>   
wrote:
>>>>
>>>>          
>>>>> On Wed, Aug 25, 2010 at 4:51 PM, Jacob Beard<jbeard4@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>    

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message