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]
> > >
> > >
> >
>
