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 Sat, 28 Aug 2010 13:46:56 GMT
Hi Rahul,

So far, I have not found any technical shortcomings that would seem to 
indicate that Maven2 with AntRun will not work. I feel the main 
challenge is the Maven community's reluctance to support such solutions, 
which makes it difficult for me to obtain answers to my questions. In 
any case, I am making progress and will commit today.

Thanks,

Jake

On 10-08-27 04:47 PM, Rahul Akolkar wrote:
> 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<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
>
>    

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


Mime
View raw message