[jboss-dev] Mavenizing Thirdparty

[Brian Stansberry]

Adrian Brock wrote:
> On Wed, 2008-04-16 at 10:50 -0500, Brian Stansberry wrote:
>> What can I pass to build.sh to stop it updating my thirdparty?
>>
>> 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.
>>
> 
> The same as the previous build:
> 
> -Dinhibit.downloads=true
> 

Which I also never knew. :-(

> The difference is that maven looks for changed snapshots once a
> day while the old build only looked when build-thirdparty.xml changed.
> 
> I guess we could add a check on whether component-martix/pom.xml
> is newer than thirdparty/libraries.ent to reproduce the old
> behaviour. 
> 
> But I actually prefer getting changed snapshots instead of broken builds
> due to snapshots not updating.
> 

Me too. Most of the time. As long as I know how to control it, I'm 
happy. :-)

> Of course, if the snapshot is broken, that's another matter. ;-)
> 

Nah, that will never happen. ;-)

Thanks, all, for the quick responses.

>> 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

-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com