RFC: Maven and the Java Build

[Bryan Kearney <bk...@redhat.com>]

I am looking for the comments from the Java developers. I have been 
working on some QMF bits, and I am interested in having maven artifacts 
for consuming the clients bits. In speaking with some of the developers, 
there is a strong desire to not move the build system to maven given the 
issues with the tool, and the impact it would have on build system.

So.. I would like to solicit thoughts from folks.

1) Do you have a desire/need for maven artifacts for the Java bits? If 
so, which java bits?
2) Have you seen good examples of how to manage pom files as well as 
dependencies in the ant or standard build system.

One bug was put forward with an attempt to do this:

https://issues.apache.org/jira/browse/QPID-1916

but this suffers from being very non-DRY. Dependencies are done both in 
the pom file and the build.deps file. My hope is that answers to (2) can 
provide a better way to resolve this issue.

Thanks!

-- bk

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Re: RFC: Ivy Integration (Was RFC: Maven and the Java Build)

[Bryan Kearney <bk...@redhat.com>]

Aidan Skinner wrote:
> On Mon, Jun 29, 2009 at 8:36 PM, Bryan Kearney<bk...@redhat.com> wrote:
> 
>> Taking what Aiden suggested. Here is a first cut at ivy integration. What
>> this does is:
>>
>> 1) Require that every module have an ivy.xml file which is contains all the
>> dependencies.
>> 2) Defines a depVersions.properties file at the root project to control the
>> actual version numbers.
>> 3) Builds a pom file (DRY) with every build (see build/pom).
> 
> I really like this approach.
> 
>> A) Use the local lib file. If the requirement is to check in every version,
>> we could do that by refactoring the lib directory to be a mini ivy or maven
>> repo.
> 
> I'd rather write a resolver which looks in a flat directory. I know
> it's a bit more work, but will make it much, much easier to get our
> stuff downstream.

We can.. as long as we bring in the pom/ivy artifacts as well. It would 
be easy to make it a flat file if we have

org.apache.mina-mina.core-1.0.1.jar
org.apache.mina-mina.core-1.0.1.pom

If folks can live with that, it can be flat. We need the upstream pom or 
ivy.xml checked in.

> 
>> Can folks please take a look at this patch and let me know what it misses
>> from your requirements. To install it, please do the following:
> 
> I gotta say, that's pretty slick. :)


Thanks. If other folks are ok.. I will complete out the patch, but I 
want to get comments on what is good/bad before I do more.

-- bk

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Re: RFC: Ivy Integration (Was RFC: Maven and the Java Build)

[Aidan Skinner <ai...@gmail.com>]

On Mon, Jun 29, 2009 at 8:36 PM, Bryan Kearney<bk...@redhat.com> wrote:

> Taking what Aiden suggested. Here is a first cut at ivy integration. What
> this does is:
>
> 1) Require that every module have an ivy.xml file which is contains all the
> dependencies.
> 2) Defines a depVersions.properties file at the root project to control the
> actual version numbers.
> 3) Builds a pom file (DRY) with every build (see build/pom).

I really like this approach.

> A) Use the local lib file. If the requirement is to check in every version,
> we could do that by refactoring the lib directory to be a mini ivy or maven
> repo.

I'd rather write a resolver which looks in a flat directory. I know
it's a bit more work, but will make it much, much easier to get our
stuff downstream.

> Can folks please take a look at this patch and let me know what it misses
> from your requirements. To install it, please do the following:

I gotta say, that's pretty slick. :)

- 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

RFC: Ivy Integration (Was RFC: Maven and the Java Build)

[Bryan Kearney <bk...@redhat.com>]

Taking what Aiden suggested. Here is a first cut at ivy integration. 
What this does is:

1) Require that every module have an ivy.xml file which is contains all 
the dependencies.
2) Defines a depVersions.properties file at the root project to control 
the actual version numbers.
3) Builds a pom file (DRY) with every build (see build/pom).

What this does not do is:

A) Use the local lib file. If the requirement is to check in every 
version, we could do that by refactoring the lib directory to be a mini 
ivy or maven repo.

Can folks please take a look at this patch and let me know what it 
misses from your requirements. To install it, please do the following:

I) Grab the latest from the repo.
II) Apply this patch from the first qpid directory.
III) Download the ivy 2.1.0rc1 jar from 
http://ant.apache.org/ivy/download.cgi and put it into the lib directory.
IV) From the java/common directory do an ant build. Inspect the ivy.xml 
file that is there. Also look at build/pom/qpid-common-0.5.pom
V) from the java/client directory do an ant build. Inspect the ivy.xml 
file and pom file. Note that this relies on qpid-common.
VI) Scan the rest of the files.. and ask any questions.

Thanks!

-- bk

Re: RFC: Maven and the Java Build

[Marnie McCormack <ma...@googlemail.com>]

It'd be useful to get into the details of who wants/is able to work on this
piece and what the requirements for the output actually are.

We should then have a design review around detailed options (potentially Ivy
vs scripted/hand crafted pom files).

Bryan - are you able/planning to work on this stuff ?

Marnie

On Fri, Jun 26, 2009 at 7:04 PM, Aidan Skinner <ai...@gmail.com>wrote:

> On Fri, Jun 26, 2009 at 3:46 PM, Rafael Schloming<ra...@redhat.com>
> wrote:
> > 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.
>
> That doesn't sound likely to be a huge problem the other way and is
> unlikely to affect us since we only really care about direct / top
> level dependencies.
>
> >> 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.
>
> I'm fairly sure that we can make ivy output a complete set of deps.
> Again, this is just what people get with 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.
>
> Hopefully modifying the build system is a rare and infrequent thing,
> and messing with dependency management even rarer.
>
> > 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.
>
> We get new deps every release, at least since I've been around (~M2).
> I really don't see much of a quantitative difference in favour of the
> work required to rebuild the pom by hand every release and the work
> required to mess with the fundamentals of the build system on the
> infrequent basis that we want to change how dependencies are handled.
>
> Several other projects are doing the ant+ivy=pom route (eg. JRoller)
> and it seems to be working out well for them so far.
>
> - 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
>
>

