I think we need to get use to the idea of deploying a different POM (as XML) from the POM that is used to build.
Here are some use-cases I can see: 1. Corporate project which deploys an artifact to a public repo. Some of the info (e.g. SCM details, developers, build, distMgmt, etc) is, due to corporate policies / sensible reasons, information that should not be deployed publically. e.g. I may not want people contacting me directly just because I worked for XYZ corp on that foobar-impl project e.g. May not want to publish how the artifact is built for external persons. 2. Shading 3. Backwards compat. 4. Properties behaving badly -Stephen On 1 November 2010 22:37, Jason van Zyl <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
