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" <[email protected]> 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 <[email protected]> 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 < > > [email protected]> wrote: > > > > > On 19 June 2014 15:48, Igor Fedorenko <[email protected]> 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 <packaging>pom</packaging> 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 <parent> 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: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > >
