On Thu, Jun 25, 2009 at 8:27 AM, Bryan Kearney<[email protected]> wrote: > Martin Ritchie wrote: >> >> 2009/6/24 Bryan Kearney <[email protected]>: >>> >>> 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<[email protected]> >>>>>>>> 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 >>>>>>>>>> it >>>>>>>>>> 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. >>> >>> 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.
Aidan, So don't we still get into the same problem if the maven repos no longer carry the version we require? Ivy could produce repeatable builds assuming the maven repos still carry the version we need. Perhaps I am missing something here?? > 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-*) There is definitely value in publishing the client bits in maven repos as a few projects that use maven wants to use Qpid. > > -- bk > > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
