maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: POM interoperability
Date Tue, 02 Nov 2010 03:12:21 GMT

On Nov 1, 2010, at 7:36 PM, Jason van Zyl wrote:

> On Nov 2, 2010, at 3:29 AM, Ralph Goers wrote:
>> I'm not sure I understand. Is the proposal here to deploy non-XML project descriptors
to the repository in addition to the standard pom?  If so, what is the point?  
> In the case of the Clojure dialect there will be two other implementations using the
same dialect. Lein, Cake, and Polyglot Maven. Lein and Cake want to deal with the Clojure
format. So it's not skin off my back if we deploy another format, it's not going to harm anyone
and help them. Polyglot Maven could deal with either but there tools might not be able to.
Should they use the bits in Polyglot Maven. I'd like that but I can't make them. 

Yes, but...
>> Many projects aren't going to bother creating multiple dialects of poms and so the
variations will still have to handle the traditional pom.  Are you planning on adding something
to Nexus to translate poms into the other language(s) to handle that so the tools don't have

this is the part that concerns me. How are these projects planning on handling existing artifacts
- I'm assuming as least some of the things they are working with can consume Java artifacts?
 Do you also want to support Gradle build files somehow?

It would be unfortunate to have this get out of control and have the repo end up a mess.

>> As for a new version of the model, this is something that has been on the table for
quite a while and what should go in it should be discussed before code gets committed.  
> Interoperability is step 1. Without figuring that out nothing gets changed/added.

I remember having this discussion a year ago in Oakland with Brian. It seemed pretty sensible
then to leave the 4.0.0 pom alone and create a new file. A project using the new model would
cause a 4.0.0 pom to be deployed in addition to the new model during a release.

>> However, I agree that a 4.0.0 pom should be generated from the new model.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message