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]
