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 10:26:22 GMT
On Thu, Jun 25, 2009 at 7:50 PM, Rafael Schloming <rafaels@redhat.com> wrote:

> I'm not sure how solvable this problem really is. The fundamental issue seems to be that
maven users want the canonical qpid dependencies specified in terms of maven repos, whereas
we need the canonical qpid dependencies to be whatever is checked into svn.

I don't think there needs to be a conflict between these.

> It seems like one way or another we'll need to maintain an extra non canonical set of
dependency metadata in order to produce meaningful poms.

I think we can use ivy to avoid having duplicate metadata.

> I think a better way to address this issue is to simply produce plain old jars from the
main build and then provide a contrib area for maven users to donate poms for the qpid artifacts
they use.

I think we'll have poms that rot, and that's (IMHO) worse than just
not offering them in the first place. It also precludes the ability to
produce -SNAPSHOT versions if we ever decide to produce regular builds
(which is another can of worms completely).

> IMHO this approach has some substantial benefits. It's quite lightweight and won't have
any impact on our release process. The poms aren't part of the officially signed release artifacts,
so if the maven repos change/break or if the poms have an error they can be updated retroactively
for any given release without invalidating the official artifacts. And ultimately, the poms
will probably be better tested and maintained than something we can get ant to spew out automatically
because they're coming from people who actually use maven and would notice when the poms are
broken.

I think the poms need to be part of the official releases if we're
going to ship them through the central repo. Once they're available
that is how most users who use maven will get us. Having an automated
test for the poms shouldn't be a lot of work and could be integrated
into the build or release process.

> What do people think? Could some scheme like this be made streamlined and workable for
all involved?

I can't see it, but I've been wrong before. :)

- 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