Hi Rafi, I've been round the houses thinking about this and had discussions with various users about it too.
I think what you have proposed is an excellent solution, allowing us to share/provide benefit for people who like maven packages and yet allowing us to avoid bearing the cost of managing it as an additional build/test overhead (which would be considerable). This seems to me to fit well with the Apache model encouraging contributions too. Marnie On Thu, Jun 25, 2009 at 7:50 PM, Rafael Schloming <[email protected]>wrote: > Aidan Skinner wrote: > >> On Thu, Jun 25, 2009 at 2:53 PM, Rajith Attapattu <[email protected]> >> wrote: >> >>> On Thu, Jun 25, 2009 at 8:27 AM, Bryan Kearney<[email protected]> >>> wrote: >>> >>>> 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?? >>> >> >> Well, my idea was to use ivy to pull from somewhere other than the >> maven repos. All the build systems I'm familar with have some varient >> of the rule that the same source built on the same system should >> result in equivalent bits, which this would help with. >> >> It would also help with letting us use system versions of the >> libraries, rather than shipping our own. This is more in keeping with >> what users expect and generally play nicer. >> >> Giving ivy enough information to let it populate our lib/ from the >> maven repos on demand and shipping those as we do today is probably >> Good Enough and quicker than writing our own resovler. >> >> There is definitely value in publishing the client bits in maven repos >>> as a few projects that use maven wants to use Qpid. >>> >> >> I'd rather do this generically for all modules, obviously more people >> are interested in the client bits... >> > > I'm not sure how solvable this problem really is. The fundamental issue > seems to be that maven users want the canonical qpid dependencies specified > in terms of maven repos, whereas we need the canonical qpid dependencies to > be whatever is checked into svn. > > It seems like one way or another we'll need to maintain an extra non > canonical set of dependency metadata in order to produce meaningful poms. > > Obviously there are better and worse ways to go about it, but unfortunately > no matter how we do this, it still means we either do twice the testing come > release time, or we ship jars that contain untested poms, neither of which > seem acceptable to me. Already there are enough different profiles and > environments to test against that releases drag on for months. > > I think a better way to address this issue is to simply produce plain old > jars from the main build and then provide a contrib area for maven users to > donate poms for the qpid artifacts they use. > > IMHO this approach has some substantial benefits. It's quite lightweight > and won't have any impact on our release process. The poms aren't part of > the officially signed release artifacts, so if the maven repos change/break > or if the poms have an error they can be updated retroactively for any given > release without invalidating the official artifacts. And ultimately, the > poms will probably be better tested and maintained than something we can get > ant to spew out automatically because they're coming from people who > actually use maven and would notice when the poms are broken. > > What do people think? Could some scheme like this be made streamlined and > workable for all involved? > > --Rafael > > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > >
