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 to? 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. >> Ralph --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
