qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aidan Skinner <aidan.skin...@gmail.com>
Subject Re: RFC: Maven and the Java Build
Date Fri, 26 Jun 2009 14:14:48 GMT
On Fri, Jun 26, 2009 at 3:01 PM, Rafael Schloming <rafaels@redhat.com> wrote:

> Aidan Skinner wrote:
>>
>> On Fri, Jun 26, 2009 at 12:27 PM, Rafael Schloming <rafaels@redhat.com> 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:dev-subscribe@qpid.apache.org


Mime
View raw message