Re: Evolving the POM format
Hi there, have you seen our work at mojo[haus] with flatten-maven-plugin? http://www.mojohaus.org/flatten-maven-plugin/examples/example-central-version.html http://www.mojohaus.org/flatten-maven-plugin/examples/example-multiple-versions.html This is already used by various projects for productive deployment. https://github.com/oasp/oasp4j/ https://github.com/m-m-m/mmm/ (clone this one recursive as it uses git modules). So with this setup it is possible to have a lot of specific build-logic and internal stuff in your pom.xml using variables for version and a lot of other things. But we deploy "flattened" POMs to the maven repo that contain the required stuff for consumers of the artefact with all variables resolved and parent removed. I argued to separate build/developers view from consumer view in maven on this mailing list already in 2009 - see e.g. https://issues.apache.org/jira/browse/MNG-4161 Unfortunately I got little to no attention those days... However, I am happy to see new movement in this area. I was kind of frustrated and fortunately Robert Scholte supported me on mojo to get the missing links of flatten-maven-plugin to work with maven core's internal tricks. If this would be done natively by maven 4.x and we can introduce a new pom format that maven 4.x can read but for deployment still model version 4.0.0 is installed and deployed this would be just perfect. Maybe then we could also revisit my suggestions to allow omitting the version in dependency and parent tags for being DRY (Dont Repeat Yourself). Thanks Jörg Am 19.06.2014 um 15:40 schrieb Jason van Zyl: > We had the hangout yesterday. I pushed the initial bit of information about > evolving the POM format here in a blog post here: > > http://localhost:4000/2014/06/19/hangout-pom-format.html > > And created a page in the Wiki to start capturing the information: > > https://cwiki.apache.org/confluence/display/MAVEN/Evolving+the+POM+Format > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > - > > the course of true love never did run smooth ... > > -- Shakespeare > > > > > > > > > > smime.p7s Description: S/MIME Cryptographic Signature
Re: Evolving the POM format
In the case of a multi module build - or any reactor build I think a valid rule would be all poms should be compatible with the maven version being used. Maybe even as far as to say the same version. Mind you - I'm also largely of the opinion that support for multi module should be deprecated/removed - but that's a separate story. ... Sent from Android On 20/06/2014 3:51 am, "Stephen Connolly" wrote: > If backwards compatible interoperability is not a requirement then: > > If I upgrade one module in my multi-module build to Maven 5.1 then I am > forced right then and there to either: > > * upgrade all of them to Maven 5.1; or > * remove the module from my multi-module build > > Neither of these are a good user experience in my mind. Maven 5.1 should be > able to build a Maven [2.0,5.1] project without modifying the pom... it can > do that by loading shim layers on demand if necessary, but to my thinking > anything less is going to cause issues for users. > > > So to my thinking we just accept that Maven needs to evolve such that for > every version X.Y of Maven you know that you can build a Maven project from > the range [2.0,X.Y]. > > If you have a project that has a parent, then the parent must be in a pom > format that buildable by Maven [2.0,${project.prerequisites.maven}], so a > child pom requiring Maven 5.1 to build can have a parent pom that requires > Maven 5.0 to build but not a parent pom requiring Maven 5.2... there may > even be turtles all the way down to an ancestor pom that requires Maven > [2.0,3.0.3] to build (IIRC after 3.0.3 you get things like wildcards in > excludes due to aether injecting "bonus" functionality... that should have > been a modelVersion bump in the strictest sense... but well it wasn't) > > I also think people overestimate how difficult it is to maintain backwards > compatibility. > > I have a Jenkins plugin that was written against Hudson 1.96 and I can take > that .hpi file and drop it into Jenkins 1.568 and it still works > unmodified. Similarly I can upgrade a Jenkins installation jumping quite a > large number of versions without issue. > > It is possible to evolve and maintain the ability to read older data... is > it easy? well it's not trivial, but it is a disservice to our users if we > don't try > > > On 19 June 2014 16:24, Paul Benedict wrote: > > > I am curious why you interoperability as a requirement? Perhaps > questioning > > that may seem outrageous, but I see no problem with saying that you need > to > > upgrade to Maven X.Y to read newer POM formats. If a vendor wants to > > backport their project into older POM formats, that should be the > vendor's > > shoulders and not be a concern of Maven core. If Maven does publish older > > formats of POMs, you then have to decide how many older formats do you > want > > to publish? One day there will be a 4.1 or 5.0, and it's going to > > complicate the world if Maven takes on the burden of interoperability. > > > > > > Cheers, > > Paul > > > > > > On Thu, Jun 19, 2014 at 9:57 AM, Stephen Connolly < > > stephen.alan.conno...@gmail.com> wrote: > > > > > On 19 June 2014 15:48, Igor Fedorenko wrote: > > > > > > > > > > > > > > > On 2014-06-19, 10:30, Stephen Connolly wrote: > > > > > > > >> - Igor is*mostly* right in that we should not deploy the pom that > is > > > used > > > >> > > > >> to build to the repository... > > > >> - Where Igor is wrong is that for pom we > should > > > >> actually deploy the build time pom to the repository... probably > with > > > the > > > >> classifier `build`... this is safe as `pom` does cannot have a > > > classifier > > > >> in model version 4.0.0. > > > >> - You couple that with a simple and obvious restriction... your > parent > > > >> must > > > >> be the same or earlier version of Maven. You cannot have as a > parent a > > > >> newer version of Maven than the child is built with. > > > >> > > > > > > > > I think there is more to this. > > > > > > > > At very least we need to decide what to do with in 4.0.0 > > > > compatible poms. Maybe we should always deploy effective pom with > > > > build-related elements removed. > > > > > > > > > > Well I think the simple thing is that the 4.0.0 pom is fully resolved > > when > > > you have a builder pom > > > > > > > > > > > > > > I am also not sure if it is enough to deploy "build" parent poms as > is. > > > > Your suggested "parent must be the same or earlier version of Maven" > > > > implies new versions of Maven can read older pom formats, which I > think > > > > will significantly limit our flexibility to evolve pom format. > > > > > > > > > They need to be able to parse it into the model. Perhaps they do the > > > parsing by downloading a parser. But I think it is reasonable to expect > > > that we can convert older build pom formats into newer ones and just > let > > > Maven take care of it... if we cannot do that then we are really > > creating a > > > brand new build tool rather than evolving Maven > > > >
Re: Evolving the POM format
I'm not sure I like the idea deploying a resolved/effective parent POM - simply because a parent is essentially the same as an abstract class or a template: it can't be used on its own. It's only non-parents that get build, get profiles activated on etc. ... Sent on android On 20/06/2014 2:48 am, "Igor Fedorenko" wrote: > > > On 2014-06-19, 10:30, Stephen Connolly wrote: > >> - Igor is*mostly* right in that we should not deploy the pom that is used >> to build to the repository... >> - Where Igor is wrong is that for pom we should >> actually deploy the build time pom to the repository... probably with the >> classifier `build`... this is safe as `pom` does cannot have a classifier >> in model version 4.0.0. >> - You couple that with a simple and obvious restriction... your parent >> must >> be the same or earlier version of Maven. You cannot have as a parent a >> newer version of Maven than the child is built with. >> > > I think there is more to this. > > At very least we need to decide what to do with in 4.0.0 > compatible poms. Maybe we should always deploy effective pom with > build-related elements removed. > > I am also not sure if it is enough to deploy "build" parent poms as is. > Your suggested "parent must be the same or earlier version of Maven" > implies new versions of Maven can read older pom formats, which I think > will significantly limit our flexibility to evolve pom format. I wonder > if we can have different solution for force parent poms, like > org.apache:apache, which are used by multiple projects and different > versions of maven and project-specific parent poms, where it is much > easier to require specific version of maven. > > -- > Regards, > Igor > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Evolving the POM format
For the purpose of this discussion I created a component (not necessary user facing) call FDPFC which is "features dependent on pom format changes". I want to be able to easily see of the 200 open issues in JIRA which ones relate to this discussion. I am going to sift through the issues this weekend, but if anyone can recall a specific issue that is a feature requiring a POM format change can you tag it with the FDPFC please. On Jun 19, 2014, at 9:50 AM, Jesse McConnell wrote: > Thanks Jason, it was fun, we have been thinking about organizing > something like this for Jetty for a while now, maybe get Greg to go > through the new http/2 implementation and talk about the latest > draft...things like that. > > anyway, good fun! > jesse > -- > jesse mcconnell > jesse.mcconn...@gmail.com > > > On Thu, Jun 19, 2014 at 8:46 AM, Jason van Zyl wrote: >> Sorry I use Jekyll locally, the actual link is: >> >> http://takari.io/2014/06/19/hangout-pom-format.html >> >> On Jun 19, 2014, at 9:43 AM, Paul Benedict wrote: >> >>> Jason, I am sure accessing your localhost is blocked :-) >>> >>> >>> Cheers, >>> Paul >>> >>> >>> On Thu, Jun 19, 2014 at 8:40 AM, Jason van Zyl wrote: >>> >>>> We had the hangout yesterday. I pushed the initial bit of information >>>> about evolving the POM format here in a blog post here: >>>> >>>> http://localhost:4000/2014/06/19/hangout-pom-format.html >>>> >>>> And created a page in the Wiki to start capturing the information: >>>> >>>> https://cwiki.apache.org/confluence/display/MAVEN/Evolving+the+POM+Format >>>> >>>> Thanks, >>>> >>>> Jason >>>> >>>> -- >>>> Jason van Zyl >>>> Founder, Apache Maven >>>> http://twitter.com/jvanzyl >>>> http://twitter.com/takari_io >>>> - >>>> >>>> the course of true love never did run smooth ... >>>> >>>> -- Shakespeare >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> http://twitter.com/takari_io >> - >> >> the course of true love never did run smooth ... >> >> -- Shakespeare >> >> >> >> >> >> >> >> >> > > - > 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 http://twitter.com/takari_io - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha
Re: Evolving the POM format
Because users need to learn the new format. The version number is not just for machines but for people too On 20 June 2014 14:04, Igor Fedorenko wrote: > > > On 2014-06-20, 7:59, Stephen Connolly wrote: > >> +1 on semver. >> >> Also if we change the schema or even the format (eg elements -> >> attributes, >> xml -> DSL, etc) then we also bump the major even if there is a 1:1 >> bijection >> >> > If newer Maven versions can fully interpret new format without any loss > of configuration, why does the format need major version bump? > > -- > Regards, > Igor > > > > > On Friday, 20 June 2014, Igor Fedorenko wrote: >> >> I think ad-hoc aggregators are an interesting use case and I need to >>> think about it some more before I decide how I'd like to support it. >>> >>> Anyways, all changes I currently have in mind are additions to the model >>> and reading older formats will not be a problem. Lets decide what to do >>> with truly incompatible model changes when we have specific problem to >>> solve. >>> >>> But this got me thinking about something else. Can we agree on >>> semver-ish versioning scheme for pom formats? We increase minor part of >>> the format version to indicate perfect supersets, i.e. new features are >>> added but all old features continue to work as-is. We increase major >>> part when we remove supported elements or change meaning of existing >>> elements. >>> >>> -- >>> Regards, >>> Igor >>> >>> >>> On 2014-06-19, 20:22, Stephen Connolly wrote: >>> >>> On Friday, 20 June 2014, Igor Fedorenko wrote: I am not sure I follow. > > Do you want to allow multi-module projects where different modules > require different versions of maven? > > No I want to allow multi-module projects where the maximum modelVersion defines the minimum required version of maven to build. If required version of maven is the same, why not require the same pom > format version for the entire build too? > > Because I may be working on several things that I am throwing together in a local aggregator pom... Because I am working on a module that I cannot change the build process for and another module at the same time that needs the newer features Are you concerned about changes to pom.xml files when moving from one format version to the next or > something else? > > I want to be able to migrate modules to newer build poms when they are ready to do so. That may mean that I have a project with one child that can be built by Maven 2.0 another that needs maven 3.2.2 and a 3rd that needs maven 4.1. To build that reactor I need to use maven 4.1 or newer... Or I can not use a reactor and push things to the local repo and build the first module with maven 2.0, change my PATH, build the second module with maven 3.2.2, change my PATH again and build the last module with Maven 4.1... All pushing to the local repo... Hoping that we haven't changed the local repo format... Hoping that I've remembered to do that all correctly, and all for the same feature branch... Oh I got distracted and had to switch to a different branch and back again... Sorry start at the beginning again just to be sure. Ok, so we can use something like RVM so that as we cd into each module we pick up an .mvnenv file that causes our PATH to auto switch... But really? And for this to work we have two choices... Never evolve the local repo OR run a local remote repo to act as a maven version neutral exchange... Great now I've gone from `mvn clean verify` to `cd foo && mvn clean deploy -DaltDeploymentUrl=... && cd ../bar && mvn clean deploy -DaltDeploymentUrl=... && cd ../manchu && ...` that's just great that is! I argue that unless we keep the contract that newer maven can build all older maven projects, then there is no point even calling new maven "maven"... Does it have to build them perfectly? Perhaps not, I can live with needing to tweak things to iron out an inconsistency as long as after the tweak both new and old build that module the same... So, for example, if the old pom references ${pom.artifactId} and new maven cannot build that unless you change it to ${project.artifactId} that is OK in my book as both forms are legal in old maven so switching to the new one will not break old maven... (Obviously better if we don't fail in that case... Just trying to give a concrete example) The reason is that there is a pressure keeping me from advancing that module to Maven 4.1. Don't force me to jump through hoops just because some a-hole is keeping that module shackled to build with Maven 2.0.6 levels of compatibility...
Re: Evolving the POM format
On 2014-06-20, 7:59, Stephen Connolly wrote: +1 on semver. Also if we change the schema or even the format (eg elements -> attributes, xml -> DSL, etc) then we also bump the major even if there is a 1:1 bijection If newer Maven versions can fully interpret new format without any loss of configuration, why does the format need major version bump? -- Regards, Igor On Friday, 20 June 2014, Igor Fedorenko wrote: I think ad-hoc aggregators are an interesting use case and I need to think about it some more before I decide how I'd like to support it. Anyways, all changes I currently have in mind are additions to the model and reading older formats will not be a problem. Lets decide what to do with truly incompatible model changes when we have specific problem to solve. But this got me thinking about something else. Can we agree on semver-ish versioning scheme for pom formats? We increase minor part of the format version to indicate perfect supersets, i.e. new features are added but all old features continue to work as-is. We increase major part when we remove supported elements or change meaning of existing elements. -- Regards, Igor On 2014-06-19, 20:22, Stephen Connolly wrote: On Friday, 20 June 2014, Igor Fedorenko wrote: I am not sure I follow. Do you want to allow multi-module projects where different modules require different versions of maven? No I want to allow multi-module projects where the maximum modelVersion defines the minimum required version of maven to build. If required version of maven is the same, why not require the same pom format version for the entire build too? Because I may be working on several things that I am throwing together in a local aggregator pom... Because I am working on a module that I cannot change the build process for and another module at the same time that needs the newer features Are you concerned about changes to pom.xml files when moving from one format version to the next or something else? I want to be able to migrate modules to newer build poms when they are ready to do so. That may mean that I have a project with one child that can be built by Maven 2.0 another that needs maven 3.2.2 and a 3rd that needs maven 4.1. To build that reactor I need to use maven 4.1 or newer... Or I can not use a reactor and push things to the local repo and build the first module with maven 2.0, change my PATH, build the second module with maven 3.2.2, change my PATH again and build the last module with Maven 4.1... All pushing to the local repo... Hoping that we haven't changed the local repo format... Hoping that I've remembered to do that all correctly, and all for the same feature branch... Oh I got distracted and had to switch to a different branch and back again... Sorry start at the beginning again just to be sure. Ok, so we can use something like RVM so that as we cd into each module we pick up an .mvnenv file that causes our PATH to auto switch... But really? And for this to work we have two choices... Never evolve the local repo OR run a local remote repo to act as a maven version neutral exchange... Great now I've gone from `mvn clean verify` to `cd foo && mvn clean deploy -DaltDeploymentUrl=... && cd ../bar && mvn clean deploy -DaltDeploymentUrl=... && cd ../manchu && ...` that's just great that is! I argue that unless we keep the contract that newer maven can build all older maven projects, then there is no point even calling new maven "maven"... Does it have to build them perfectly? Perhaps not, I can live with needing to tweak things to iron out an inconsistency as long as after the tweak both new and old build that module the same... So, for example, if the old pom references ${pom.artifactId} and new maven cannot build that unless you change it to ${project.artifactId} that is OK in my book as both forms are legal in old maven so switching to the new one will not break old maven... (Obviously better if we don't fail in that case... Just trying to give a concrete example) The reason is that there is a pressure keeping me from advancing that module to Maven 4.1. Don't force me to jump through hoops just because some a-hole is keeping that module shackled to build with Maven 2.0.6 levels of compatibility... Because if Maven forces me to jump through those hoops... Congratulations, Maven is now an a-hole too. -- Regards, Igor On 2014-06-19, 11:50, Stephen Connolly wrote: If backwards compatible interoperability is not a requirement then: If I upgrade one module in my multi-module build to Maven 5.1 then I am forced right then and there to either: * upgrade all of them to Maven 5.1; or * remove the module from my multi-module build Neither of these are a good user experience in my mind. Maven 5.1 should be able to build a Maven [2.0,5.1] project without modifying the pom... it can do that by loading shim layers on demand if necessary, but to my thinking anything less is going to cause issues for u
Re: Evolving the POM format
+1 on semver. Also if we change the schema or even the format (eg elements -> attributes, xml -> DSL, etc) then we also bump the major even if there is a 1:1 bijection On Friday, 20 June 2014, Igor Fedorenko wrote: > I think ad-hoc aggregators are an interesting use case and I need to > think about it some more before I decide how I'd like to support it. > > Anyways, all changes I currently have in mind are additions to the model > and reading older formats will not be a problem. Lets decide what to do > with truly incompatible model changes when we have specific problem to > solve. > > But this got me thinking about something else. Can we agree on > semver-ish versioning scheme for pom formats? We increase minor part of > the format version to indicate perfect supersets, i.e. new features are > added but all old features continue to work as-is. We increase major > part when we remove supported elements or change meaning of existing > elements. > > -- > Regards, > Igor > > > On 2014-06-19, 20:22, Stephen Connolly wrote: > >> On Friday, 20 June 2014, Igor Fedorenko wrote: >> >> I am not sure I follow. >>> >>> Do you want to allow multi-module projects where different modules >>> require different versions of maven? >>> >> >> >> No I want to allow multi-module projects where the maximum modelVersion >> defines the minimum required version of maven to build. >> >> >>> If required version of maven is the same, why not require the same pom >>> format version for the entire build too? >>> >> >> >> Because I may be working on several things that I am throwing together in >> a local aggregator pom... Because I am working on a module that I cannot >> change the build process for and another module at the same time that >> needs >> the newer features >> >> Are you concerned about changes >> >>> to pom.xml files when moving from one format version to the next or >>> something else? >>> >> >> >> I want to be able to migrate modules to newer build poms when they are >> ready to do so. That may mean that I have a project with one child that >> can >> be built by Maven 2.0 another that needs maven 3.2.2 and a 3rd that needs >> maven 4.1. To build that reactor I need to use maven 4.1 or newer... Or I >> can not use a reactor and push things to the local repo and build the >> first >> module with maven 2.0, change my PATH, build the second module with maven >> 3.2.2, change my PATH again and build the last module with Maven 4.1... >> All >> pushing to the local repo... Hoping that we haven't changed the local repo >> format... Hoping that I've remembered to do that all correctly, and all >> for >> the same feature branch... Oh I got distracted and had to switch to a >> different branch and back again... Sorry start at the beginning again just >> to be sure. >> >> Ok, so we can use something like RVM so that as we cd into each module we >> pick up an .mvnenv file that causes our PATH to auto switch... But really? >> And for this to work we have two choices... Never evolve the local repo OR >> run a local remote repo to act as a maven version neutral exchange... >> Great >> now I've gone from `mvn clean verify` to `cd foo && mvn clean deploy >> -DaltDeploymentUrl=... && cd ../bar && mvn clean deploy >> -DaltDeploymentUrl=... && cd ../manchu && ...` that's just great that is! >> >> I argue that unless we keep the contract that newer maven can build all >> older maven projects, then there is no point even calling new maven >> "maven"... >> >> Does it have to build them perfectly? Perhaps not, I can live with needing >> to tweak things to iron out an inconsistency as long as after the tweak >> both new and old build that module the same... So, for example, if the old >> pom references ${pom.artifactId} and new maven cannot build that unless >> you >> change it to ${project.artifactId} that is OK in my book as both forms are >> legal in old maven so switching to the new one will not break old maven... >> (Obviously better if we don't fail in that case... Just trying to give a >> concrete example) >> >> The reason is that there is a pressure keeping me from advancing that >> module to Maven 4.1. Don't force me to jump through hoops just because >> some >> a-hole is keeping that module shackled to build with Maven 2.0.6 levels of >> compatibility... Because if Maven forces me to jump through those hoops... >> Congratulations, Maven is now an a-hole too. >> >> >> -- >>> Regards, >>> Igor >>> >>> On 2014-06-19, 11:50, Stephen Connolly wrote: >>> >>> If backwards compatible interoperability is not a requirement then: If I upgrade one module in my multi-module build to Maven 5.1 then I am forced right then and there to either: * upgrade all of them to Maven 5.1; or * remove the module from my multi-module build Neither of these are a good user experience in my mind. Maven 5.1 should be able to build a Maven [2.0,5.1] project without modifying the pom... it can
Re: Evolving the POM format
I think ad-hoc aggregators are an interesting use case and I need to think about it some more before I decide how I'd like to support it. Anyways, all changes I currently have in mind are additions to the model and reading older formats will not be a problem. Lets decide what to do with truly incompatible model changes when we have specific problem to solve. But this got me thinking about something else. Can we agree on semver-ish versioning scheme for pom formats? We increase minor part of the format version to indicate perfect supersets, i.e. new features are added but all old features continue to work as-is. We increase major part when we remove supported elements or change meaning of existing elements. -- Regards, Igor On 2014-06-19, 20:22, Stephen Connolly wrote: On Friday, 20 June 2014, Igor Fedorenko wrote: I am not sure I follow. Do you want to allow multi-module projects where different modules require different versions of maven? No I want to allow multi-module projects where the maximum modelVersion defines the minimum required version of maven to build. If required version of maven is the same, why not require the same pom format version for the entire build too? Because I may be working on several things that I am throwing together in a local aggregator pom... Because I am working on a module that I cannot change the build process for and another module at the same time that needs the newer features Are you concerned about changes to pom.xml files when moving from one format version to the next or something else? I want to be able to migrate modules to newer build poms when they are ready to do so. That may mean that I have a project with one child that can be built by Maven 2.0 another that needs maven 3.2.2 and a 3rd that needs maven 4.1. To build that reactor I need to use maven 4.1 or newer... Or I can not use a reactor and push things to the local repo and build the first module with maven 2.0, change my PATH, build the second module with maven 3.2.2, change my PATH again and build the last module with Maven 4.1... All pushing to the local repo... Hoping that we haven't changed the local repo format... Hoping that I've remembered to do that all correctly, and all for the same feature branch... Oh I got distracted and had to switch to a different branch and back again... Sorry start at the beginning again just to be sure. Ok, so we can use something like RVM so that as we cd into each module we pick up an .mvnenv file that causes our PATH to auto switch... But really? And for this to work we have two choices... Never evolve the local repo OR run a local remote repo to act as a maven version neutral exchange... Great now I've gone from `mvn clean verify` to `cd foo && mvn clean deploy -DaltDeploymentUrl=... && cd ../bar && mvn clean deploy -DaltDeploymentUrl=... && cd ../manchu && ...` that's just great that is! I argue that unless we keep the contract that newer maven can build all older maven projects, then there is no point even calling new maven "maven"... Does it have to build them perfectly? Perhaps not, I can live with needing to tweak things to iron out an inconsistency as long as after the tweak both new and old build that module the same... So, for example, if the old pom references ${pom.artifactId} and new maven cannot build that unless you change it to ${project.artifactId} that is OK in my book as both forms are legal in old maven so switching to the new one will not break old maven... (Obviously better if we don't fail in that case... Just trying to give a concrete example) The reason is that there is a pressure keeping me from advancing that module to Maven 4.1. Don't force me to jump through hoops just because some a-hole is keeping that module shackled to build with Maven 2.0.6 levels of compatibility... Because if Maven forces me to jump through those hoops... Congratulations, Maven is now an a-hole too. -- Regards, Igor On 2014-06-19, 11:50, Stephen Connolly wrote: If backwards compatible interoperability is not a requirement then: If I upgrade one module in my multi-module build to Maven 5.1 then I am forced right then and there to either: * upgrade all of them to Maven 5.1; or * remove the module from my multi-module build Neither of these are a good user experience in my mind. Maven 5.1 should be able to build a Maven [2.0,5.1] project without modifying the pom... it can do that by loading shim layers on demand if necessary, but to my thinking anything less is going to cause issues for users. So to my thinking we just accept that Maven needs to evolve such that for every version X.Y of Maven you know that you can build a Maven project from the range [2.0,X.Y]. If you have a project that has a parent, then the parent must be in a pom format that buildable by Maven [2.0,${project.prerequisites.maven}], so a child pom requiring Maven 5.1 to build can have a parent pom that requires Maven 5.0 to build but not a parent p
Re: Evolving the POM format
OK, when you have been referring to the build pom I thought you just meant the pom in the project source. You actually mean that source pom (perhaps flattened) deployed to the repository. I don't see any need for the build pom to be deployed except where the project has type="pom". Ie we intend for the pom itself to be consumed by another pom. This is what I was referring to as the (B) option. And why I believe it needs the build section. When/why would you want the build pom to be deployed for another type of artifact? William On Fri, Jun 20, 2014 at 10:39 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > On Friday, 20 June 2014, William Ferguson > wrote: > > > Stephen, I'm a little confused by the 3 POMs you have outlined. > > > > 1. The 4.0.0 flattened consumer pom > > > This is the pom for any consumers who only understand modelVersion 4.0.0 ie > Maven [2.0,4.0) and Gradle and Ivy and Buildr and ... > > > > 2. The post 4.0.0 flattened consumer pom > > > This is the pom for any consumers that understand modelVersion > 4.0.0 > > > > 3. The build pom > > > This is the pom for building > > > The trick here is in realising that different artifact types need different > use cases. > > Q: When do you need to pull the build pom from the repository? > A: When it is the parent of the project you are building. > > Q: When do you need a consumer pom? > A: When you are consuming an artifact. > > So the only time we need consumer poms is when packaging != pom > > The only time we need build poms is when packaging == pom (we may need to > introduce a new packaging type for those "fake pom" packaging projects > where we produce assemblies, xsd schemas, etc) > > The consumer poms are all about expressing the dependency tree (they may > include limited metadata, such as SCM URL, etc) but ultimately they are > about describing how to use the artifact as a dependency... What it brings > with it and what it needs brought for it to work. > > The build pom is all about inheritance (perhaps also Mixins) > > > > Maybe it's just a naming issue, I also see 3 POMs but they are these: > > A) Consumer POM for non POM projects. Essentially an effective POM sans > > build section, ie it never has a parent and never has any POM > dependencies > > (mix-ins). > > B) Consumer POM for POM projects. Same as (A) but it includes the build > > section. > > > Why do you think this needs a build section? > > > > C) Build POM which is where we want to introduce all manner of > flexibility. > > > > A and B would seem to be easy to provide and create no forward or > backward > > compatibility issues. > > > Well B is where we want to add new "dependency tree features"... This is a > smaller set of changes than would affect build an reporting sections, but > let us not be so arrogant as to assume we know everything that should go in > here... Hence this is the format we need great care with. > > > > > C is what then is up for discussion. > > > But C doesn't need to be backwards compatible... maven needs to be able to > read older formats of C > > > > > > In short, format A is fixed... So we don't have to worry about backwards > compat with format A as it is fixed. > > Format C is build time only, we can legitimately say you need to use a > certain minimum version of maven to build a specific builder model version. > > Format B is the one that risks fragmentation if we get it wrong. > > Deploying A & B is bad enough but acceptable... Deploying A, B, B', B'', > B''', ... Well that is inexcusable > > > > Orthogonal to this is whether there is other meta data that should be > > published as part of a deployment. But it could be published as a > separate > > artefact to avoid any problem with backward compat. > > > > William > > > > > > > > > > On Fri, Jun 20, 2014 at 2:07 AM, Stephen Connolly < > > stephen.alan.conno...@gmail.com > wrote: > > > > > Yeah I thought about that... and I don't like it. > > > > > > First off pom reading is not a pure java world. The ship has sailed. > > There > > > are people parsing the pom using Ruby, people parsing the pom using > other > > > languages that don't even run on the JVM. Thus the only common > > denominator > > > is to provide an XSLT transformation to map the newer XML format down > to > > > the older XML format. > > > > > > Publishing all formats is just ridiculous. > > > > > > My proposal, and I have not seen a better one, is to limit ourselves to > > at > > > most three poms: > > > > > > 1. The 4.0.0 flattened consumer pom > > > 2. The post 4.0.0 flattened consumer pom > > > 3. The build pom > > > > > > So for 1 we know what that will look like. We just change the rules so > > that > > > it is always flattened, it never has a parent, we strip out some > things, > > > we're explicit on dependency exclusions, etc. In other words it makes > it > > > as simple as possible for any pom 4.0.0 parser to construct the > > transitive > > > dependency tree that we believe it should have. All
Re: Evolving the POM format
On Friday, 20 June 2014, William Ferguson wrote: > Stephen, I'm a little confused by the 3 POMs you have outlined. > > 1. The 4.0.0 flattened consumer pom This is the pom for any consumers who only understand modelVersion 4.0.0 ie Maven [2.0,4.0) and Gradle and Ivy and Buildr and ... > 2. The post 4.0.0 flattened consumer pom This is the pom for any consumers that understand modelVersion > 4.0.0 > 3. The build pom This is the pom for building The trick here is in realising that different artifact types need different use cases. Q: When do you need to pull the build pom from the repository? A: When it is the parent of the project you are building. Q: When do you need a consumer pom? A: When you are consuming an artifact. So the only time we need consumer poms is when packaging != pom The only time we need build poms is when packaging == pom (we may need to introduce a new packaging type for those "fake pom" packaging projects where we produce assemblies, xsd schemas, etc) The consumer poms are all about expressing the dependency tree (they may include limited metadata, such as SCM URL, etc) but ultimately they are about describing how to use the artifact as a dependency... What it brings with it and what it needs brought for it to work. The build pom is all about inheritance (perhaps also Mixins) > Maybe it's just a naming issue, I also see 3 POMs but they are these: > A) Consumer POM for non POM projects. Essentially an effective POM sans > build section, ie it never has a parent and never has any POM dependencies > (mix-ins). > B) Consumer POM for POM projects. Same as (A) but it includes the build > section. Why do you think this needs a build section? > C) Build POM which is where we want to introduce all manner of flexibility. > > A and B would seem to be easy to provide and create no forward or backward > compatibility issues. Well B is where we want to add new "dependency tree features"... This is a smaller set of changes than would affect build an reporting sections, but let us not be so arrogant as to assume we know everything that should go in here... Hence this is the format we need great care with. > C is what then is up for discussion. But C doesn't need to be backwards compatible... maven needs to be able to read older formats of C > > In short, format A is fixed... So we don't have to worry about backwards compat with format A as it is fixed. Format C is build time only, we can legitimately say you need to use a certain minimum version of maven to build a specific builder model version. Format B is the one that risks fragmentation if we get it wrong. Deploying A & B is bad enough but acceptable... Deploying A, B, B', B'', B''', ... Well that is inexcusable > Orthogonal to this is whether there is other meta data that should be > published as part of a deployment. But it could be published as a separate > artefact to avoid any problem with backward compat. > > William > > > > > On Fri, Jun 20, 2014 at 2:07 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com > wrote: > > > Yeah I thought about that... and I don't like it. > > > > First off pom reading is not a pure java world. The ship has sailed. > There > > are people parsing the pom using Ruby, people parsing the pom using other > > languages that don't even run on the JVM. Thus the only common > denominator > > is to provide an XSLT transformation to map the newer XML format down to > > the older XML format. > > > > Publishing all formats is just ridiculous. > > > > My proposal, and I have not seen a better one, is to limit ourselves to > at > > most three poms: > > > > 1. The 4.0.0 flattened consumer pom > > 2. The post 4.0.0 flattened consumer pom > > 3. The build pom > > > > So for 1 we know what that will look like. We just change the rules so > that > > it is always flattened, it never has a parent, we strip out some things, > > we're explicit on dependency exclusions, etc. In other words it makes it > > as simple as possible for any pom 4.0.0 parser to construct the > transitive > > dependency tree that we believe it should have. All other use is > > unnecessary. We don't publish a 4.0.0 consumer pom with > > pom because > > > > * they are unnecessary for other 4.0.0 consumer poms as none of them will > > reference a parent > > * it removes the problem of people wanting to use the 4.0.0 consumer poms > > as a parent, and we are setting the post-modelVersion-4.0.0 rule as your > > parent must be of a modelVersion <= the child's modelVersion > > > > For 3, we have no fucking clue what that will look like. I think we need > to > > agree that the first line of it needs some hint as to the model > version... > > but if we stick to the rule that you need a Maven version that is >= the > > model version of the pom you are building to build... well we can always > > just try all the parsers we have until one of them works... and if it > don't > > work... well we can safely bomb out as you are tryi
Re: Evolving the POM format
On Friday, 20 June 2014, Igor Fedorenko wrote: > I am not sure I follow. > > Do you want to allow multi-module projects where different modules > require different versions of maven? No I want to allow multi-module projects where the maximum modelVersion defines the minimum required version of maven to build. > > If required version of maven is the same, why not require the same pom > format version for the entire build too? Because I may be working on several things that I am throwing together in a local aggregator pom... Because I am working on a module that I cannot change the build process for and another module at the same time that needs the newer features Are you concerned about changes > to pom.xml files when moving from one format version to the next or > something else? I want to be able to migrate modules to newer build poms when they are ready to do so. That may mean that I have a project with one child that can be built by Maven 2.0 another that needs maven 3.2.2 and a 3rd that needs maven 4.1. To build that reactor I need to use maven 4.1 or newer... Or I can not use a reactor and push things to the local repo and build the first module with maven 2.0, change my PATH, build the second module with maven 3.2.2, change my PATH again and build the last module with Maven 4.1... All pushing to the local repo... Hoping that we haven't changed the local repo format... Hoping that I've remembered to do that all correctly, and all for the same feature branch... Oh I got distracted and had to switch to a different branch and back again... Sorry start at the beginning again just to be sure. Ok, so we can use something like RVM so that as we cd into each module we pick up an .mvnenv file that causes our PATH to auto switch... But really? And for this to work we have two choices... Never evolve the local repo OR run a local remote repo to act as a maven version neutral exchange... Great now I've gone from `mvn clean verify` to `cd foo && mvn clean deploy -DaltDeploymentUrl=... && cd ../bar && mvn clean deploy -DaltDeploymentUrl=... && cd ../manchu && ...` that's just great that is! I argue that unless we keep the contract that newer maven can build all older maven projects, then there is no point even calling new maven "maven"... Does it have to build them perfectly? Perhaps not, I can live with needing to tweak things to iron out an inconsistency as long as after the tweak both new and old build that module the same... So, for example, if the old pom references ${pom.artifactId} and new maven cannot build that unless you change it to ${project.artifactId} that is OK in my book as both forms are legal in old maven so switching to the new one will not break old maven... (Obviously better if we don't fail in that case... Just trying to give a concrete example) The reason is that there is a pressure keeping me from advancing that module to Maven 4.1. Don't force me to jump through hoops just because some a-hole is keeping that module shackled to build with Maven 2.0.6 levels of compatibility... Because if Maven forces me to jump through those hoops... Congratulations, Maven is now an a-hole too. > -- > Regards, > Igor > > On 2014-06-19, 11:50, Stephen Connolly wrote: > >> If backwards compatible interoperability is not a requirement then: >> >> If I upgrade one module in my multi-module build to Maven 5.1 then I am >> forced right then and there to either: >> >> * upgrade all of them to Maven 5.1; or >> * remove the module from my multi-module build >> >> Neither of these are a good user experience in my mind. Maven 5.1 should >> be >> able to build a Maven [2.0,5.1] project without modifying the pom... it >> can >> do that by loading shim layers on demand if necessary, but to my thinking >> anything less is going to cause issues for users. >> >> >> So to my thinking we just accept that Maven needs to evolve such that for >> every version X.Y of Maven you know that you can build a Maven project >> from >> the range [2.0,X.Y]. >> >> If you have a project that has a parent, then the parent must be in a pom >> format that buildable by Maven [2.0,${project.prerequisites.maven}], so a >> child pom requiring Maven 5.1 to build can have a parent pom that requires >> Maven 5.0 to build but not a parent pom requiring Maven 5.2... there may >> even be turtles all the way down to an ancestor pom that requires Maven >> [2.0,3.0.3] to build (IIRC after 3.0.3 you get things like wildcards in >> excludes due to aether injecting "bonus" functionality... that should have >> been a modelVersion bump in the strictest sense... but well it wasn't) >> >> I also think people overestimate how difficult it is to maintain backwards >> compatibility. >> >> I have a Jenkins plugin that was written against Hudson 1.96 and I can >> take >> that .hpi file and drop it into Jenkins 1.568 and it still works >> unmodified. Similarly I can upgrade a Jenkins installation jumping quite a >> large number of versions witho
Re: Evolving the POM format
Stephen, I'm a little confused by the 3 POMs you have outlined. 1. The 4.0.0 flattened consumer pom 2. The post 4.0.0 flattened consumer pom 3. The build pom Maybe it's just a naming issue, I also see 3 POMs but they are these: A) Consumer POM for non POM projects. Essentially an effective POM sans build section, ie it never has a parent and never has any POM dependencies (mix-ins). B) Consumer POM for POM projects. Same as (A) but it includes the build section. C) Build POM which is where we want to introduce all manner of flexibility. A and B would seem to be easy to provide and create no forward or backward compatibility issues. C is what then is up for discussion. Orthogonal to this is whether there is other meta data that should be published as part of a deployment. But it could be published as a separate artefact to avoid any problem with backward compat. William On Fri, Jun 20, 2014 at 2:07 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > Yeah I thought about that... and I don't like it. > > First off pom reading is not a pure java world. The ship has sailed. There > are people parsing the pom using Ruby, people parsing the pom using other > languages that don't even run on the JVM. Thus the only common denominator > is to provide an XSLT transformation to map the newer XML format down to > the older XML format. > > Publishing all formats is just ridiculous. > > My proposal, and I have not seen a better one, is to limit ourselves to at > most three poms: > > 1. The 4.0.0 flattened consumer pom > 2. The post 4.0.0 flattened consumer pom > 3. The build pom > > So for 1 we know what that will look like. We just change the rules so that > it is always flattened, it never has a parent, we strip out some things, > we're explicit on dependency exclusions, etc. In other words it makes it > as simple as possible for any pom 4.0.0 parser to construct the transitive > dependency tree that we believe it should have. All other use is > unnecessary. We don't publish a 4.0.0 consumer pom with > pom because > > * they are unnecessary for other 4.0.0 consumer poms as none of them will > reference a parent > * it removes the problem of people wanting to use the 4.0.0 consumer poms > as a parent, and we are setting the post-modelVersion-4.0.0 rule as your > parent must be of a modelVersion <= the child's modelVersion > > For 3, we have no fucking clue what that will look like. I think we need to > agree that the first line of it needs some hint as to the model version... > but if we stick to the rule that you need a Maven version that is >= the > model version of the pom you are building to build... well we can always > just try all the parsers we have until one of them works... and if it don't > work... well we can safely bomb out as you are trying to build with a > version of Maven that is too old. > > Now we have the hard problem, what does 2 look like? > > Well 2 is produced and consumed by machines only. So I think it will be > either json or xml. Both are problematic formats for people to write > correctly, but are simple for machines to create and parse. YAML is out in > my view as it becomes too tempting for people to try and hand craft... also > have you seen the YAML spec? > > If we go for XML, we need to use namespaces and define up front what to do > with unknown namespaces. > > If we go for JSON, we need to define the extension mechanism and how to > handle unknown extensions. > > Perhaps the simplest thing to do is to have extensions include a flag that > says understanding them is mandatory or not. > > In any case this post 4.0.0 flattened consumer pom only has to worry about > expressing dependencies and dependency like constructs (such as > platforms/runtimes and "provides" information). > > Which poms we deploy depends on the packaging: > > packaging == pom: deploy build pom only > packaging != pom : deploy 4.0.0 consumer pom and post 4.0.0 consumer poms > only > > That is my vision... the bit that I feel worried about is ensuring that we > get the post-4.0.0 consumer pom flexible enough that it can handle future > stuff that we have not anticipated... as if we get that wrong then 2-3 > years down the road we end up with a 4.0.0 consumer pom, a 5.0.0 consumer > pom and a post-5.0.0 consumer pom. I would hate to see us deploying 15 > different consumer poms just to publish a 1k utility jar > > > On 19 June 2014 16:49, Paul Benedict wrote: > > > I definitely agree that there should be two kinds of POMs: building and > > consuming. Those are two separate concerns and there's no reason to > pollute > > dependency consumption with build information (or site information!). I > am > > on board with separating the two out. When it comes to evolving the > > building POM, that's clear cut: upgrade to the Maven X.Y that can read > that > > kind of POM. However, you're still "stuck" (for a lack of better word) > with > > evolving the POM that everyone consumes, as I said, due to (i)
Re: Evolving the POM format
I am not sure I follow. Do you want to allow multi-module projects where different modules require different versions of maven? If required version of maven is the same, why not require the same pom format version for the entire build too? Are you concerned about changes to pom.xml files when moving from one format version to the next or something else? -- Regards, Igor On 2014-06-19, 11:50, Stephen Connolly wrote: If backwards compatible interoperability is not a requirement then: If I upgrade one module in my multi-module build to Maven 5.1 then I am forced right then and there to either: * upgrade all of them to Maven 5.1; or * remove the module from my multi-module build Neither of these are a good user experience in my mind. Maven 5.1 should be able to build a Maven [2.0,5.1] project without modifying the pom... it can do that by loading shim layers on demand if necessary, but to my thinking anything less is going to cause issues for users. So to my thinking we just accept that Maven needs to evolve such that for every version X.Y of Maven you know that you can build a Maven project from the range [2.0,X.Y]. If you have a project that has a parent, then the parent must be in a pom format that buildable by Maven [2.0,${project.prerequisites.maven}], so a child pom requiring Maven 5.1 to build can have a parent pom that requires Maven 5.0 to build but not a parent pom requiring Maven 5.2... there may even be turtles all the way down to an ancestor pom that requires Maven [2.0,3.0.3] to build (IIRC after 3.0.3 you get things like wildcards in excludes due to aether injecting "bonus" functionality... that should have been a modelVersion bump in the strictest sense... but well it wasn't) I also think people overestimate how difficult it is to maintain backwards compatibility. I have a Jenkins plugin that was written against Hudson 1.96 and I can take that .hpi file and drop it into Jenkins 1.568 and it still works unmodified. Similarly I can upgrade a Jenkins installation jumping quite a large number of versions without issue. It is possible to evolve and maintain the ability to read older data... is it easy? well it's not trivial, but it is a disservice to our users if we don't try On 19 June 2014 16:24, Paul Benedict wrote: I am curious why you interoperability as a requirement? Perhaps questioning that may seem outrageous, but I see no problem with saying that you need to upgrade to Maven X.Y to read newer POM formats. If a vendor wants to backport their project into older POM formats, that should be the vendor's shoulders and not be a concern of Maven core. If Maven does publish older formats of POMs, you then have to decide how many older formats do you want to publish? One day there will be a 4.1 or 5.0, and it's going to complicate the world if Maven takes on the burden of interoperability. Cheers, Paul On Thu, Jun 19, 2014 at 9:57 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: On 19 June 2014 15:48, Igor Fedorenko wrote: On 2014-06-19, 10:30, Stephen Connolly wrote: - Igor is*mostly* right in that we should not deploy the pom that is used to build to the repository... - Where Igor is wrong is that for pom we should actually deploy the build time pom to the repository... probably with the classifier `build`... this is safe as `pom` does cannot have a classifier in model version 4.0.0. - You couple that with a simple and obvious restriction... your parent must be the same or earlier version of Maven. You cannot have as a parent a newer version of Maven than the child is built with. I think there is more to this. At very least we need to decide what to do with in 4.0.0 compatible poms. Maybe we should always deploy effective pom with build-related elements removed. Well I think the simple thing is that the 4.0.0 pom is fully resolved when you have a builder pom I am also not sure if it is enough to deploy "build" parent poms as is. Your suggested "parent must be the same or earlier version of Maven" implies new versions of Maven can read older pom formats, which I think will significantly limit our flexibility to evolve pom format. They need to be able to parse it into the model. Perhaps they do the parsing by downloading a parser. But I think it is reasonable to expect that we can convert older build pom formats into newer ones and just let Maven take care of it... if we cannot do that then we are really creating a brand new build tool rather than evolving Maven I wonder if we can have different solution for force parent poms, like org.apache:apache, which are used by multiple projects and different versions of maven and project-specific parent poms, where it is much easier to require specific version of maven. Well the simple way is we have deployed the 4.0.0 parent pom as org.apache:apache:14:pom if you want to upgrade your parent to org.apache:apache:15 then you will need to require Maven 4.0+ to build. If
Re: Evolving the POM format
On Thursday, 19 June 2014, Robert Scholte wrote: > Op Thu, 19 Jun 2014 18:07:33 +0200 schreef Stephen Connolly < > stephen.alan.conno...@gmail.com>: > > Yeah I thought about that... and I don't like it. >> >> First off pom reading is not a pure java world. The ship has sailed. There >> are people parsing the pom using Ruby, people parsing the pom using other >> languages that don't even run on the JVM. Thus the only common denominator >> is to provide an XSLT transformation to map the newer XML format down to >> the older XML format. >> >> Publishing all formats is just ridiculous. >> >> My proposal, and I have not seen a better one, is to limit ourselves to at >> most three poms: >> >> 1. The 4.0.0 flattened consumer pom >> 2. The post 4.0.0 flattened consumer pom >> 3. The build pom >> >> > The flatten-maven-plugin is a very nice experiment which taught me that > some repository managers require extra information inside the pom.xml > beside the consuming parts. Right now they do because of policy decisions. I think we still have the influence to change such policy if we have a good reason to > So apart from the dependencies it expects developers, scm and a few other > elements. We have to be sure that this consumer pom is accepted by all repo > managers one way or another. > For 2 it is only useful if frameworks like Aether want it and will use it. IIUC aether doesn't parse the pom but instead uses an abstraction and is more of a dependency graph solver coupled to a transport and storage layer > I think they should be in the lead for the format so it is optimized for > them. You might even wonder if it is Maven Core who should create it. I can > imagine that either the repo managers extract that information from the > artifact and generates the consumer pom OR that the maven-deploy-plugin > adds it, so you're not bound to the Maven version to generate such files. > > Robert > > So for 1 we know what that will look like. We just change the rules so >> that >> it is always flattened, it never has a parent, we strip out some things, >> we're explicit on dependency exclusions, etc. In other words it makes it >> as simple as possible for any pom 4.0.0 parser to construct the transitive >> dependency tree that we believe it should have. All other use is >> unnecessary. We don't publish a 4.0.0 consumer pom with >> pom because >> >> * they are unnecessary for other 4.0.0 consumer poms as none of them will >> reference a parent >> * it removes the problem of people wanting to use the 4.0.0 consumer poms >> as a parent, and we are setting the post-modelVersion-4.0.0 rule as your >> parent must be of a modelVersion <= the child's modelVersion >> >> For 3, we have no fucking clue what that will look like. I think we need >> to >> agree that the first line of it needs some hint as to the model version... >> but if we stick to the rule that you need a Maven version that is >= the >> model version of the pom you are building to build... well we can always >> just try all the parsers we have until one of them works... and if it >> don't >> work... well we can safely bomb out as you are trying to build with a >> version of Maven that is too old. >> >> Now we have the hard problem, what does 2 look like? >> >> Well 2 is produced and consumed by machines only. So I think it will be >> either json or xml. Both are problematic formats for people to write >> correctly, but are simple for machines to create and parse. YAML is out in >> my view as it becomes too tempting for people to try and hand craft... >> also >> have you seen the YAML spec? >> >> If we go for XML, we need to use namespaces and define up front what to do >> with unknown namespaces. >> >> If we go for JSON, we need to define the extension mechanism and how to >> handle unknown extensions. >> >> Perhaps the simplest thing to do is to have extensions include a flag that >> says understanding them is mandatory or not. >> >> In any case this post 4.0.0 flattened consumer pom only has to worry about >> expressing dependencies and dependency like constructs (such as >> platforms/runtimes and "provides" information). >> >> Which poms we deploy depends on the packaging: >> >> packaging == pom: deploy build pom only >> packaging != pom : deploy 4.0.0 consumer pom and post 4.0.0 consumer poms >> only >> >> That is my vision... the bit that I feel worried about is ensuring that we >> get the post-4.0.0 consumer pom flexible enough that it can handle future >> stuff that we have not anticipated... as if we get that wrong then 2-3 >> years down the road we end up with a 4.0.0 consumer pom, a 5.0.0 consumer >> pom and a post-5.0.0 consumer pom. I would hate to see us deploying 15 >> different consumer poms just to publish a 1k utility jar >> >> >> On 19 June 2014 16:49, Paul Benedict wrote: >> >> I definitely agree that there should be two kinds of POMs: building and >>> consuming. Those are two separate concerns and there's no reason to >>> pollute >>> de
Re: Evolving the POM format
Op Thu, 19 Jun 2014 18:07:33 +0200 schreef Stephen Connolly : Yeah I thought about that... and I don't like it. First off pom reading is not a pure java world. The ship has sailed. There are people parsing the pom using Ruby, people parsing the pom using other languages that don't even run on the JVM. Thus the only common denominator is to provide an XSLT transformation to map the newer XML format down to the older XML format. Publishing all formats is just ridiculous. My proposal, and I have not seen a better one, is to limit ourselves to at most three poms: 1. The 4.0.0 flattened consumer pom 2. The post 4.0.0 flattened consumer pom 3. The build pom The flatten-maven-plugin is a very nice experiment which taught me that some repository managers require extra information inside the pom.xml beside the consuming parts. So apart from the dependencies it expects developers, scm and a few other elements. We have to be sure that this consumer pom is accepted by all repo managers one way or another. For 2 it is only useful if frameworks like Aether want it and will use it. I think they should be in the lead for the format so it is optimized for them. You might even wonder if it is Maven Core who should create it. I can imagine that either the repo managers extract that information from the artifact and generates the consumer pom OR that the maven-deploy-plugin adds it, so you're not bound to the Maven version to generate such files. Robert So for 1 we know what that will look like. We just change the rules so that it is always flattened, it never has a parent, we strip out some things, we're explicit on dependency exclusions, etc. In other words it makes it as simple as possible for any pom 4.0.0 parser to construct the transitive dependency tree that we believe it should have. All other use is unnecessary. We don't publish a 4.0.0 consumer pom with pom because * they are unnecessary for other 4.0.0 consumer poms as none of them will reference a parent * it removes the problem of people wanting to use the 4.0.0 consumer poms as a parent, and we are setting the post-modelVersion-4.0.0 rule as your parent must be of a modelVersion <= the child's modelVersion For 3, we have no fucking clue what that will look like. I think we need to agree that the first line of it needs some hint as to the model version... but if we stick to the rule that you need a Maven version that is >= the model version of the pom you are building to build... well we can always just try all the parsers we have until one of them works... and if it don't work... well we can safely bomb out as you are trying to build with a version of Maven that is too old. Now we have the hard problem, what does 2 look like? Well 2 is produced and consumed by machines only. So I think it will be either json or xml. Both are problematic formats for people to write correctly, but are simple for machines to create and parse. YAML is out in my view as it becomes too tempting for people to try and hand craft... also have you seen the YAML spec? If we go for XML, we need to use namespaces and define up front what to do with unknown namespaces. If we go for JSON, we need to define the extension mechanism and how to handle unknown extensions. Perhaps the simplest thing to do is to have extensions include a flag that says understanding them is mandatory or not. In any case this post 4.0.0 flattened consumer pom only has to worry about expressing dependencies and dependency like constructs (such as platforms/runtimes and "provides" information). Which poms we deploy depends on the packaging: packaging == pom: deploy build pom only packaging != pom : deploy 4.0.0 consumer pom and post 4.0.0 consumer poms only That is my vision... the bit that I feel worried about is ensuring that we get the post-4.0.0 consumer pom flexible enough that it can handle future stuff that we have not anticipated... as if we get that wrong then 2-3 years down the road we end up with a 4.0.0 consumer pom, a 5.0.0 consumer pom and a post-5.0.0 consumer pom. I would hate to see us deploying 15 different consumer poms just to publish a 1k utility jar On 19 June 2014 16:49, Paul Benedict wrote: I definitely agree that there should be two kinds of POMs: building and consuming. Those are two separate concerns and there's no reason to pollute dependency consumption with build information (or site information!). I am on board with separating the two out. When it comes to evolving the building POM, that's clear cut: upgrade to the Maven X.Y that can read that kind of POM. However, you're still "stuck" (for a lack of better word) with evolving the POM that everyone consumes, as I said, due to (i) how far back in time you want to support and (ii) publishing all the formats that could exist. Here is my armchair idea to give for consideration: 1) The POM reading code is refactored out of core and become
Re: Evolving the POM format
On Jun 19, 2014, at 11:49 AM, Paul Benedict wrote: > I definitely agree that there should be two kinds of POMs: building and > consuming. Those are two separate concerns and there's no reason to pollute > dependency consumption with build information (or site information!). I am > on board with separating the two out. When it comes to evolving the > building POM, that's clear cut: upgrade to the Maven X.Y that can read that > kind of POM. However, you're still "stuck" (for a lack of better word) with > evolving the POM that everyone consumes, as I said, due to (i) how far back > in time you want to support and (ii) publishing all the formats that could > exist. > > Here is my armchair idea to give for consideration: > > 1) The POM reading code is refactored out of core and becomes a plugin that > runs in a new phase at the very beginning (before "validate"). Either the > plugin supports all POM versions, there exists a plugin per specific POM > version, or it's configurable which versions you want to read. > This is effectively how it works already apart from the fact that the specific reader required is not automatically downloaded. The polyglot form of Maven figures out what is needed to read the POM and loads the appropriate extension. Actually being able to have a consumer POM is one of the major blockers for having DSL-based POMs. > 2) At publish to repo time, for whatever plugin actually generate the > "consuming" POM, the builder configures how many POM versions he wants to > publish: 3.x, 4.0, 4.1, etc. > Without enumerating all the the features requested thus far I'm not sure what's actually necessary. I'm collating them all now to see what we have. Without looking through JIRA I can't remember everything that's been requested. I'm going to start from the concretely requested features. > My idea is not to force either party into saying "I must read or write > umpteen formats". Leave it all to the builder and consumer to decide which > are important to each respective use cases. > > Paul > > > > Cheers, > Paul > > > On Thu, Jun 19, 2014 at 10:32 AM, Jason van Zyl wrote: > >> >> On Jun 19, 2014, at 11:24 AM, Paul Benedict wrote: >> >>> I am curious why you interoperability as a requirement? Perhaps >> questioning >>> that may seem outrageous, but I see no problem with saying that you need >> to >>> upgrade to Maven X.Y to read newer POM formats. >> >> To build a project that is certainly fine. If a project starts using a >> Ruby-based POM you will need a newer version of Maven to build the project. >> The issue of interoperability arises when projects that want to use what >> was built by the project using the Ruby-based POM. Say the Guice project >> starts using a Ruby-based POM: you do not want to force everyone who uses >> Guice to use a version of Maven that has the capability to read a >> Ruby-based POM. I think it would be an enormously limiting move to require >> that. Build with whatever you want but let's make it easy to consume for >> everyone which means making those dependencies usable by all the existing >> versions of Maven. The build-time information is mostly, if not completely, >> irrelevant at consumption time. >> >>> If a vendor wants to >>> backport their project into older POM formats, that should be the >> vendor's >>> shoulders and not be a concern of Maven core. If Maven does publish older >>> formats of POMs, you then have to decide how many older formats do you >> want >>> to publish? One day there will be a 4.1 or 5.0, and it's going to >>> complicate the world if Maven takes on the burden of interoperability. >>> >>> >>> Cheers, >>> Paul >>> >>> >>> On Thu, Jun 19, 2014 at 9:57 AM, Stephen Connolly < >>> stephen.alan.conno...@gmail.com> wrote: >>> On 19 June 2014 15:48, Igor Fedorenko wrote: > > > On 2014-06-19, 10:30, Stephen Connolly wrote: > >> - Igor is*mostly* right in that we should not deploy the pom that is used >> >> to build to the repository... >> - Where Igor is wrong is that for pom we should >> actually deploy the build time pom to the repository... probably with the >> classifier `build`... this is safe as `pom` does cannot have a classifier >> in model version 4.0.0. >> - You couple that with a simple and obvious restriction... your parent >> must >> be the same or earlier version of Maven. You cannot have as a parent a >> newer version of Maven than the child is built with. >> > > I think there is more to this. > > At very least we need to decide what to do with in 4.0.0 > compatible poms. Maybe we should always deploy effective pom with > build-related elements removed. > Well I think the simple thing is that the 4.0.0 pom is fully resolved >> when you have a builder pom > > I am also not sure if it is enough to deploy "build" parent poms as is. > Your
Re: Evolving the POM format
Yeah I thought about that... and I don't like it. First off pom reading is not a pure java world. The ship has sailed. There are people parsing the pom using Ruby, people parsing the pom using other languages that don't even run on the JVM. Thus the only common denominator is to provide an XSLT transformation to map the newer XML format down to the older XML format. Publishing all formats is just ridiculous. My proposal, and I have not seen a better one, is to limit ourselves to at most three poms: 1. The 4.0.0 flattened consumer pom 2. The post 4.0.0 flattened consumer pom 3. The build pom So for 1 we know what that will look like. We just change the rules so that it is always flattened, it never has a parent, we strip out some things, we're explicit on dependency exclusions, etc. In other words it makes it as simple as possible for any pom 4.0.0 parser to construct the transitive dependency tree that we believe it should have. All other use is unnecessary. We don't publish a 4.0.0 consumer pom with pom because * they are unnecessary for other 4.0.0 consumer poms as none of them will reference a parent * it removes the problem of people wanting to use the 4.0.0 consumer poms as a parent, and we are setting the post-modelVersion-4.0.0 rule as your parent must be of a modelVersion <= the child's modelVersion For 3, we have no fucking clue what that will look like. I think we need to agree that the first line of it needs some hint as to the model version... but if we stick to the rule that you need a Maven version that is >= the model version of the pom you are building to build... well we can always just try all the parsers we have until one of them works... and if it don't work... well we can safely bomb out as you are trying to build with a version of Maven that is too old. Now we have the hard problem, what does 2 look like? Well 2 is produced and consumed by machines only. So I think it will be either json or xml. Both are problematic formats for people to write correctly, but are simple for machines to create and parse. YAML is out in my view as it becomes too tempting for people to try and hand craft... also have you seen the YAML spec? If we go for XML, we need to use namespaces and define up front what to do with unknown namespaces. If we go for JSON, we need to define the extension mechanism and how to handle unknown extensions. Perhaps the simplest thing to do is to have extensions include a flag that says understanding them is mandatory or not. In any case this post 4.0.0 flattened consumer pom only has to worry about expressing dependencies and dependency like constructs (such as platforms/runtimes and "provides" information). Which poms we deploy depends on the packaging: packaging == pom: deploy build pom only packaging != pom : deploy 4.0.0 consumer pom and post 4.0.0 consumer poms only That is my vision... the bit that I feel worried about is ensuring that we get the post-4.0.0 consumer pom flexible enough that it can handle future stuff that we have not anticipated... as if we get that wrong then 2-3 years down the road we end up with a 4.0.0 consumer pom, a 5.0.0 consumer pom and a post-5.0.0 consumer pom. I would hate to see us deploying 15 different consumer poms just to publish a 1k utility jar On 19 June 2014 16:49, Paul Benedict wrote: > I definitely agree that there should be two kinds of POMs: building and > consuming. Those are two separate concerns and there's no reason to pollute > dependency consumption with build information (or site information!). I am > on board with separating the two out. When it comes to evolving the > building POM, that's clear cut: upgrade to the Maven X.Y that can read that > kind of POM. However, you're still "stuck" (for a lack of better word) with > evolving the POM that everyone consumes, as I said, due to (i) how far back > in time you want to support and (ii) publishing all the formats that could > exist. > > Here is my armchair idea to give for consideration: > > 1) The POM reading code is refactored out of core and becomes a plugin that > runs in a new phase at the very beginning (before "validate"). Either the > plugin supports all POM versions, there exists a plugin per specific POM > version, or it's configurable which versions you want to read. > > 2) At publish to repo time, for whatever plugin actually generate the > "consuming" POM, the builder configures how many POM versions he wants to > publish: 3.x, 4.0, 4.1, etc. > > My idea is not to force either party into saying "I must read or write > umpteen formats". Leave it all to the builder and consumer to decide which > are important to each respective use cases. > > Paul > > > > Cheers, > Paul > > > On Thu, Jun 19, 2014 at 10:32 AM, Jason van Zyl wrote: > > > > > On Jun 19, 2014, at 11:24 AM, Paul Benedict > wrote: > > > > > I am curious why you interoperability as a requirement? Perhaps > > questioning > > > that may seem outrageous, but I see no problem with sayi
Re: Evolving the POM format
If backwards compatible interoperability is not a requirement then: If I upgrade one module in my multi-module build to Maven 5.1 then I am forced right then and there to either: * upgrade all of them to Maven 5.1; or * remove the module from my multi-module build Neither of these are a good user experience in my mind. Maven 5.1 should be able to build a Maven [2.0,5.1] project without modifying the pom... it can do that by loading shim layers on demand if necessary, but to my thinking anything less is going to cause issues for users. So to my thinking we just accept that Maven needs to evolve such that for every version X.Y of Maven you know that you can build a Maven project from the range [2.0,X.Y]. If you have a project that has a parent, then the parent must be in a pom format that buildable by Maven [2.0,${project.prerequisites.maven}], so a child pom requiring Maven 5.1 to build can have a parent pom that requires Maven 5.0 to build but not a parent pom requiring Maven 5.2... there may even be turtles all the way down to an ancestor pom that requires Maven [2.0,3.0.3] to build (IIRC after 3.0.3 you get things like wildcards in excludes due to aether injecting "bonus" functionality... that should have been a modelVersion bump in the strictest sense... but well it wasn't) I also think people overestimate how difficult it is to maintain backwards compatibility. I have a Jenkins plugin that was written against Hudson 1.96 and I can take that .hpi file and drop it into Jenkins 1.568 and it still works unmodified. Similarly I can upgrade a Jenkins installation jumping quite a large number of versions without issue. It is possible to evolve and maintain the ability to read older data... is it easy? well it's not trivial, but it is a disservice to our users if we don't try On 19 June 2014 16:24, Paul Benedict wrote: > I am curious why you interoperability as a requirement? Perhaps questioning > that may seem outrageous, but I see no problem with saying that you need to > upgrade to Maven X.Y to read newer POM formats. If a vendor wants to > backport their project into older POM formats, that should be the vendor's > shoulders and not be a concern of Maven core. If Maven does publish older > formats of POMs, you then have to decide how many older formats do you want > to publish? One day there will be a 4.1 or 5.0, and it's going to > complicate the world if Maven takes on the burden of interoperability. > > > Cheers, > Paul > > > On Thu, Jun 19, 2014 at 9:57 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > On 19 June 2014 15:48, Igor Fedorenko wrote: > > > > > > > > > > > On 2014-06-19, 10:30, Stephen Connolly wrote: > > > > > >> - Igor is*mostly* right in that we should not deploy the pom that is > > used > > >> > > >> to build to the repository... > > >> - Where Igor is wrong is that for pom we should > > >> actually deploy the build time pom to the repository... probably with > > the > > >> classifier `build`... this is safe as `pom` does cannot have a > > classifier > > >> in model version 4.0.0. > > >> - You couple that with a simple and obvious restriction... your parent > > >> must > > >> be the same or earlier version of Maven. You cannot have as a parent a > > >> newer version of Maven than the child is built with. > > >> > > > > > > I think there is more to this. > > > > > > At very least we need to decide what to do with in 4.0.0 > > > compatible poms. Maybe we should always deploy effective pom with > > > build-related elements removed. > > > > > > > Well I think the simple thing is that the 4.0.0 pom is fully resolved > when > > you have a builder pom > > > > > > > > > > I am also not sure if it is enough to deploy "build" parent poms as is. > > > Your suggested "parent must be the same or earlier version of Maven" > > > implies new versions of Maven can read older pom formats, which I think > > > will significantly limit our flexibility to evolve pom format. > > > > > > They need to be able to parse it into the model. Perhaps they do the > > parsing by downloading a parser. But I think it is reasonable to expect > > that we can convert older build pom formats into newer ones and just let > > Maven take care of it... if we cannot do that then we are really > creating a > > brand new build tool rather than evolving Maven > > > > > > > I wonder > > > if we can have different solution for force parent poms, like > > > org.apache:apache, which are used by multiple projects and different > > > versions of maven and project-specific parent poms, where it is much > > > easier to require specific version of maven. > > > > > > > Well the simple way is we have deployed the 4.0.0 parent pom as > > org.apache:apache:14:pom if you want to upgrade your parent to > > org.apache:apache:15 then you will need to require Maven 4.0+ to build. > If > > you don't want to upgrade your build time requirements, then don't > upgrade > > the parent... and if we need to "fix"
Re: Evolving the POM format
I definitely agree that there should be two kinds of POMs: building and consuming. Those are two separate concerns and there's no reason to pollute dependency consumption with build information (or site information!). I am on board with separating the two out. When it comes to evolving the building POM, that's clear cut: upgrade to the Maven X.Y that can read that kind of POM. However, you're still "stuck" (for a lack of better word) with evolving the POM that everyone consumes, as I said, due to (i) how far back in time you want to support and (ii) publishing all the formats that could exist. Here is my armchair idea to give for consideration: 1) The POM reading code is refactored out of core and becomes a plugin that runs in a new phase at the very beginning (before "validate"). Either the plugin supports all POM versions, there exists a plugin per specific POM version, or it's configurable which versions you want to read. 2) At publish to repo time, for whatever plugin actually generate the "consuming" POM, the builder configures how many POM versions he wants to publish: 3.x, 4.0, 4.1, etc. My idea is not to force either party into saying "I must read or write umpteen formats". Leave it all to the builder and consumer to decide which are important to each respective use cases. Paul Cheers, Paul On Thu, Jun 19, 2014 at 10:32 AM, Jason van Zyl wrote: > > On Jun 19, 2014, at 11:24 AM, Paul Benedict wrote: > > > I am curious why you interoperability as a requirement? Perhaps > questioning > > that may seem outrageous, but I see no problem with saying that you need > to > > upgrade to Maven X.Y to read newer POM formats. > > To build a project that is certainly fine. If a project starts using a > Ruby-based POM you will need a newer version of Maven to build the project. > The issue of interoperability arises when projects that want to use what > was built by the project using the Ruby-based POM. Say the Guice project > starts using a Ruby-based POM: you do not want to force everyone who uses > Guice to use a version of Maven that has the capability to read a > Ruby-based POM. I think it would be an enormously limiting move to require > that. Build with whatever you want but let's make it easy to consume for > everyone which means making those dependencies usable by all the existing > versions of Maven. The build-time information is mostly, if not completely, > irrelevant at consumption time. > > > If a vendor wants to > > backport their project into older POM formats, that should be the > vendor's > > shoulders and not be a concern of Maven core. If Maven does publish older > > formats of POMs, you then have to decide how many older formats do you > want > > to publish? One day there will be a 4.1 or 5.0, and it's going to > > complicate the world if Maven takes on the burden of interoperability. > > > > > > Cheers, > > Paul > > > > > > On Thu, Jun 19, 2014 at 9:57 AM, Stephen Connolly < > > stephen.alan.conno...@gmail.com> wrote: > > > >> On 19 June 2014 15:48, Igor Fedorenko wrote: > >> > >>> > >>> > >>> On 2014-06-19, 10:30, Stephen Connolly wrote: > >>> > - Igor is*mostly* right in that we should not deploy the pom that is > >> used > > to build to the repository... > - Where Igor is wrong is that for pom we should > actually deploy the build time pom to the repository... probably with > >> the > classifier `build`... this is safe as `pom` does cannot have a > >> classifier > in model version 4.0.0. > - You couple that with a simple and obvious restriction... your parent > must > be the same or earlier version of Maven. You cannot have as a parent a > newer version of Maven than the child is built with. > > >>> > >>> I think there is more to this. > >>> > >>> At very least we need to decide what to do with in 4.0.0 > >>> compatible poms. Maybe we should always deploy effective pom with > >>> build-related elements removed. > >>> > >> > >> Well I think the simple thing is that the 4.0.0 pom is fully resolved > when > >> you have a builder pom > >> > >> > >>> > >>> I am also not sure if it is enough to deploy "build" parent poms as is. > >>> Your suggested "parent must be the same or earlier version of Maven" > >>> implies new versions of Maven can read older pom formats, which I think > >>> will significantly limit our flexibility to evolve pom format. > >> > >> > >> They need to be able to parse it into the model. Perhaps they do the > >> parsing by downloading a parser. But I think it is reasonable to expect > >> that we can convert older build pom formats into newer ones and just let > >> Maven take care of it... if we cannot do that then we are really > creating a > >> brand new build tool rather than evolving Maven > >> > >> > >>> I wonder > >>> if we can have different solution for force parent poms, like > >>> org.apache:apache, which are used by multiple projects and different > >>> versions of maven and project-specific
Re: Evolving the POM format
On Jun 19, 2014, at 11:24 AM, Paul Benedict wrote: > I am curious why you interoperability as a requirement? Perhaps questioning > that may seem outrageous, but I see no problem with saying that you need to > upgrade to Maven X.Y to read newer POM formats. To build a project that is certainly fine. If a project starts using a Ruby-based POM you will need a newer version of Maven to build the project. The issue of interoperability arises when projects that want to use what was built by the project using the Ruby-based POM. Say the Guice project starts using a Ruby-based POM: you do not want to force everyone who uses Guice to use a version of Maven that has the capability to read a Ruby-based POM. I think it would be an enormously limiting move to require that. Build with whatever you want but let's make it easy to consume for everyone which means making those dependencies usable by all the existing versions of Maven. The build-time information is mostly, if not completely, irrelevant at consumption time. > If a vendor wants to > backport their project into older POM formats, that should be the vendor's > shoulders and not be a concern of Maven core. If Maven does publish older > formats of POMs, you then have to decide how many older formats do you want > to publish? One day there will be a 4.1 or 5.0, and it's going to > complicate the world if Maven takes on the burden of interoperability. > > > Cheers, > Paul > > > On Thu, Jun 19, 2014 at 9:57 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > >> On 19 June 2014 15:48, Igor Fedorenko wrote: >> >>> >>> >>> On 2014-06-19, 10:30, Stephen Connolly wrote: >>> - Igor is*mostly* right in that we should not deploy the pom that is >> used to build to the repository... - Where Igor is wrong is that for pom we should actually deploy the build time pom to the repository... probably with >> the classifier `build`... this is safe as `pom` does cannot have a >> classifier in model version 4.0.0. - You couple that with a simple and obvious restriction... your parent must be the same or earlier version of Maven. You cannot have as a parent a newer version of Maven than the child is built with. >>> >>> I think there is more to this. >>> >>> At very least we need to decide what to do with in 4.0.0 >>> compatible poms. Maybe we should always deploy effective pom with >>> build-related elements removed. >>> >> >> Well I think the simple thing is that the 4.0.0 pom is fully resolved when >> you have a builder pom >> >> >>> >>> I am also not sure if it is enough to deploy "build" parent poms as is. >>> Your suggested "parent must be the same or earlier version of Maven" >>> implies new versions of Maven can read older pom formats, which I think >>> will significantly limit our flexibility to evolve pom format. >> >> >> They need to be able to parse it into the model. Perhaps they do the >> parsing by downloading a parser. But I think it is reasonable to expect >> that we can convert older build pom formats into newer ones and just let >> Maven take care of it... if we cannot do that then we are really creating a >> brand new build tool rather than evolving Maven >> >> >>> I wonder >>> if we can have different solution for force parent poms, like >>> org.apache:apache, which are used by multiple projects and different >>> versions of maven and project-specific parent poms, where it is much >>> easier to require specific version of maven. >>> >> >> Well the simple way is we have deployed the 4.0.0 parent pom as >> org.apache:apache:14:pom if you want to upgrade your parent to >> org.apache:apache:15 then you will need to require Maven 4.0+ to build. If >> you don't want to upgrade your build time requirements, then don't upgrade >> the parent... and if we need to "fix" things in the parent for 4.0.0 >> consumers, we can always deploy org.apache:apache:14.1 as a newer 4.0.0 >> model pom >> >> >>> -- >>> Regards, >>> Igor >>> >>> >>> - >>> 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 http://twitter.com/takari_io - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa
Re: Evolving the POM format
I am curious why you interoperability as a requirement? Perhaps questioning that may seem outrageous, but I see no problem with saying that you need to upgrade to Maven X.Y to read newer POM formats. If a vendor wants to backport their project into older POM formats, that should be the vendor's shoulders and not be a concern of Maven core. If Maven does publish older formats of POMs, you then have to decide how many older formats do you want to publish? One day there will be a 4.1 or 5.0, and it's going to complicate the world if Maven takes on the burden of interoperability. Cheers, Paul On Thu, Jun 19, 2014 at 9:57 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > On 19 June 2014 15:48, Igor Fedorenko wrote: > > > > > > > On 2014-06-19, 10:30, Stephen Connolly wrote: > > > >> - Igor is*mostly* right in that we should not deploy the pom that is > used > >> > >> to build to the repository... > >> - Where Igor is wrong is that for pom we should > >> actually deploy the build time pom to the repository... probably with > the > >> classifier `build`... this is safe as `pom` does cannot have a > classifier > >> in model version 4.0.0. > >> - You couple that with a simple and obvious restriction... your parent > >> must > >> be the same or earlier version of Maven. You cannot have as a parent a > >> newer version of Maven than the child is built with. > >> > > > > I think there is more to this. > > > > At very least we need to decide what to do with in 4.0.0 > > compatible poms. Maybe we should always deploy effective pom with > > build-related elements removed. > > > > Well I think the simple thing is that the 4.0.0 pom is fully resolved when > you have a builder pom > > > > > > I am also not sure if it is enough to deploy "build" parent poms as is. > > Your suggested "parent must be the same or earlier version of Maven" > > implies new versions of Maven can read older pom formats, which I think > > will significantly limit our flexibility to evolve pom format. > > > They need to be able to parse it into the model. Perhaps they do the > parsing by downloading a parser. But I think it is reasonable to expect > that we can convert older build pom formats into newer ones and just let > Maven take care of it... if we cannot do that then we are really creating a > brand new build tool rather than evolving Maven > > > > I wonder > > if we can have different solution for force parent poms, like > > org.apache:apache, which are used by multiple projects and different > > versions of maven and project-specific parent poms, where it is much > > easier to require specific version of maven. > > > > Well the simple way is we have deployed the 4.0.0 parent pom as > org.apache:apache:14:pom if you want to upgrade your parent to > org.apache:apache:15 then you will need to require Maven 4.0+ to build. If > you don't want to upgrade your build time requirements, then don't upgrade > the parent... and if we need to "fix" things in the parent for 4.0.0 > consumers, we can always deploy org.apache:apache:14.1 as a newer 4.0.0 > model pom > > > > -- > > Regards, > > Igor > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
Re: Evolving the POM format
On 19 June 2014 15:48, Igor Fedorenko wrote: > > > On 2014-06-19, 10:30, Stephen Connolly wrote: > >> - Igor is*mostly* right in that we should not deploy the pom that is used >> >> to build to the repository... >> - Where Igor is wrong is that for pom we should >> actually deploy the build time pom to the repository... probably with the >> classifier `build`... this is safe as `pom` does cannot have a classifier >> in model version 4.0.0. >> - You couple that with a simple and obvious restriction... your parent >> must >> be the same or earlier version of Maven. You cannot have as a parent a >> newer version of Maven than the child is built with. >> > > I think there is more to this. > > At very least we need to decide what to do with in 4.0.0 > compatible poms. Maybe we should always deploy effective pom with > build-related elements removed. > Well I think the simple thing is that the 4.0.0 pom is fully resolved when you have a builder pom > > I am also not sure if it is enough to deploy "build" parent poms as is. > Your suggested "parent must be the same or earlier version of Maven" > implies new versions of Maven can read older pom formats, which I think > will significantly limit our flexibility to evolve pom format. They need to be able to parse it into the model. Perhaps they do the parsing by downloading a parser. But I think it is reasonable to expect that we can convert older build pom formats into newer ones and just let Maven take care of it... if we cannot do that then we are really creating a brand new build tool rather than evolving Maven > I wonder > if we can have different solution for force parent poms, like > org.apache:apache, which are used by multiple projects and different > versions of maven and project-specific parent poms, where it is much > easier to require specific version of maven. > Well the simple way is we have deployed the 4.0.0 parent pom as org.apache:apache:14:pom if you want to upgrade your parent to org.apache:apache:15 then you will need to require Maven 4.0+ to build. If you don't want to upgrade your build time requirements, then don't upgrade the parent... and if we need to "fix" things in the parent for 4.0.0 consumers, we can always deploy org.apache:apache:14.1 as a newer 4.0.0 model pom > -- > Regards, > Igor > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Evolving the POM format
On 2014-06-19, 10:30, Stephen Connolly wrote: - Igor is*mostly* right in that we should not deploy the pom that is used to build to the repository... - Where Igor is wrong is that for pom we should actually deploy the build time pom to the repository... probably with the classifier `build`... this is safe as `pom` does cannot have a classifier in model version 4.0.0. - You couple that with a simple and obvious restriction... your parent must be the same or earlier version of Maven. You cannot have as a parent a newer version of Maven than the child is built with. I think there is more to this. At very least we need to decide what to do with in 4.0.0 compatible poms. Maybe we should always deploy effective pom with build-related elements removed. I am also not sure if it is enough to deploy "build" parent poms as is. Your suggested "parent must be the same or earlier version of Maven" implies new versions of Maven can read older pom formats, which I think will significantly limit our flexibility to evolve pom format. I wonder if we can have different solution for force parent poms, like org.apache:apache, which are used by multiple projects and different versions of maven and project-specific parent poms, where it is much easier to require specific version of maven. -- Regards, Igor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Evolving the POM format
While the time of day is perfect for me, the day of week being Wed is exactly wrong for me... I have a weekly meeting at that exact time. Some thoughts on evolving the pom. - We need to deploy the 4.0.0 compatible pom no matter what we do. Full stop. - Igor is *mostly* right in that we should not deploy the pom that is used to build to the repository... - Where Igor is wrong is that for pom we should actually deploy the build time pom to the repository... probably with the classifier `build`... this is safe as `pom` does cannot have a classifier in model version 4.0.0. - You couple that with a simple and obvious restriction... your parent must be the same or earlier version of Maven. You cannot have as a parent a newer version of Maven than the child is built with. - So that leaves the 4.0.0 compatible pom only detailing ... there are some concepts that we need to introduce that cannot be handled in 4.0.0 model: * "provides" concept, i.e. this artifact is equivalent to another artifact... so that you can remove artifacts from the dependency tree *of consumers* sensibly without needing to add excludes everywhere. So for example org.mortbay.jetty:servlet-api:3.0.20100224 could say it provides javax.servlet:servlet-api:3.0 and thus if I have a direct dependency on org.mortbay.jetty:servlet-api:3.0.20100224 then Maven will know that any of my other dependencies that have a transitive dependency on javax.servlet:servlet-api:3.0 can have that dependency purged from the tree. The provides concept can be transitive depending on the scope of the dependency... probably need a new scope to reflect a dependency being included in an überjar style. So a "provided" dependency would not add a provides entry... but a "bundled" dependency would. * "runtimes" concept, in some ways this can be handled by using dependencies... in other words we can create a "pseudo" dependency at "java.lang:specification" with versions 1.1, 1.2, 1.3, 1.4, 5.0, 6.0, 7.0, 8.0, etc and use that dependency to indicate the byte code version that you require. Similarly a "pseudo" dependency could handle the "java.lang:runtime" to cover the runtime library requirements... here provides is a great help as those features that are included in different versions of the JRE but available via standalone dependencies can be covered with "provides" in those pseudo poms. The actual jars can be empty. This should work for android too as the android runtime can be considered as a snapshot of the java one for a specific version. The downside with the dependency approach is that we loose out on enforcement policies... OTOH perhaps we can use the pseudo dependencies as a way of mapping the information back. On 19 June 2014 14:50, Jesse McConnell wrote: > Thanks Jason, it was fun, we have been thinking about organizing > something like this for Jetty for a while now, maybe get Greg to go > through the new http/2 implementation and talk about the latest > draft...things like that. > > anyway, good fun! > jesse > -- > jesse mcconnell > jesse.mcconn...@gmail.com > > > On Thu, Jun 19, 2014 at 8:46 AM, Jason van Zyl wrote: > > Sorry I use Jekyll locally, the actual link is: > > > > http://takari.io/2014/06/19/hangout-pom-format.html > > > > On Jun 19, 2014, at 9:43 AM, Paul Benedict wrote: > > > >> Jason, I am sure accessing your localhost is blocked :-) > >> > >> > >> Cheers, > >> Paul > >> > >> > >> On Thu, Jun 19, 2014 at 8:40 AM, Jason van Zyl wrote: > >> > >>> We had the hangout yesterday. I pushed the initial bit of information > >>> about evolving the POM format here in a blog post here: > >>> > >>> http://localhost:4000/2014/06/19/hangout-pom-format.html > >>> > >>> And created a page in the Wiki to start capturing the information: > >>> > >>> > https://cwiki.apache.org/confluence/display/MAVEN/Evolving+the+POM+Format > >>> > >>> Thanks, > >>> > >>> Jason > >>> > >>> -- > >>> Jason van Zyl > >>> Founder, Apache Maven > >>> http://twitter.com/jvanzyl > >>> http://twitter.com/takari_io > >>> - > >>> > >>> the course of true love never did run smooth ... > >>> > >>> -- Shakespeare > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > > > > Thanks, > > > > Jason > > > > -- > > Jason van Zyl > > Founder, Apache Maven > > http://twitter.com/jvanzyl > > http://twitter.com/takari_io > > - > > > > the course of true love never did run smooth ... > > > > -- Shakespeare > > > > > > > > > > > > > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Evolving the POM format
Thanks Jason, it was fun, we have been thinking about organizing something like this for Jetty for a while now, maybe get Greg to go through the new http/2 implementation and talk about the latest draft...things like that. anyway, good fun! jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Thu, Jun 19, 2014 at 8:46 AM, Jason van Zyl wrote: > Sorry I use Jekyll locally, the actual link is: > > http://takari.io/2014/06/19/hangout-pom-format.html > > On Jun 19, 2014, at 9:43 AM, Paul Benedict wrote: > >> Jason, I am sure accessing your localhost is blocked :-) >> >> >> Cheers, >> Paul >> >> >> On Thu, Jun 19, 2014 at 8:40 AM, Jason van Zyl wrote: >> >>> We had the hangout yesterday. I pushed the initial bit of information >>> about evolving the POM format here in a blog post here: >>> >>> http://localhost:4000/2014/06/19/hangout-pom-format.html >>> >>> And created a page in the Wiki to start capturing the information: >>> >>> https://cwiki.apache.org/confluence/display/MAVEN/Evolving+the+POM+Format >>> >>> Thanks, >>> >>> Jason >>> >>> -- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> http://twitter.com/takari_io >>> - >>> >>> the course of true love never did run smooth ... >>> >>> -- Shakespeare >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > - > > the course of true love never did run smooth ... > > -- Shakespeare > > > > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Evolving the POM format
Sorry I use Jekyll locally, the actual link is: http://takari.io/2014/06/19/hangout-pom-format.html On Jun 19, 2014, at 9:43 AM, Paul Benedict wrote: > Jason, I am sure accessing your localhost is blocked :-) > > > Cheers, > Paul > > > On Thu, Jun 19, 2014 at 8:40 AM, Jason van Zyl wrote: > >> We had the hangout yesterday. I pushed the initial bit of information >> about evolving the POM format here in a blog post here: >> >> http://localhost:4000/2014/06/19/hangout-pom-format.html >> >> And created a page in the Wiki to start capturing the information: >> >> https://cwiki.apache.org/confluence/display/MAVEN/Evolving+the+POM+Format >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> http://twitter.com/takari_io >> - >> >> the course of true love never did run smooth ... >> >> -- Shakespeare >> >> >> >> >> >> >> >> >> >> Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - the course of true love never did run smooth ... -- Shakespeare
Re: Evolving the POM format
Ah, both localhost and recording problem solved. The proper link is http://takari.io/2014/06/19/hangout-pom-format.html On Thu, Jun 19, 2014 at 3:45 PM, Tamás Cservenák wrote: > I could not make it for hangout, and got a message by google that hangout > was canceled? > > Where is a link of the recording, if any? > > > Thanks, > ~t~ > > > On Thu, Jun 19, 2014 at 3:40 PM, Jason van Zyl wrote: > >> We had the hangout yesterday. I pushed the initial bit of information >> about evolving the POM format here in a blog post here: >> >> http://localhost:4000/2014/06/19/hangout-pom-format.html >> >> And created a page in the Wiki to start capturing the information: >> >> https://cwiki.apache.org/confluence/display/MAVEN/Evolving+the+POM+Format >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> http://twitter.com/takari_io >> - >> >> the course of true love never did run smooth ... >> >> -- Shakespeare >> >> >> >> >> >> >> >> >> >> >
Re: Evolving the POM format
I could not make it for hangout, and got a message by google that hangout was canceled? Where is a link of the recording, if any? Thanks, ~t~ On Thu, Jun 19, 2014 at 3:40 PM, Jason van Zyl wrote: > We had the hangout yesterday. I pushed the initial bit of information > about evolving the POM format here in a blog post here: > > http://localhost:4000/2014/06/19/hangout-pom-format.html > > And created a page in the Wiki to start capturing the information: > > https://cwiki.apache.org/confluence/display/MAVEN/Evolving+the+POM+Format > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > - > > the course of true love never did run smooth ... > > -- Shakespeare > > > > > > > > > >
Re: Evolving the POM format
The links are broken due to use of "localhost". Gary On Thu, Jun 19, 2014 at 9:40 AM, Jason van Zyl wrote: > We had the hangout yesterday. I pushed the initial bit of information > about evolving the POM format here in a blog post here: > > http://localhost:4000/2014/06/19/hangout-pom-format.html > > And created a page in the Wiki to start capturing the information: > > https://cwiki.apache.org/confluence/display/MAVEN/Evolving+the+POM+Format > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > - > > the course of true love never did run smooth ... > > -- Shakespeare > > > > > > > > > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: Evolving the POM format
Jason, I am sure accessing your localhost is blocked :-) Cheers, Paul On Thu, Jun 19, 2014 at 8:40 AM, Jason van Zyl wrote: > We had the hangout yesterday. I pushed the initial bit of information > about evolving the POM format here in a blog post here: > > http://localhost:4000/2014/06/19/hangout-pom-format.html > > And created a page in the Wiki to start capturing the information: > > https://cwiki.apache.org/confluence/display/MAVEN/Evolving+the+POM+Format > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > - > > the course of true love never did run smooth ... > > -- Shakespeare > > > > > > > > > >
Evolving the POM format
We had the hangout yesterday. I pushed the initial bit of information about evolving the POM format here in a blog post here: http://localhost:4000/2014/06/19/hangout-pom-format.html And created a page in the Wiki to start capturing the information: https://cwiki.apache.org/confluence/display/MAVEN/Evolving+the+POM+Format Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - the course of true love never did run smooth ... -- Shakespeare