On Nov 2, 2010, at 12:14 AM, Stephen Connolly wrote: > I wasn't saying my use cases were in scope for polyglot's requirements. >
I'm talking generally for the model vN to model vN translation. Reduction is orthogonal to translation, it's a transformation. I'm thinking along the lines of making same canonical representation, not changing it. > I was saying my use cases were in scope for arguing that we deploy > multiple POM's to the repo. Interoperability involving selective reduction versus interoperability of the same canonical model is what we're talking about. I think the selective reduction to the model which is a superset of what I think should first be attempted. If you let users reduce what they liked you're likely to have no operability, that would certainly need to be bounded from our side I think. > > one POM must always be a 4.0.0 XML representation of the project Not following, because that's won't be the case for an altered model in 3.1. Say model 4.1. > , 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 > Right the lowest common denominator will be model version 4.0.0. > -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 > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society
