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 <i...@ifedorenko.com> 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 <i...@ifedorenko.com> 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 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 <pbened...@apache.org> 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 <i...@ifedorenko.com> 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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
