On Nov 2, 2010, at 4:12 AM, Ralph Goers wrote: > > 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? >
Sure, they are all for JVM-based languages. It makes no difference to me how they state their dependencies, I don't mind doing the work to make sure we have interoperability. Polyglot is where the innovation is going to happen even though most people will be using Maven proper. Enabling the other formats is a priority for me because the amount of work being done in the other build tools is staggering. I want to help those folks, and capture their energy if possible. Lots of good stuff going on there. If someone wanted to do the work to support Gradel I would absolutely support it. Why not? I'm not saying it's ever anything that would go into Maven proper but if another group wanted to leverage Maven's internals then that's something I will encourage. I will do anything to prevent people having to re-implement build tool or repository logic. > It would be unfortunate to have this get out of control and have the repo end > up a mess. > You're preaching to the choir. More unfortunate would be to have every other build tool go off and write their own complete system. >>> >>> 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. > That's what I said. >> >>> 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 > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language
