qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Kearney <bkear...@redhat.com>
Subject Re: RFC: Maven and the Java Build
Date Thu, 25 Jun 2009 12:27:06 GMT
Martin Ritchie wrote:
> 2009/6/24 Bryan Kearney <bkearney@redhat.com>:
>> Rafael Schloming wrote:
>>> 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
>>>>>>>>> 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
>>>>>>>>> it
>>>>>>>>> yet.
>>>>>>>> Why is it bad to use the maven repos instead of copying things
>>>>>>>> java/lib?
>>>>>>> It makes reproducible builds hard/impossible and doesn't play
>>>>>>> with package systems.
>>>>>> I have not seen the former issue.. but I will trust you on it. On
>>>>>> 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
>>>>> fail because it is dependent on a set of external maven repos that are
>>>>> 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.
>> Ok... I have always used required... so I have never seen it pick the
>> latest. I have also not seen the items go away.. but I understand the issue.
> One of the main issues that even caused a split in the maven community
> was in the maven plugins versioning rather than the libraries we
> specify.
> Sure you can use required for the apps dependencies but not the mave
> core plugins that will update themselves making repeatability between
> builds difficult. Two developers can perform a build at the same time
> and get a different result. For me this is the biggest failing of
> maven.
> Martin
>>> 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.
>> Can the ivy setup Aiden mentioned populate/update the lib directory? That
>> way they latest can be checked in and we can use a single depdendency data
>> to build and create poms.

Ok.. I get it it now. As I understand Aiden's idea in ivy is to pull the 
dependenr libraries from maven repos, but not to use maven as the build. 
  Does that help clear it up? My goal would not be to move to maven.. 
but to spit out maven artifacts for those who want to use maven. This is 
why I think we only need the artifats for the client bits. (qpid-common, 
qpid-client, qpid-management-*)

-- bk

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

View raw message