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.
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.
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.
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.
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.
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.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
