My view is that we do not want to get into having a costly side-build to maintain and from what I can see there's that risk if we opt to take the ivy route over a contributed-pom option. Introducing Ivy solely for this purpose seems expensive.
We potentially could extract the jar names from the lib directories, using the ant build files for dependency lists if lower level module info required, and generate the pom definitions that way ? Eclipse has a plugin to generate poms from manifests - this would fly for the Java broker at least using the existing manifest. On the testing side, we do extensive pre-release testing of the Java client/broker. I'm not at all sure we can afford to spend the same time on a generated maven pom (shout if you do have the time ?) so we should look to involve the user community here. Marnie On Fri, Jun 26, 2009 at 12:27 PM, Rafael Schloming <[email protected]>wrote: > Aidan Skinner wrote: > >> On Fri, Jun 26, 2009 at 11:50 AM, Robert Godfrey >> <[email protected]> wrote: >> >> I've not used Ivy, so I may be underestimating its cleverness; but I'm >>> not sure how we can get away without the meta data being in effect a >>> manually maintained duplicate of data that is mastered elsewhere. In >>> particular we want/require to build of versions of jars that are in >>> our repo (so that we can have repeatable builds). Thus the "metadata" >>> is actually the version information pertaining to the jars that are >>> actually checked in. Are you saying that Ivy extracts version >>> information from the checked in jars - or do we have to manually >>> maintain a list of what jars are at what version? >>> >> >> We already maintain that, albiet build.deps encodes it into the file >> name so it's not useful. >> >> The idea is to teach ivy to look in lib/ for the jar, then we maintain >> our deps in ivy.xml >> >> Admittedly >> commons-lang=lib/commons-lang-2.2.jar >> is more concise than >> <dependency org="commons-lang" name="commons-lang" rev="2.2"/> >> >> But it's not a huge hardship if we can then guarantee meaningful poms >> that are automatically generated. >> > > I don't think we could actually guarantee this. Imagine if there were a > typo in the org part: > > <dependency org="commns-lang" name="commons-lang" rev="2.2"/> > > This could easily happen, and we wouldn't notice either because we don't > use the org part or we have the same typo in the path to the file on disk. > This would result in a useless pom that could easily get included into the > release artifact and then signed and voted for release. And once that > happens, we can't go back and fix it. > > IMHO it's really a bad idea to sign the pom regardless, because even if > it's correct at the time of release, it may become out of date after the > release since it depends on external configuration that may change. > > I'm also not sure how we could automatically test this in a reasonable way > without actually firing up maven, and that would sort of defeat the purpose. > I know we could possibly test that ivy can find the remote dependency > without firing up maven, but from what I hear maven and ivy have different > behavior wrt poms and so some poms work with one and not the other. > > --Rafael > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > >
