It'd be useful to get into the details of who wants/is able to work on this piece and what the requirements for the output actually are.
We should then have a design review around detailed options (potentially Ivy vs scripted/hand crafted pom files). Bryan - are you able/planning to work on this stuff ? Marnie On Fri, Jun 26, 2009 at 7:04 PM, Aidan Skinner <[email protected]>wrote: > On Fri, Jun 26, 2009 at 3:46 PM, Rafael Schloming<[email protected]> > wrote: > > Aidan Skinner wrote: > >> > >> It isn't all about syntax, but it's trivial to ask ivy to go "hey, can > >> you resolve all this from repo1?" which should be sufficient. > > > > You'd think so, but pom isn't a well-defined standard, and ivy and maven > > behave differently. I know that ivy users complain about maven repo > > maintainers refusing to fix broken poms because the work with maven even > > though they break on ivy. > > That doesn't sound likely to be a huge problem the other way and is > unlikely to affect us since we only really care about direct / top > level dependencies. > > >> So, two things. Firstly I would imagine we'd be shipping the repo as a > >> seperate thing from the existing binaries. > >> > >> Secondly, I don't see why the pom is likely to stop working at some > point. > > > > You need to ensure that the transitive dependency set is fully specified > for > > a pom to be "stable". This may be impossible to do since you don't have > > control over upstream poms. See the link in my other post for more > details. > > I'm fairly sure that we can make ivy output a complete set of deps. > Again, this is just what people get with Maven. > > >> I really can't believe it's simpler for anybody to keep a set of poms > >> up to date by hand than it is to do it this way. > > > > This question really comes down to how often things change. Maintaining > an > > automated pom generator is going to involve some up front work plus > > potentially introduce additional work anytime we want to modify the build > > system. Maintaining poms by hand is going to introduce additional work > > anytime our dependencies change. > > Hopefully modifying the build system is a rare and infrequent thing, > and messing with dependency management even rarer. > > > Given how infrequently our dependencies change, it's not at all clear to > me > > that it actually is more work, and more importantly it's work that can be > > much more easily contributed as opposed to requiring the strict oversight > of > > one of our build gurus. > > We get new deps every release, at least since I've been around (~M2). > I really don't see much of a quantitative difference in favour of the > work required to rebuild the pom by hand every release and the work > required to mess with the fundamentals of the build system on the > infrequent basis that we want to change how dependencies are handled. > > Several other projects are doing the ant+ivy=pom route (eg. JRoller) > and it seems to be working out well for them so far. > > - Aidan > > -- > Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org > "A witty saying proves nothing" - Voltaire > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > >
