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. > 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? > > 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. > However, I agree that a 4.0.0 pom should be generated from the new model. > > Ralph > > On Nov 1, 2010, at 3:37 PM, Jason van Zyl wrote: > >> I am working on a release of Polyglot Maven and the only tangible thing >> stopping me is having a plan for POM interoperability between: >> >> 1) Different representations of the model for the same version of the model. >> This is what I'd like for the first version of Polyglot Maven where I just >> want to translate the version 4.0.0 model between different representations. >> >> 2) Different versions of the model. This is something we will need for Maven >> 3.1. >> >> In talking with Benjamin and Brian for 1) I think it would be easiest to >> deploy both versions of the model. The complete model in the native dialect >> like Clojure, and the complete XML translation. Deploying both would be >> useful because in the case of Clojure they are trying to come up with a >> common model, like the POM, for Clojure-based build tools. So if someone >> built and deployed with Polyglot Maven using the Clojure dialect then they >> want people not using Polyglot Maven i.e. a native Clojure tool to read the >> Clojure. This assumes our models are compatible but we'll have to work that >> out. We need to start somewhere so I don't think abbreviating any of the >> information is good for a first pass. Leave it all there for now and we'll >> figure out if a build-only representation of the model will suffice for >> sending to the repository. >> >> For 2) Benjamin's recommendation was to transform elements in the newer >> model back to the 4.0.0 model. I'm not sure how long this will be possible >> but if we live with our baggage and say we'll only add elements to the model >> I think this will be a lot easier. Having to track removals across versions >> of the model will be a pain in the ass. We translate back for as long as we >> can and when we can't do that anymore maybe we do a build-only >> transformation. >> >> I'd like to field other thoughts before I write something up. I'm going to >> do all this work in Polyglot Maven because I'm sure I'm going to break >> things but the folks I'm working with will tolerate this for a while. I'm >> chatting with folks in the Clojure community on a Lein-like markup, Dhanji >> (a Googler working on Guice and Sitebricks) who is working on a format >> called Atom, and Kristian (fellow who makes all the Ruby/Maven tooling) who >> is working on a Ruby DSL. If things break here for a while it's not the end >> of the world and is a good testing ground. >> >> At any rate if anyone has ideas or documents I'll integrate it into the >> proposal I'm writing. I'm moving pretty fast and I plan to release a version >> of the Maven Shell next week, and then a couple weeks later a version with >> Polyglot capabilities. So if you have thoughts I'd appreciate them sooner >> rather then later. >> >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> --------------------------------------------------------- >> >> Selfish deeds are the shortest path to self destruction. >> >> -- The Seven Samuari, Akira Kurosawa >> >> >> > > > --------------------------------------------------------------------- > 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 --------------------------------------------------------- You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
