You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@takari.io> on 2014/06/19 15:40:16 UTC
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
Re: Evolving the POM format
Posted by Tamás Cservenák <ta...@cservenak.net>.
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 <ta...@cservenak.net>
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 <ja...@takari.io> 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
Posted by Tamás Cservenák <ta...@cservenak.net>.
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 <ja...@takari.io> 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
Posted by Gary Gregory <ga...@gmail.com>.
The links are broken due to use of "localhost".
Gary
On Thu, Jun 19, 2014 at 9:40 AM, Jason van Zyl <ja...@takari.io> 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: garydgregory@gmail.com | ggregory@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
Posted by Jörg Hohwiller <jo...@j-hohwiller.de>.
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
>
>
>
>
>
>
>
>
>
>
Re: Evolving the POM format
Posted by Jason van Zyl <ja...@takari.io>.
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 <je...@gmail.com> 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.mcconnell@gmail.com
>
>
> On Thu, Jun 19, 2014 at 8:46 AM, Jason van Zyl <ja...@takari.io> 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 <pb...@apache.org> wrote:
>>
>>> Jason, I am sure accessing your localhost is blocked :-)
>>>
>>>
>>> Cheers,
>>> Paul
>>>
>>>
>>> On Thu, Jun 19, 2014 at 8:40 AM, Jason van Zyl <ja...@takari.io> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
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
Posted by Stephen Connolly <st...@gmail.com>.
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 <ig...@ifedorenko.com> 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 <ig...@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 <ig...@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 <pb...@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.connolly@gmail.com> wrote:
>>>>>>>
>>>>>>> On 19 June 2014 15:48, Igor Fedorenko <ig...@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-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>>> ---------
>>>>>>
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Evolving the POM format
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
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 <ig...@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 <ig...@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 <pb...@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.connolly@gmail.com> wrote:
>>>>>>
>>>>>> On 19 June 2014 15:48, Igor Fedorenko <ig...@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-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Evolving the POM format
Posted by Stephen Connolly <st...@gmail.com>.
+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 <ig...@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 <ig...@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 <pb...@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.connolly@gmail.com> wrote:
>>>>>
>>>>> On 19 June 2014 15:48, Igor Fedorenko <ig...@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-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Sent from my phone
Re: Evolving the POM format
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
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 <ig...@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 <pb...@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.connolly@gmail.com> wrote:
>>>>
>>>> On 19 June 2014 15:48, Igor Fedorenko <ig...@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Evolving the POM format
Posted by Stephen Connolly <st...@gmail.com>.
On Friday, 20 June 2014, Igor Fedorenko <ig...@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 <pb...@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.connolly@gmail.com> wrote:
>>>
>>> On 19 June 2014 15:48, Igor Fedorenko <ig...@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Sent from my phone
Re: Evolving the POM format
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
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 <pb...@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.connolly@gmail.com> wrote:
>>
>>> On 19 June 2014 15:48, Igor Fedorenko <ig...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Evolving the POM format
Posted by Mark Derricutt <ma...@talios.com>.
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" <st...@gmail.com>
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 <pb...@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.connolly@gmail.com> wrote:
> >
> > > On 19 June 2014 15:48, Igor Fedorenko <ig...@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-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
>
Re: Evolving the POM format
Posted by Stephen Connolly <st...@gmail.com>.
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 <pb...@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.connolly@gmail.com> wrote:
>
> > On 19 June 2014 15:48, Igor Fedorenko <ig...@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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
Re: Evolving the POM format
Posted by Jason van Zyl <ja...@takari.io>.
On Jun 19, 2014, at 11:49 AM, Paul Benedict <pb...@apache.org> 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 <ja...@takari.io> wrote:
>
>>
>> On Jun 19, 2014, at 11:24 AM, Paul Benedict <pb...@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.
>>
>> 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.connolly@gmail.com> wrote:
>>>
>>>> On 19 June 2014 15:48, Igor Fedorenko <ig...@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> ---------------------------------------------------------
>>
>> Selfish deeds are the shortest path to self destruction.
>>
>> -- The Seven Samuari, Akira Kurosawa
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------
Be not afraid of growing slowly, be only afraid of standing still.
-- Chinese Proverb
Re: Evolving the POM format
Posted by Stephen Connolly <st...@gmail.com>.
On Thursday, 19 June 2014, Robert Scholte <rf...@apache.org> wrote:
> Op Thu, 19 Jun 2014 18:07:33 +0200 schreef Stephen Connolly <
> stephen.alan.connolly@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
>> <packaging>pom</packaging> 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 <pb...@apache.org> 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 <ja...@takari.io> wrote:
>>>
>>> >
>>> > On Jun 19, 2014, at 11:24 AM, Paul Benedict <pb...@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.
>>> >
>>> > 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.connolly@gmail.com> wrote:
>>> > >
>>> > >> On 19 June 2014 15:48, Igor Fedorenko <ig...@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-unsubscribe@maven.apache.org
>>> > >>> For additional commands, e-mail: dev-help@maven.apache.org
>>> > >>>
>>> > >>>
>>> > >>
>>> >
>>> > Thanks,
>>> >
>>> > Jason
>>> >
>>> > ----------------------------------------------------------
>>> > Jason van Zyl
>>> > Founder, Apache Maven
>>> > http://twitter.com/jvanzyl
>>> > http://twitter.com/takari_io
>>> > ---------------------------------------------------------
>>> >
>>> > Selfish deeds are the shortest path to self destruction.
>>> >
>>> > -- The Seven Samuari, Akira Kurosawa
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Sent from my phone
Re: Evolving the POM format
Posted by Robert Scholte <rf...@apache.org>.
Op Thu, 19 Jun 2014 18:07:33 +0200 schreef Stephen Connolly
<st...@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. 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
> <packaging>pom</packaging> 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 <pb...@apache.org> 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 <ja...@takari.io> wrote:
>>
>> >
>> > On Jun 19, 2014, at 11:24 AM, Paul Benedict <pb...@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.
>> >
>> > 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.connolly@gmail.com> wrote:
>> > >
>> > >> On 19 June 2014 15:48, Igor Fedorenko <ig...@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-unsubscribe@maven.apache.org
>> > >>> For additional commands, e-mail: dev-help@maven.apache.org
>> > >>>
>> > >>>
>> > >>
>> >
>> > Thanks,
>> >
>> > Jason
>> >
>> > ----------------------------------------------------------
>> > Jason van Zyl
>> > Founder, Apache Maven
>> > http://twitter.com/jvanzyl
>> > http://twitter.com/takari_io
>> > ---------------------------------------------------------
>> >
>> > Selfish deeds are the shortest path to self destruction.
>> >
>> > -- The Seven Samuari, Akira Kurosawa
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Evolving the POM format
Posted by William Ferguson <wi...@xandar.com.au>.
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.connolly@gmail.com> wrote:
> On Friday, 20 June 2014, William Ferguson <wi...@xandar.com.au>
> 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.connolly@gmail.com <javascript:;>> 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
> > > <packaging>pom</packaging> 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 <pbenedict@apache.org
> > <javascript:;>> 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 <jason@takari.io
> > <javascript:;>> wrote:
> > > >
> > > > >
> > > > > On Jun 19, 2014, at 11:24 AM, Paul Benedict <pbenedict@apache.org
> > <javascript:;>>
> > > > 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.connolly@gmail.com <javascript:;>> wrote:
> > > > > >
> > > > > >> On 19 June 2014 15:48, Igor Fedorenko <igor@ifedorenko.com
> > <javascript:;>> 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-unsubscribe@maven.apache.org
> > <javascript:;>
> > > > > >>> For additional commands, e-mail: dev-help@maven.apache.org
> > <javascript:;>
> > > > > >>>
> > > > > >>>
> > > > > >>
> > > > >
> > > > > 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
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
>
> --
> Sent from my phone
>
Re: Evolving the POM format
Posted by Stephen Connolly <st...@gmail.com>.
On Friday, 20 June 2014, William Ferguson <wi...@xandar.com.au>
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.connolly@gmail.com <javascript:;>> 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
> > <packaging>pom</packaging> 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 <pbenedict@apache.org
> <javascript:;>> 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 <jason@takari.io
> <javascript:;>> wrote:
> > >
> > > >
> > > > On Jun 19, 2014, at 11:24 AM, Paul Benedict <pbenedict@apache.org
> <javascript:;>>
> > > 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.connolly@gmail.com <javascript:;>> wrote:
> > > > >
> > > > >> On 19 June 2014 15:48, Igor Fedorenko <igor@ifedorenko.com
> <javascript:;>> 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-unsubscribe@maven.apache.org
> <javascript:;>
> > > > >>> For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;>
> > > > >>>
> > > > >>>
> > > > >>
> > > >
> > > > 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
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
>
--
Sent from my phone
Re: Evolving the POM format
Posted by William Ferguson <wi...@xandar.com.au>.
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.connolly@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
> <packaging>pom</packaging> 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 <pb...@apache.org> 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 <ja...@takari.io> wrote:
> >
> > >
> > > On Jun 19, 2014, at 11:24 AM, Paul Benedict <pb...@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.
> > >
> > > 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.connolly@gmail.com> wrote:
> > > >
> > > >> On 19 June 2014 15:48, Igor Fedorenko <ig...@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-unsubscribe@maven.apache.org
> > > >>> For additional commands, e-mail: dev-help@maven.apache.org
> > > >>>
> > > >>>
> > > >>
> > >
> > > Thanks,
> > >
> > > Jason
> > >
> > > ----------------------------------------------------------
> > > Jason van Zyl
> > > Founder, Apache Maven
> > > http://twitter.com/jvanzyl
> > > http://twitter.com/takari_io
> > > ---------------------------------------------------------
> > >
> > > Selfish deeds are the shortest path to self destruction.
> > >
> > > -- The Seven Samuari, Akira Kurosawa
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
Re: Evolving the POM format
Posted by Stephen Connolly <st...@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
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
<packaging>pom</packaging> 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 <pb...@apache.org> 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 <ja...@takari.io> wrote:
>
> >
> > On Jun 19, 2014, at 11:24 AM, Paul Benedict <pb...@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.
> >
> > 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.connolly@gmail.com> wrote:
> > >
> > >> On 19 June 2014 15:48, Igor Fedorenko <ig...@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-unsubscribe@maven.apache.org
> > >>> For additional commands, e-mail: dev-help@maven.apache.org
> > >>>
> > >>>
> > >>
> >
> > Thanks,
> >
> > Jason
> >
> > ----------------------------------------------------------
> > Jason van Zyl
> > Founder, Apache Maven
> > http://twitter.com/jvanzyl
> > http://twitter.com/takari_io
> > ---------------------------------------------------------
> >
> > Selfish deeds are the shortest path to self destruction.
> >
> > -- The Seven Samuari, Akira Kurosawa
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
Re: Evolving the POM format
Posted by Paul Benedict <pb...@apache.org>.
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 <ja...@takari.io> wrote:
>
> On Jun 19, 2014, at 11:24 AM, Paul Benedict <pb...@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.
>
> 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.connolly@gmail.com> wrote:
> >
> >> On 19 June 2014 15:48, Igor Fedorenko <ig...@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-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>>
> >>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
>
> Selfish deeds are the shortest path to self destruction.
>
> -- The Seven Samuari, Akira Kurosawa
>
>
>
>
>
>
>
>
>
>
Re: Evolving the POM format
Posted by Jason van Zyl <ja...@takari.io>.
On Jun 19, 2014, at 11:24 AM, Paul Benedict <pb...@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.
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.connolly@gmail.com> wrote:
>
>> On 19 June 2014 15:48, Igor Fedorenko <ig...@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------
Selfish deeds are the shortest path to self destruction.
-- The Seven Samuari, Akira Kurosawa
Re: Evolving the POM format
Posted by Paul Benedict <pb...@apache.org>.
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.connolly@gmail.com> wrote:
> On 19 June 2014 15:48, Igor Fedorenko <ig...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Evolving the POM format
Posted by Stephen Connolly <st...@gmail.com>.
On 19 June 2014 15:48, Igor Fedorenko <ig...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Evolving the POM format
Posted by Mark Derricutt <ma...@talios.com>.
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" <ig...@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.
>
> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Evolving the POM format
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
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.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Evolving the POM format
Posted by Stephen Connolly <st...@gmail.com>.
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 <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.
- So that leaves the 4.0.0 compatible pom only detailing <dependencies>...
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 <je...@gmail.com> 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.mcconnell@gmail.com
>
>
> On Thu, Jun 19, 2014 at 8:46 AM, Jason van Zyl <ja...@takari.io> 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 <pb...@apache.org> wrote:
> >
> >> Jason, I am sure accessing your localhost is blocked :-)
> >>
> >>
> >> Cheers,
> >> Paul
> >>
> >>
> >> On Thu, Jun 19, 2014 at 8:40 AM, Jason van Zyl <ja...@takari.io> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Evolving the POM format
Posted by Jesse McConnell <je...@gmail.com>.
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.mcconnell@gmail.com
On Thu, Jun 19, 2014 at 8:46 AM, Jason van Zyl <ja...@takari.io> 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 <pb...@apache.org> wrote:
>
>> Jason, I am sure accessing your localhost is blocked :-)
>>
>>
>> Cheers,
>> Paul
>>
>>
>> On Thu, Jun 19, 2014 at 8:40 AM, Jason van Zyl <ja...@takari.io> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Evolving the POM format
Posted by Jason van Zyl <ja...@takari.io>.
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 <pb...@apache.org> wrote:
> Jason, I am sure accessing your localhost is blocked :-)
>
>
> Cheers,
> Paul
>
>
> On Thu, Jun 19, 2014 at 8:40 AM, Jason van Zyl <ja...@takari.io> 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
Posted by Paul Benedict <pb...@apache.org>.
Jason, I am sure accessing your localhost is blocked :-)
Cheers,
Paul
On Thu, Jun 19, 2014 at 8:40 AM, Jason van Zyl <ja...@takari.io> 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
>
>
>
>
>
>
>
>
>
>