Aidan Skinner wrote:
On Fri, Jun 26, 2009 at 12:27 PM, Rafael Schloming <[email protected]> wrote:
Aidan Skinner wrote:
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.
It's pretty trivial to automate those sort of checks.
A trivial syntactic check doesn't amount to a guarantee that the pom
will actually work with maven.
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 don't see how that differs from the usual "I am using maven"
situation for them, and I don't see how that relates to signing the
pom in any case.
I'm not referring to signing the pom per/se, but rather to including the
pom in our release tarball, which will then get signed. This irrevocably
couples together the official jars in that release tarball with a pom
that is quite likely to stop working at some point. It also doesn't seem
to serve much purpose since if you're using maven you probably don't
care about the tarball much anyways.
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.
Firing up maven in the test suite is, surely, different from using it
as the main build tool? It shouldn't affect anything other than the
automated testing step and it would be easy to allow that to be
disabled if you were building in an isolated environment.
Possibly in theory. I'm just skeptical both that it will be less work
and that it will be more reliable than having a reasonable way to easily
contribute a hand written pom. Case in point we have plenty of automated
tests that end up breaking and getting added to the exclude file because
nobody cares enough or has the time to fix them.
Given that the maven users are going to be the ones who notice the
breakage and care about it, I think it would be simpler for them to just
edit the pom file to be correct and submit a new one rather than to
understand how our build system works and then figure out how to fix it.
I think a solution where someone needs to have in-depth knowledge of
both maven and our build system is likely to be less reliable than a
solution where you just need to know about maven.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
