I wasn't saying my use cases were in scope for polyglot's requirements. I was saying my use cases were in scope for arguing that we deploy multiple POM's to the repo.
one POM must always be a 4.0.0 XML representation of the project, but it may not be the same as the other versions, as long as an automated process does the mapping ONTO the 4.0.0 XML representation -Stephen On 1 November 2010 23:04, Jason van Zyl <ja...@maven.org> wrote: > > On Nov 1, 2010, at 11:59 PM, Stephen Connolly wrote: > >> 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. >> > > Yes, my assumption for Polyglot is the front-end format could be anything, > but an XML 4.0.0 POM must go to the repository. > >> 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. > > This is out of scope. For interoperability, within the same model the > selective reduction of the representation is a different problem. > >> >> e.g. I may not want people contacting me directly just because I >> worked for XYZ corp on that foobar-impl project > > Out of scope. > >> >> e.g. May not want to publish how the artifact is built for external persons. >> > > Out of scope. > > I think any form of selective reduction is not an interoperability problem > per se. I don't want to conflate model reduction with the translations of > models of the same version. > >> 2. Shading >> > > Not sure what this has to do with it. The shade plugin can already make a > reduced dependency POM if you like. > >> 3. Backwards compat. >> > > Sure, which is 2) when we start making changes to the POM. > >> 4. Properties behaving badly >> > > You'll have to explain here. I honestly don't know what you mean here. > >> -Stephen >> >> On 1 November 2010 22:37, Jason van Zyl <ja...@maven.org> 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 > --------------------------------------------------------- > > A language that doesn’t affect the way you think about programming is not > worth knowing. > > -— Alan Perlis > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
