You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@maven.org> on 2010/11/01 23:37:53 UTC
POM interoperability
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
Re: POM interoperability
Posted by Jason van Zyl <ja...@maven.org>.
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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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
Re: POM interoperability
Posted by Stephen Connolly <st...@gmail.com>.
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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM interoperability
Posted by Jason van Zyl <ja...@maven.org>.
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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
Re: POM interoperability
Posted by Stephen Connolly <st...@gmail.com>.
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 <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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM interoperability
Posted by Jason van Zyl <ja...@maven.org>.
On Nov 2, 2010, at 8:25 AM, Brett Porter wrote:
> On 01/11/2010, at 6:37 PM, Jason van Zyl wrote:
>
>> 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.
>
>
> Not had time to read all the mail on list in the last few hours, but in the interest of sooner rather than later...
>
> I've posted some thoughts on this to the list before, and planned to dig it up by Wednesday for the meetup. I'd also hacked together support into the branch of 2.x that works with attributes. At the most basic, I'm thinking we should deploy a trimmed version under the 4.0.0 model to the repository as the interchangable format under the current layout, then the actual model as it stands at the time separately.
>
You have absolutely no idea how the information would be used. Why would you, as a first step, reduce the model before you even know how it's going to be used.
To me the order of precedence is:
1. vN model to vN model translation. Albeit no one here may be interested in that because it's specifically for Polyglot but this one is relatively simple. Straight up translation and deployment of both models.
2. vN+1 to VN model translation. This is what we should be most interested in for 3.1. where the operating model for Maven 3.1 (4.1) must be downgraded to operate with Maven 3.0/2.2 (4.0.0) and both models deployed.
Let's please be realistic about the work that's going to be done. Selective reduction of the model is a nice idea but not required, and not going to impact interoperability. That's a nice to have in the future but we should be pragmatic and tackle the simpler forms of interoperability before tackling something more complicated.
> It would be nice to consider a long term migration to extensible metadata for this aspect of the repository, while retaining original artifacts as a separate file.
>
Again, we should start simple. We have consider forward and backward metadata in p2 repositories and that is a lot of work and a ton of testing. I've absolutely no evidence here in the last year that this project can deliver that. I would propose we do work with the p2 folks as their repository metadata format is more sophisticated then ours and ultimately merging the metadata models would make sense as then we have a whole other body of developers working on the problem.
But seriously, I urge folks to be pragmatic and tackle the simple models of interoperability. We don't need to boil the ocean to make 3.1 work. I think model reduction while coming up with a plan for interoperability is a recipe for disaster.
> Cheers,
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people.
-- Paul Graham
Re: POM interoperability
Posted by Brett Porter <br...@apache.org>.
On 01/11/2010, at 6:37 PM, Jason van Zyl wrote:
> 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.
Not had time to read all the mail on list in the last few hours, but in the interest of sooner rather than later...
I've posted some thoughts on this to the list before, and planned to dig it up by Wednesday for the meetup. I'd also hacked together support into the branch of 2.x that works with attributes. At the most basic, I'm thinking we should deploy a trimmed version under the 4.0.0 model to the repository as the interchangable format under the current layout, then the actual model as it stands at the time separately.
It would be nice to consider a long term migration to extensible metadata for this aspect of the repository, while retaining original artifacts as a separate file.
Cheers,
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM interoperability
Posted by Brian Fox <br...@infinity.nu>.
>So if they wanted to we can't stop them using what's available in Aether APIs anyway. So I >suppose we could leave it up to them. I don't see the big deal really.
Sure but lets give them a standard to follow for this and try to
prevent it from exploding randomly.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM interoperability
Posted by Jason van Zyl <ja...@maven.org>.
On Nov 4, 2010, at 7:04 PM, Brian Fox 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.
>
> If everything gets converted to the standard pom format, what use is
> there having the alternate forms of their pom in the repo? If I depend
> on something, I don't care how they built it, just that the pom has
> the correct dependency information.
>
If everything used Aether with the Maven connector then the interoperable XML format is all that would be required. Right now in Clojure-world there is PolyglotMaven, Cake and Leinigen. I'm not sure either of them do transitive dependencies, or just turn GAVs in their native format into URLs and just grab artifacts directly. If they don't happen to use Aether then they might want to use their format directly. They may want to crawl their repositories using tools written in Clojure processing their .clj files to do whatever. I don't know what these groups may ultimately do.
> If you think the native info absolutely must be there for some other
> reason, then I think it should be in a standard file to avoid an
> explosion of unmanaged crap polluting the repo. Something like:
> foo-1.0.pom and foo-1.0.native where native can contain any dialect
> but is prefaced by a header describing what dialect it is. What I
> wouldn't want to see is randomly named standards popping up for every
> new dialect.
Within the Maven world, I'm fine being fairly strict. But anything emitted in other dialects is not really going to cause Maven any grief and if having the native format makes these other folks happier and prevents them from rewriting bits I honestly don't think having a few extra bits in the repository matters. It's like another attached artifact? In fact nothing would stop them from just doing that anyway in their deployment phase using Aether. So if they wanted to we can't stop them using what's available in Aether APIs anyway. So I suppose we could leave it up to them. I don't see the big deal really.
>
> No one disagrees with the rest of what you said here about leveraging
> the energy of the communities, I think the concern is simply that it
> be done in a bounded way to keep the repo contents fairly normalized.
I think it's bounded if there is always the XML format. The native formats being deployed won't affect Maven at all. We may find all of them use Aether and it's never required
>
> BTW this concept of native vs pom could apply to how we manage future
> maven pom formats. Maven 3.1, 4 ,5 could all be valid native layouts
> where the dependency info is translated back to the v4 pom we have
> today. It is a mix of concerns to have both the build info and the
> dependency info described in the same file in the repo.
>
Sure.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
We know what we are, but know not what we may be.
-- Shakespeare
Re: POM interoperability
Posted by Stephen Connolly <st...@gmail.com>.
On 4 November 2010 18:04, Brian Fox <br...@infinity.nu> 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.
>
> If everything gets converted to the standard pom format, what use is
> there having the alternate forms of their pom in the repo? If I depend
> on something, I don't care how they built it, just that the pom has
> the correct dependency information.
>
The only issue I have is that the 4.0.0 scopes are too restrictive in
terms of dependency information.
we really need something like <scope>implements</scope> or
<scope>bundled</scope>
to allow removing duplicate dependencies
Otherwise +1 to all of what you (Brian) said
-Stephen
>
> If you think the native info absolutely must be there for some other
> reason, then I think it should be in a standard file to avoid an
> explosion of unmanaged crap polluting the repo. Something like:
> foo-1.0.pom and foo-1.0.native where native can contain any dialect
> but is prefaced by a header describing what dialect it is. What I
> wouldn't want to see is randomly named standards popping up for every
> new dialect.
>
> No one disagrees with the rest of what you said here about leveraging
> the energy of the communities, I think the concern is simply that it
> be done in a bounded way to keep the repo contents fairly normalized.
>
> BTW this concept of native vs pom could apply to how we manage future
> maven pom formats. Maven 3.1, 4 ,5 could all be valid native layouts
> where the dependency info is translated back to the v4 pom we have
> today. It is a mix of concerns to have both the build info and the
> dependency info described in the same file in the repo.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM interoperability
Posted by Brian Fox <br...@infinity.nu>.
>>>> 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.
If everything gets converted to the standard pom format, what use is
there having the alternate forms of their pom in the repo? If I depend
on something, I don't care how they built it, just that the pom has
the correct dependency information.
If you think the native info absolutely must be there for some other
reason, then I think it should be in a standard file to avoid an
explosion of unmanaged crap polluting the repo. Something like:
foo-1.0.pom and foo-1.0.native where native can contain any dialect
but is prefaced by a header describing what dialect it is. What I
wouldn't want to see is randomly named standards popping up for every
new dialect.
No one disagrees with the rest of what you said here about leveraging
the energy of the communities, I think the concern is simply that it
be done in a bounded way to keep the repo contents fairly normalized.
BTW this concept of native vs pom could apply to how we manage future
maven pom formats. Maven 3.1, 4 ,5 could all be valid native layouts
where the dependency info is translated back to the v4 pom we have
today. It is a mix of concerns to have both the build info and the
dependency info described in the same file in the repo.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM interoperability
Posted by Jason van Zyl <ja...@maven.org>.
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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
Re: POM interoperability
Posted by Ralph Goers <ra...@dslextreme.com>.
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?
It would be unfortunate to have this get out of control and have the repo end up a mess.
>>
>> 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.
>
>> However, I agree that a 4.0.0 pom should be generated from the new model.
>>
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM interoperability
Posted by Jason van Zyl <ja...@maven.org>.
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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
Re: POM interoperability
Posted by Ralph Goers <ra...@dslextreme.com>.
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? 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. 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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org