Re: RFC: Maven and the Java Build

[Aidan Skinner <ai...@gmail.com>]

On Fri, Jun 26, 2009 at 3:46 PM, Rafael Schloming<ra...@redhat.com> wrote:
> 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.

That doesn't sound likely to be a huge problem the other way and is
unlikely to affect us since we only really care about direct / top
level dependencies.

>> 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.

I'm fairly sure that we can make ivy output a complete set of deps.
Again, this is just what people get with 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.

Hopefully modifying the build system is a rare and infrequent thing,
and messing with dependency management even rarer.

> 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.

We get new deps every release, at least since I've been around (~M2).
I really don't see much of a quantitative difference in favour of the
work required to rebuild the pom by hand every release and the work
required to mess with the fundamentals of the build system on the
infrequent basis that we want to change how dependencies are handled.

Several other projects are doing the ant+ivy=pom route (eg. JRoller)
and it seems to be working out well for them so far.

- 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

Re: RFC: Maven and the Java Build

[Rafael Schloming <ra...@redhat.com>]

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:dev-subscribe@qpid.apache.org

Re: RFC: Maven and the Java Build

[Aidan Skinner <ai...@gmail.com>]

On Fri, Jun 26, 2009 at 3:01 PM, Rafael Schloming <ra...@redhat.com> wrote:

> Aidan Skinner wrote:
>>
>> On Fri, Jun 26, 2009 at 12:27 PM, Rafael Schloming <ra...@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

Re: RFC: Maven and the Java Build

[Marnie McCormack <ma...@googlemail.com>]

My view is that we do not want to get into having a costly side-build to
maintain and from what I can see there's that risk if we opt to take the ivy
route over a contributed-pom option. Introducing Ivy solely for this purpose
seems expensive.

We potentially could extract the jar names from the lib directories, using
the ant build files for dependency lists if lower level module info
required, and generate the pom definitions that way ?

Eclipse has a plugin to generate poms from manifests - this would fly for
the Java broker at least using the existing manifest.

On the testing side, we do extensive pre-release testing of the Java
client/broker. I'm not at all sure we can afford to spend the same time on a
generated maven pom (shout if you do have the time ?) so we should look to
involve the user community here.

Marnie




On Fri, Jun 26, 2009 at 12:27 PM, Rafael Schloming <ra...@redhat.com>wrote:

> Aidan Skinner wrote:
>
>> On Fri, Jun 26, 2009 at 11:50 AM, Robert Godfrey
>> <ro...@gmail.com> wrote:
>>
>> I've not used Ivy, so I may be underestimating its cleverness; but I'm
>>> not sure how we can get away without the meta data being in effect a
>>> manually maintained duplicate of data that is mastered elsewhere.  In
>>> particular we want/require to build of versions of jars that are in
>>> our repo (so that we can have repeatable builds).  Thus the "metadata"
>>> is actually the version information pertaining to the jars that are
>>> actually checked in.  Are you saying that Ivy extracts version
>>> information from the checked in jars - or do we have to manually
>>> maintain a list of what jars are at what version?
>>>
>>
>> We already maintain that, albiet build.deps encodes it into the file
>> name so it's not useful.
>>
>> The idea is to teach ivy to look in lib/ for the jar, then we maintain
>> our deps in ivy.xml
>>
>> 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.
>
> 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'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.
>
> --Rafael
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>

Re: RFC: Maven and the Java Build

[Rafael Schloming <ra...@redhat.com>]

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

Re: RFC: Maven and the Java Build

[Aidan Skinner <ai...@gmail.com>]

On Fri, Jun 26, 2009 at 12:27 PM, Rafael Schloming <ra...@redhat.com> 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.

> 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 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.

- 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

Re: RFC: Maven and the Java Build

[Bryan Kearney <bk...@redhat.com>]

Rafael Schloming wrote:
> Aidan Skinner wrote:
>> On Fri, Jun 26, 2009 at 11:50 AM, Robert Godfrey
>> <ro...@gmail.com> wrote:
>>
>>> I've not used Ivy, so I may be underestimating its cleverness; but I'm
>>> not sure how we can get away without the meta data being in effect a
>>> manually maintained duplicate of data that is mastered elsewhere.  In
>>> particular we want/require to build of versions of jars that are in
>>> our repo (so that we can have repeatable builds).  Thus the "metadata"
>>> is actually the version information pertaining to the jars that are
>>> actually checked in.  Are you saying that Ivy extracts version
>>> information from the checked in jars - or do we have to manually
>>> maintain a list of what jars are at what version?
>>
>> We already maintain that, albiet build.deps encodes it into the file
>> name so it's not useful.
>>
>> The idea is to teach ivy to look in lib/ for the jar, then we maintain
>> our deps in ivy.xml
>>
>> 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.
> 
> 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'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.

How is this any different then relying on geronimo-jms? It works at the 
time of build, but I need to supply a container specific JMS to make it 
work. If ivy metadata replaces the build.deps file metadata and that can 
be used to generic additional artifatcts.. it seems like a win win. No 
maven in the build, but maven can be used to consume it.

-- bk



---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Re: RFC: Maven and the Java Build

[Rafael Schloming <ra...@redhat.com>]

