On Fri, Jun 26, 2009 at 3:01 PM, Rafael Schloming <[email protected]> wrote:
> Aidan Skinner wrote: >> >> On Fri, Jun 26, 2009 at 12:27 PM, Rafael Schloming <[email protected]> >> wrote: >>> 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. 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. >> 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. 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. >> 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. If we do this, we only need do it once and we can check that it works in future. Having somebody contribute hand crafted poms is dead simple, we can take a patch, but seems like it'd be a lot of effort. IKWYM about our test harness, but that's really a counsel of despair against doing *anything*. And particularly against accepting more high-maintence components like hand crafted poms. > 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. 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. - 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]
