[jboss-dev] Mavenizing Thirdparty

Andrew Lee Rubinger andrew.rubinger at redhat.com
Wed Apr 16 12:03:51 EDT 2008


Brian Stansberry wrote:
> What can I pass to build.sh to stop it updating my thirdparty?

Go into your ~/.m2/settings.xml and set the snapshot policy to "never" 
on the snapshots repo.  The default is once daily.  Then you can have 
manual control of when the snapshots are updated by passing the "-U" 
switch to mvn.

> I just did a build following a 2 line change to a class, and suddenly 
> the AS wouldn't start cleanly anymore because some new version of a 
> snapshot got downloaded.

This is the evil of snapshots.  We've got to be depending upon frequent 
releases, using snapshots at a minimum when developing locally.  Then 
release, then do integration testing.

> 
> Paul Gier wrote:
>> I just wanted to follow up on this issue of including the source jars.
>> Yesterday I added a profile to the maven thirdparty build that will 
>> download source jars (using the maven dependency plugin) to the local 
>> maven repo.  The maven plugin will then look for the source jars in 
>> the local maven repository and copy them to the correct location in 
>> the thirdparty folder.
>>
>> Currently this is off by default because checking for the sources can 
>> be time consuming, and they only need to be downloaded on the first 
>> build.
>>
>> I also added the ability to pass maven options to the thirdparty build 
>> through build.sh or build.xml.  So for example to call the profile for 
>> downloading sources, the command looks like this:
>>
>> ./build.sh -Dthirdparty.maven.opts="-Pdownload-sources"
>>
>> This causes the following command to be run against the 
>> thirdparty/pom.xml
>>
>> mvn -Pdownload-sources package
>>
>> So any maven options that you want to pass to the mavenized thirdparty 
>> can be passed through that property.
>>
>>
>> Paul Gier wrote:
>>> I could add it to the mapping like that, but it would not download 
>>> the sources for the non-mapped artifacts.  I'll try to make the 
>>> plugin automatically check for sources and download them if they 
>>> exists.  Does the zip vs. jar format matter?
>>>
>>> Scott Stark wrote:
>>>> One difference is that the source artifacts are not being downloaded 
>>>> any longer. We should be able to define which sources are downloaded 
>>>> by default in the mapping section via an includeSources or some such 
>>>> element:
>>>>
>>>>            <dependency>
>>>>              <groupId>org.jboss.cl</groupId>
>>>>              <artifactId>jboss-classloader</artifactId>
>>>>              <mapping>
>>>>                <componentId>jboss.jboss-cl</componentId>
>>>>                <includeSources>true</includeSources>
>>>>              </mapping>
>>>>            </dependency>
>>>>
>>>> Would that be easy to add?
>>>>
>>>> I can run mvn dependency:sources from thirdparty to pull all of the 
>>>> source dependencies into my local maven tree, but this does not 
>>>> update thirdparty.
>>>>
>>>> Paul Gier wrote:
>>>>> The mavenized thirdparty builds have been running ok (similar 
>>>>> testsuite results to non-maven build) on hudson for a few days and 
>>>>> I've heard from other people that have successfully run the build 
>>>>> locally.
>>>>>
>>>>> So I'm planning to switch to the mavenized thirdparty build at the 
>>>>> end of the day today.  Please try it out if you haven't already 
>>>>> (ant -f build-maven.xml), and bring up any issues.
>>>>>
>>>>> There are still some issues that we are working out regarding 
>>>>> managing the dependencies (see build forum for more info), but 
>>>>> these issues don't prevent building and testing, and I believe they 
>>>>> can be resolved as development continues.
>>>>> _______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-development at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
> 

-- 
Andrew Lee Rubinger
Sr. Software Engineer
JBoss EJB3
JBoss, a division of Red Hat, Inc.
http://www.jboss.org/jbossejb3/
http://exitcondition.alrubinger.com



More information about the jboss-development mailing list