Aidan Skinner wrote:
> On Fri, Jun 26, 2009 at 11:50 AM, Robert Godfrey
> <ro...@gmail.com> wrote:
> 
>> I've not used Ivy, so I may be underestimating its cleverness; but I'm
>> not sure how we can get away without the meta data being in effect a
>> manually maintained duplicate of data that is mastered elsewhere.  In
>> particular we want/require to build of versions of jars that are in
>> our repo (so that we can have repeatable builds).  Thus the "metadata"
>> is actually the version information pertaining to the jars that are
>> actually checked in.  Are you saying that Ivy extracts version
>> information from the checked in jars - or do we have to manually
>> maintain a list of what jars are at what version?
> 
> We already maintain that, albiet build.deps encodes it into the file
> name so it's not useful.
> 
> The idea is to teach ivy to look in lib/ for the jar, then we maintain
> our deps in ivy.xml
> 
> 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.

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'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.

--Rafael

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Re: RFC: Maven and the Java Build

[Aidan Skinner <ai...@gmail.com>]

On Fri, Jun 26, 2009 at 11:50 AM, Robert Godfrey
<ro...@gmail.com> wrote:

> I've not used Ivy, so I may be underestimating its cleverness; but I'm
> not sure how we can get away without the meta data being in effect a
> manually maintained duplicate of data that is mastered elsewhere.  In
> particular we want/require to build of versions of jars that are in
> our repo (so that we can have repeatable builds).  Thus the "metadata"
> is actually the version information pertaining to the jars that are
> actually checked in.  Are you saying that Ivy extracts version
> information from the checked in jars - or do we have to manually
> maintain a list of what jars are at what version?

We already maintain that, albiet build.deps encodes it into the file
name so it's not useful.

The idea is to teach ivy to look in lib/ for the jar, then we maintain
our deps in ivy.xml

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.

If we did that, then downstream could concievably teach it to look in
/usr/lib/java or wherever to use system jars, which is what most linux
distros I'm familiar with strongly prefer.

- 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

Re: RFC: Maven and the Java Build

[Marnie McCormack <ma...@googlemail.com>]

Hi Rafi,

I've been round the houses thinking about this and had discussions with
various users about it too.

I think what you have proposed is an excellent solution, allowing us to
share/provide benefit for people who like maven packages and yet allowing us
to avoid bearing the cost of managing it as an additional build/test
overhead (which would be considerable).

This seems to me to fit well with the Apache model encouraging contributions
too.

Marnie



On Thu, Jun 25, 2009 at 7:50 PM, Rafael Schloming <ra...@redhat.com>wrote:

> Aidan Skinner wrote:
>
>> On Thu, Jun 25, 2009 at 2:53 PM, Rajith Attapattu <ra...@gmail.com>
>> wrote:
>>
>>> On Thu, Jun 25, 2009 at 8:27 AM, Bryan Kearney<bk...@redhat.com>
>>> wrote:
>>>
>>>> Ok.. I get it it now. As I understand Aiden's idea in ivy is to pull the
>>>> dependenr libraries from maven repos, but not to use maven as the build.
>>>>
>>> Aidan, So don't we still get into the same problem if the maven repos
>>> no longer carry the version we require?
>>> Ivy could produce repeatable builds assuming the maven repos still
>>> carry the version we need.
>>> Perhaps I am missing something here??
>>>
>>
>> Well, my idea was to use ivy to pull from somewhere other than the
>> maven repos. All the build systems I'm familar with have some varient
>> of the rule that the same source built on the same system should
>> result in equivalent bits, which this would help with.
>>
>> It would also help with letting us use system versions of the
>> libraries, rather than shipping our own. This is more in keeping with
>> what users expect and generally play nicer.
>>
>> Giving ivy enough information to let it populate our lib/ from the
>> maven repos on demand and shipping those as we do today is probably
>> Good Enough and quicker than writing our own resovler.
>>
>> There is definitely value in publishing the client bits in maven repos
>>> as a few projects that use maven wants to use Qpid.
>>>
>>
>> I'd rather do this generically for all modules, obviously more people
>> are interested in the client bits...
>>
>
> 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.
>
> 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.
>
> Obviously there are better and worse ways to go about it, but unfortunately
> no matter how we do this, it still means we either do twice the testing come
> release time, or we ship jars that contain untested poms, neither of which
> seem acceptable to me. Already there are enough different profiles and
> environments to test against that releases drag on for months.
>
> 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.
>
> 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.
>
> What do people think? Could some scheme like this be made streamlined and
> workable for all involved?
>
> --Rafael
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>

Re: RFC: Maven and the Java Build

[Rajith Attapattu <ra...@gmail.com>]

On Fri, Jun 26, 2009 at 10:06 AM, Rafael Schloming<ra...@redhat.com> wrote:
> Bryan Kearney wrote:
>>
>> Aidan Skinner wrote:
>>>
>>> On Thu, Jun 25, 2009 at 7:50 PM, Rafael Schloming <ra...@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).
>>
>> It would either lead to rot, or folks saying that the maven builds are
>> forks/not official.
>
> If it really leads to rot, then I think that's a sign that there aren't
> enough interested maven users for us to worry about it, and conversely, if
> there are enough interested maven users then I don't see how the poms would
> be able to rot.

Rafi, we may have folks you are interested in using Qpid (via Maven)
but may not have the cycles to contribute/maintain it.
IMO the qpid community should maintain the builds without expecting
the end users to contribute.
Also as Aidan pointed out we need to have the maven artifacts as part
of the official release.
I haven't used Ivy so I can't comment on it, but I don't think Rafi's
idea of having a seperate contrib section for the maven poms will work
all though the idea has some merit on paper.

> As for the maven builds being forks or unofficial, I don't see how they
> could be considered either if they're using exactly the same jars we ship
> and this is verifiable via digital signature.
>
> --Rafael
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>



-- 
Regards,

Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Re: RFC: Maven and the Java Build

[Rafael Schloming <ra...@redhat.com>]

