qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <rafa...@redhat.com>
Subject Re: RFC: Maven and the Java Build
Date Wed, 24 Jun 2009 19:43:45 GMT
Bryan Kearney wrote:
> Rafael Schloming wrote:
>> Bryan Kearney wrote:
>>> Aidan Skinner wrote:
>>>> On Wed, Jun 24, 2009 at 3:59 PM, Bryan Kearney<bkearney@redhat.com>

>>>> wrote:
>>>>>> The main issue is that for dep resolution it still needs something
>>>>>> looks like a maven repo, not like /usr/java. I think a new resolver
>>>>>> wouldn't be very hard to write, but I haven't found the cycles for
>>>>>> yet.
>>>>> Why is it bad to use the maven repos instead of copying things from
>>>>> java/lib?
>>>> It makes reproducible builds hard/impossible and doesn't play well
>>>> with package systems.
>>> I have not seen the former issue.. but I will trust you on it. On the 
>>> latter (package systems) using maven repos seems no worse then what 
>>> is being done now.
>> The issue with using maven repos is that if you happen to use svn to 
>> rollback to a version where we were using maven, the build will most 
>> likely fail because it is dependent on a set of external maven repos 
>> that are no longer in sync with the needs of that particular revision.
> sorry to be dense.. if I am using version 2.2 of a libarary, and then 
> rollback to version 2.1...how does that cause an issue with the build?

If I try to build an older version of qpid that requires version 2.1, 
and the maven repo only has version 2.2 then one of two things will 
happen depending on how the pom is configured. If I specify that 
revision 2.1 is required in the pom file then the build will break 
because version 2.1 of the library is no longer available. If I don't 
specify this, then maven will attempt to build against version 2.2 which 
may fail due to incompatibilities, and even if it succeeds, it won't be 
the same bits I would have gotten had I built against version 2.1.

With ant we have all the dependencies stored in svn, so if I roll back 
to an older version of qpid and do a rebuild, then I know I'll get 
exactly the same bits I would have gotten had I done a build when that 
version was current.


Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message