Daniel Kulp wrote:
> On Fri June 26 2009 6:50:49 am Robert Godfrey wrote:
>> I've not used Ivy, so I may be underestimating its cleverness; but I'm
>> not sure how we can get away without the meta data being in effect a
>> manually maintained duplicate of data that is mastered elsewhere.  In
>> particular we want/require to build of versions of jars that are in
>> our repo (so that we can have repeatable builds). 
> 
> Just want to inject in here.   It has NOTHING to do with repeatable builds.   
> The Jars in central NEVER change and are NEVER deleted.   If you depend on 
> jars at central, the builds would be repeatable just fine.

Actually our issue WAS with repeatable builds. We pretty much had every 
issue this guy talks about and more:

http://ignorancecompounded.blogspot.com/2008/10/maven-sucks.html

> The problem you had with maven were:
> 1) You didn't want to use released jars at central.  You wanted your own 
> versions of various things from who knows where.  You didn't want to use 
> officially released jars.

We did use a patched version of MINA, but I believe we were forced to 
abandon it due to problems with maven. I'm not sure which version we use 
now, but if it is patched or if we need to patch it again, then that 
would be a problem for any poms we produce.

> 2) The maven plugin version issues (which did make builds non-reproducable, 
> but that is fixed in maven >= 2.0.8 and was easily worked around by specifying 
> plugin versions)

This isn't so trivially worked around. Even if you nail down all the 
versions of every dependency in your own pom, you transitively depend on 
other people's poms, and their dependencies may use snapshots or version 
ranges. This means that in general it's very difficult to ensure that 
you're working with the same set of dependencies as another developer or 
as yourself 5 minutes from now when maven decides to download a 
different set for you.

--Rafael

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Re: RFC: Maven and the Java Build

[Daniel Kulp <dk...@apache.org>]

On Fri June 26 2009 6:50:49 am Robert Godfrey wrote:
> I've not used Ivy, so I may be underestimating its cleverness; but I'm
> not sure how we can get away without the meta data being in effect a
> manually maintained duplicate of data that is mastered elsewhere.  In
> particular we want/require to build of versions of jars that are in
> our repo (so that we can have repeatable builds). 

Just want to inject in here.   It has NOTHING to do with repeatable builds.   
The Jars in central NEVER change and are NEVER deleted.   If you depend on 
jars at central, the builds would be repeatable just fine.

The problem you had with maven were:
1) You didn't want to use released jars at central.  You wanted your own 
versions of various things from who knows where.  You didn't want to use 
officially released jars.

2) The maven plugin version issues (which did make builds non-reproducable, 
but that is fixed in maven >= 2.0.8 and was easily worked around by specifying 
plugin versions)

Dan


> Thus the "metadata"
> is actually the version information pertaining to the jars that are
> actually checked in.  Are you saying that Ivy extracts version
> information from the checked in jars - or do we have to manually
> maintain a list of what jars are at what version?
>
> -- Rob
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Re: RFC: Maven and the Java Build

[Rafael Schloming <ra...@redhat.com>]

Bryan Kearney wrote:
> Aidan Skinner wrote:
>> On Thu, Jun 25, 2009 at 7:50 PM, Rafael Schloming <ra...@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).
> 
> It would either lead to rot, or folks saying that the maven builds are 
> forks/not official.

If it really leads to rot, then I think that's a sign that there aren't 
enough interested maven users for us to worry about it, and conversely, 
if there are enough interested maven users then I don't see how the poms 
would be able to rot.

As for the maven builds being forks or unofficial, I don't see how they 
could be considered either if they're using exactly the same jars we 
ship and this is verifiable via digital signature.

--Rafael


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Re: RFC: Maven and the Java Build

[Bryan Kearney <bk...@redhat.com>]

Aidan Skinner wrote:
> On Thu, Jun 25, 2009 at 7:50 PM, Rafael Schloming <ra...@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).

It would either lead to rot, or folks saying that the maven builds are 
forks/not official.

> 
>> 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.
> 

I agree. Maven would be used to test consumption, not building.


-- bk

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Re: RFC: Maven and the Java Build

[Robert Godfrey <ro...@gmail.com>]

2009/6/26 Aidan Skinner <ai...@gmail.com>:
> On Thu, Jun 25, 2009 at 7:50 PM, Rafael Schloming <ra...@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've not used Ivy, so I may be underestimating its cleverness; but I'm
not sure how we can get away without the meta data being in effect a
manually maintained duplicate of data that is mastered elsewhere.  In
particular we want/require to build of versions of jars that are in
our repo (so that we can have repeatable builds).  Thus the "metadata"
is actually the version information pertaining to the jars that are
actually checked in.  Are you saying that Ivy extracts version
information from the checked in jars - or do we have to manually
maintain a list of what jars are at what version?

-- Rob

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Re: RFC: Maven and the Java Build

[Aidan Skinner <ai...@gmail.com>]

On Thu, Jun 25, 2009 at 7:50 PM, Rafael Schloming <ra...@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

Re: RFC: Maven and the Java Build

[Rafael Schloming <ra...@redhat.com>]

Aidan Skinner wrote:
> On Thu, Jun 25, 2009 at 2:53 PM, Rajith Attapattu <ra...@gmail.com> wrote:
>> On Thu, Jun 25, 2009 at 8:27 AM, Bryan Kearney<bk...@redhat.com> wrote:
>>> Ok.. I get it it now. As I understand Aiden's idea in ivy is to pull the
>>> dependenr libraries from maven repos, but not to use maven as the build.
>> Aidan, So don't we still get into the same problem if the maven repos
>> no longer carry the version we require?
>> Ivy could produce repeatable builds assuming the maven repos still
>> carry the version we need.
>> Perhaps I am missing something here??
> 
> Well, my idea was to use ivy to pull from somewhere other than the
> maven repos. All the build systems I'm familar with have some varient
> of the rule that the same source built on the same system should
> result in equivalent bits, which this would help with.
> 
> It would also help with letting us use system versions of the
> libraries, rather than shipping our own. This is more in keeping with
> what users expect and generally play nicer.
> 
> Giving ivy enough information to let it populate our lib/ from the
> maven repos on demand and shipping those as we do today is probably
> Good Enough and quicker than writing our own resovler.
> 
>> There is definitely value in publishing the client bits in maven repos
>> as a few projects that use maven wants to use Qpid.
> 
> I'd rather do this generically for all modules, obviously more people
> are interested in the client bits...

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.

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.

Obviously there are better and worse ways to go about it, but 
unfortunately no matter how we do this, it still means we either do 
twice the testing come release time, or we ship jars that contain 
untested poms, neither of which seem acceptable to me. Already there are 
enough different profiles and environments to test against that releases 
drag on for months.

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.

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.

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

--Rafael


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Re: RFC: Maven and the Java Build

[Aidan Skinner <ai...@gmail.com>]

On Thu, Jun 25, 2009 at 2:53 PM, Rajith Attapattu <ra...@gmail.com> wrote:
>
> On Thu, Jun 25, 2009 at 8:27 AM, Bryan Kearney<bk...@redhat.com> wrote:
> > Ok.. I get it it now. As I understand Aiden's idea in ivy is to pull the
> > dependenr libraries from maven repos, but not to use maven as the build.
>
> Aidan, So don't we still get into the same problem if the maven repos
> no longer carry the version we require?
> Ivy could produce repeatable builds assuming the maven repos still
> carry the version we need.
> Perhaps I am missing something here??

Well, my idea was to use ivy to pull from somewhere other than the
maven repos. All the build systems I'm familar with have some varient
of the rule that the same source built on the same system should
result in equivalent bits, which this would help with.

It would also help with letting us use system versions of the
libraries, rather than shipping our own. This is more in keeping with
what users expect and generally play nicer.

Giving ivy enough information to let it populate our lib/ from the
maven repos on demand and shipping those as we do today is probably
Good Enough and quicker than writing our own resovler.

> There is definitely value in publishing the client bits in maven repos
> as a few projects that use maven wants to use Qpid.

I'd rather do this generically for all modules, obviously more people
are interested in the client bits...

- 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

Re: RFC: Maven and the Java Build

[Rajith Attapattu <ra...@gmail.com>]

On Thu, Jun 25, 2009 at 8:27 AM, Bryan Kearney<bk...@redhat.com> wrote:
> Martin Ritchie wrote:
>>
>> 2009/6/24 Bryan Kearney <bk...@redhat.com>:
>>>
>>> Rafael Schloming wrote:
>>>>
>>>> Bryan Kearney wrote:
>>>>>
>>>>> Rafael Schloming wrote:
>>>>>>
>>>>>> Bryan Kearney wrote:
>>>>>>>
>>>>>>> Aidan Skinner wrote:
>>>>>>>>
>>>>>>>> On Wed, Jun 24, 2009 at 3:59 PM, Bryan Kearney<bk...@redhat.com>
>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> The main issue is that for dep resolution it still needs something
>>>>>>>>>> looks like a maven repo, not like /usr/java. I think a new
>>>>>>>>>> resolver
>>>>>>>>>> wouldn't be very hard to write, but I haven't found the cycles for
>>>>>>>>>> it
>>>>>>>>>> yet.
>>>>>>>>>>
>>>>>>>>> Why is it bad to use the maven repos instead of copying things from
>>>>>>>>> java/lib?
>>>>>>>>
>>>>>>>> It makes reproducible builds hard/impossible and doesn't play well
>>>>>>>> with package systems.
>>>>>>>>
>>>>>>> I have not seen the former issue.. but I will trust you on it. On the
>>>>>>> latter (package systems) using maven repos seems no worse then what
>>>>>>> is being
>>>>>>> done now.
>>>>>>
>>>>>> The issue with using maven repos is that if you happen to use svn to
>>>>>> rollback to a version where we were using maven, the build will most
>>>>>> likely
>>>>>> fail because it is dependent on a set of external maven repos that are
>>>>>> no
>>>>>> longer in sync with the needs of that particular revision.
>>>>>>
>>>>> sorry to be dense.. if I am using version 2.2 of a libarary, and then
>>>>> rollback to version 2.1...how does that cause an issue with the build?
>>>>
>>>> If I try to build an older version of qpid that requires version 2.1,
>>>> and
>>>> the maven repo only has version 2.2 then one of two things will happen
>>>> depending on how the pom is configured. If I specify that revision 2.1
>>>> is
>>>> required in the pom file then the build will break because version 2.1
>>>> of
>>>> the library is no longer available. If I don't specify this, then maven
>>>> will
>>>> attempt to build against version 2.2 which may fail due to
>>>> incompatibilities, and even if it succeeds, it won't be the same bits I
>>>> would have gotten had I built against version 2.1.
>>>
>>> Ok... I have always used required... so I have never seen it pick the
>>> latest. I have also not seen the items go away.. but I understand the
>>> issue.
>>
>> One of the main issues that even caused a split in the maven community
>> was in the maven plugins versioning rather than the libraries we
>> specify.
>> Sure you can use required for the apps dependencies but not the mave
>> core plugins that will update themselves making repeatability between
>> builds difficult. Two developers can perform a build at the same time
>> and get a different result. For me this is the biggest failing of
>> maven.
>>
>> Martin
>>
>>>> With ant we have all the dependencies stored in svn, so if I roll back
>>>> to
>>>> an older version of qpid and do a rebuild, then I know I'll get exactly
>>>> the
>>>> same bits I would have gotten had I done a build when that version was
>>>> current.
>>>
>>> Can the ivy setup Aiden mentioned populate/update the lib directory? That
>>> way they latest can be checked in and we can use a single depdendency
>>> data
>>> to build and create poms.
>>>
>
> Ok.. I get it it now. As I understand Aiden's idea in ivy is to pull the
> dependenr libraries from maven repos, but not to use maven as the build.

Aidan, So don't we still get into the same problem if the maven repos
no longer carry the version we require?
Ivy could produce repeatable builds assuming the maven repos still
carry the version we need.
Perhaps I am missing something here??

>  Does that help clear it up? My goal would not be to move to maven.. but to
> spit out maven artifacts for those who want to use maven. This is why I
> think we only need the artifats for the client bits. (qpid-common,
> qpid-client, qpid-management-*)

There is definitely value in publishing the client bits in maven repos
as a few projects that use maven wants to use Qpid.

>
> -- bk
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>



-- 
Regards,

Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Re: RFC: Maven and the Java Build

[Bryan Kearney <bk...@redhat.com>]

Martin Ritchie wrote:
> 2009/6/24 Bryan Kearney <bk...@redhat.com>:
>> Rafael Schloming wrote:
>>> Bryan Kearney wrote:
>>>> Rafael Schloming wrote:
>>>>> Bryan Kearney wrote:
>>>>>> Aidan Skinner wrote:
>>>>>>> On Wed, Jun 24, 2009 at 3:59 PM, Bryan Kearney<bk...@redhat.com>
>>>>>>> wrote:
>>>>>>>>> The main issue is that for dep resolution it still needs something
>>>>>>>>> looks like a maven repo, not like /usr/java. I think a new resolver
>>>>>>>>> wouldn't be very hard to write, but I haven't found the cycles for
>>>>>>>>> it
>>>>>>>>> yet.
>>>>>>>>>
>>>>>>>> Why is it bad to use the maven repos instead of copying things from
>>>>>>>> java/lib?
>>>>>>> It makes reproducible builds hard/impossible and doesn't play well
>>>>>>> with package systems.
>>>>>>>
>>>>>> I have not seen the former issue.. but I will trust you on it. On the
>>>>>> latter (package systems) using maven repos seems no worse then what is being
>>>>>> done now.
>>>>> The issue with using maven repos is that if you happen to use svn to
>>>>> rollback to a version where we were using maven, the build will most likely
>>>>> fail because it is dependent on a set of external maven repos that are no
>>>>> longer in sync with the needs of that particular revision.
>>>>>
>>>> sorry to be dense.. if I am using version 2.2 of a libarary, and then
>>>> rollback to version 2.1...how does that cause an issue with the build?
>>> If I try to build an older version of qpid that requires version 2.1, and
>>> the maven repo only has version 2.2 then one of two things will happen
>>> depending on how the pom is configured. If I specify that revision 2.1 is
>>> required in the pom file then the build will break because version 2.1 of
>>> the library is no longer available. If I don't specify this, then maven will
>>> attempt to build against version 2.2 which may fail due to
>>> incompatibilities, and even if it succeeds, it won't be the same bits I
>>> would have gotten had I built against version 2.1.
>> Ok... I have always used required... so I have never seen it pick the
>> latest. I have also not seen the items go away.. but I understand the issue.
> 
> One of the main issues that even caused a split in the maven community
> was in the maven plugins versioning rather than the libraries we
> specify.
> Sure you can use required for the apps dependencies but not the mave
> core plugins that will update themselves making repeatability between
> builds difficult. Two developers can perform a build at the same time
> and get a different result. For me this is the biggest failing of
> maven.
> 
> Martin
> 
>>> With ant we have all the dependencies stored in svn, so if I roll back to
>>> an older version of qpid and do a rebuild, then I know I'll get exactly the
>>> same bits I would have gotten had I done a build when that version was
>>> current.
>> Can the ivy setup Aiden mentioned populate/update the lib directory? That
>> way they latest can be checked in and we can use a single depdendency data
>> to build and create poms.
>>

Ok.. I get it it now. As I understand Aiden's idea in ivy is to pull the 
dependenr libraries from maven repos, but not to use maven as the build. 
  Does that help clear it up? My goal would not be to move to maven.. 
but to spit out maven artifacts for those who want to use maven. This is 
why I think we only need the artifats for the client bits. (qpid-common, 
qpid-client, qpid-management-*)

-- bk



---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Re: RFC: Maven and the Java Build

[Martin Ritchie <ri...@apache.org>]

2009/6/24 Bryan Kearney <bk...@redhat.com>:
> Rafael Schloming wrote:
>>
>> Bryan Kearney wrote:
>>>
>>> Rafael Schloming wrote:
>>>>
>>>> Bryan Kearney wrote:
>>>>>
>>>>> Aidan Skinner wrote:
>>>>>>
>>>>>> On Wed, Jun 24, 2009 at 3:59 PM, Bryan Kearney<bk...@redhat.com>
>>>>>> wrote:
>>>>>>>>
>>>>>>>> The main issue is that for dep resolution it still needs something
>>>>>>>> looks like a maven repo, not like /usr/java. I think a new resolver
>>>>>>>> wouldn't be very hard to write, but I haven't found the cycles for
>>>>>>>> it
>>>>>>>> yet.
>>>>>>>>
>>>>>>> Why is it bad to use the maven repos instead of copying things from
>>>>>>> java/lib?
>>>>>>
>>>>>> It makes reproducible builds hard/impossible and doesn't play well
>>>>>> with package systems.
>>>>>>
>>>>> I have not seen the former issue.. but I will trust you on it. On the
>>>>> latter (package systems) using maven repos seems no worse then what is being
>>>>> done now.
>>>>
>>>> The issue with using maven repos is that if you happen to use svn to
>>>> rollback to a version where we were using maven, the build will most likely
>>>> fail because it is dependent on a set of external maven repos that are no
>>>> longer in sync with the needs of that particular revision.
>>>>
>>>
>>> sorry to be dense.. if I am using version 2.2 of a libarary, and then
>>> rollback to version 2.1...how does that cause an issue with the build?
>>
>> If I try to build an older version of qpid that requires version 2.1, and
>> the maven repo only has version 2.2 then one of two things will happen
>> depending on how the pom is configured. If I specify that revision 2.1 is
>> required in the pom file then the build will break because version 2.1 of
>> the library is no longer available. If I don't specify this, then maven will
>> attempt to build against version 2.2 which may fail due to
>> incompatibilities, and even if it succeeds, it won't be the same bits I
>> would have gotten had I built against version 2.1.
>
> Ok... I have always used required... so I have never seen it pick the
> latest. I have also not seen the items go away.. but I understand the issue.

One of the main issues that even caused a split in the maven community
was in the maven plugins versioning rather than the libraries we
specify.
Sure you can use required for the apps dependencies but not the mave
core plugins that will update themselves making repeatability between
builds difficult. Two developers can perform a build at the same time
and get a different result. For me this is the biggest failing of
maven.

Martin

>>
>> With ant we have all the dependencies stored in svn, so if I roll back to
>> an older version of qpid and do a rebuild, then I know I'll get exactly the
>> same bits I would have gotten had I done a build when that version was
>> current.
>
> Can the ivy setup Aiden mentioned populate/update the lib directory? That
> way they latest can be checked in and we can use a single depdendency data
> to build and create poms.
>
> -- bk
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>



-- 
Martin Ritchie

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Re: RFC: Maven and the Java Build

[Bryan Kearney <bk...@redhat.com>]

Rafael Schloming wrote:
> Bryan Kearney wrote:
>> Rafael Schloming wrote:
>>> Bryan Kearney wrote:
>>>> Aidan Skinner wrote:
>>>>> On Wed, Jun 24, 2009 at 3:59 PM, Bryan Kearney<bk...@redhat.com> 
>>>>> wrote:
>>>>>>> The main issue is that for dep resolution it still needs something
>>>>>>> looks like a maven repo, not like /usr/java. I think a new resolver
>>>>>>> wouldn't be very hard to write, but I haven't found the cycles 
>>>>>>> for it
>>>>>>> yet.
>>>>>>>
>>>>>> Why is it bad to use the maven repos instead of copying things from
>>>>>> java/lib?
>>>>>
>>>>> It makes reproducible builds hard/impossible and doesn't play well
>>>>> with package systems.
>>>>>
>>>> I have not seen the former issue.. but I will trust you on it. On 
>>>> the latter (package systems) using maven repos seems no worse then 
>>>> what is being done now.
>>>
>>> The issue with using maven repos is that if you happen to use svn to 
>>> rollback to a version where we were using maven, the build will most 
>>> likely fail because it is dependent on a set of external maven repos 
>>> that are no longer in sync with the needs of that particular revision.
>>>
>>
>> sorry to be dense.. if I am using version 2.2 of a libarary, and then 
>> rollback to version 2.1...how does that cause an issue with the build?
> 
> If I try to build an older version of qpid that requires version 2.1, 
> and the maven repo only has version 2.2 then one of two things will 
> happen depending on how the pom is configured. If I specify that 
> revision 2.1 is required in the pom file then the build will break 
> because version 2.1 of the library is no longer available. If I don't 
> specify this, then maven will attempt to build against version 2.2 which 
> may fail due to incompatibilities, and even if it succeeds, it won't be 
> the same bits I would have gotten had I built against version 2.1.

Ok... I have always used required... so I have never seen it pick the 
latest. I have also not seen the items go away.. but I understand the issue.

> 
> With ant we have all the dependencies stored in svn, so if I roll back 
> to an older version of qpid and do a rebuild, then I know I'll get 
> exactly the same bits I would have gotten had I done a build when that 
> version was current.

Can the ivy setup Aiden mentioned populate/update the lib directory? 
That way they latest can be checked in and we can use a single 
depdendency data to build and create poms.

-- bk

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Re: RFC: Maven and the Java Build

[Rafael Schloming <ra...@redhat.com>]

Bryan Kearney wrote:
> Rafael Schloming wrote:
>> Bryan Kearney wrote:
>>> Aidan Skinner wrote:
>>>> On Wed, Jun 24, 2009 at 3:59 PM, Bryan Kearney<bk...@redhat.com> 
>>>> wrote:
>>>>>> The main issue is that for dep resolution it still needs something
>>>>>> looks like a maven repo, not like /usr/java. I think a new resolver
>>>>>> wouldn't be very hard to write, but I haven't found the cycles for it
>>>>>> yet.
>>>>>>
>>>>> Why is it bad to use the maven repos instead of copying things from
>>>>> java/lib?
>>>>
>>>> It makes reproducible builds hard/impossible and doesn't play well
>>>> with package systems.
>>>>
>>> I have not seen the former issue.. but I will trust you on it. On the 
>>> latter (package systems) using maven repos seems no worse then what 
>>> is being done now.
>>
>> The issue with using maven repos is that if you happen to use svn to 
>> rollback to a version where we were using maven, the build will most 
>> likely fail because it is dependent on a set of external maven repos 
>> that are no longer in sync with the needs of that particular revision.
>>
> 
> sorry to be dense.. if I am using version 2.2 of a libarary, and then 
> rollback to version 2.1...how does that cause an issue with the build?

If I try to build an older version of qpid that requires version 2.1, 
and the maven repo only has version 2.2 then one of two things will 
happen depending on how the pom is configured. If I specify that 
revision 2.1 is required in the pom file then the build will break 
because version 2.1 of the library is no longer available. If I don't 
specify this, then maven will attempt to build against version 2.2 which 
may fail due to incompatibilities, and even if it succeeds, it won't be 
the same bits I would have gotten had I built against version 2.1.

With ant we have all the dependencies stored in svn, so if I roll back 
to an older version of qpid and do a rebuild, then I know I'll get 
exactly the same bits I would have gotten had I done a build when that 
version was current.

--Rafael

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Re: RFC: Maven and the Java Build

[Bryan Kearney <bk...@redhat.com>]

Rafael Schloming wrote:
> Bryan Kearney wrote:
>> Aidan Skinner wrote:
>>> On Wed, Jun 24, 2009 at 3:59 PM, Bryan Kearney<bk...@redhat.com> 
>>> wrote:
>>>>> The main issue is that for dep resolution it still needs something
>>>>> looks like a maven repo, not like /usr/java. I think a new resolver
>>>>> wouldn't be very hard to write, but I haven't found the cycles for it
>>>>> yet.
>>>>>
>>>> Why is it bad to use the maven repos instead of copying things from
>>>> java/lib?
>>>
>>> It makes reproducible builds hard/impossible and doesn't play well
>>> with package systems.
>>>
>> I have not seen the former issue.. but I will trust you on it. On the 
>> latter (package systems) using maven repos seems no worse then what is 
>> being done now.
> 
> The issue with using maven repos is that if you happen to use svn to 
> rollback to a version where we were using maven, the build will most 
> likely fail because it is dependent on a set of external maven repos 
> that are no longer in sync with the needs of that particular revision.
> 

sorry to be dense.. if I am using version 2.2 of a libarary, and then 
rollback to version 2.1...how does that cause an issue with the build?

-- bk

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Re: RFC: Maven and the Java Build

[Rafael Schloming <ra...@redhat.com>]

Bryan Kearney wrote:
> Aidan Skinner wrote:
>> On Wed, Jun 24, 2009 at 3:59 PM, Bryan Kearney<bk...@redhat.com> 
>> wrote:
>>>> The main issue is that for dep resolution it still needs something
>>>> looks like a maven repo, not like /usr/java. I think a new resolver
>>>> wouldn't be very hard to write, but I haven't found the cycles for it
>>>> yet.
>>>>
>>> Why is it bad to use the maven repos instead of copying things from
>>> java/lib?
>>
>> It makes reproducible builds hard/impossible and doesn't play well
>> with package systems.
>>
> I have not seen the former issue.. but I will trust you on it. On the 
> latter (package systems) using maven repos seems no worse then what is 
> being done now.

The issue with using maven repos is that if you happen to use svn to 
rollback to a version where we were using maven, the build will most 
likely fail because it is dependent on a set of external maven repos 
that are no longer in sync with the needs of that particular revision.

The nice thing about the way it is now, is that I can do an svn update 
-r<foo> and rollback to any given version with the current build system 
and be fairly certain that the build will function because the only 
dependency stored outside of svn is ant, and that has a fairly small and 
stable footprint.

--Rafael


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Re: RFC: Maven and the Java Build

[Bryan Kearney <bk...@redhat.com>]

Aidan Skinner wrote:
> On Wed, Jun 24, 2009 at 3:59 PM, Bryan Kearney<bk...@redhat.com> wrote:
>>> The main issue is that for dep resolution it still needs something
>>> looks like a maven repo, not like /usr/java. I think a new resolver
>>> wouldn't be very hard to write, but I haven't found the cycles for it
>>> yet.
>>>
>> Why is it bad to use the maven repos instead of copying things from
>> java/lib?
> 
> It makes reproducible builds hard/impossible and doesn't play well
> with package systems.
> 
I have not seen the former issue.. but I will trust you on it. On the 
latter (package systems) using maven repos seems no worse then what is 
being done now.

-- bk


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Re: RFC: Maven and the Java Build

[Aidan Skinner <ai...@gmail.com>]

On Wed, Jun 24, 2009 at 3:59 PM, Bryan Kearney<bk...@redhat.com> wrote:
>> The main issue is that for dep resolution it still needs something
>> looks like a maven repo, not like /usr/java. I think a new resolver
>> wouldn't be very hard to write, but I haven't found the cycles for it
>> yet.
>>
> Why is it bad to use the maven repos instead of copying things from
> java/lib?

It makes reproducible builds hard/impossible and doesn't play well
with package systems.

- 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

Re: RFC: Maven and the Java Build

[Bryan Kearney <bk...@redhat.com>]

Aidan Skinner wrote:
> On Wed, Jun 24, 2009 at 3:28 PM, Bryan Kearney<bk...@redhat.com> wrote:
> 
>> So.. I would like to solicit thoughts from folks.
>>
>> 1) Do you have a desire/need for maven artifacts for the Java bits? If so,
>> which java bits?
>> 2) Have you seen good examples of how to manage pom files as well as
>> dependencies in the ant or standard build system.
> 
> I've been looking into using ivy to manage or deps for this purpouse.
> It can produce proper poms automagically, which is quite neat.

I have not used it, but I have heard good things about it.

> 
> The main issue is that for dep resolution it still needs something
> looks like a maven repo, not like /usr/java. I think a new resolver
> wouldn't be very hard to write, but I haven't found the cycles for it
> yet.
> 
Why is it bad to use the maven repos instead of copying things from 
java/lib?

-- bk


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Re: RFC: Maven and the Java Build

[Aidan Skinner <ai...@gmail.com>]

On Wed, Jun 24, 2009 at 3:28 PM, Bryan Kearney<bk...@redhat.com> wrote:

> So.. I would like to solicit thoughts from folks.
>
> 1) Do you have a desire/need for maven artifacts for the Java bits? If so,
> which java bits?
> 2) Have you seen good examples of how to manage pom files as well as
> dependencies in the ant or standard build system.

I've been looking into using ivy to manage or deps for this purpouse.
It can produce proper poms automagically, which is quite neat.

The main issue is that for dep resolution it still needs something
looks like a maven repo, not like /usr/java. I think a new resolver
wouldn't be very hard to write, but I haven't found the cycles for it
yet.

- 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