Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Karl Heinz Marbaise <kh...@gmx.de>]

Hi,

first changing the discussion to the dev list:

On 21/08/16 14:36, Robert Scholte wrote:
> Hi,
>
> Keep in mind that Maven is not the only tool/application using the pom.xml.
> Some of them probably never check the xsd or the modelVersion, so we
> need to be very carefull with this.
> If we introduce a new major modelVersion, that should probably result in
> a new file including a backported to the current 4.0.0 so all tools will
> keep working, including older versions of Maven.
> In this case 4.1.0 doesn't change the xsd but the handling of
> dependencies. I have no idea yet about the impact of such change. The
> last thing we want is that it'll destroy the Maven repository eco system.

The last sentence is very important...

So using a new POM Model version (4.1.0) and now I will deploy it to 
Maven Central. This means that only Maven 3.4+ can read and handle that. 
Older Maven versions will simply fail with this new version.

Furthermore If I would like to use Model version 4.1.0 now in my project 
I can't change it alone. I can not change only my project (a multi 
module build) and inherit from another POM's (corporate pom) with 
version 4.0.0. This will force me to change the whole inheritance 
hierachie chain to use Model version 4.1.0...and forces me to create a 
new hierachie of corporate pom's which are using Model Version 4.1.0 and 
in consequence I have to duplicate informations/work and maintanence 
which I will never do (independent of the advantages it might 
have)..neither other people in particular in companies will do so...(I 
have strong doubts about that).

I'm not sure about the suggestion of Christian using 
release:prepare-with-pom will that not result in a situation like this: 
Using the Model version 4.1.0 to handle some issue correct but deploying 
a pom with Model version 4.0.0 which can't handle that? All consumers 
would consume the model version 4.0.0 pom and fail in some situations ?


I've got a very strong impression this will not work at all...and in the 
end and the longer I'm thinking about this change:

-1 about this Change.

We need to find a better way for those things...May be this is exactly a 
sitution to control the behaviour via a feature flag to change this. So 
anybody can decide to use the new (correct) behaviour or keep the old 
behaviour...(which could be defined as the default).

As a first step we could emit warnings about those wrong pom's and give 
the user the hint that he could change that by using feature flag or 
better to fix the wrong pom files...


Changing the pom format in general can only being done in the Future 
with Maven 4.X may be can start working on PoC's or working on Maven 4.X 
  to see how this works..and see what does not work...or may be we are 
getting a better impression what kind of path we could go for in 
particular for the compatibility path...


Introducing an new `include` scope might be solution which might be 
discusses more in detail...


Kind regards
Karl Heinz

>
> Herv� and I plan to work on the consumer-pom, but that requires a good
> roadmap.
> First of all we need to separate the build-pom with the
> distribution-pom. They are now exactly the same, but this needs to be
> separated to be able to move forward.

 > On the the things we can finally
> fix is the absence of the version in the parent in case of a multimodule
> project.
 > So the build-pom you don't have to define the version, only the
> relativePath unless the default value is already okay. The
> distribution-pom can replace relativePath with the actual version.
>
> Next we need to think of the consumer-pom. The idea of this file is that
> it contains only relevant transitive information. The original idea was
> about a new format for speed and and having a list of all resolved
> dependencies. This way Maven doesn't have to go to a repository for
> every artifact, since this file already has all the required
> information.
 >
  Based on some suggested changed in Aether it seems that
> distance still matters, so maybe the dependencies should keep its tree
> structure within this consumer-pom.
> Another advantage of this is that the file already contains the fully
> resolved tree, so you don't depend on the implementation of any tool
> anymore regarding resolution rules.


>
> What is important it that we must keep a pom in the repository
> understandable for all other tools. If somehow the Maven repository
> becomes useless by introducing changes to the current pom we shouldn't
> do that, but think of a new file-format being extra installed/deployed.


> Robert
>
>
> On Sun, 21 Aug 2016 02:16:34 +0200, Christian Schulte <cs...@schulte.it>
> wrote:
>
>> Am 08/21/16 um 00:30 schrieb Mark Derricutt:
>>> Christian, is there anywhere describing what changes there are/or
>>> planned
>>> in Model version 4.1.0 at all?
>>
>> Nothing is documented yet. There have never been any plans. It's more
>> about having to revert a bunch of useful things to stay backwards
>> compatible or increase the model version and be able to ship without
>> breaking backwards compatibility. Plan is to keep all information about
>> different model versions in one central place. That currently is the
>> following class.
>>
>> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-model-builder/src/main/java/org/apache/maven/model/versioning/ModelVersions.java;h=6b527ca8666c279f55047702b3987f37b032bbe3;hb=HEAD>
>>
>>
>> If you search for the usages of the 'supportsXyz' methods, you can
>> easily spot the differences without the need for documentation today.
>> Not much. I think there are quite some things that have been discussed
>> for years that should really go into 3.4 based on model version 4.1.0
>> now. Personally I see no reason not to progress by incrementing the
>> model version.
>>
>> Maven also is about developers producing software for developers working
>> together with developers and only developers. That should really show
>> how easy things can progress and how productive things can be and not
>> the opposite. We should all focus more on this, in my opinion.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Mark Derricutt <ma...@talios.com>]

On 26 Aug 2016, at 22:07, Tibor Digana wrote:

> One or two years ago I watched mvn dev hangouts videos with Jason and

Were they really that long ago? Wow.  I was actually thinking about them the other day, wondering when/why they petered out, I ended up having to stop joining due to timezone issues ( it conflicted with my morning commute to work ) but enjoyed the discussions.

Mark

-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Tibor Digana <ti...@apache.org>]

One or two years ago I watched mvn dev hangouts videos with Jason and
Karl and others and there we mentioned the need for BOM. I understood
that BOM is similar to dependencyManagement different from typical
POM. In the video they wanted to solve some problem with dependencies
resolutions.
Do we still have this interest?
If yes what version 3.4 or 4.0 ?

On 8/26/16, Christian Schulte [via Maven]
<ml...@n5.nabble.com> wrote:
>
>
> Am 08/22/16 um 09:08 schrieb Stephen Connolly:
>> This is why I said that the v5 pom (which v4.1 is... just under a
>> different
>> name) would have to be deployed separately with a *best effort*
>> translation
>> down to the 4.0.0 model deployed at the standard coordinates.
>>
>> The problem then becomes that we are deploying now two poms for
>> everything,
>> a 4.0.0 as .pom and a 4.1.0 as -v4.1.0.pom say (i.e. if the classifier is
>> "v4.1.0")
>>
>> That in and of itself is not the end of the world... but then Maven 3.5
>> comes along and now every time we deploy a pom we will need to deploy a
>> 4.0.0 as foobar-1.0.pom, a 4.1.0 as foobar-1.0-v4.1.0.pom a 4.2.0 as
>> foobar-1.0-v4.2.0.pom...
>>
>> eventually we will end up deploying 20 or thirty poms at the same time...
>> just to deploy the pom.
>>
>> So that will not scale.
>
> That won't scale. What is to note here is that the XML schema or
> anything syntax does not change between 4.0.0 and 4.1.0. It's just that
> Maven 3.4 performs the dependency management import differently when
> operating on a 4.1.0 POM instead of a 4.0.0 POM.
>
>> So I am -1 on bumping a version number without an associated fix to
>> future-proof this.
>
> We cannot postpone such things forever. Let's just find such a
> future-proof solution please. Those endless discussions have led to
> nowhere so far. That -1 means I need to revert the new import scope
> behaviour. I wouldn't mind doing that but I see the minor version
> increment in the model version by far not so problematic as others. I
> don't know what to do else when introducing new model building
> behaviour. I'am on that "let's just do it, it won't do any harm" road
> here. I better not be wrong with that, of course.
>
>> I will, however, provide a *really bad solution* to this problem: XSLT
>
> It's not that bad. It's XML only and would make things like polyglot
> Maven even harder but since the consumer POM is something technical -
> not edited manually - we could just keep it XML forever. There are XML
> parsers and XSLT processors available for nearly every programming
> language. So XML is what makes the most sense. What is not solved that
> way is the change in semantics because it could only be used to
> transform different syntaxes. The changes which made me bump the model
> version are not syntax related. In fact, if you diff a pom-4.0.0.xml and
> a pom-4.1.0.xml the only difference would be the value of the model
> version element. Maven would build the effective model differently based
> on that value. You would not need to deploy two poms for this. So to
> summarize, we need to find a solution for handling different syntaxes
> and a solution to handle different semantics for the same syntax. If we
> are going to bump model versions, it must be clear to everyone what
> increment means what. Same syntax, different semantics: minor version
> increment. Different syntax, same semantics: major version increment.
> Leaves the patch version for bug fixes (like changing the order of
> elements for the combine.children attribute). Quite XML related. So we
> better not think about the model in terms of XML. What we currently have
> on master (4.1.0) would just work. I am not sure this model version
> increment without any change in syntax is really such an issue, however.
>
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
>
> _______________________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/Re-POM-Model-version-4-1-0-in-3-4-0-SNAPSHOTs-tp5878254p5878500.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166h86@n5.nabble.com
> To unsubscribe from Maven Developers, visit
> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==


-- 
Cheers
Tibor




--
View this message in context: http://maven.40175.n5.nabble.com/Re-POM-Model-version-4-1-0-in-3-4-0-SNAPSHOTs-tp5878254p5878501.html
Sent from the Maven Developers mailing list archive at Nabble.com.

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Hervé BOUTEMY <he...@free.fr>]

+1

Le dimanche 28 août 2016 12:57:52 Robert Scholte a écrit :
> Hi Tibor,
> 
> There's no need to hurry to for Maven-4.0.0 just because of the
> modelVersion. Maven2 was already using it, we may assume that users
> already know about this.
> I'd really prefer to stay on 3.x and go to 5.x once we've extended the
> model to version 5.0.0. (I don't mind skipping 4.x if that's the case)
> Users may expect huge changes when going to the next major.
> In case of the 3.0 it was most of all architectural, I wonder if most
> users noticed the changes. However, it still took a long long time to
> convince users to switch from 2.2.1 to 3.x
> 
> thanks,
> Robert
> 
> On Sat, 27 Aug 2016 22:42:49 +0200, Tibor Digana <ti...@apache.org>
> 
> wrote:
> > I supposed to align Maven 4.x with model version 4.0, and then
> > Maven 5.x with model version 5.0.
> > 
> > I supposed to directly release Maven 4.0.0 instead of 3.4.0.
> > 
> > Why we have to control model version and support it if the XSD
> > schemaLocation is already defined:
> > http://maven.apache.org/xsd/maven-4.0.0.xsd
> > ?
> > 
> > Is this double definition (xsd schema and modelVersion)?
> > 
> > On 8/27/16, Paul Benedict [via Maven]
> > 
> > <ml...@n5.nabble.com> wrote:
> >> Christian, I argue this is a matter of perspective in regards to
> >> "solve".
> >> 
> >> There are two things to solve:
> >> 1) Introducing new functionality with POM 4.1/5.0
> >> 2) Introducing acceptable responsiveness to the new POM by older tools
> >> 
> >> Point #1 can be introduced in whatever version of Maven, that is true,
> >> but
> >> it does have impact on Point #2. I've come to this conclusion based on
> >> some
> >> of the push back seen in this thread. If I may emphasize what concerns
> >> me
> >> most, it is the question of how older versions of Maven will be able to
> >> cope with something it cannot understand? I believe the best way to
> >> separate out these two concerns is to have separate lines of
> >> development --
> >> Maven 4.0 for #1 and Maven 3.x for #2 -- so that the two don't constrict
> >> and collide. The two concerns are admittedly related, but they don't
> >> need
> >> to be developed together because they are distinct enough in their
> >> behavior. I'd think you really want Maven 4.0 development to be as free
> >> as
> >> possible in terms of building out new features, and then letting the 3.x
> >> branch react to them in the wild. That's my formula for success which I
> >> propose to the development team here. I don't think it makes any sense
> >> to
> >> introduce such a grand feature in the 3.x line because it obscures the
> >> need
> >> to devise acceptable responses for older tools.
> >> 
> >> Pretending that Maven 3.4 (for sake of argument) started to gracefully
> >> handle future POM versions, the problem yet remains for Maven versions
> >> prior to 3.4. That's true. However, if agreement can be found in 3.4 for
> >> how to gracefully handle, and if that design plan is documented well,
> >> such
> >> concerns could be back-ported to even older versions, no? Clearly this
> >> doesn't help people who refuse to upgrade, but my emphasis here is about
> >> mitigation for those users who can tolerate a patch release. I'd rather
> >> have a plan in place to help those who want to help themselves, than do
> >> nothing at all.
> >> 
> >> With that said, it is really up to how 3.4 (for sake of argument) should
> >> gracefully handle the new POM versions. Many forks in the road here
> >> leading
> >> to different design answers :-) However, I find that to be a secondary
> >> concern, at this time. The first step is really deciding what I
> >> proposed:
> >> introduce POM 4.1/50 in Maven 4.0 or 3.x? If the development team can
> >> clearly answer that big picture strategy (and you know my opinion on
> >> that
> >> matter), you can then begin to debate how best to be backward
> >> compatible.
> >> 
> >> Cheers,
> >> Paul
> >> 
> >> On Tue, Aug 23, 2016 at 9:55 AM, Christian Schulte <cs...@schulte.it>
> >> 
> >> wrote:
> >>> Am 23.08.2016 um 15:53 schrieb Paul Benedict:
> >>> > I advise to not introduce any new POM version in the 3.x series.
> >>> 
> >>> Please
> >>> do
> >>> 
> >>> > that in Maven 4.0 where you can blue sky ideas and green field the
> >>> > development.
> >>> 
> >>> And how would we solve the issue at hand in Maven 4? We increase the
> >>> model version in Maven 4 to 5.0.0 and then? We do not run into exactly
> >>> the same issue we are currently trying to solve? Postponing to Maven 4
> >>> is not solving anything, really.
> >>> 
> >>> Regards,
> >>> --
> >>> Christian
> >>> 
> >>> 
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >> 
> >> _______________________________________________
> >> If you reply to this email, your message will be added to the discussion
> >> below:
> >> http://maven.40175.n5.nabble.com/Re-POM-Model-version-4-1-0-in-3-4-0-SNAP
> >> SHOTs-tp5878254p5878775.html To start a new topic under Maven Developers,
> >> email
> >> ml-node+s40175n142166h86@n5.nabble.com
> >> To unsubscribe from Maven Developers, visit
> >> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscri
> >> be_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4O
> >> TQ5MjEwMg==
> ---------------------------------------------------------------------
> 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: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 21.08.2016 um 17:19 schrieb Karl Heinz Marbaise:
> We need to find a better way for those things...May be this is exactly a
> sitution to control the behaviour via a feature flag to change this. So
> anybody can decide to use the new (correct) behaviour or keep the old
> behaviour...(which could be defined as the default).

You cannot deploy such POMs as well. Using command line options to 
control model building behaviour is not possible.

cmd> mvn --my-very-special-flag deploy

Someone consuming this pom also needs to add '--my-very-special-flag' to 
get the same result. Not even possible to print a warning about lack of 
that flag.

>
> As a first step we could emit warnings about those wrong pom's and give
> the user the hint that he could change that by using feature flag or
> better to fix the wrong pom files...

That's what I did. The warnings are not due to the change to the import 
scope. They would appear without any change to the import scope as well.

> Introducing an new `include` scope might be solution which might be
> discusses more in detail...

Increase the model version, introduce the include scope, or revert the 
changes. Just someone tell me what to do, please.

Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 08/21/16 um 17:19 schrieb Karl Heinz Marbaise:
> So using a new POM Model version (4.1.0) and now I will deploy it to 
> Maven Central. This means that only Maven 3.4+ can read and handle that. 
> Older Maven versions will simply fail with this new version.

Those older Maven versions would silently produce different effective
dependency managements when not using 3.4+ with those POMs. That's what
needs to be avoided. Introducing a new include scope, older Maven
versions would not support that as well and would hopefully fail due to
missing dependencies in the dependency management. I would like to be
sure they do fail - by incrementing the model version.

> 
> Furthermore If I would like to use Model version 4.1.0 now in my project 
> I can't change it alone. I can not change only my project (a multi 
> module build) and inherit from another POM's (corporate pom) with 
> version 4.0.0. This will force me to change the whole inheritance 
> hierachie chain to use Model version 4.1.0...and forces me to create a 
> new hierachie of corporate pom's which are using Model Version 4.1.0 and 
> in consequence I have to duplicate informations/work and maintanence 
> which I will never do (independent of the advantages it might 
> have)..neither other people in particular in companies will do so...(I 
> have strong doubts about that).

That's a question of upgrading to 4.1.0 or keeping 4.0.0. If you do not
need any of the 4.1.0 features, just keep things at 4.0.0. It's for
projects needing those features. I would not maintain 4.0.0 and 4.1.0
models in parallel. Why would someone want to do that? Upgrading to
4.1.0 means giving up on anything < 3.4. You do that for a reason or you
keep things the way they are.

> 
> I'm not sure about the suggestion of Christian using 
> release:prepare-with-pom will that not result in a situation like this: 
> Using the Model version 4.1.0 to handle some issue correct but deploying 
> a pom with Model version 4.0.0 which can't handle that? All consumers 
> would consume the model version 4.0.0 pom and fail in some situations ?

Of course not. The effective dependency management will be deployed. No
matter how that has been build. Import or include is invisible in those
flattened POMs.

> Introducing an new `include` scope might be solution which might be 
> discusses more in detail...

a: Revert the changes to the import scope making it incompatible with
older Maven versions.

b: Introduce model version 4.1.0 (current master).

c: Introduce the include scope and keep fingers crossed when used with
older Maven versions (had done that months ago but was asked to not
introduce a new scope).

d: Do nothing! Oh wait. That's not an option anymore. Remove my commit
bit so a situation like this will never happen again and revert the
changes yourself ;-). Damn it. Someone tell that damn idiot (<- me ;-))
what he should do now. If no one says anything, he will not do anything
and we get model version 4.1.0 in the next release.

Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Hervé Boutemy <hb...@apache.org>]

when we put "build-pom vs consumer-pom" in place, we don't need to publish 
build poms in the repository: the repository is here only to consume already-
built artifacts as dependencies, then with their consumer pom, then without 
newer Maven version prerequisites (= what we want: let people consume the 
built artifact without constraints on their build tool)

The key feature is to be able to generate a consumer-pom with good old POM 4.0 
semantics (and without build configuration, which is useless for consumers): I 
suppose the new "include" scope could be expanded to classical 
dependencies/dependencyManagement in consumer pom, for example.

the only build-poms we need in central are parent poms, ie poms with pom 
packaging: these poms are only necessary to build the artifacts, then putting 
some Maven version prerequisite to use them is not an issue.

Notice that consumer-poms for parent poms are not useful: then IMHO, for 
parent poms, only build-poms  should be published to central, when for any 
other pom, only consumer-poms should be published.

With this, we have a sustainable solution, where we have only one pom per 
artifactId, isn't it?

The only limitation is when we can't generate a build-pom from the consumer-
pom, since the new semantics has really no equivalent: is there such a case? 
(remember, it's about artifact consumption, not artifact build)

Regards,

Hervé

Le lundi 22 août 2016 19:26:54 Christian Schulte a écrit :
> Am 08/22/16 um 09:08 schrieb Stephen Connolly:
> > This is why I said that the v5 pom (which v4.1 is... just under a
> > different
> > name) would have to be deployed separately with a *best effort*
> > translation
> > down to the 4.0.0 model deployed at the standard coordinates.
> > 
> > The problem then becomes that we are deploying now two poms for
> > everything,
> > a 4.0.0 as .pom and a 4.1.0 as -v4.1.0.pom say (i.e. if the classifier is
> > "v4.1.0")
> > 
> > That in and of itself is not the end of the world... but then Maven 3.5
> > comes along and now every time we deploy a pom we will need to deploy a
> > 4.0.0 as foobar-1.0.pom, a 4.1.0 as foobar-1.0-v4.1.0.pom a 4.2.0 as
> > foobar-1.0-v4.2.0.pom...
> > 
> > eventually we will end up deploying 20 or thirty poms at the same time...
> > just to deploy the pom.
> > 
> > So that will not scale.
> 
> That won't scale. What is to note here is that the XML schema or
> anything syntax does not change between 4.0.0 and 4.1.0. It's just that
> Maven 3.4 performs the dependency management import differently when
> operating on a 4.1.0 POM instead of a 4.0.0 POM.
> 
> > So I am -1 on bumping a version number without an associated fix to
> > future-proof this.
> 
> We cannot postpone such things forever. Let's just find such a
> future-proof solution please. Those endless discussions have led to
> nowhere so far. That -1 means I need to revert the new import scope
> behaviour. I wouldn't mind doing that but I see the minor version
> increment in the model version by far not so problematic as others. I
> don't know what to do else when introducing new model building
> behaviour. I'am on that "let's just do it, it won't do any harm" road
> here. I better not be wrong with that, of course.
> 
> > I will, however, provide a *really bad solution* to this problem: XSLT
> 
> It's not that bad. It's XML only and would make things like polyglot
> Maven even harder but since the consumer POM is something technical -
> not edited manually - we could just keep it XML forever. There are XML
> parsers and XSLT processors available for nearly every programming
> language. So XML is what makes the most sense. What is not solved that
> way is the change in semantics because it could only be used to
> transform different syntaxes. The changes which made me bump the model
> version are not syntax related. In fact, if you diff a pom-4.0.0.xml and
> a pom-4.1.0.xml the only difference would be the value of the model
> version element. Maven would build the effective model differently based
> on that value. You would not need to deploy two poms for this. So to
> summarize, we need to find a solution for handling different syntaxes
> and a solution to handle different semantics for the same syntax. If we
> are going to bump model versions, it must be clear to everyone what
> increment means what. Same syntax, different semantics: minor version
> increment. Different syntax, same semantics: major version increment.
> Leaves the patch version for bug fixes (like changing the order of
> elements for the combine.children attribute). Quite XML related. So we
> better not think about the model in terms of XML. What we currently have
> on master (4.1.0) would just work. I am not sure this model version
> increment without any change in syntax is really such an issue, however.
> 
> 
> Regards,


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Tibor Digana <ti...@apache.org>]

@Jason
@all
Can you tell me why we want to release Maven 3.4.0 and not Maven 4.0.0?
I guess Maven 4.0.x may finalize Model Version 4.0.0 era.
Do you have other plans with Maven 4.x?

Back to modelVersion and consumer POM. The consumer pom is a subset of
normal POM. Keep using consumer POM with current schema would not
break the current users and therefore I think the schema should be
currently same. Even if the consumer POM would be smaller than you
project POM, it's still ok.

Maybe later users would have chance to release consumer POM under
modelVersion 5.0.0, 6.0.0, etc. Or lower version preferably chosen by
our plugins.

On 8/28/16, Tibor Digana <ti...@apache.org> wrote:
> Hi Robert, as I am reading your comments, I see the situation is not
> be so tragic :)
> What about to let m-deploy-p and m-release-p to decide on modelVersion
> of consumer project as the minimum version. If for instance a new
> scope value is available in <dependency/> of your project POM, then
> the plugin would decide to align modelVersion to higher than 4.0 and
> lower or equal to modelVersion in reactor's parent POM.
> This would guarantee that the consumer POM has minimum conflicts and
> maximize consumers community who can use this POM from Maven Central
>
> To override the modelVersion in Consumer POM:
>
> <configuration>
>    <targetConsumerModelVersion/>
> </configuration>
>
> --
> Cheers
> Tibor
>
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Re-POM-Model-version-4-1-0-in-3-4-0-SNAPSHOTs-tp5878254p5878961.html
> Sent from the Maven Developers mailing list archive at Nabble.com.


-- 
Cheers
Tibor

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Tibor Digana <ti...@apache.org>]

Hi Robert, as I am reading your comments, I see the situation is not
be so tragic :)
What about to let m-deploy-p and m-release-p to decide on modelVersion
of consumer project as the minimum version. If for instance a new
scope value is available in <dependency/> of your project POM, then
the plugin would decide to align modelVersion to higher than 4.0 and
lower or equal to modelVersion in reactor's parent POM.
This would guarantee that the consumer POM has minimum conflicts and
maximize consumers community who can use this POM from Maven Central

To override the modelVersion in Consumer POM:

<configuration>
   <targetConsumerModelVersion/>
</configuration>

-- 
Cheers
Tibor




--
View this message in context: http://maven.40175.n5.nabble.com/Re-POM-Model-version-4-1-0-in-3-4-0-SNAPSHOTs-tp5878254p5878961.html
Sent from the Maven Developers mailing list archive at Nabble.com.

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Hervé BOUTEMY <he...@free.fr>]

Le mercredi 24 août 2016 11:29:26 Fred Cooke a écrit :
> Someone nailed it when they said it'd be two big decisions, one for JRE one
> for MVN.
> 
> But here's the reality: People are just going to grab and use "the latest",
> whatever it is.
> 
> What does that mean? We'll probably start seeing dependencies we can't
> consume, but want to, and otherwise could.
> 
> A good library author/maintainer will dodge this bullet for their
> downstream users, but some won't care, or will be lazy, or will get annoyed
> running N versions of Maven.
+1
that's exactly what I fear: we'll be in a bad situation

> 
> There's some great discussion further up about splitting things sideways. I
> think that's the line this has to take.
> 
> In terms of a chunk of code that I want to leverage, I don't care much
> about it aside from its dependency tree and the classes within.
> 
> Keep this behaviour, somehow.
> 
> On Wed, Aug 24, 2016 at 11:11 AM, Christian Schulte <cs...@schulte.it> wrote:
> > Am 08/24/16 um 00:57 schrieb Paul Benedict:
> > > escape hatch here. If a client can't understand what's being specified,
> > > then what else can be done but fail?
> > 
> > That's what caught my attention as well. Is there anyone around knowing
> > about any kind of software which can handle forward compatiblity in a
> > way I could learn from?
> > 
> > Regards,
> > --
> > Christian
> > 
> > 
> > ---------------------------------------------------------------------
> > 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: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Fred Cooke <fr...@gmail.com>]

Someone nailed it when they said it'd be two big decisions, one for JRE one
for MVN.

But here's the reality: People are just going to grab and use "the latest",
whatever it is.

What does that mean? We'll probably start seeing dependencies we can't
consume, but want to, and otherwise could.

A good library author/maintainer will dodge this bullet for their
downstream users, but some won't care, or will be lazy, or will get annoyed
running N versions of Maven.

There's some great discussion further up about splitting things sideways. I
think that's the line this has to take.

In terms of a chunk of code that I want to leverage, I don't care much
about it aside from its dependency tree and the classes within.

Keep this behaviour, somehow.


On Wed, Aug 24, 2016 at 11:11 AM, Christian Schulte <cs...@schulte.it> wrote:

> Am 08/24/16 um 00:57 schrieb Paul Benedict:
> > escape hatch here. If a client can't understand what's being specified,
> > then what else can be done but fail?
>
> That's what caught my attention as well. Is there anyone around knowing
> about any kind of software which can handle forward compatiblity in a
> way I could learn from?
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 08/24/16 um 00:57 schrieb Paul Benedict:
> escape hatch here. If a client can't understand what's being specified,
> then what else can be done but fail?

That's what caught my attention as well. Is there anyone around knowing
about any kind of software which can handle forward compatiblity in a
way I could learn from?

Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Robert Scholte <rf...@apache.org>]

On Thu, 25 Aug 2016 08:00:14 +0200, Hervé BOUTEMY <he...@free.fr>  
wrote:

> Le mercredi 24 août 2016 13:50:33 Robert Scholte a écrit :
>> I realized last ApacheCon that I wasn't clear about my definiton of the
>> consumer-pom.
>> I don't think it should be a flattened pom with only the dependency
>> information. Instead it shouldn't be a pom  (matching the pom.xsd) at  
>> all.
> IMHO, that's perhaps a future version of consumer pom: a first iteration  
> of
> consumer pom as I understood it would be IMHO an important step in the  
> right
> direction = permit Maven evolution on build features, without breaking
> anything for artifact consumers
>
>> Maybe it should be called something like consumer-dom (dependency object
>> model, though dom is confusing...).
> when the model diverge, yes, we'll probably find a new name: to me,  
> that's a
> long future
>
>> It should be the most fast and efficient way to resolve the dependency
>> tree. That means it should do less roundtrips like Maven must do do  
>> right
>> now: for every dependency download the pom, for all transitive
>> dependencies download all poms, etc.
> flatten already helps: not the faster, but faster.
>

It is faster because there's less to parse, which results in less memory  
usage. These are indeed small improvements. But there's still a lot of  
overhead because of all the separate downloads.

>> Why can't it be a pom? I'd like to add the (file)extension too.  
>> Otherwise
>> Maven needs to initialize the matching ArtifactHandler and translate the
>> type to the proper extension. The pom doesn't have room for this.
> what is the performance loss from this requirement?
> I really don't catch the issue: network roundtrips have a strong impact,  
> using
> an object in memory injected by IoC doesn't have any impact to me
>

Then I have to assume you've never worked with custom packaging types. In  
those cases you need to specify a plugin with extensions=true to know  
about lifecycleHandlers and artifactHandlers. This implies that you first  
must download the plugin (and its dependencies) and load the Components  
before you know which file-extensions is used for the type.
Another related example is unpacking. Unpacking a jar now works because  
the definition is in maven-core, but for custom packaging types you are  
required to have the pom which has a plugin with extensions=true, which  
has a definition for the UnArchiver, etc, etc.

>> Consumer-dom is an extraction and enriched version of the pom and will  
>> be
>> a separate upload to the repository. Build tools who can understand this
>> file can use it or fall back by downloading all poms.
>>
>> thanks,
>> Robert
>>
>> On Wed, 24 Aug 2016 09:22:03 +0200, Stephen Connolly
>>
>> <st...@gmail.com> wrote:
>> > The consumer Pom is for machine to machine, it should be human  
>> readable
>> > because that is nice, but intent is never human generated.
>> >
>> > Switching to this separation allows us to be more radical in the  
>> changes
>> > to
>> > the build Pom.
>> >
>> > The only reason we deploy packaging Pom's build Pom is for  
>> inheritance.
>> > If
>> > we didn't have to deal with that we wouldn't need to deploy any build
>> > poms
>> > ever.
>> >
>> > For using a build Pom as a parent, you implicitly pick up the minimum
>> > version of maven that your parent requires, so we then are free to  
>> evolve
>> > the build Pom format without worrying about forward compatibility,  
>> only
>> > backwards compatibility on the *build* Pom.
>> >
>> > The consumer Pom needs partial *forward* compatibility, so that older
>> > clients are able to *attempt* to consume...
>> >
>> > In short there are totally different compatibility constraints on the
>> > two,
>> > so they should be separate.
>> >
>> > Mixins would probably also be deployed, once we figure out how they  
>> work
>> > with build poms.
>> >
>> > I think we probably need to rethink version ranges. What I'd like is  
>> to
>> > let
>> > the consumer Pom treat version ranges more as guidance rather than  
>> hard
>> > requirements. It's a pain if you depend transitiveky on Foo:[1.0] but
>> > need
>> > Foo:[1.0.1,1.1) for the critical security fix... Having to run around
>> > applying excludes is not a good plan... Yes the build should initially
>> > fail
>> > if I depend on [1.0] and [1.0.1,1.1) in my graph, but I should be  
>> able to
>> > resolve the conflict for all my consumers (unless they pull in the
>> > conflict
>> > again themselves)
>> >
>> > On Tuesday 23 August 2016, Fred Cooke <fr...@gmail.com> wrote:
>> >> I still find it a bit off that the original real POM won't always be
>> >> directly available anymore.
>> >>
>> >> Other tools create fake POMs because they *have* to - there's no  
>> other
>> >> option.
>> >>
>> >> I feel like some fidelity would be lost. Diffability would be lost
>> >> (from a
>> >> scenario where there's nothing to diff).
>> >>
>> >> Unrelated, really, but kind of related: top level deployable artefact
>> >> deployments, debs, wars, exes, etc. When ranges are in use it'd be  
>> nice
>> >> to
>> >> deploy a sort of strict effective pom with fully hard [] versions for
>> >> all
>> >> things. This can be achieved in other ways, though.
>> >>
>> >> I guess that is to say, don't forget about non-central deployments. I
>> >> suppose if there's a way to always deploy pom.xml.build through some
>> >> plugin
>> >> or configuration or some such, then that's fine with me.
>> >>
>> >> On Wed, Aug 24, 2016 at 6:49 PM, Hervé BOUTEMY <herve.boutemy@free.fr
>> >> <javascript:;>>
>> >>
>> >> wrote:
>> >> > Le mercredi 24 août 2016 18:41:59 Fred Cooke a écrit :
>> >> > > Fair call re embedded pom, however it's quite convenient to just
>> >>
>> >> browse
>> >>
>> >> > to
>> >> >
>> >> > > it and read.
>> >> > >
>> >> > > I've occasionally gone looking for details from poms of artefacts
>> >>
>> >> and
>> >>
>> >> > found
>> >> >
>> >> > > a mess and missing stuff, and been annoyed. It probably wasn't
>> >>
>> >> gradle's
>> >>
>> >> > > fault, though. Just a sloppy author. If I'm honest I wouldn't  
>> even
>> >>
>> >> know
>> >>
>> >> > if
>> >> >
>> >> > > I've ever consumed a non-maven artefact, certainly none of mine!  
>> :-)
>> >> > >
>> >> > > No, I am sure, I have, at least one, and it's an ant one with a  
>> hard
>> >> >
>> >> > coded
>> >> >
>> >> > > POM that doesn't always reflect the contents of the jar. Yuck.
>> >>
>> >> Clearly
>> >>
>> >> > not
>> >> >
>> >> > > an issue with automated stuff, though.
>> >> > >
>> >> > > My only argument now is ease of reading things like project
>> >>
>> >> descriptions,
>> >>
>> >> > > contributors, SCM details, etc rather than having to unpack the  
>> jar.
>> >>
>> >> And
>> >>
>> >> > if
>> >> >
>> >> > > you do, and end up with two pom.xmls laying around, that's not  
>> nice.
>> >> >
>> >> > Better
>> >> >
>> >> > > to just start always suffixing one with pom.xml.build or some  
>> such?
>> >>
>> >> I
>> >>
>> >> > think
>> >> >
>> >> > > so, but I haven't thought deeply about it aside from reading this
>> >>
>> >> thread.
>> >>
>> >> > our consumer pom will be generated from build pom: we can automate
>> >>
>> >> copy
>> >> of
>> >>
>> >> > any
>> >> > information we want, and for sure, I expect to put at least
>> >>
>> >> description,
>> >>
>> >> > scm
>> >> > details, issueManagement, license (of course).
>> >> > In your list, there is only constributors that I was not counting  
>> on
>> >>
>> >> it:
>> >> > but
>> >> > it's a detailed decision we'll have to make
>> >> >
>> >> > for sure, Maven consumer poms, since generated from Maven build  
>> pom,
>> >>
>> >> can
>> >>
>> >> > have
>> >> > much more details (and be sure they are accurrate) than build tools
>> >>
>> >> that
>> >>
>> >> > don't
>> >> > generate it from data that exists in their original build format
>> >> >
>> >> > Regards,
>> >> >
>> >> > Hervé
>> >> >
>> >> > > On Wed, Aug 24, 2016 at 6:32 PM, Hervé BOUTEMY
>> >>
>> >> <herve.boutemy@free.fr
>> >> <javascript:;>>
>> >>
>> >> > > wrote:
>> >> > > > Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit :
>> >> > > > > That should have separation between builder Pom and consumer
>> >>
>> >> Pom.
>> >> For
>> >>
>> >> > > > > packaging=pom we deploy the builder Pom using  
>> classifier=build
>> >> > > > > *for all other packaging a we do not deploy the builder Pom*.
>> >> > > > >
>> >> > > > > I don't like the sound of this. The deployed artefacts should
>> >>
>> >> include
>> >>
>> >> > > > > the
>> >> > > > > exact POM in use to build the project, as a reference, even  
>> if
>> >>
>> >> under
>> >>
>> >> > a
>> >> >
>> >> > > > > different name. Yes, they should be in SCM, however down  
>> stream
>> >>
>> >> it's
>> >>
>> >> > > > useful
>> >> > > >
>> >> > > > > to see these even when the SCM is offline or gone or private  
>> or
>> >> > > > > whatever.
>> >> > > > > Or did I misunderstand? If so, please clarify?
>> >> > > >
>> >> > > > when you consume an artifact not build with Maven, do you get  
>> the
>> >>
>> >> full
>> >>
>> >> > > > build
>> >> > > > script?
>> >> > > > no
>> >> > > > I know that, as Maven users, we got used to have the build pom
>> >> >
>> >> > published
>> >> >
>> >> > > > in
>> >> > > > central: this is now an issue, but we like that
>> >> > > >
>> >> > > > notice: the build pom can be injected in the artifact, in
>> >> >
>> >> > META-INF/maven,
>> >> >
>> >> > > > like
>> >> > > > it is currently done
>> >> > > > but I don't see the point in requiring it to be pbulished
>> >>
>> >> separately
>> >> in
>> >>
>> >> > > > central: no other build tool does that, and they don't have any
>> >>
>> >> issue
>> >>
>> >> > with
>> >> >
>> >> > > > that (and eventually it's a feature: don't publish internal
>> >>
>> >> details
>> >> you
>> >>
>> >> > > > don't
>> >> > > > really want people to see)
>> >> > > >
>> >> > > > Regards,
>> >> > > >
>> >> > > > Hervé
>> >> > > >
>> >> > > > > On Wed, Aug 24, 2016 at 1:52 PM, Stephen Connolly <
>> >> > > > >
>> >> > > > > stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>> >> > > > > > On Tuesday 23 August 2016, Paul Benedict  
>> <pbenedict@apache.org
>> >>
>> >> <javascript:;>>
>> >>
>> >> > wrote:
>> >> > > > > > > On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <
>> >> >
>> >> > cs@schulte.it <javascript:;>
>> >> >
>> >> > > > > > > <javascript:;>> wrote:
>> >> > > > > > > > Am 08/24/16 um 00:08 schrieb Paul Benedict:
>> >> > > > > > > > > POM and a future major version POM? I am hinting at a
>> >> >
>> >> > strategy
>> >> >
>> >> > > > for
>> >> > > >
>> >> > > > > > > > forward
>> >> > > > > > > >
>> >> > > > > > > > > compatibility.
>> >> > > > > > > >
>> >> > > > > > > > Is forward compatibility really needed/required?
>> >> > > > > > >
>> >> > > > > > > I honestly don't know, which is why I am asking. An  
>> answer
>> >>
>> >> of
>> >> "no
>> >>
>> >> > > > > > > compatibility" is possible, too.
>> >> > > > > > >
>> >> > > > > > > I can completely see the argument that says POMs must be
>> >> > > > > > > all-parseable-or-nothing -- for the sake of
>> >>
>> >> reproducibility. I
>> >>
>> >> > > > actually
>> >> > > >
>> >> > > > > > > prefer this answer. I think it is sensible to fail a  
>> build
>> >>
>> >> when
>> >>
>> >> > > > > > > encountering a POM version too advanced. If your client  
>> only
>> >> > > >
>> >> > > > supports up
>> >> > > >
>> >> > > > > > to
>> >> > > > > >
>> >> > > > > > > model 4.0.0, then all artifacts must be specified by  
>> 4.0.0
>> >> >
>> >> > models,
>> >> >
>> >> > > > too.
>> >> > > >
>> >> > > > > > > On the other hand, I wanted to give the benefit of the
>> >>
>> >> doubt to
>> >>
>> >> > the
>> >> >
>> >> > > > > > > opposite argument. At least one person spoke up and said
>> >>
>> >> it's
>> >>
>> >> > > > > > unacceptable
>> >> > > > > >
>> >> > > > > > > to fail a build on configuration you don't understand.  
>> Well,
>> >> >
>> >> > that's
>> >> >
>> >> > > > an
>> >> > > >
>> >> > > > > > > interesting argument, too. That person doesn't want to  
>> tank
>> >>
>> >> the
>> >>
>> >> > > > > > > build
>> >> > > > > > > for
>> >> > > > > > > the 1% of configuration that can't be understood.... but  
>> I
>> >>
>> >> fail
>> >>
>> >> > to
>> >> >
>> >> > > > see
>> >> > > >
>> >> > > > > > > an
>> >> > > > > > > escape hatch here. If a client can't understand what's  
>> being
>> >> > > >
>> >> > > > specified,
>> >> > > >
>> >> > > > > > > then what else can be done but fail?
>> >> > > > > >
>> >> > > > > > Strip the dependencies a and let the user fix up manually
>> >>
>> >> (ideally
>> >>
>> >> > by
>> >> >
>> >> > > > > > logging a warning that you are consuming a dependency  
>> using a
>> >>
>> >> newer
>> >>
>> >> > > > > > modelVersion)
>> >> > > > > >
>> >> > > > > > Everyone forgets that the 4.0.0 ship has sailed already,  
>> so we
>> >> >
>> >> > have to
>> >> >
>> >> > > > > > deploy best-effort 4.0.0 poms
>> >> > > > > >
>> >> > > > > > Now I say that 3.4 should not have a new modelVersion but
>> >>
>> >> what it
>> >>
>> >> > > > could do
>> >> > > >
>> >> > > > > > is be more forgiving of newer modelVersions or try and
>> >>
>> >> download
>> >> and
>> >>
>> >> > > > use an
>> >> > > >
>> >> > > > > > XSLT to convert newer modelVersions to 4.0.0 (while  
>> logging a
>> >> >
>> >> > warning)
>> >> >
>> >> > > > > > with
>> >> > > > > > option flags to allow failing the build if XSLT had to be
>> >>
>> >> applied
>> >>
>> >> > > > > > So let's bump the modelVersion in Maven 5.0.0 (there is no
>> >>
>> >> Maven
>> >>
>> >> > 4.x
>> >> >
>> >> > > > let's
>> >> > > >
>> >> > > > > > align on the modelVersion)
>> >> > > > > >
>> >> > > > > > That should have separation between builder Pom and  
>> consumer
>> >>
>> >> Pom.
>> >>
>> >> > For
>> >> >
>> >> > > > > > packaging=pom we deploy the builder Pom using  
>> classifier=build
>> >>
>> >> for
>> >>
>> >> > all
>> >> >
>> >> > > > > > other packaging a we do not deploy the builder Pom.
>> >> > > > > >
>> >> > > > > > We deploy a *best effort* conversion of the consumer Pom to
>> >> > > >
>> >> > > > modelVersion
>> >> > > >
>> >> > > > > > 4.0.0 without a classifier and the consumer Pom gets  
>> deployed
>> >>
>> >> as
>> >>
>> >> > > > > > classifier
>> >> > > > > > consumer.
>> >> > > > > >
>> >> > > > > > The consumer Pom format allows for XSLT to transform to a
>> >>
>> >> parsable
>> >>
>> >> > > > syntax,
>> >> > > >
>> >> > > > > > if transform is required we log a warning (or fail the  
>> build
>> >>
>> >> if
>> >> the
>> >>
>> >> > > > > > builder
>> >> > > > > > Pom indicates strict modelVersion adherence)
>> >> > > > > >
>> >> > > > > > So yeah maven 5.x will be able to parse dependencies with
>> >> >
>> >> > modelVersion
>> >> >
>> >> > > > 6.x
>> >> > > >
>> >> > > > > > while logging warnings that the user may not have the  
>> correct
>> >> > > >
>> >> > > > dependency
>> >> > > >
>> >> > > > > > tree. That is IMHO acceptable forward compatibility
>> >> > > > > >
>> >> > > > > > HTH
>> >> > > > > >
>> >> > > > > > -Stephen
>> >> > > > > >
>> >> > > > > > Ps I'm really hoping someone has a less crappy solution  
>> that
>> >> >
>> >> > this...
>> >> >
>> >> > > > But I
>> >> > > >
>> >> > > > > > believe this is actually *a* solution... And prior to this  
>> I
>> >>
>> >> have
>> >>
>> >> > not
>> >> >
>> >> > > > seen
>> >> > > >
>> >> > > > > > any solution
>> >> > > > > >
>> >> > > > > > > Cheers,
>> >> > > > > > > Paul
>> >> > > > > >
>> >> > > > > > --
>> >> > > > > > Sent from my phone
>> >> > > >
>> >> > > > ------------------------------------------------------------
>> >>
>> >> ---------
>> >>
>> >> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>
>> >> <javascript:;>
>> >>
>> >> > > > For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >> <javascript:;>
>> >>
>> >> >  
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>
>> >> <javascript:;>
>> >>
>> >> > For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >> <javascript:;>
>>
>> ---------------------------------------------------------------------
>> 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: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Hervé BOUTEMY <he...@free.fr>]

Le mercredi 24 août 2016 13:50:33 Robert Scholte a écrit :
> I realized last ApacheCon that I wasn't clear about my definiton of the
> consumer-pom.
> I don't think it should be a flattened pom with only the dependency
> information. Instead it shouldn't be a pom  (matching the pom.xsd) at all.
IMHO, that's perhaps a future version of consumer pom: a first iteration of 
consumer pom as I understood it would be IMHO an important step in the right 
direction = permit Maven evolution on build features, without breaking 
anything for artifact consumers

> Maybe it should be called something like consumer-dom (dependency object
> model, though dom is confusing...).
when the model diverge, yes, we'll probably find a new name: to me, that's a 
long future

> It should be the most fast and efficient way to resolve the dependency
> tree. That means it should do less roundtrips like Maven must do do right
> now: for every dependency download the pom, for all transitive
> dependencies download all poms, etc.
flatten already helps: not the faster, but faster.

> Why can't it be a pom? I'd like to add the (file)extension too. Otherwise
> Maven needs to initialize the matching ArtifactHandler and translate the
> type to the proper extension. The pom doesn't have room for this.
what is the performance loss from this requirement?
I really don't catch the issue: network roundtrips have a strong impact, using 
an object in memory injected by IoC doesn't have any impact to me

> Consumer-dom is an extraction and enriched version of the pom and will be
> a separate upload to the repository. Build tools who can understand this
> file can use it or fall back by downloading all poms.
> 
> thanks,
> Robert
> 
> On Wed, 24 Aug 2016 09:22:03 +0200, Stephen Connolly
> 
> <st...@gmail.com> wrote:
> > The consumer Pom is for machine to machine, it should be human readable
> > because that is nice, but intent is never human generated.
> > 
> > Switching to this separation allows us to be more radical in the changes
> > to
> > the build Pom.
> > 
> > The only reason we deploy packaging Pom's build Pom is for inheritance.
> > If
> > we didn't have to deal with that we wouldn't need to deploy any build
> > poms
> > ever.
> > 
> > For using a build Pom as a parent, you implicitly pick up the minimum
> > version of maven that your parent requires, so we then are free to evolve
> > the build Pom format without worrying about forward compatibility, only
> > backwards compatibility on the *build* Pom.
> > 
> > The consumer Pom needs partial *forward* compatibility, so that older
> > clients are able to *attempt* to consume...
> > 
> > In short there are totally different compatibility constraints on the
> > two,
> > so they should be separate.
> > 
> > Mixins would probably also be deployed, once we figure out how they work
> > with build poms.
> > 
> > I think we probably need to rethink version ranges. What I'd like is to
> > let
> > the consumer Pom treat version ranges more as guidance rather than hard
> > requirements. It's a pain if you depend transitiveky on Foo:[1.0] but
> > need
> > Foo:[1.0.1,1.1) for the critical security fix... Having to run around
> > applying excludes is not a good plan... Yes the build should initially
> > fail
> > if I depend on [1.0] and [1.0.1,1.1) in my graph, but I should be able to
> > resolve the conflict for all my consumers (unless they pull in the
> > conflict
> > again themselves)
> > 
> > On Tuesday 23 August 2016, Fred Cooke <fr...@gmail.com> wrote:
> >> I still find it a bit off that the original real POM won't always be
> >> directly available anymore.
> >> 
> >> Other tools create fake POMs because they *have* to - there's no other
> >> option.
> >> 
> >> I feel like some fidelity would be lost. Diffability would be lost
> >> (from a
> >> scenario where there's nothing to diff).
> >> 
> >> Unrelated, really, but kind of related: top level deployable artefact
> >> deployments, debs, wars, exes, etc. When ranges are in use it'd be nice
> >> to
> >> deploy a sort of strict effective pom with fully hard [] versions for
> >> all
> >> things. This can be achieved in other ways, though.
> >> 
> >> I guess that is to say, don't forget about non-central deployments. I
> >> suppose if there's a way to always deploy pom.xml.build through some
> >> plugin
> >> or configuration or some such, then that's fine with me.
> >> 
> >> On Wed, Aug 24, 2016 at 6:49 PM, Hervé BOUTEMY <herve.boutemy@free.fr
> >> <javascript:;>>
> >> 
> >> wrote:
> >> > Le mercredi 24 août 2016 18:41:59 Fred Cooke a écrit :
> >> > > Fair call re embedded pom, however it's quite convenient to just
> >> 
> >> browse
> >> 
> >> > to
> >> > 
> >> > > it and read.
> >> > > 
> >> > > I've occasionally gone looking for details from poms of artefacts
> >> 
> >> and
> >> 
> >> > found
> >> > 
> >> > > a mess and missing stuff, and been annoyed. It probably wasn't
> >> 
> >> gradle's
> >> 
> >> > > fault, though. Just a sloppy author. If I'm honest I wouldn't even
> >> 
> >> know
> >> 
> >> > if
> >> > 
> >> > > I've ever consumed a non-maven artefact, certainly none of mine! :-)
> >> > > 
> >> > > No, I am sure, I have, at least one, and it's an ant one with a hard
> >> > 
> >> > coded
> >> > 
> >> > > POM that doesn't always reflect the contents of the jar. Yuck.
> >> 
> >> Clearly
> >> 
> >> > not
> >> > 
> >> > > an issue with automated stuff, though.
> >> > > 
> >> > > My only argument now is ease of reading things like project
> >> 
> >> descriptions,
> >> 
> >> > > contributors, SCM details, etc rather than having to unpack the jar.
> >> 
> >> And
> >> 
> >> > if
> >> > 
> >> > > you do, and end up with two pom.xmls laying around, that's not nice.
> >> > 
> >> > Better
> >> > 
> >> > > to just start always suffixing one with pom.xml.build or some such?
> >> 
> >> I
> >> 
> >> > think
> >> > 
> >> > > so, but I haven't thought deeply about it aside from reading this
> >> 
> >> thread.
> >> 
> >> > our consumer pom will be generated from build pom: we can automate
> >> 
> >> copy
> >> of
> >> 
> >> > any
> >> > information we want, and for sure, I expect to put at least
> >> 
> >> description,
> >> 
> >> > scm
> >> > details, issueManagement, license (of course).
> >> > In your list, there is only constributors that I was not counting on
> >> 
> >> it:
> >> > but
> >> > it's a detailed decision we'll have to make
> >> > 
> >> > for sure, Maven consumer poms, since generated from Maven build pom,
> >> 
> >> can
> >> 
> >> > have
> >> > much more details (and be sure they are accurrate) than build tools
> >> 
> >> that
> >> 
> >> > don't
> >> > generate it from data that exists in their original build format
> >> > 
> >> > Regards,
> >> > 
> >> > Hervé
> >> > 
> >> > > On Wed, Aug 24, 2016 at 6:32 PM, Hervé BOUTEMY
> >> 
> >> <herve.boutemy@free.fr
> >> <javascript:;>>
> >> 
> >> > > wrote:
> >> > > > Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit :
> >> > > > > That should have separation between builder Pom and consumer
> >> 
> >> Pom.
> >> For
> >> 
> >> > > > > packaging=pom we deploy the builder Pom using classifier=build
> >> > > > > *for all other packaging a we do not deploy the builder Pom*.
> >> > > > > 
> >> > > > > I don't like the sound of this. The deployed artefacts should
> >> 
> >> include
> >> 
> >> > > > > the
> >> > > > > exact POM in use to build the project, as a reference, even if
> >> 
> >> under
> >> 
> >> > a
> >> > 
> >> > > > > different name. Yes, they should be in SCM, however down stream
> >> 
> >> it's
> >> 
> >> > > > useful
> >> > > > 
> >> > > > > to see these even when the SCM is offline or gone or private or
> >> > > > > whatever.
> >> > > > > Or did I misunderstand? If so, please clarify?
> >> > > > 
> >> > > > when you consume an artifact not build with Maven, do you get the
> >> 
> >> full
> >> 
> >> > > > build
> >> > > > script?
> >> > > > no
> >> > > > I know that, as Maven users, we got used to have the build pom
> >> > 
> >> > published
> >> > 
> >> > > > in
> >> > > > central: this is now an issue, but we like that
> >> > > > 
> >> > > > notice: the build pom can be injected in the artifact, in
> >> > 
> >> > META-INF/maven,
> >> > 
> >> > > > like
> >> > > > it is currently done
> >> > > > but I don't see the point in requiring it to be pbulished
> >> 
> >> separately
> >> in
> >> 
> >> > > > central: no other build tool does that, and they don't have any
> >> 
> >> issue
> >> 
> >> > with
> >> > 
> >> > > > that (and eventually it's a feature: don't publish internal
> >> 
> >> details
> >> you
> >> 
> >> > > > don't
> >> > > > really want people to see)
> >> > > > 
> >> > > > Regards,
> >> > > > 
> >> > > > Hervé
> >> > > > 
> >> > > > > On Wed, Aug 24, 2016 at 1:52 PM, Stephen Connolly <
> >> > > > > 
> >> > > > > stephen.alan.connolly@gmail.com <javascript:;>> wrote:
> >> > > > > > On Tuesday 23 August 2016, Paul Benedict <pbenedict@apache.org
> >> 
> >> <javascript:;>>
> >> 
> >> > wrote:
> >> > > > > > > On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <
> >> > 
> >> > cs@schulte.it <javascript:;>
> >> > 
> >> > > > > > > <javascript:;>> wrote:
> >> > > > > > > > Am 08/24/16 um 00:08 schrieb Paul Benedict:
> >> > > > > > > > > POM and a future major version POM? I am hinting at a
> >> > 
> >> > strategy
> >> > 
> >> > > > for
> >> > > > 
> >> > > > > > > > forward
> >> > > > > > > > 
> >> > > > > > > > > compatibility.
> >> > > > > > > > 
> >> > > > > > > > Is forward compatibility really needed/required?
> >> > > > > > > 
> >> > > > > > > I honestly don't know, which is why I am asking. An answer
> >> 
> >> of
> >> "no
> >> 
> >> > > > > > > compatibility" is possible, too.
> >> > > > > > > 
> >> > > > > > > I can completely see the argument that says POMs must be
> >> > > > > > > all-parseable-or-nothing -- for the sake of
> >> 
> >> reproducibility. I
> >> 
> >> > > > actually
> >> > > > 
> >> > > > > > > prefer this answer. I think it is sensible to fail a build
> >> 
> >> when
> >> 
> >> > > > > > > encountering a POM version too advanced. If your client only
> >> > > > 
> >> > > > supports up
> >> > > > 
> >> > > > > > to
> >> > > > > > 
> >> > > > > > > model 4.0.0, then all artifacts must be specified by 4.0.0
> >> > 
> >> > models,
> >> > 
> >> > > > too.
> >> > > > 
> >> > > > > > > On the other hand, I wanted to give the benefit of the
> >> 
> >> doubt to
> >> 
> >> > the
> >> > 
> >> > > > > > > opposite argument. At least one person spoke up and said
> >> 
> >> it's
> >> 
> >> > > > > > unacceptable
> >> > > > > > 
> >> > > > > > > to fail a build on configuration you don't understand. Well,
> >> > 
> >> > that's
> >> > 
> >> > > > an
> >> > > > 
> >> > > > > > > interesting argument, too. That person doesn't want to tank
> >> 
> >> the
> >> 
> >> > > > > > > build
> >> > > > > > > for
> >> > > > > > > the 1% of configuration that can't be understood.... but I
> >> 
> >> fail
> >> 
> >> > to
> >> > 
> >> > > > see
> >> > > > 
> >> > > > > > > an
> >> > > > > > > escape hatch here. If a client can't understand what's being
> >> > > > 
> >> > > > specified,
> >> > > > 
> >> > > > > > > then what else can be done but fail?
> >> > > > > > 
> >> > > > > > Strip the dependencies a and let the user fix up manually
> >> 
> >> (ideally
> >> 
> >> > by
> >> > 
> >> > > > > > logging a warning that you are consuming a dependency using a
> >> 
> >> newer
> >> 
> >> > > > > > modelVersion)
> >> > > > > > 
> >> > > > > > Everyone forgets that the 4.0.0 ship has sailed already, so we
> >> > 
> >> > have to
> >> > 
> >> > > > > > deploy best-effort 4.0.0 poms
> >> > > > > > 
> >> > > > > > Now I say that 3.4 should not have a new modelVersion but
> >> 
> >> what it
> >> 
> >> > > > could do
> >> > > > 
> >> > > > > > is be more forgiving of newer modelVersions or try and
> >> 
> >> download
> >> and
> >> 
> >> > > > use an
> >> > > > 
> >> > > > > > XSLT to convert newer modelVersions to 4.0.0 (while logging a
> >> > 
> >> > warning)
> >> > 
> >> > > > > > with
> >> > > > > > option flags to allow failing the build if XSLT had to be
> >> 
> >> applied
> >> 
> >> > > > > > So let's bump the modelVersion in Maven 5.0.0 (there is no
> >> 
> >> Maven
> >> 
> >> > 4.x
> >> > 
> >> > > > let's
> >> > > > 
> >> > > > > > align on the modelVersion)
> >> > > > > > 
> >> > > > > > That should have separation between builder Pom and consumer
> >> 
> >> Pom.
> >> 
> >> > For
> >> > 
> >> > > > > > packaging=pom we deploy the builder Pom using classifier=build
> >> 
> >> for
> >> 
> >> > all
> >> > 
> >> > > > > > other packaging a we do not deploy the builder Pom.
> >> > > > > > 
> >> > > > > > We deploy a *best effort* conversion of the consumer Pom to
> >> > > > 
> >> > > > modelVersion
> >> > > > 
> >> > > > > > 4.0.0 without a classifier and the consumer Pom gets deployed
> >> 
> >> as
> >> 
> >> > > > > > classifier
> >> > > > > > consumer.
> >> > > > > > 
> >> > > > > > The consumer Pom format allows for XSLT to transform to a
> >> 
> >> parsable
> >> 
> >> > > > syntax,
> >> > > > 
> >> > > > > > if transform is required we log a warning (or fail the build
> >> 
> >> if
> >> the
> >> 
> >> > > > > > builder
> >> > > > > > Pom indicates strict modelVersion adherence)
> >> > > > > > 
> >> > > > > > So yeah maven 5.x will be able to parse dependencies with
> >> > 
> >> > modelVersion
> >> > 
> >> > > > 6.x
> >> > > > 
> >> > > > > > while logging warnings that the user may not have the correct
> >> > > > 
> >> > > > dependency
> >> > > > 
> >> > > > > > tree. That is IMHO acceptable forward compatibility
> >> > > > > > 
> >> > > > > > HTH
> >> > > > > > 
> >> > > > > > -Stephen
> >> > > > > > 
> >> > > > > > Ps I'm really hoping someone has a less crappy solution that
> >> > 
> >> > this...
> >> > 
> >> > > > But I
> >> > > > 
> >> > > > > > believe this is actually *a* solution... And prior to this I
> >> 
> >> have
> >> 
> >> > not
> >> > 
> >> > > > seen
> >> > > > 
> >> > > > > > any solution
> >> > > > > > 
> >> > > > > > > Cheers,
> >> > > > > > > Paul
> >> > > > > > 
> >> > > > > > --
> >> > > > > > Sent from my phone
> >> > > > 
> >> > > > ------------------------------------------------------------
> >> 
> >> ---------
> >> 
> >> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> 
> >> <javascript:;>
> >> 
> >> > > > For additional commands, e-mail: dev-help@maven.apache.org
> >> 
> >> <javascript:;>
> >> 
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> 
> >> <javascript:;>
> >> 
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> 
> >> <javascript:;>
> 
> ---------------------------------------------------------------------
> 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: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Hervé BOUTEMY <he...@free.fr>]

yes, we'll need to find clear terms for each concept: I now understand what 
you meant by consumer pom, which is not what I meant :)


there are 2 ideas:

- publishing classical Maven pom without build information (pom generated by 
flatten plugin or alike), to be able to add new build features in Maven pom 
model version 5 without wreaking havoc in Central for the whole consumer eco-
system (Maven2 & 3 and other build tools)

- creating a new descriptor format for repositories to be able to consume 
artifacts more efficiently


The good news is that IMHO, these ideas are complementary: we just need to 
solve the name conflict regarding "comsumer pom".

Regards,

Hervé

Le jeudi 25 août 2016 21:14:09 Robert Scholte a écrit :
> The current pom will still be there, always, consumer pom is an extra file
> for more effective artifact resolution. So yes, that's why I suggested
> consumer dom to ensure it is not confused with the current pom.
> 
> Robert
> 
> On Thu, 25 Aug 2016 20:16:08 +0200, Chas Honton <ch...@honton.org> wrote:
> > I use the current Pom to automate checking license policy and checking
> > owasp database for known security flaws. The scm and website metadata is
> > also very useful. Automated download of source for debugging is
> > essential. As a consumer, I don't want to lose these abilities.
> > 
> > Chas
> > 
> >> On Aug 25, 2016, at 10:11 AM, Paul Benedict <pb...@apache.org>
> >> wrote:
> >> 
> >> Is it really correct to call a dependency-only (more of less) file a
> >> POM if
> >> it ceases to contain project information? A project is (or should be!)
> >> synonymous with a build. Is that why someone referred to it as a DOM? A
> >> DOM
> >> makes way more sense to me than overloading the usage of POM and
> >> calling it
> >> a "consumer POM"
> >> 
> >> Cheers,
> >> Paul
> >> 
> >> On Thu, Aug 25, 2016 at 11:53 AM, Robert Scholte <rf...@apache.org>
> >> 
> >> wrote:
> >>> For both the flattened-pom and consumer-pom the idea is to remove build
> >>> related information. Most of it is only used during build.
> >>> The question is: is there other information which should be added?
> >>> e.g. In case of JARs: the major version number of the class file format
> >>> being used. Is it interesting to know this BEFORE downloading the jar?
> >>> And
> >>> if so, there should be a possibility to make choices based on that
> >>> information. The choice-option doesn't exist and would make it all too
> >>> complex.
> >>> I would say that it is indeed all about dependencies.
> >>> 
> >>> thanks,
> >>> Robert
> >>> 
> >>> 
> >>> On Thu, 25 Aug 2016 18:25:36 +0200, Paul Benedict
> >>> <pb...@apache.org>
> >>> wrote:
> >>> 
> >>> The only (minor?) issue I have with the term "consumer POM" is that it
> >>> 
> >>>> implies one type of consumption. What is the kind of consumption we're
> >>>> addressing -- is it merely the GAV and dependencies?
> >>>> 
> >>>> Cheers,
> >>>> Paul
> >>>> 
> >>>> On Thu, Aug 25, 2016 at 3:34 AM, Robert Scholte <rf...@apache.org>
> >>>> wrote:
> >>>> 
> >>>> On Thu, 25 Aug 2016 01:10:36 +0200, Stephen Connolly <
> >>>> 
> >>>>> stephen.alan.connolly@gmail.com> wrote:
> >>>>>> On 24 August 2016 at 04:50, Robert Scholte <rf...@apache.org>
> >>>>>> wrote:
> >>>>>> 
> >>>>>> 
> >>>>>> I realized last ApacheCon that I wasn't clear about my definiton of
> >>>>>> the
> >>>>>> 
> >>>>>>> consumer-pom.
> >>>>>>> I don't think it should be a flattened pom with only the dependency
> >>>>>>> information. Instead it shouldn't be a pom  (matching the pom.xsd)
> >>>>>>> at
> >>>>>>> all.
> >>>>>>> 
> >>>>>>> 
> >>>>>>> I am not in disagreement, but as a concept the name "consumer pom"
> >>>>>>> has
> >>>>>> 
> >>>>>> more
> >>>>>> traction.
> >>>>> 
> >>>>> I'd prefer consumer pom too, but it has led to confusion due to the
> >>>>> assumption that consumer pom and flattened pom are the same thing.
> >>>>> To me
> >>>>> it
> >>>>> makes sense to consider a new fileformat for the consumer pom which
> >>>>> matches
> >>>>> better the requirements. And yes, the "provides" would fit here.
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> I see the builder pom as probably ending up not even being XML at
> >>>>> all.
> >>>>> 
> >>>>>> Rather IMHO it will end up being a DSL that is easy to author and
> >>>>>> not
> >>>>>> verbose... and certainly not XML
> >>>>>> 
> >>>>>> So the consumer pom should be stripped back to include two sets of
> >>>>>> information:
> >>>>>> 
> >>>>>> * dependencies - we are mostly familiar with this... though we may
> >>>>>> not
> >>>>>> expose all the scopes... depends on how we think about things and
> >>>>>> how we
> >>>>>> view scopes moving forward
> >>>>>> 
> >>>>>> * provides - this is vitally important IMHO and not handled
> >>>>>> currently.
> >>>>>> 
> >>>>>> To understand provides we have to look at things like JavaEE (but
> >>>>>> the
> >>>>>> concept has general utility... though I suspect only for about
> >>>>>> 10-25% of
> >>>>>> projects)
> >>>>>> 
> >>>>>> If I have a project that says: provides
> >>>>>> javax.servlet:servlet-api:3.1
> >>>>>> then
> >>>>>> that is saying that my project is providing the equivalent content
> >>>>>> as in
> >>>>>> javax.servlet:servlet-api:3.1 so for example
> >>>>>> org.jboss.spec.javax.servlet:
> >>>>>> jboss-servlet-api_3.1_spec:1.0.0.Final would say
> >>>>>> javax.servlet:servlet-api:3.1
> >>>>>> 
> >>>>>> When resolving the dependency tree, maven then knows that any
> >>>>>> transitive
> >>>>>> requirement for javax.servlet:servlet-api:3.1 has already been met
> >>>>>> by my
> >>>>>> direct dependency on org.jboss.spec.javax.servlet:j
> >>>>>> boss-servlet-api_3.1_spec
> >>>>>> 
> >>>>>> :1.0.0.Final if we have a direct dependency on
> >>>>>> 
> >>>>>> org.apache.tomcat:tomcat-servlet-api:8.5.4 (which would also say
> >>>>>> javax.servlet:servlet-api:3.1) then Maven can report an error and
> >>>>>> fail
> >>>>>> the
> >>>>>> build due to dependency conflict.
> >>>>>> 
> >>>>>> There are lots of other improvements we can add, but to start we
> >>>>>> need to
> >>>>>> have a way to declare when a project includes duplicate content of
> >>>>>> another
> >>>>>> artifact. Convention will be required to make this work correctly...
> >>>>>> perhaps we can even introduce a new project type that provides
> >>>>>> needs to
> >>>>>> point at so that a provides has to point at an "empty" specification
> >>>>>> project...
> >>>>>> 
> >>>>>> Finally, for the consumer pom refactoring I believe we need to
> >>>>>> address
> >>>>>> architecture specific artifacts as these are a sort of implicit
> >>>>>> provides.
> >>>>>> 
> >>>>>> 
> >>>>>> Maybe it should be called something like consumer-dom (dependency
> >>>>>> object
> >>>>>> 
> >>>>>>> model, though dom is confusing...).
> >>>>>>> It should be the most fast and efficient way to resolve the
> >>>>>>> dependency
> >>>>>>> tree. That means it should do less roundtrips like Maven must do do
> >>>>>>> right
> >>>>>>> now: for every dependency download the pom, for all transitive
> >>>>>>> dependencies
> >>>>>>> download all poms, etc.
> >>>>>>> Why can't it be a pom? I'd like to add the (file)extension too.
> >>>>>>> Otherwise
> >>>>>>> Maven needs to initialize the matching ArtifactHandler and
> >>>>>>> translate
> >>>>>>> the
> >>>>>>> type to the proper extension.
> >>>>>> 
> >>>>>> I think the consumer pom needs to embed some of the artifact handler
> >>>>>> information for it self as otherwise non-maven tooling cannot be
> >>>>>> expected
> >>>>>> to understand those details... also we should be making the
> >>>>>> consumer pom
> >>>>>> both Maven and Java agnostic... but this is a grand problem alright!
> >>>>>> 
> >>>>>> 
> >>>>>> The pom doesn't have room for this.
> >>>>>> 
> >>>>>>> I saw the whole flattened pom experiment as mostly a waste of time
> >>>>>>> for
> >>>>>> 
> >>>>>> the
> >>>>>> consumer pom effort as I envision the consumer pom not looking
> >>>>>> anything
> >>>>>> like the current pom at all... but it is a project model...
> >>>>>> 
> >>>>>> Oh and the consumer pom should include information for the
> >>>>>> side-artifacts
> >>>>>> (which would help with reusing tests as we could attach the test
> >>>>>> dependencies to the test artifact details in the consumer pom)
> >>>>>> 
> >>>>>> Consumer-dom is an extraction and enriched version of the pom and
> >>>>>> will
> >>>>>> be
> >>>>>> a
> >>>>>> 
> >>>>>> separate upload to the repository. Build tools who can understand
> >>>>>> this
> >>>>>> 
> >>>>>>> file
> >>>>>>> can use it or fall back by downloading all poms.
> >>>>>>> 
> >>>>>>> thanks,
> >>>>>>> Robert
> >>>>>>> 
> >>>>>>> 
> >>>>>>> On Wed, 24 Aug 2016 09:22:03 +0200, Stephen Connolly <
> >>>>>>> stephen.alan.connolly@gmail.com> wrote:
> >>>>>>> 
> >>>>>>> The consumer Pom is for machine to machine, it should be human
> >>>>>>> readable
> >>>>>>> 
> >>>>>>> because that is nice, but intent is never human generated.
> >>>>>>> 
> >>>>>>>> Switching to this separation allows us to be more radical in the
> >>>>>>>> changes
> >>>>>>>> to
> >>>>>>>> the build Pom.
> >>>>>>>> 
> >>>>>>>> The only reason we deploy packaging Pom's build Pom is for
> >>>>>>>> inheritance.
> >>>>>>>> If
> >>>>>>>> we didn't have to deal with that we wouldn't need to deploy any
> >>>>>>>> build
> >>>>>>>> poms
> >>>>>>>> ever.
> >>>>>>>> 
> >>>>>>>> For using a build Pom as a parent, you implicitly pick up the
> >>>>>>>> minimum
> >>>>>>>> version of maven that your parent requires, so we then are free to
> >>>>>>>> evolve
> >>>>>>>> the build Pom format without worrying about forward compatibility,
> >>>>>>>> only
> >>>>>>>> backwards compatibility on the *build* Pom.
> >>>>>>>> 
> >>>>>>>> The consumer Pom needs partial *forward* compatibility, so that
> >>>>>>>> older
> >>>>>>>> clients are able to *attempt* to consume...
> >>>>>>>> 
> >>>>>>>> In short there are totally different compatibility constraints on
> >>>>>>>> the
> >>>>>>>> two,
> >>>>>>>> so they should be separate.
> >>>>>>>> 
> >>>>>>>> Mixins would probably also be deployed, once we figure out how
> >>>>>>>> they
> >>>>>>>> work
> >>>>>>>> with build poms.
> >>>>>>>> 
> >>>>>>>> I think we probably need to rethink version ranges. What I'd like
> >>>>>>>> is
> >>>>>>>> to
> >>>>>>>> let
> >>>>>>>> the consumer Pom treat version ranges more as guidance rather than
> >>>>>>>> hard
> >>>>>>>> requirements. It's a pain if you depend transitiveky on Foo:[1.0]
> >>>>>>>> but
> >>>>>>>> need
> >>>>>>>> Foo:[1.0.1,1.1) for the critical security fix... Having to run
> >>>>>>>> around
> >>>>>>>> applying excludes is not a good plan... Yes the build should
> >>>>>>>> initially
> >>>>>>>> fail
> >>>>>>>> if I depend on [1.0] and [1.0.1,1.1) in my graph, but I should be
> >>>>>>>> able
> >>>>>>>> to
> >>>>>>>> resolve the conflict for all my consumers (unless they pull in the
> >>>>>>>> conflict
> >>>>>>>> again themselves)
> >>>>>>>> 
> >>>>>>>> On Tuesday 23 August 2016, Fred Cooke <fr...@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>> 
> >>>>>>>> I still find it a bit off that the original real POM won't always
> >>>>>>>> be
> >>>>>>>> 
> >>>>>>>> directly available anymore.
> >>>>>>>> 
> >>>>>>>>> Other tools create fake POMs because they *have* to - there's no
> >>>>>>>>> other
> >>>>>>>>> option.
> >>>>>>>>> 
> >>>>>>>>> I feel like some fidelity would be lost. Diffability would be
> >>>>>>>>> lost
> >>>>>>>>> (from
> >>>>>>>>> a
> >>>>>>>>> scenario where there's nothing to diff).
> >>>>>>>>> 
> >>>>>>>>> Unrelated, really, but kind of related: top level deployable
> >>>>>>>>> artefact
> >>>>>>>>> deployments, debs, wars, exes, etc. When ranges are in use it'd
> >>>>>>>>> be
> >>>>>>>>> nice
> >>>>>>>>> to
> >>>>>>>>> deploy a sort of strict effective pom with fully hard []
> >>>>>>>>> versions for
> >>>>>>>>> all
> >>>>>>>>> things. This can be achieved in other ways, though.
> >>>>>>>>> 
> >>>>>>>>> I guess that is to say, don't forget about non-central
> >>>>>>>>> deployments. I
> >>>>>>>>> suppose if there's a way to always deploy pom.xml.build through
> >>>>>>>>> some
> >>>>>>>>> plugin
> >>>>>>>>> or configuration or some such, then that's fine with me.
> >>>>>>>>> 
> >>>>>>>>> On Wed, Aug 24, 2016 at 6:49 PM, Hervé BOUTEMY <
> >>>>>>>>> herve.boutemy@free.fr
> >>>>>>>>> <javascript:;>>
> >>>>>>>>> 
> >>>>>>>>> wrote:
> >>>>>>>>>> Le mercredi 24 août 2016 18:41:59 Fred Cooke a écrit :
> >>>>>>>>>>> Fair call re embedded pom, however it's quite convenient to
> >>>>>>>>>>> just
> >>>>>>>>> 
> >>>>>>>>> browse
> >>>>>>>>> 
> >>>>>>>>>> to
> >>>>>>>>>> 
> >>>>>>>>>>> it and read.
> >>>>>>>>>>> 
> >>>>>>>>>>> I've occasionally gone looking for details from poms of
> >>>>>>>>>>> artefacts
> >>>>>>>>> 
> >>>>>>>>> and
> >>>>>>>>> 
> >>>>>>>>>> found
> >>>>>>>>>> 
> >>>>>>>>>>> a mess and missing stuff, and been annoyed. It probably wasn't
> >>>>>>>>> 
> >>>>>>>>> gradle's
> >>>>>>>>> 
> >>>>>>>>>>> fault, though. Just a sloppy author. If I'm honest I wouldn't
> >>>>>>>>> 
> >>>>>>>>> even
> >>>>>>>>> know
> >>>>>>>>> 
> >>>>>>>>>> if
> >>>>>>>>>> 
> >>>>>>>>>>> I've ever consumed a non-maven artefact, certainly none of
> >>>>>>>>>>> mine!
> >>>>>>>>> :
> >>>>>>>>> :-)
> >>>>>>>>> :
> >>>>>>>>>>> No, I am sure, I have, at least one, and it's an ant one with a
> >>>>>>>>> 
> >>>>>>>>> hard
> >>>>>>>>> 
> >>>>>>>>>> coded
> >>>>>>>>>> 
> >>>>>>>>>>> POM that doesn't always reflect the contents of the jar. Yuck.
> >>>>>>>>> 
> >>>>>>>>> Clearly
> >>>>>>>>> 
> >>>>>>>>>> not
> >>>>>>>>>> 
> >>>>>>>>>>> an issue with automated stuff, though.
> >>>>>>>>>>> 
> >>>>>>>>>>> My only argument now is ease of reading things like project
> >>>>>>>>> 
> >>>>>>>>> descriptions,
> >>>>>>>>> 
> >>>>>>>>>>> contributors, SCM details, etc rather than having to unpack the
> >>>>>>>>> 
> >>>>>>>>> jar.
> >>>>>>>>> And
> >>>>>>>>> 
> >>>>>>>>>> if
> >>>>>>>>>> 
> >>>>>>>>>>> you do, and end up with two pom.xmls laying around, that's not
> >>>>>>>>> 
> >>>>>>>>> nice.
> >>>>>>>>> 
> >>>>>>>>>> Better
> >>>>>>>>>> 
> >>>>>>>>>>> to just start always suffixing one with pom.xml.build or some
> >>>>>>>>> 
> >>>>>>>>> such? I
> >>>>>>>>> 
> >>>>>>>>>> think
> >>>>>>>>>> 
> >>>>>>>>>>> so, but I haven't thought deeply about it aside from reading
> >>>>>>>>>>> this
> >>>>>>>>> 
> >>>>>>>>> thread.
> >>>>>>>>> 
> >>>>>>>>>> our consumer pom will be generated from build pom: we can
> >>>>>>>>>> automate
> >>>>>>>>> 
> >>>>>>>>> copy
> >>>>>>>>> of
> >>>>>>>>> 
> >>>>>>>>>> any
> >>>>>>>>>> information we want, and for sure, I expect to put at least
> >>>>>>>>> 
> >>>>>>>>> description,
> >>>>>>>>> 
> >>>>>>>>>> scm
> >>>>>>>>>> details, issueManagement, license (of course).
> >>>>>>>>>> In your list, there is only constributors that I was not
> >>>>>>>>>> counting
> >>>>>>>>> 
> >>>>>>>>> on
> >>>>>>>>> 
> >>>>>>>>> it:
> >>>>>>>>>> but
> >>>>>>>>>> it's a detailed decision we'll have to make
> >>>>>>>>>> 
> >>>>>>>>>> for sure, Maven consumer poms, since generated from Maven build
> >>>>>>>>> 
> >>>>>>>>> pom,
> >>>>>>>>> can
> >>>>>>>>> 
> >>>>>>>>>> have
> >>>>>>>>>> much more details (and be sure they are accurrate) than build
> >>>>>>>>>> tools
> >>>>>>>>> 
> >>>>>>>>> that
> >>>>>>>>> 
> >>>>>>>>>> don't
> >>>>>>>>>> generate it from data that exists in their original build format
> >>>>>>>>>> 
> >>>>>>>>>> Regards,
> >>>>>>>>>> 
> >>>>>>>>>> Hervé
> >>>>>>>>>> 
> >>>>>>>>>>> On Wed, Aug 24, 2016 at 6:32 PM, Hervé BOUTEMY <
> >>>>>>>>> 
> >>>>>>>>> herve.boutemy@free.fr
> >>>>>>>>> <javascript:;>>
> >>>>>>>>> 
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>> Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit :
> >>>>>>>>>>>>> That should have separation between builder Pom and consumer
> >>>>>>>>> 
> >>>>>>>>> Pom.
> >>>>>>>>> For
> >>>>>>>>> 
> >>>>>>>>>>>>> packaging=pom we deploy the builder Pom using
> >>>>>>>>> 
> >>>>>>>>> classifier=build
> >>>>>>>>> 
> >>>>>>>>>>>>> *for all other packaging a we do not deploy the builder Pom*.
> >>>>>>>>>>>>> 
> >>>>>>>>>>>>> I don't like the sound of this. The deployed artefacts should
> >>>>>>>>> 
> >>>>>>>>> include
> >>>>>>>>> 
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>> exact POM in use to build the project, as a reference, even
> >>>>>>>>> 
> >>>>>>>>> if
> >>>>>>>>> under
> >>>>>>>>> 
> >>>>>>>>>> a
> >>>>>>>>>> 
> >>>>>>>>>>>>> different name. Yes, they should be in SCM, however down
> >>>>>>>>> 
> >>>>>>>>> stream
> >>>>>>>>> it's
> >>>>>>>>> 
> >>>>>>>>>>>> useful
> >>>>>>>>>>>> 
> >>>>>>>>>>>>> to see these even when the SCM is offline or gone or private
> >>>>>>>>> 
> >>>>>>>>> or
> >>>>>>>>> 
> >>>>>>>>>>>>> whatever.
> >>>>>>>>>>>>> Or did I misunderstand? If so, please clarify?
> >>>>>>>>>>>> 
> >>>>>>>>>>>> when you consume an artifact not build with Maven, do you get
> >>>>>>>>> 
> >>>>>>>>> the
> >>>>>>>>> full
> >>>>>>>>> 
> >>>>>>>>>>>> build
> >>>>>>>>>>>> script?
> >>>>>>>>>>>> no
> >>>>>>>>>>>> I know that, as Maven users, we got used to have the build pom
> >>>>>>>>>> 
> >>>>>>>>>> published
> >>>>>>>>>> 
> >>>>>>>>>>>> in
> >>>>>>>>>>>> central: this is now an issue, but we like that
> >>>>>>>>>>>> 
> >>>>>>>>>>>> notice: the build pom can be injected in the artifact, in
> >>>>>>>>>> 
> >>>>>>>>>> META-INF/maven,
> >>>>>>>>>> 
> >>>>>>>>>>>> like
> >>>>>>>>>>>> it is currently done
> >>>>>>>>>>>> but I don't see the point in requiring it to be pbulished
> >>>>>>>>> 
> >>>>>>>>> separately
> >>>>>>>>> in
> >>>>>>>>> 
> >>>>>>>>>>>> central: no other build tool does that, and they don't have
> >>>>>>>>>>>> any
> >>>>>>>>> 
> >>>>>>>>> issue
> >>>>>>>>> 
> >>>>>>>>>> with
> >>>>>>>>>> 
> >>>>>>>>>>>> that (and eventually it's a feature: don't publish internal
> >>>>>>>>> 
> >>>>>>>>> details
> >>>>>>>>> you
> >>>>>>>>> 
> >>>>>>>>>>>> don't
> >>>>>>>>>>>> really want people to see)
> >>>>>>>>>>>> 
> >>>>>>>>>>>> Regards,
> >>>>>>>>>>>> 
> >>>>>>>>>>>> Hervé
> >>>>>>>>>>>> 
> >>>>>>>>>>>>> On Wed, Aug 24, 2016 at 1:52 PM, Stephen Connolly <
> >>>>>>>>>>>>> 
> >>>>>>>>>>>>> stephen.alan.connolly@gmail.com <javascript:;>> wrote:
> >>>>>>>>>>>>>> On Tuesday 23 August 2016, Paul Benedict <
> >>>>>>>>> 
> >>>>>>>>> pbenedict@apache.org
> >>>>>>>>> <javascript:;>>
> >>>>>>>>> 
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>>>> On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <
> >>>>>>>>>> 
> >>>>>>>>>> cs@schulte.it <javascript:;>
> >>>>>>>>>> 
> >>>>>>>>>>>>>>> <javascript:;>> wrote:
> >>>>>>>>>>>>>>>>> Am 08/24/16 um 00:08 schrieb Paul Benedict:
> >>>>>>>>>>>>>>>>> POM and a future major version POM? I am hinting at a
> >>>>>>>>>> 
> >>>>>>>>>> strategy
> >>>>>>>>>> 
> >>>>>>>>>>>> for
> >>>>>>>>>>>> 
> >>>>>>>>>>>>>>>> forward
> >>>>>>>>>>>>>>>> 
> >>>>>>>>>>>>>>>>> compatibility.
> >>>>>>>>>>>>>>>> 
> >>>>>>>>>>>>>>>> Is forward compatibility really needed/required?
> >>>>>>>>>>>>>>> 
> >>>>>>>>>>>>>>> I honestly don't know, which is why I am asking. An
> >>>>>>>>> 
> >>>>>>>>> answer
> >>>>>>>>> of
> >>>>>>>>> "no
> >>>>>>>>> 
> >>>>>>>>>>>>>>> compatibility" is possible, too.
> >>>>>>>>>>>>>>> 
> >>>>>>>>>>>>>>> I can completely see the argument that says POMs must be
> >>>>>>>>>>>>>>> all-parseable-or-nothing -- for the sake of
> >>>>>>>>> 
> >>>>>>>>> reproducibility.
> >>>>>>>>> I
> >>>>>>>>> 
> >>>>>>>>>>>> actually
> >>>>>>>>>>>> 
> >>>>>>>>>>>>>>> prefer this answer. I think it is sensible to fail a
> >>>>>>>>> 
> >>>>>>>>> build
> >>>>>>>>> when
> >>>>>>>>> 
> >>>>>>>>>>>>>>> encountering a POM version too advanced. If your client
> >>>>>>>>> 
> >>>>>>>>> only
> >>>>>>>>> 
> >>>>>>>>>>>> supports up
> >>>>>>>>>>>> 
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>> 
> >>>>>>>>>>>>>>> model 4.0.0, then all artifacts must be specified by
> >>>>>>>>> 
> >>>>>>>>> 4.0.0
> >>>>>>>>> 
> >>>>>>>>>> models,
> >>>>>>>>>> 
> >>>>>>>>>>>> too.
> >>>>>>>>>>>> 
> >>>>>>>>>>>>>>> On the other hand, I wanted to give the benefit of the
> >>>>>>>>> 
> >>>>>>>>> doubt
> >>>>>>>>> to
> >>>>>>>>> 
> >>>>>>>>>> the
> >>>>>>>>>> 
> >>>>>>>>>>>>>>> opposite argument. At least one person spoke up and said
> >>>>>>>>> 
> >>>>>>>>> it's
> >>>>>>>>> 
> >>>>>>>>>>>>>> unacceptable
> >>>>>>>>>>>>>> 
> >>>>>>>>>>>>>>> to fail a build on configuration you don't understand.
> >>>>>>>>> 
> >>>>>>>>> Well,
> >>>>>>>>> 
> >>>>>>>>>> that's
> >>>>>>>>>> 
> >>>>>>>>>>>> an
> >>>>>>>>>>>> 
> >>>>>>>>>>>>>>> interesting argument, too. That person doesn't want to
> >>>>>>>>> 
> >>>>>>>>> tank
> >>>>>>>>> the
> >>>>>>>>> 
> >>>>>>>>>>>>>>> build
> >>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>> the 1% of configuration that can't be understood.... but
> >>>>>>>>> 
> >>>>>>>>> I
> >>>>>>>>> fail
> >>>>>>>>> 
> >>>>>>>>>> to
> >>>>>>>>>> 
> >>>>>>>>>>>> see
> >>>>>>>>>>>> 
> >>>>>>>>>>>>>>> an
> >>>>>>>>>>>>>>> escape hatch here. If a client can't understand what's
> >>>>>>>>> 
> >>>>>>>>> being
> >>>>>>>>> 
> >>>>>>>>>>>> specified,
> >>>>>>>>>>>> 
> >>>>>>>>>>>>>>> then what else can be done but fail?
> >>>>>>>>>>>>>> 
> >>>>>>>>>>>>>> Strip the dependencies a and let the user fix up manually
> >>>>>>>>> 
> >>>>>>>>> (ideally
> >>>>>>>>> 
> >>>>>>>>>> by
> >>>>>>>>>> 
> >>>>>>>>>>>>>> logging a warning that you are consuming a dependency
> >>>>>>>>> 
> >>>>>>>>> using a
> >>>>>>>>> newer
> >>>>>>>>> 
> >>>>>>>>>>>>>> modelVersion)
> >>>>>>>>>>>>>> 
> >>>>>>>>>>>>>> Everyone forgets that the 4.0.0 ship has sailed already, so
> >>>>>>>>> 
> >>>>>>>>> we
> >>>>>>>>> 
> >>>>>>>>>> have to
> >>>>>>>>>> 
> >>>>>>>>>>>>>> deploy best-effort 4.0.0 poms
> >>>>>>>>>>>>>> 
> >>>>>>>>>>>>>> Now I say that 3.4 should not have a new modelVersion but
> >>>>>>>>> 
> >>>>>>>>> what
> >>>>>>>>> it
> >>>>>>>>> 
> >>>>>>>>>>>> could do
> >>>>>>>>>>>> 
> >>>>>>>>>>>>>> is be more forgiving of newer modelVersions or try and
> >>>>>>>>> 
> >>>>>>>>> download
> >>>>>>>>> and
> >>>>>>>>> 
> >>>>>>>>>>>> use an
> >>>>>>>>>>>> 
> >>>>>>>>>>>>>> XSLT to convert newer modelVersions to 4.0.0 (while
> >>>>>>>>> 
> >>>>>>>>> logging a
> >>>>>>>>> 
> >>>>>>>>>> warning)
> >>>>>>>>>> 
> >>>>>>>>>>>>>> with
> >>>>>>>>>>>>>> option flags to allow failing the build if XSLT had to be
> >>>>>>>>> 
> >>>>>>>>> applied
> >>>>>>>>> 
> >>>>>>>>>>>>>> So let's bump the modelVersion in Maven 5.0.0 (there is no
> >>>>>>>>> 
> >>>>>>>>> Maven
> >>>>>>>>> 
> >>>>>>>>>> 4.x
> >>>>>>>>>> 
> >>>>>>>>>>>> let's
> >>>>>>>>>>>> 
> >>>>>>>>>>>>>> align on the modelVersion)
> >>>>>>>>>>>>>> 
> >>>>>>>>>>>>>> That should have separation between builder Pom and
> >>>>>>>>> 
> >>>>>>>>> consumer
> >>>>>>>>> Pom.
> >>>>>>>>> 
> >>>>>>>>>> For
> >>>>>>>>>> 
> >>>>>>>>>>>>>> packaging=pom we deploy the builder Pom using
> >>>>>>>>> 
> >>>>>>>>> classifier=build
> >>>>>>>>> for
> >>>>>>>>> 
> >>>>>>>>>> all
> >>>>>>>>>> 
> >>>>>>>>>>>>>> other packaging a we do not deploy the builder Pom.
> >>>>>>>>>>>>>> 
> >>>>>>>>>>>>>> We deploy a *best effort* conversion of the consumer Pom to
> >>>>>>>>>>>> 
> >>>>>>>>>>>> modelVersion
> >>>>>>>>>>>> 
> >>>>>>>>>>>>>> 4.0.0 without a classifier and the consumer Pom gets
> >>>>>>>>> 
> >>>>>>>>> deployed
> >>>>>>>>> as
> >>>>>>>>> 
> >>>>>>>>>>>>>> classifier
> >>>>>>>>>>>>>> consumer.
> >>>>>>>>>>>>>> 
> >>>>>>>>>>>>>> The consumer Pom format allows for XSLT to transform to a
> >>>>>>>>> 
> >>>>>>>>> parsable
> >>>>>>>>> 
> >>>>>>>>>>>> syntax,
> >>>>>>>>>>>> 
> >>>>>>>>>>>>>> if transform is required we log a warning (or fail the
> >>>>>>>>> 
> >>>>>>>>> build
> >>>>>>>>> if
> >>>>>>>>> the
> >>>>>>>>> 
> >>>>>>>>>>>>>> builder
> >>>>>>>>>>>>>> Pom indicates strict modelVersion adherence)
> >>>>>>>>>>>>>> 
> >>>>>>>>>>>>>> So yeah maven 5.x will be able to parse dependencies with
> >>>>>>>>>> 
> >>>>>>>>>> modelVersion
> >>>>>>>>>> 
> >>>>>>>>>>>> 6.x
> >>>>>>>>>>>> 
> >>>>>>>>>>>>>> while logging warnings that the user may not have the
> >>>>>>>>> 
> >>>>>>>>> correct
> >>>>>>>>> 
> >>>>>>>>>>>> dependency
> >>>>>>>>>>>> 
> >>>>>>>>>>>>>> tree. That is IMHO acceptable forward compatibility
> >>>>>>>>>>>>>> 
> >>>>>>>>>>>>>> HTH
> >>>>>>>>>>>>>> 
> >>>>>>>>>>>>>> -Stephen
> >>>>>>>>>>>>>> 
> >>>>>>>>>>>>>> Ps I'm really hoping someone has a less crappy solution
> >>>>>>>>> 
> >>>>>>>>> that
> >>>>>>>>> 
> >>>>>>>>>> this...
> >>>>>>>>>> 
> >>>>>>>>>>>> But I
> >>>>>>>>>>>> 
> >>>>>>>>>>>>>> believe this is actually *a* solution... And prior to this
> >>>>>>>>> 
> >>>>>>>>> I
> >>>>>>>>> have
> >>>>>>>>> 
> >>>>>>>>>> not
> >>>>>>>>>> 
> >>>>>>>>>>>> seen
> >>>>>>>>>>>> 
> >>>>>>>>>>>>>> any solution
> >>>>>>>>>>>>>> 
> >>>>>>>>>>>>>>> Cheers,
> >>>>>>>>>>>>>>> Paul
> >>>>>>>>>>>>>> 
> >>>>>>>>>>>>>> --
> >>>>>>>>>>>>>> Sent from my phone
> >>>>>>>>>>>> 
> >>>>>>>>>>>> ------------------------------------------------------------
> >>>>>>>>> 
> >>>>>>>>> ---------
> >>>>>>>>> 
> >>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>> 
> >>>>>>>>> <javascript:;>
> >>>>>>>>> 
> >>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>> 
> >>>>>>>>> <javascript:;>
> >>>>>>>>> 
> >>>>>>>>>> ------------------------------------------------------------
> >>>>>>>>> 
> >>>>>>>>> ---------
> >>>>>>>>> 
> >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>> 
> >>>>>>>>> <javascript:;>
> >>>>>>>>> 
> >>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>> 
> >>>>>>>>> <javascript:;>
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> ------------------------------------------------------------
> >>>>>>>> 
> >>>>>>>> ---------
> >>>>>>> 
> >>>>>>> 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
> 
> ---------------------------------------------------------------------
> 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: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Robert Scholte <rf...@apache.org>]

The current pom will still be there, always, consumer pom is an extra file  
for more effective artifact resolution. So yes, that's why I suggested  
consumer dom to ensure it is not confused with the current pom.

Robert

On Thu, 25 Aug 2016 20:16:08 +0200, Chas Honton <ch...@honton.org> wrote:

> I use the current Pom to automate checking license policy and checking   
> owasp database for known security flaws. The scm and website metadata is  
> also very useful. Automated download of source for debugging is  
> essential. As a consumer, I don't want to lose these abilities.
>
> Chas
>
>> On Aug 25, 2016, at 10:11 AM, Paul Benedict <pb...@apache.org>  
>> wrote:
>>
>> Is it really correct to call a dependency-only (more of less) file a  
>> POM if
>> it ceases to contain project information? A project is (or should be!)
>> synonymous with a build. Is that why someone referred to it as a DOM? A  
>> DOM
>> makes way more sense to me than overloading the usage of POM and  
>> calling it
>> a "consumer POM"
>>
>> Cheers,
>> Paul
>>
>> On Thu, Aug 25, 2016 at 11:53 AM, Robert Scholte <rf...@apache.org>
>> wrote:
>>
>>> For both the flattened-pom and consumer-pom the idea is to remove build
>>> related information. Most of it is only used during build.
>>> The question is: is there other information which should be added?
>>> e.g. In case of JARs: the major version number of the class file format
>>> being used. Is it interesting to know this BEFORE downloading the jar?  
>>> And
>>> if so, there should be a possibility to make choices based on that
>>> information. The choice-option doesn't exist and would make it all too
>>> complex.
>>> I would say that it is indeed all about dependencies.
>>>
>>> thanks,
>>> Robert
>>>
>>>
>>> On Thu, 25 Aug 2016 18:25:36 +0200, Paul Benedict  
>>> <pb...@apache.org>
>>> wrote:
>>>
>>> The only (minor?) issue I have with the term "consumer POM" is that it
>>>> implies one type of consumption. What is the kind of consumption we're
>>>> addressing -- is it merely the GAV and dependencies?
>>>>
>>>> Cheers,
>>>> Paul
>>>>
>>>> On Thu, Aug 25, 2016 at 3:34 AM, Robert Scholte <rf...@apache.org>
>>>> wrote:
>>>>
>>>> On Thu, 25 Aug 2016 01:10:36 +0200, Stephen Connolly <
>>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>>
>>>>>> On 24 August 2016 at 04:50, Robert Scholte <rf...@apache.org>  
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> I realized last ApacheCon that I wasn't clear about my definiton of  
>>>>>> the
>>>>>>
>>>>>>> consumer-pom.
>>>>>>> I don't think it should be a flattened pom with only the dependency
>>>>>>> information. Instead it shouldn't be a pom  (matching the pom.xsd)  
>>>>>>> at
>>>>>>> all.
>>>>>>>
>>>>>>>
>>>>>>> I am not in disagreement, but as a concept the name "consumer pom"  
>>>>>>> has
>>>>>> more
>>>>>> traction.
>>>>>>
>>>>>>
>>>>> I'd prefer consumer pom too, but it has led to confusion due to the
>>>>> assumption that consumer pom and flattened pom are the same thing.  
>>>>> To me
>>>>> it
>>>>> makes sense to consider a new fileformat for the consumer pom which
>>>>> matches
>>>>> better the requirements. And yes, the "provides" would fit here.
>>>>>
>>>>>
>>>>>
>>>>> I see the builder pom as probably ending up not even being XML at  
>>>>> all.
>>>>>> Rather IMHO it will end up being a DSL that is easy to author and  
>>>>>> not
>>>>>> verbose... and certainly not XML
>>>>>>
>>>>>> So the consumer pom should be stripped back to include two sets of
>>>>>> information:
>>>>>>
>>>>>> * dependencies - we are mostly familiar with this... though we may  
>>>>>> not
>>>>>> expose all the scopes... depends on how we think about things and  
>>>>>> how we
>>>>>> view scopes moving forward
>>>>>>
>>>>>> * provides - this is vitally important IMHO and not handled  
>>>>>> currently.
>>>>>>
>>>>>> To understand provides we have to look at things like JavaEE (but  
>>>>>> the
>>>>>> concept has general utility... though I suspect only for about  
>>>>>> 10-25% of
>>>>>> projects)
>>>>>>
>>>>>> If I have a project that says: provides  
>>>>>> javax.servlet:servlet-api:3.1
>>>>>> then
>>>>>> that is saying that my project is providing the equivalent content  
>>>>>> as in
>>>>>> javax.servlet:servlet-api:3.1 so for example
>>>>>> org.jboss.spec.javax.servlet:
>>>>>> jboss-servlet-api_3.1_spec:1.0.0.Final would say
>>>>>> javax.servlet:servlet-api:3.1
>>>>>>
>>>>>> When resolving the dependency tree, maven then knows that any  
>>>>>> transitive
>>>>>> requirement for javax.servlet:servlet-api:3.1 has already been met  
>>>>>> by my
>>>>>> direct dependency on org.jboss.spec.javax.servlet:j
>>>>>> boss-servlet-api_3.1_spec
>>>>>> :1.0.0.Final if we have a direct dependency on
>>>>>> org.apache.tomcat:tomcat-servlet-api:8.5.4 (which would also say
>>>>>> javax.servlet:servlet-api:3.1) then Maven can report an error and  
>>>>>> fail
>>>>>> the
>>>>>> build due to dependency conflict.
>>>>>>
>>>>>> There are lots of other improvements we can add, but to start we  
>>>>>> need to
>>>>>> have a way to declare when a project includes duplicate content of
>>>>>> another
>>>>>> artifact. Convention will be required to make this work correctly...
>>>>>> perhaps we can even introduce a new project type that provides  
>>>>>> needs to
>>>>>> point at so that a provides has to point at an "empty" specification
>>>>>> project...
>>>>>>
>>>>>> Finally, for the consumer pom refactoring I believe we need to  
>>>>>> address
>>>>>> architecture specific artifacts as these are a sort of implicit
>>>>>> provides.
>>>>>>
>>>>>>
>>>>>> Maybe it should be called something like consumer-dom (dependency  
>>>>>> object
>>>>>>
>>>>>>> model, though dom is confusing...).
>>>>>>> It should be the most fast and efficient way to resolve the  
>>>>>>> dependency
>>>>>>> tree. That means it should do less roundtrips like Maven must do do
>>>>>>> right
>>>>>>> now: for every dependency download the pom, for all transitive
>>>>>>> dependencies
>>>>>>> download all poms, etc.
>>>>>>> Why can't it be a pom? I'd like to add the (file)extension too.
>>>>>>> Otherwise
>>>>>>> Maven needs to initialize the matching ArtifactHandler and  
>>>>>>> translate
>>>>>>> the
>>>>>>> type to the proper extension.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I think the consumer pom needs to embed some of the artifact handler
>>>>>> information for it self as otherwise non-maven tooling cannot be
>>>>>> expected
>>>>>> to understand those details... also we should be making the  
>>>>>> consumer pom
>>>>>> both Maven and Java agnostic... but this is a grand problem alright!
>>>>>>
>>>>>>
>>>>>> The pom doesn't have room for this.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I saw the whole flattened pom experiment as mostly a waste of time  
>>>>>>> for
>>>>>> the
>>>>>> consumer pom effort as I envision the consumer pom not looking  
>>>>>> anything
>>>>>> like the current pom at all... but it is a project model...
>>>>>>
>>>>>> Oh and the consumer pom should include information for the
>>>>>> side-artifacts
>>>>>> (which would help with reusing tests as we could attach the test
>>>>>> dependencies to the test artifact details in the consumer pom)
>>>>>>
>>>>>> Consumer-dom is an extraction and enriched version of the pom and  
>>>>>> will
>>>>>> be
>>>>>> a
>>>>>>
>>>>>> separate upload to the repository. Build tools who can understand  
>>>>>> this
>>>>>>> file
>>>>>>> can use it or fall back by downloading all poms.
>>>>>>>
>>>>>>> thanks,
>>>>>>> Robert
>>>>>>>
>>>>>>>
>>>>>>> On Wed, 24 Aug 2016 09:22:03 +0200, Stephen Connolly <
>>>>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>>>>
>>>>>>> The consumer Pom is for machine to machine, it should be human  
>>>>>>> readable
>>>>>>>
>>>>>>> because that is nice, but intent is never human generated.
>>>>>>>>
>>>>>>>> Switching to this separation allows us to be more radical in the
>>>>>>>> changes
>>>>>>>> to
>>>>>>>> the build Pom.
>>>>>>>>
>>>>>>>> The only reason we deploy packaging Pom's build Pom is for
>>>>>>>> inheritance.
>>>>>>>> If
>>>>>>>> we didn't have to deal with that we wouldn't need to deploy any  
>>>>>>>> build
>>>>>>>> poms
>>>>>>>> ever.
>>>>>>>>
>>>>>>>> For using a build Pom as a parent, you implicitly pick up the  
>>>>>>>> minimum
>>>>>>>> version of maven that your parent requires, so we then are free to
>>>>>>>> evolve
>>>>>>>> the build Pom format without worrying about forward compatibility,
>>>>>>>> only
>>>>>>>> backwards compatibility on the *build* Pom.
>>>>>>>>
>>>>>>>> The consumer Pom needs partial *forward* compatibility, so that  
>>>>>>>> older
>>>>>>>> clients are able to *attempt* to consume...
>>>>>>>>
>>>>>>>> In short there are totally different compatibility constraints on  
>>>>>>>> the
>>>>>>>> two,
>>>>>>>> so they should be separate.
>>>>>>>>
>>>>>>>> Mixins would probably also be deployed, once we figure out how  
>>>>>>>> they
>>>>>>>> work
>>>>>>>> with build poms.
>>>>>>>>
>>>>>>>> I think we probably need to rethink version ranges. What I'd like  
>>>>>>>> is
>>>>>>>> to
>>>>>>>> let
>>>>>>>> the consumer Pom treat version ranges more as guidance rather than
>>>>>>>> hard
>>>>>>>> requirements. It's a pain if you depend transitiveky on Foo:[1.0]  
>>>>>>>> but
>>>>>>>> need
>>>>>>>> Foo:[1.0.1,1.1) for the critical security fix... Having to run  
>>>>>>>> around
>>>>>>>> applying excludes is not a good plan... Yes the build should  
>>>>>>>> initially
>>>>>>>> fail
>>>>>>>> if I depend on [1.0] and [1.0.1,1.1) in my graph, but I should be  
>>>>>>>> able
>>>>>>>> to
>>>>>>>> resolve the conflict for all my consumers (unless they pull in the
>>>>>>>> conflict
>>>>>>>> again themselves)
>>>>>>>>
>>>>>>>> On Tuesday 23 August 2016, Fred Cooke <fr...@gmail.com>  
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I still find it a bit off that the original real POM won't always  
>>>>>>>> be
>>>>>>>>
>>>>>>>> directly available anymore.
>>>>>>>>>
>>>>>>>>> Other tools create fake POMs because they *have* to - there's no
>>>>>>>>> other
>>>>>>>>> option.
>>>>>>>>>
>>>>>>>>> I feel like some fidelity would be lost. Diffability would be  
>>>>>>>>> lost
>>>>>>>>> (from
>>>>>>>>> a
>>>>>>>>> scenario where there's nothing to diff).
>>>>>>>>>
>>>>>>>>> Unrelated, really, but kind of related: top level deployable  
>>>>>>>>> artefact
>>>>>>>>> deployments, debs, wars, exes, etc. When ranges are in use it'd  
>>>>>>>>> be
>>>>>>>>> nice
>>>>>>>>> to
>>>>>>>>> deploy a sort of strict effective pom with fully hard []  
>>>>>>>>> versions for
>>>>>>>>> all
>>>>>>>>> things. This can be achieved in other ways, though.
>>>>>>>>>
>>>>>>>>> I guess that is to say, don't forget about non-central  
>>>>>>>>> deployments. I
>>>>>>>>> suppose if there's a way to always deploy pom.xml.build through  
>>>>>>>>> some
>>>>>>>>> plugin
>>>>>>>>> or configuration or some such, then that's fine with me.
>>>>>>>>>
>>>>>>>>> On Wed, Aug 24, 2016 at 6:49 PM, Hervé BOUTEMY <
>>>>>>>>> herve.boutemy@free.fr
>>>>>>>>> <javascript:;>>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Le mercredi 24 août 2016 18:41:59 Fred Cooke a écrit :
>>>>>>>>>>> Fair call re embedded pom, however it's quite convenient to  
>>>>>>>>>>> just
>>>>>>>>> browse
>>>>>>>>>> to
>>>>>>>>>>> it and read.
>>>>>>>>>>>
>>>>>>>>>>> I've occasionally gone looking for details from poms of  
>>>>>>>>>>> artefacts
>>>>>>>>> and
>>>>>>>>>> found
>>>>>>>>>>> a mess and missing stuff, and been annoyed. It probably wasn't
>>>>>>>>> gradle's
>>>>>>>>>>> fault, though. Just a sloppy author. If I'm honest I wouldn't
>>>>>>>>> even
>>>>>>>>> know
>>>>>>>>>> if
>>>>>>>>>>> I've ever consumed a non-maven artefact, certainly none of  
>>>>>>>>>>> mine!
>>>>>>>>> :-)
>>>>>>>>>>>
>>>>>>>>>>> No, I am sure, I have, at least one, and it's an ant one with a
>>>>>>>>> hard
>>>>>>>>>> coded
>>>>>>>>>>> POM that doesn't always reflect the contents of the jar. Yuck.
>>>>>>>>> Clearly
>>>>>>>>>> not
>>>>>>>>>>> an issue with automated stuff, though.
>>>>>>>>>>>
>>>>>>>>>>> My only argument now is ease of reading things like project
>>>>>>>>> descriptions,
>>>>>>>>>>> contributors, SCM details, etc rather than having to unpack the
>>>>>>>>> jar.
>>>>>>>>> And
>>>>>>>>>> if
>>>>>>>>>>> you do, and end up with two pom.xmls laying around, that's not
>>>>>>>>> nice.
>>>>>>>>>> Better
>>>>>>>>>>> to just start always suffixing one with pom.xml.build or some
>>>>>>>>> such? I
>>>>>>>>>> think
>>>>>>>>>>> so, but I haven't thought deeply about it aside from reading  
>>>>>>>>>>> this
>>>>>>>>> thread.
>>>>>>>>>> our consumer pom will be generated from build pom: we can  
>>>>>>>>>> automate
>>>>>>>>> copy
>>>>>>>>> of
>>>>>>>>>> any
>>>>>>>>>> information we want, and for sure, I expect to put at least
>>>>>>>>> description,
>>>>>>>>>> scm
>>>>>>>>>> details, issueManagement, license (of course).
>>>>>>>>>> In your list, there is only constributors that I was not  
>>>>>>>>>> counting
>>>>>>>>> on
>>>>>>>>> it:
>>>>>>>>>> but
>>>>>>>>>> it's a detailed decision we'll have to make
>>>>>>>>>>
>>>>>>>>>> for sure, Maven consumer poms, since generated from Maven build
>>>>>>>>> pom,
>>>>>>>>> can
>>>>>>>>>> have
>>>>>>>>>> much more details (and be sure they are accurrate) than build  
>>>>>>>>>> tools
>>>>>>>>> that
>>>>>>>>>> don't
>>>>>>>>>> generate it from data that exists in their original build format
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Hervé
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Aug 24, 2016 at 6:32 PM, Hervé BOUTEMY <
>>>>>>>>> herve.boutemy@free.fr
>>>>>>>>> <javascript:;>>
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit :
>>>>>>>>>>>>> That should have separation between builder Pom and consumer
>>>>>>>>> Pom.
>>>>>>>>> For
>>>>>>>>>>>>> packaging=pom we deploy the builder Pom using
>>>>>>>>> classifier=build
>>>>>>>>>>>>> *for all other packaging a we do not deploy the builder Pom*.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I don't like the sound of this. The deployed artefacts should
>>>>>>>>> include
>>>>>>>>>>>>> the
>>>>>>>>>>>>> exact POM in use to build the project, as a reference, even
>>>>>>>>> if
>>>>>>>>> under
>>>>>>>>>> a
>>>>>>>>>>>>> different name. Yes, they should be in SCM, however down
>>>>>>>>> stream
>>>>>>>>> it's
>>>>>>>>>>>>
>>>>>>>>>>>> useful
>>>>>>>>>>>>
>>>>>>>>>>>>> to see these even when the SCM is offline or gone or private
>>>>>>>>> or
>>>>>>>>>>>>> whatever.
>>>>>>>>>>>>> Or did I misunderstand? If so, please clarify?
>>>>>>>>>>>>
>>>>>>>>>>>> when you consume an artifact not build with Maven, do you get
>>>>>>>>> the
>>>>>>>>> full
>>>>>>>>>>>> build
>>>>>>>>>>>> script?
>>>>>>>>>>>> no
>>>>>>>>>>>> I know that, as Maven users, we got used to have the build pom
>>>>>>>>>> published
>>>>>>>>>>>> in
>>>>>>>>>>>> central: this is now an issue, but we like that
>>>>>>>>>>>>
>>>>>>>>>>>> notice: the build pom can be injected in the artifact, in
>>>>>>>>>> META-INF/maven,
>>>>>>>>>>>> like
>>>>>>>>>>>> it is currently done
>>>>>>>>>>>> but I don't see the point in requiring it to be pbulished
>>>>>>>>> separately
>>>>>>>>> in
>>>>>>>>>>>> central: no other build tool does that, and they don't have  
>>>>>>>>>>>> any
>>>>>>>>> issue
>>>>>>>>>> with
>>>>>>>>>>>> that (and eventually it's a feature: don't publish internal
>>>>>>>>> details
>>>>>>>>> you
>>>>>>>>>>>> don't
>>>>>>>>>>>> really want people to see)
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Hervé
>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Aug 24, 2016 at 1:52 PM, Stephen Connolly <
>>>>>>>>>>>>>
>>>>>>>>>>>>> stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>>>>>>>>>>>>>> On Tuesday 23 August 2016, Paul Benedict <
>>>>>>>>> pbenedict@apache.org
>>>>>>>>> <javascript:;>>
>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <
>>>>>>>>>> cs@schulte.it <javascript:;>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <javascript:;>> wrote:
>>>>>>>>>>>>>>>>> Am 08/24/16 um 00:08 schrieb Paul Benedict:
>>>>>>>>>>>>>>>>> POM and a future major version POM? I am hinting at a
>>>>>>>>>> strategy
>>>>>>>>>>>>
>>>>>>>>>>>> for
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> forward
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> compatibility.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Is forward compatibility really needed/required?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I honestly don't know, which is why I am asking. An
>>>>>>>>> answer
>>>>>>>>> of
>>>>>>>>> "no
>>>>>>>>>>>>>>> compatibility" is possible, too.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I can completely see the argument that says POMs must be
>>>>>>>>>>>>>>> all-parseable-or-nothing -- for the sake of
>>>>>>>>> reproducibility.
>>>>>>>>> I
>>>>>>>>>>>>
>>>>>>>>>>>> actually
>>>>>>>>>>>>
>>>>>>>>>>>>>>> prefer this answer. I think it is sensible to fail a
>>>>>>>>> build
>>>>>>>>> when
>>>>>>>>>>>>>>> encountering a POM version too advanced. If your client
>>>>>>>>> only
>>>>>>>>>>>>
>>>>>>>>>>>> supports up
>>>>>>>>>>>>
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> model 4.0.0, then all artifacts must be specified by
>>>>>>>>> 4.0.0
>>>>>>>>>> models,
>>>>>>>>>>>>
>>>>>>>>>>>> too.
>>>>>>>>>>>>
>>>>>>>>>>>>>>> On the other hand, I wanted to give the benefit of the
>>>>>>>>> doubt
>>>>>>>>> to
>>>>>>>>>> the
>>>>>>>>>>>>>>> opposite argument. At least one person spoke up and said
>>>>>>>>> it's
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> unacceptable
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> to fail a build on configuration you don't understand.
>>>>>>>>> Well,
>>>>>>>>>> that's
>>>>>>>>>>>>
>>>>>>>>>>>> an
>>>>>>>>>>>>
>>>>>>>>>>>>>>> interesting argument, too. That person doesn't want to
>>>>>>>>> tank
>>>>>>>>> the
>>>>>>>>>>>>>>> build
>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>> the 1% of configuration that can't be understood.... but
>>>>>>>>> I
>>>>>>>>> fail
>>>>>>>>>> to
>>>>>>>>>>>>
>>>>>>>>>>>> see
>>>>>>>>>>>>
>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>> escape hatch here. If a client can't understand what's
>>>>>>>>> being
>>>>>>>>>>>>
>>>>>>>>>>>> specified,
>>>>>>>>>>>>
>>>>>>>>>>>>>>> then what else can be done but fail?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Strip the dependencies a and let the user fix up manually
>>>>>>>>> (ideally
>>>>>>>>>> by
>>>>>>>>>>>>>> logging a warning that you are consuming a dependency
>>>>>>>>> using a
>>>>>>>>> newer
>>>>>>>>>>>>>> modelVersion)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Everyone forgets that the 4.0.0 ship has sailed already, so
>>>>>>>>> we
>>>>>>>>>> have to
>>>>>>>>>>>>>> deploy best-effort 4.0.0 poms
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Now I say that 3.4 should not have a new modelVersion but
>>>>>>>>> what
>>>>>>>>> it
>>>>>>>>>>>>
>>>>>>>>>>>> could do
>>>>>>>>>>>>
>>>>>>>>>>>>>> is be more forgiving of newer modelVersions or try and
>>>>>>>>> download
>>>>>>>>> and
>>>>>>>>>>>>
>>>>>>>>>>>> use an
>>>>>>>>>>>>
>>>>>>>>>>>>>> XSLT to convert newer modelVersions to 4.0.0 (while
>>>>>>>>> logging a
>>>>>>>>>> warning)
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>> option flags to allow failing the build if XSLT had to be
>>>>>>>>> applied
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So let's bump the modelVersion in Maven 5.0.0 (there is no
>>>>>>>>> Maven
>>>>>>>>>> 4.x
>>>>>>>>>>>>
>>>>>>>>>>>> let's
>>>>>>>>>>>>
>>>>>>>>>>>>>> align on the modelVersion)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That should have separation between builder Pom and
>>>>>>>>> consumer
>>>>>>>>> Pom.
>>>>>>>>>> For
>>>>>>>>>>>>>> packaging=pom we deploy the builder Pom using
>>>>>>>>> classifier=build
>>>>>>>>> for
>>>>>>>>>> all
>>>>>>>>>>>>>> other packaging a we do not deploy the builder Pom.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We deploy a *best effort* conversion of the consumer Pom to
>>>>>>>>>>>>
>>>>>>>>>>>> modelVersion
>>>>>>>>>>>>
>>>>>>>>>>>>>> 4.0.0 without a classifier and the consumer Pom gets
>>>>>>>>> deployed
>>>>>>>>> as
>>>>>>>>>>>>>> classifier
>>>>>>>>>>>>>> consumer.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The consumer Pom format allows for XSLT to transform to a
>>>>>>>>> parsable
>>>>>>>>>>>>
>>>>>>>>>>>> syntax,
>>>>>>>>>>>>
>>>>>>>>>>>>>> if transform is required we log a warning (or fail the
>>>>>>>>> build
>>>>>>>>> if
>>>>>>>>> the
>>>>>>>>>>>>>> builder
>>>>>>>>>>>>>> Pom indicates strict modelVersion adherence)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So yeah maven 5.x will be able to parse dependencies with
>>>>>>>>>> modelVersion
>>>>>>>>>>>>
>>>>>>>>>>>> 6.x
>>>>>>>>>>>>
>>>>>>>>>>>>>> while logging warnings that the user may not have the
>>>>>>>>> correct
>>>>>>>>>>>>
>>>>>>>>>>>> dependency
>>>>>>>>>>>>
>>>>>>>>>>>>>> tree. That is IMHO acceptable forward compatibility
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> HTH
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Stephen
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ps I'm really hoping someone has a less crappy solution
>>>>>>>>> that
>>>>>>>>>> this...
>>>>>>>>>>>>
>>>>>>>>>>>> But I
>>>>>>>>>>>>
>>>>>>>>>>>>>> believe this is actually *a* solution... And prior to this
>>>>>>>>> I
>>>>>>>>> have
>>>>>>>>>> not
>>>>>>>>>>>>
>>>>>>>>>>>> seen
>>>>>>>>>>>>
>>>>>>>>>>>>>> any solution
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>> Paul
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Sent from my phone
>>>>>>>>>>>>
>>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>> ---------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> <javascript:;>
>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>> <javascript:;>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>> ---------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> <javascript:;>
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>> <javascript:;>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------
>>>>>>>> ---------
>>>>>>>>
>>>>>>> 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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Chas Honton <ch...@honton.org>]

I use the current Pom to automate checking license policy and checking  owasp database for known security flaws. The scm and website metadata is also very useful. Automated download of source for debugging is essential. As a consumer, I don't want to lose these abilities. 

Chas

> On Aug 25, 2016, at 10:11 AM, Paul Benedict <pb...@apache.org> wrote:
> 
> Is it really correct to call a dependency-only (more of less) file a POM if
> it ceases to contain project information? A project is (or should be!)
> synonymous with a build. Is that why someone referred to it as a DOM? A DOM
> makes way more sense to me than overloading the usage of POM and calling it
> a "consumer POM"
> 
> Cheers,
> Paul
> 
> On Thu, Aug 25, 2016 at 11:53 AM, Robert Scholte <rf...@apache.org>
> wrote:
> 
>> For both the flattened-pom and consumer-pom the idea is to remove build
>> related information. Most of it is only used during build.
>> The question is: is there other information which should be added?
>> e.g. In case of JARs: the major version number of the class file format
>> being used. Is it interesting to know this BEFORE downloading the jar? And
>> if so, there should be a possibility to make choices based on that
>> information. The choice-option doesn't exist and would make it all too
>> complex.
>> I would say that it is indeed all about dependencies.
>> 
>> thanks,
>> Robert
>> 
>> 
>> On Thu, 25 Aug 2016 18:25:36 +0200, Paul Benedict <pb...@apache.org>
>> wrote:
>> 
>> The only (minor?) issue I have with the term "consumer POM" is that it
>>> implies one type of consumption. What is the kind of consumption we're
>>> addressing -- is it merely the GAV and dependencies?
>>> 
>>> Cheers,
>>> Paul
>>> 
>>> On Thu, Aug 25, 2016 at 3:34 AM, Robert Scholte <rf...@apache.org>
>>> wrote:
>>> 
>>> On Thu, 25 Aug 2016 01:10:36 +0200, Stephen Connolly <
>>>> stephen.alan.connolly@gmail.com> wrote:
>>>> 
>>>>> On 24 August 2016 at 04:50, Robert Scholte <rf...@apache.org> wrote:
>>>>> 
>>>>> 
>>>>> I realized last ApacheCon that I wasn't clear about my definiton of the
>>>>> 
>>>>>> consumer-pom.
>>>>>> I don't think it should be a flattened pom with only the dependency
>>>>>> information. Instead it shouldn't be a pom  (matching the pom.xsd) at
>>>>>> all.
>>>>>> 
>>>>>> 
>>>>>> I am not in disagreement, but as a concept the name "consumer pom" has
>>>>> more
>>>>> traction.
>>>>> 
>>>>> 
>>>> I'd prefer consumer pom too, but it has led to confusion due to the
>>>> assumption that consumer pom and flattened pom are the same thing. To me
>>>> it
>>>> makes sense to consider a new fileformat for the consumer pom which
>>>> matches
>>>> better the requirements. And yes, the "provides" would fit here.
>>>> 
>>>> 
>>>> 
>>>> I see the builder pom as probably ending up not even being XML at all.
>>>>> Rather IMHO it will end up being a DSL that is easy to author and not
>>>>> verbose... and certainly not XML
>>>>> 
>>>>> So the consumer pom should be stripped back to include two sets of
>>>>> information:
>>>>> 
>>>>> * dependencies - we are mostly familiar with this... though we may not
>>>>> expose all the scopes... depends on how we think about things and how we
>>>>> view scopes moving forward
>>>>> 
>>>>> * provides - this is vitally important IMHO and not handled currently.
>>>>> 
>>>>> To understand provides we have to look at things like JavaEE (but the
>>>>> concept has general utility... though I suspect only for about 10-25% of
>>>>> projects)
>>>>> 
>>>>> If I have a project that says: provides javax.servlet:servlet-api:3.1
>>>>> then
>>>>> that is saying that my project is providing the equivalent content as in
>>>>> javax.servlet:servlet-api:3.1 so for example
>>>>> org.jboss.spec.javax.servlet:
>>>>> jboss-servlet-api_3.1_spec:1.0.0.Final would say
>>>>> javax.servlet:servlet-api:3.1
>>>>> 
>>>>> When resolving the dependency tree, maven then knows that any transitive
>>>>> requirement for javax.servlet:servlet-api:3.1 has already been met by my
>>>>> direct dependency on org.jboss.spec.javax.servlet:j
>>>>> boss-servlet-api_3.1_spec
>>>>> :1.0.0.Final if we have a direct dependency on
>>>>> org.apache.tomcat:tomcat-servlet-api:8.5.4 (which would also say
>>>>> javax.servlet:servlet-api:3.1) then Maven can report an error and fail
>>>>> the
>>>>> build due to dependency conflict.
>>>>> 
>>>>> There are lots of other improvements we can add, but to start we need to
>>>>> have a way to declare when a project includes duplicate content of
>>>>> another
>>>>> artifact. Convention will be required to make this work correctly...
>>>>> perhaps we can even introduce a new project type that provides needs to
>>>>> point at so that a provides has to point at an "empty" specification
>>>>> project...
>>>>> 
>>>>> Finally, for the consumer pom refactoring I believe we need to address
>>>>> architecture specific artifacts as these are a sort of implicit
>>>>> provides.
>>>>> 
>>>>> 
>>>>> Maybe it should be called something like consumer-dom (dependency object
>>>>> 
>>>>>> model, though dom is confusing...).
>>>>>> It should be the most fast and efficient way to resolve the dependency
>>>>>> tree. That means it should do less roundtrips like Maven must do do
>>>>>> right
>>>>>> now: for every dependency download the pom, for all transitive
>>>>>> dependencies
>>>>>> download all poms, etc.
>>>>>> Why can't it be a pom? I'd like to add the (file)extension too.
>>>>>> Otherwise
>>>>>> Maven needs to initialize the matching ArtifactHandler and translate
>>>>>> the
>>>>>> type to the proper extension.
>>>>>> 
>>>>>> 
>>>>> 
>>>>> I think the consumer pom needs to embed some of the artifact handler
>>>>> information for it self as otherwise non-maven tooling cannot be
>>>>> expected
>>>>> to understand those details... also we should be making the consumer pom
>>>>> both Maven and Java agnostic... but this is a grand problem alright!
>>>>> 
>>>>> 
>>>>> The pom doesn't have room for this.
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> I saw the whole flattened pom experiment as mostly a waste of time for
>>>>> the
>>>>> consumer pom effort as I envision the consumer pom not looking anything
>>>>> like the current pom at all... but it is a project model...
>>>>> 
>>>>> Oh and the consumer pom should include information for the
>>>>> side-artifacts
>>>>> (which would help with reusing tests as we could attach the test
>>>>> dependencies to the test artifact details in the consumer pom)
>>>>> 
>>>>> Consumer-dom is an extraction and enriched version of the pom and will
>>>>> be
>>>>> a
>>>>> 
>>>>> separate upload to the repository. Build tools who can understand this
>>>>>> file
>>>>>> can use it or fall back by downloading all poms.
>>>>>> 
>>>>>> thanks,
>>>>>> Robert
>>>>>> 
>>>>>> 
>>>>>> On Wed, 24 Aug 2016 09:22:03 +0200, Stephen Connolly <
>>>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>>> 
>>>>>> The consumer Pom is for machine to machine, it should be human readable
>>>>>> 
>>>>>> because that is nice, but intent is never human generated.
>>>>>>> 
>>>>>>> Switching to this separation allows us to be more radical in the
>>>>>>> changes
>>>>>>> to
>>>>>>> the build Pom.
>>>>>>> 
>>>>>>> The only reason we deploy packaging Pom's build Pom is for
>>>>>>> inheritance.
>>>>>>> If
>>>>>>> we didn't have to deal with that we wouldn't need to deploy any build
>>>>>>> poms
>>>>>>> ever.
>>>>>>> 
>>>>>>> For using a build Pom as a parent, you implicitly pick up the minimum
>>>>>>> version of maven that your parent requires, so we then are free to
>>>>>>> evolve
>>>>>>> the build Pom format without worrying about forward compatibility,
>>>>>>> only
>>>>>>> backwards compatibility on the *build* Pom.
>>>>>>> 
>>>>>>> The consumer Pom needs partial *forward* compatibility, so that older
>>>>>>> clients are able to *attempt* to consume...
>>>>>>> 
>>>>>>> In short there are totally different compatibility constraints on the
>>>>>>> two,
>>>>>>> so they should be separate.
>>>>>>> 
>>>>>>> Mixins would probably also be deployed, once we figure out how they
>>>>>>> work
>>>>>>> with build poms.
>>>>>>> 
>>>>>>> I think we probably need to rethink version ranges. What I'd like is
>>>>>>> to
>>>>>>> let
>>>>>>> the consumer Pom treat version ranges more as guidance rather than
>>>>>>> hard
>>>>>>> requirements. It's a pain if you depend transitiveky on Foo:[1.0] but
>>>>>>> need
>>>>>>> Foo:[1.0.1,1.1) for the critical security fix... Having to run around
>>>>>>> applying excludes is not a good plan... Yes the build should initially
>>>>>>> fail
>>>>>>> if I depend on [1.0] and [1.0.1,1.1) in my graph, but I should be able
>>>>>>> to
>>>>>>> resolve the conflict for all my consumers (unless they pull in the
>>>>>>> conflict
>>>>>>> again themselves)
>>>>>>> 
>>>>>>> On Tuesday 23 August 2016, Fred Cooke <fr...@gmail.com> wrote:
>>>>>>> 
>>>>>>> I still find it a bit off that the original real POM won't always be
>>>>>>> 
>>>>>>> directly available anymore.
>>>>>>>> 
>>>>>>>> Other tools create fake POMs because they *have* to - there's no
>>>>>>>> other
>>>>>>>> option.
>>>>>>>> 
>>>>>>>> I feel like some fidelity would be lost. Diffability would be lost
>>>>>>>> (from
>>>>>>>> a
>>>>>>>> scenario where there's nothing to diff).
>>>>>>>> 
>>>>>>>> Unrelated, really, but kind of related: top level deployable artefact
>>>>>>>> deployments, debs, wars, exes, etc. When ranges are in use it'd be
>>>>>>>> nice
>>>>>>>> to
>>>>>>>> deploy a sort of strict effective pom with fully hard [] versions for
>>>>>>>> all
>>>>>>>> things. This can be achieved in other ways, though.
>>>>>>>> 
>>>>>>>> I guess that is to say, don't forget about non-central deployments. I
>>>>>>>> suppose if there's a way to always deploy pom.xml.build through some
>>>>>>>> plugin
>>>>>>>> or configuration or some such, then that's fine with me.
>>>>>>>> 
>>>>>>>> On Wed, Aug 24, 2016 at 6:49 PM, Hervé BOUTEMY <
>>>>>>>> herve.boutemy@free.fr
>>>>>>>> <javascript:;>>
>>>>>>>> 
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Le mercredi 24 août 2016 18:41:59 Fred Cooke a écrit :
>>>>>>>>>> Fair call re embedded pom, however it's quite convenient to just
>>>>>>>> browse
>>>>>>>>> to
>>>>>>>>>> it and read.
>>>>>>>>>> 
>>>>>>>>>> I've occasionally gone looking for details from poms of artefacts
>>>>>>>> and
>>>>>>>>> found
>>>>>>>>>> a mess and missing stuff, and been annoyed. It probably wasn't
>>>>>>>> gradle's
>>>>>>>>>> fault, though. Just a sloppy author. If I'm honest I wouldn't
>>>>>>>> even
>>>>>>>> know
>>>>>>>>> if
>>>>>>>>>> I've ever consumed a non-maven artefact, certainly none of mine!
>>>>>>>> :-)
>>>>>>>>>> 
>>>>>>>>>> No, I am sure, I have, at least one, and it's an ant one with a
>>>>>>>> hard
>>>>>>>>> coded
>>>>>>>>>> POM that doesn't always reflect the contents of the jar. Yuck.
>>>>>>>> Clearly
>>>>>>>>> not
>>>>>>>>>> an issue with automated stuff, though.
>>>>>>>>>> 
>>>>>>>>>> My only argument now is ease of reading things like project
>>>>>>>> descriptions,
>>>>>>>>>> contributors, SCM details, etc rather than having to unpack the
>>>>>>>> jar.
>>>>>>>> And
>>>>>>>>> if
>>>>>>>>>> you do, and end up with two pom.xmls laying around, that's not
>>>>>>>> nice.
>>>>>>>>> Better
>>>>>>>>>> to just start always suffixing one with pom.xml.build or some
>>>>>>>> such? I
>>>>>>>>> think
>>>>>>>>>> so, but I haven't thought deeply about it aside from reading this
>>>>>>>> thread.
>>>>>>>>> our consumer pom will be generated from build pom: we can automate
>>>>>>>> copy
>>>>>>>> of
>>>>>>>>> any
>>>>>>>>> information we want, and for sure, I expect to put at least
>>>>>>>> description,
>>>>>>>>> scm
>>>>>>>>> details, issueManagement, license (of course).
>>>>>>>>> In your list, there is only constributors that I was not counting
>>>>>>>> on
>>>>>>>> it:
>>>>>>>>> but
>>>>>>>>> it's a detailed decision we'll have to make
>>>>>>>>> 
>>>>>>>>> for sure, Maven consumer poms, since generated from Maven build
>>>>>>>> pom,
>>>>>>>> can
>>>>>>>>> have
>>>>>>>>> much more details (and be sure they are accurrate) than build tools
>>>>>>>> that
>>>>>>>>> don't
>>>>>>>>> generate it from data that exists in their original build format
>>>>>>>>> 
>>>>>>>>> Regards,
>>>>>>>>> 
>>>>>>>>> Hervé
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Wed, Aug 24, 2016 at 6:32 PM, Hervé BOUTEMY <
>>>>>>>> herve.boutemy@free.fr
>>>>>>>> <javascript:;>>
>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> wrote:
>>>>>>>>>>> Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit :
>>>>>>>>>>>> That should have separation between builder Pom and consumer
>>>>>>>> Pom.
>>>>>>>> For
>>>>>>>>>>>> packaging=pom we deploy the builder Pom using
>>>>>>>> classifier=build
>>>>>>>>>>>> *for all other packaging a we do not deploy the builder Pom*.
>>>>>>>>>>>> 
>>>>>>>>>>>> I don't like the sound of this. The deployed artefacts should
>>>>>>>> include
>>>>>>>>>>>> the
>>>>>>>>>>>> exact POM in use to build the project, as a reference, even
>>>>>>>> if
>>>>>>>> under
>>>>>>>>> a
>>>>>>>>>>>> different name. Yes, they should be in SCM, however down
>>>>>>>> stream
>>>>>>>> it's
>>>>>>>>>>> 
>>>>>>>>>>> useful
>>>>>>>>>>> 
>>>>>>>>>>>> to see these even when the SCM is offline or gone or private
>>>>>>>> or
>>>>>>>>>>>> whatever.
>>>>>>>>>>>> Or did I misunderstand? If so, please clarify?
>>>>>>>>>>> 
>>>>>>>>>>> when you consume an artifact not build with Maven, do you get
>>>>>>>> the
>>>>>>>> full
>>>>>>>>>>> build
>>>>>>>>>>> script?
>>>>>>>>>>> no
>>>>>>>>>>> I know that, as Maven users, we got used to have the build pom
>>>>>>>>> published
>>>>>>>>>>> in
>>>>>>>>>>> central: this is now an issue, but we like that
>>>>>>>>>>> 
>>>>>>>>>>> notice: the build pom can be injected in the artifact, in
>>>>>>>>> META-INF/maven,
>>>>>>>>>>> like
>>>>>>>>>>> it is currently done
>>>>>>>>>>> but I don't see the point in requiring it to be pbulished
>>>>>>>> separately
>>>>>>>> in
>>>>>>>>>>> central: no other build tool does that, and they don't have any
>>>>>>>> issue
>>>>>>>>> with
>>>>>>>>>>> that (and eventually it's a feature: don't publish internal
>>>>>>>> details
>>>>>>>> you
>>>>>>>>>>> don't
>>>>>>>>>>> really want people to see)
>>>>>>>>>>> 
>>>>>>>>>>> Regards,
>>>>>>>>>>> 
>>>>>>>>>>> Hervé
>>>>>>>>>>> 
>>>>>>>>>>>> On Wed, Aug 24, 2016 at 1:52 PM, Stephen Connolly <
>>>>>>>>>>>> 
>>>>>>>>>>>> stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>>>>>>>>>>>>> On Tuesday 23 August 2016, Paul Benedict <
>>>>>>>> pbenedict@apache.org
>>>>>>>> <javascript:;>>
>>>>>>>> 
>>>>>>>>> wrote:
>>>>>>>>>>>>>> On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <
>>>>>>>>> cs@schulte.it <javascript:;>
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> <javascript:;>> wrote:
>>>>>>>>>>>>>>>> Am 08/24/16 um 00:08 schrieb Paul Benedict:
>>>>>>>>>>>>>>>> POM and a future major version POM? I am hinting at a
>>>>>>>>> strategy
>>>>>>>>>>> 
>>>>>>>>>>> for
>>>>>>>>>>> 
>>>>>>>>>>>>>>> forward
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> compatibility.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Is forward compatibility really needed/required?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I honestly don't know, which is why I am asking. An
>>>>>>>> answer
>>>>>>>> of
>>>>>>>> "no
>>>>>>>>>>>>>> compatibility" is possible, too.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I can completely see the argument that says POMs must be
>>>>>>>>>>>>>> all-parseable-or-nothing -- for the sake of
>>>>>>>> reproducibility.
>>>>>>>> I
>>>>>>>>>>> 
>>>>>>>>>>> actually
>>>>>>>>>>> 
>>>>>>>>>>>>>> prefer this answer. I think it is sensible to fail a
>>>>>>>> build
>>>>>>>> when
>>>>>>>>>>>>>> encountering a POM version too advanced. If your client
>>>>>>>> only
>>>>>>>>>>> 
>>>>>>>>>>> supports up
>>>>>>>>>>> 
>>>>>>>>>>>>> to
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> model 4.0.0, then all artifacts must be specified by
>>>>>>>> 4.0.0
>>>>>>>>> models,
>>>>>>>>>>> 
>>>>>>>>>>> too.
>>>>>>>>>>> 
>>>>>>>>>>>>>> On the other hand, I wanted to give the benefit of the
>>>>>>>> doubt
>>>>>>>> to
>>>>>>>>> the
>>>>>>>>>>>>>> opposite argument. At least one person spoke up and said
>>>>>>>> it's
>>>>>>>>>>>>> 
>>>>>>>>>>>>> unacceptable
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> to fail a build on configuration you don't understand.
>>>>>>>> Well,
>>>>>>>>> that's
>>>>>>>>>>> 
>>>>>>>>>>> an
>>>>>>>>>>> 
>>>>>>>>>>>>>> interesting argument, too. That person doesn't want to
>>>>>>>> tank
>>>>>>>> the
>>>>>>>>>>>>>> build
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>> the 1% of configuration that can't be understood.... but
>>>>>>>> I
>>>>>>>> fail
>>>>>>>>> to
>>>>>>>>>>> 
>>>>>>>>>>> see
>>>>>>>>>>> 
>>>>>>>>>>>>>> an
>>>>>>>>>>>>>> escape hatch here. If a client can't understand what's
>>>>>>>> being
>>>>>>>>>>> 
>>>>>>>>>>> specified,
>>>>>>>>>>> 
>>>>>>>>>>>>>> then what else can be done but fail?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Strip the dependencies a and let the user fix up manually
>>>>>>>> (ideally
>>>>>>>>> by
>>>>>>>>>>>>> logging a warning that you are consuming a dependency
>>>>>>>> using a
>>>>>>>> newer
>>>>>>>>>>>>> modelVersion)
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Everyone forgets that the 4.0.0 ship has sailed already, so
>>>>>>>> we
>>>>>>>>> have to
>>>>>>>>>>>>> deploy best-effort 4.0.0 poms
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Now I say that 3.4 should not have a new modelVersion but
>>>>>>>> what
>>>>>>>> it
>>>>>>>>>>> 
>>>>>>>>>>> could do
>>>>>>>>>>> 
>>>>>>>>>>>>> is be more forgiving of newer modelVersions or try and
>>>>>>>> download
>>>>>>>> and
>>>>>>>>>>> 
>>>>>>>>>>> use an
>>>>>>>>>>> 
>>>>>>>>>>>>> XSLT to convert newer modelVersions to 4.0.0 (while
>>>>>>>> logging a
>>>>>>>>> warning)
>>>>>>>>>>>>> with
>>>>>>>>>>>>> option flags to allow failing the build if XSLT had to be
>>>>>>>> applied
>>>>>>>>>>>>> 
>>>>>>>>>>>>> So let's bump the modelVersion in Maven 5.0.0 (there is no
>>>>>>>> Maven
>>>>>>>>> 4.x
>>>>>>>>>>> 
>>>>>>>>>>> let's
>>>>>>>>>>> 
>>>>>>>>>>>>> align on the modelVersion)
>>>>>>>>>>>>> 
>>>>>>>>>>>>> That should have separation between builder Pom and
>>>>>>>> consumer
>>>>>>>> Pom.
>>>>>>>>> For
>>>>>>>>>>>>> packaging=pom we deploy the builder Pom using
>>>>>>>> classifier=build
>>>>>>>> for
>>>>>>>>> all
>>>>>>>>>>>>> other packaging a we do not deploy the builder Pom.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> We deploy a *best effort* conversion of the consumer Pom to
>>>>>>>>>>> 
>>>>>>>>>>> modelVersion
>>>>>>>>>>> 
>>>>>>>>>>>>> 4.0.0 without a classifier and the consumer Pom gets
>>>>>>>> deployed
>>>>>>>> as
>>>>>>>>>>>>> classifier
>>>>>>>>>>>>> consumer.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> The consumer Pom format allows for XSLT to transform to a
>>>>>>>> parsable
>>>>>>>>>>> 
>>>>>>>>>>> syntax,
>>>>>>>>>>> 
>>>>>>>>>>>>> if transform is required we log a warning (or fail the
>>>>>>>> build
>>>>>>>> if
>>>>>>>> the
>>>>>>>>>>>>> builder
>>>>>>>>>>>>> Pom indicates strict modelVersion adherence)
>>>>>>>>>>>>> 
>>>>>>>>>>>>> So yeah maven 5.x will be able to parse dependencies with
>>>>>>>>> modelVersion
>>>>>>>>>>> 
>>>>>>>>>>> 6.x
>>>>>>>>>>> 
>>>>>>>>>>>>> while logging warnings that the user may not have the
>>>>>>>> correct
>>>>>>>>>>> 
>>>>>>>>>>> dependency
>>>>>>>>>>> 
>>>>>>>>>>>>> tree. That is IMHO acceptable forward compatibility
>>>>>>>>>>>>> 
>>>>>>>>>>>>> HTH
>>>>>>>>>>>>> 
>>>>>>>>>>>>> -Stephen
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Ps I'm really hoping someone has a less crappy solution
>>>>>>>> that
>>>>>>>>> this...
>>>>>>>>>>> 
>>>>>>>>>>> But I
>>>>>>>>>>> 
>>>>>>>>>>>>> believe this is actually *a* solution... And prior to this
>>>>>>>> I
>>>>>>>> have
>>>>>>>>> not
>>>>>>>>>>> 
>>>>>>>>>>> seen
>>>>>>>>>>> 
>>>>>>>>>>>>> any solution
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>> Paul
>>>>>>>>>>>>> 
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Sent from my phone
>>>>>>>>>>> 
>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>> ---------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> <javascript:;>
>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>> <javascript:;>
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> ------------------------------------------------------------
>>>>>>>> ---------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> <javascript:;>
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>> <javascript:;>
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> ------------------------------------------------------------
>>>>>>> ---------
>>>>>>> 
>>>>>> 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: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Paul Benedict <pb...@apache.org>]

Is it really correct to call a dependency-only (more of less) file a POM if
it ceases to contain project information? A project is (or should be!)
synonymous with a build. Is that why someone referred to it as a DOM? A DOM
makes way more sense to me than overloading the usage of POM and calling it
a "consumer POM"

Cheers,
Paul

On Thu, Aug 25, 2016 at 11:53 AM, Robert Scholte <rf...@apache.org>
wrote:

> For both the flattened-pom and consumer-pom the idea is to remove build
> related information. Most of it is only used during build.
> The question is: is there other information which should be added?
> e.g. In case of JARs: the major version number of the class file format
> being used. Is it interesting to know this BEFORE downloading the jar? And
> if so, there should be a possibility to make choices based on that
> information. The choice-option doesn't exist and would make it all too
> complex.
> I would say that it is indeed all about dependencies.
>
> thanks,
> Robert
>
>
> On Thu, 25 Aug 2016 18:25:36 +0200, Paul Benedict <pb...@apache.org>
> wrote:
>
> The only (minor?) issue I have with the term "consumer POM" is that it
>> implies one type of consumption. What is the kind of consumption we're
>> addressing -- is it merely the GAV and dependencies?
>>
>> Cheers,
>> Paul
>>
>> On Thu, Aug 25, 2016 at 3:34 AM, Robert Scholte <rf...@apache.org>
>> wrote:
>>
>> On Thu, 25 Aug 2016 01:10:36 +0200, Stephen Connolly <
>>> stephen.alan.connolly@gmail.com> wrote:
>>>
>>> On 24 August 2016 at 04:50, Robert Scholte <rf...@apache.org> wrote:
>>>
>>>>
>>>> I realized last ApacheCon that I wasn't clear about my definiton of the
>>>>
>>>>> consumer-pom.
>>>>> I don't think it should be a flattened pom with only the dependency
>>>>> information. Instead it shouldn't be a pom  (matching the pom.xsd) at
>>>>> all.
>>>>>
>>>>>
>>>>> I am not in disagreement, but as a concept the name "consumer pom" has
>>>> more
>>>> traction.
>>>>
>>>>
>>> I'd prefer consumer pom too, but it has led to confusion due to the
>>> assumption that consumer pom and flattened pom are the same thing. To me
>>> it
>>> makes sense to consider a new fileformat for the consumer pom which
>>> matches
>>> better the requirements. And yes, the "provides" would fit here.
>>>
>>>
>>>
>>> I see the builder pom as probably ending up not even being XML at all.
>>>> Rather IMHO it will end up being a DSL that is easy to author and not
>>>> verbose... and certainly not XML
>>>>
>>>> So the consumer pom should be stripped back to include two sets of
>>>> information:
>>>>
>>>> * dependencies - we are mostly familiar with this... though we may not
>>>> expose all the scopes... depends on how we think about things and how we
>>>> view scopes moving forward
>>>>
>>>> * provides - this is vitally important IMHO and not handled currently.
>>>>
>>>> To understand provides we have to look at things like JavaEE (but the
>>>> concept has general utility... though I suspect only for about 10-25% of
>>>> projects)
>>>>
>>>> If I have a project that says: provides javax.servlet:servlet-api:3.1
>>>> then
>>>> that is saying that my project is providing the equivalent content as in
>>>> javax.servlet:servlet-api:3.1 so for example
>>>> org.jboss.spec.javax.servlet:
>>>> jboss-servlet-api_3.1_spec:1.0.0.Final would say
>>>> javax.servlet:servlet-api:3.1
>>>>
>>>> When resolving the dependency tree, maven then knows that any transitive
>>>> requirement for javax.servlet:servlet-api:3.1 has already been met by my
>>>> direct dependency on org.jboss.spec.javax.servlet:j
>>>> boss-servlet-api_3.1_spec
>>>> :1.0.0.Final if we have a direct dependency on
>>>> org.apache.tomcat:tomcat-servlet-api:8.5.4 (which would also say
>>>> javax.servlet:servlet-api:3.1) then Maven can report an error and fail
>>>> the
>>>> build due to dependency conflict.
>>>>
>>>> There are lots of other improvements we can add, but to start we need to
>>>> have a way to declare when a project includes duplicate content of
>>>> another
>>>> artifact. Convention will be required to make this work correctly...
>>>> perhaps we can even introduce a new project type that provides needs to
>>>> point at so that a provides has to point at an "empty" specification
>>>> project...
>>>>
>>>> Finally, for the consumer pom refactoring I believe we need to address
>>>> architecture specific artifacts as these are a sort of implicit
>>>> provides.
>>>>
>>>>
>>>> Maybe it should be called something like consumer-dom (dependency object
>>>>
>>>>> model, though dom is confusing...).
>>>>> It should be the most fast and efficient way to resolve the dependency
>>>>> tree. That means it should do less roundtrips like Maven must do do
>>>>> right
>>>>> now: for every dependency download the pom, for all transitive
>>>>> dependencies
>>>>> download all poms, etc.
>>>>> Why can't it be a pom? I'd like to add the (file)extension too.
>>>>> Otherwise
>>>>> Maven needs to initialize the matching ArtifactHandler and translate
>>>>> the
>>>>> type to the proper extension.
>>>>>
>>>>>
>>>>
>>>> I think the consumer pom needs to embed some of the artifact handler
>>>> information for it self as otherwise non-maven tooling cannot be
>>>> expected
>>>> to understand those details... also we should be making the consumer pom
>>>> both Maven and Java agnostic... but this is a grand problem alright!
>>>>
>>>>
>>>> The pom doesn't have room for this.
>>>>
>>>>>
>>>>>
>>>>> I saw the whole flattened pom experiment as mostly a waste of time for
>>>> the
>>>> consumer pom effort as I envision the consumer pom not looking anything
>>>> like the current pom at all... but it is a project model...
>>>>
>>>> Oh and the consumer pom should include information for the
>>>> side-artifacts
>>>> (which would help with reusing tests as we could attach the test
>>>> dependencies to the test artifact details in the consumer pom)
>>>>
>>>> Consumer-dom is an extraction and enriched version of the pom and will
>>>> be
>>>> a
>>>>
>>>> separate upload to the repository. Build tools who can understand this
>>>>> file
>>>>> can use it or fall back by downloading all poms.
>>>>>
>>>>> thanks,
>>>>> Robert
>>>>>
>>>>>
>>>>> On Wed, 24 Aug 2016 09:22:03 +0200, Stephen Connolly <
>>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>>
>>>>> The consumer Pom is for machine to machine, it should be human readable
>>>>>
>>>>> because that is nice, but intent is never human generated.
>>>>>>
>>>>>> Switching to this separation allows us to be more radical in the
>>>>>> changes
>>>>>> to
>>>>>> the build Pom.
>>>>>>
>>>>>> The only reason we deploy packaging Pom's build Pom is for
>>>>>> inheritance.
>>>>>> If
>>>>>> we didn't have to deal with that we wouldn't need to deploy any build
>>>>>> poms
>>>>>> ever.
>>>>>>
>>>>>> For using a build Pom as a parent, you implicitly pick up the minimum
>>>>>> version of maven that your parent requires, so we then are free to
>>>>>> evolve
>>>>>> the build Pom format without worrying about forward compatibility,
>>>>>> only
>>>>>> backwards compatibility on the *build* Pom.
>>>>>>
>>>>>> The consumer Pom needs partial *forward* compatibility, so that older
>>>>>> clients are able to *attempt* to consume...
>>>>>>
>>>>>> In short there are totally different compatibility constraints on the
>>>>>> two,
>>>>>> so they should be separate.
>>>>>>
>>>>>> Mixins would probably also be deployed, once we figure out how they
>>>>>> work
>>>>>> with build poms.
>>>>>>
>>>>>> I think we probably need to rethink version ranges. What I'd like is
>>>>>> to
>>>>>> let
>>>>>> the consumer Pom treat version ranges more as guidance rather than
>>>>>> hard
>>>>>> requirements. It's a pain if you depend transitiveky on Foo:[1.0] but
>>>>>> need
>>>>>> Foo:[1.0.1,1.1) for the critical security fix... Having to run around
>>>>>> applying excludes is not a good plan... Yes the build should initially
>>>>>> fail
>>>>>> if I depend on [1.0] and [1.0.1,1.1) in my graph, but I should be able
>>>>>> to
>>>>>> resolve the conflict for all my consumers (unless they pull in the
>>>>>> conflict
>>>>>> again themselves)
>>>>>>
>>>>>> On Tuesday 23 August 2016, Fred Cooke <fr...@gmail.com> wrote:
>>>>>>
>>>>>> I still find it a bit off that the original real POM won't always be
>>>>>>
>>>>>> directly available anymore.
>>>>>>>
>>>>>>> Other tools create fake POMs because they *have* to - there's no
>>>>>>> other
>>>>>>> option.
>>>>>>>
>>>>>>> I feel like some fidelity would be lost. Diffability would be lost
>>>>>>> (from
>>>>>>> a
>>>>>>> scenario where there's nothing to diff).
>>>>>>>
>>>>>>> Unrelated, really, but kind of related: top level deployable artefact
>>>>>>> deployments, debs, wars, exes, etc. When ranges are in use it'd be
>>>>>>> nice
>>>>>>> to
>>>>>>> deploy a sort of strict effective pom with fully hard [] versions for
>>>>>>> all
>>>>>>> things. This can be achieved in other ways, though.
>>>>>>>
>>>>>>> I guess that is to say, don't forget about non-central deployments. I
>>>>>>> suppose if there's a way to always deploy pom.xml.build through some
>>>>>>> plugin
>>>>>>> or configuration or some such, then that's fine with me.
>>>>>>>
>>>>>>> On Wed, Aug 24, 2016 at 6:49 PM, Hervé BOUTEMY <
>>>>>>> herve.boutemy@free.fr
>>>>>>> <javascript:;>>
>>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> > Le mercredi 24 août 2016 18:41:59 Fred Cooke a écrit :
>>>>>>> > > Fair call re embedded pom, however it's quite convenient to just
>>>>>>> browse
>>>>>>> > to
>>>>>>> > > it and read.
>>>>>>> > >
>>>>>>> > > I've occasionally gone looking for details from poms of artefacts
>>>>>>> and
>>>>>>> > found
>>>>>>> > > a mess and missing stuff, and been annoyed. It probably wasn't
>>>>>>> gradle's
>>>>>>> > > fault, though. Just a sloppy author. If I'm honest I wouldn't
>>>>>>> even
>>>>>>> know
>>>>>>> > if
>>>>>>> > > I've ever consumed a non-maven artefact, certainly none of mine!
>>>>>>> :-)
>>>>>>> > >
>>>>>>> > > No, I am sure, I have, at least one, and it's an ant one with a
>>>>>>> hard
>>>>>>> > coded
>>>>>>> > > POM that doesn't always reflect the contents of the jar. Yuck.
>>>>>>> Clearly
>>>>>>> > not
>>>>>>> > > an issue with automated stuff, though.
>>>>>>> > >
>>>>>>> > > My only argument now is ease of reading things like project
>>>>>>> descriptions,
>>>>>>> > > contributors, SCM details, etc rather than having to unpack the
>>>>>>> jar.
>>>>>>> And
>>>>>>> > if
>>>>>>> > > you do, and end up with two pom.xmls laying around, that's not
>>>>>>> nice.
>>>>>>> > Better
>>>>>>> > > to just start always suffixing one with pom.xml.build or some
>>>>>>> such? I
>>>>>>> > think
>>>>>>> > > so, but I haven't thought deeply about it aside from reading this
>>>>>>> thread.
>>>>>>> > our consumer pom will be generated from build pom: we can automate
>>>>>>> copy
>>>>>>> of
>>>>>>> > any
>>>>>>> > information we want, and for sure, I expect to put at least
>>>>>>> description,
>>>>>>> > scm
>>>>>>> > details, issueManagement, license (of course).
>>>>>>> > In your list, there is only constributors that I was not counting
>>>>>>> on
>>>>>>> it:
>>>>>>> > but
>>>>>>> > it's a detailed decision we'll have to make
>>>>>>> >
>>>>>>> > for sure, Maven consumer poms, since generated from Maven build
>>>>>>> pom,
>>>>>>> can
>>>>>>> > have
>>>>>>> > much more details (and be sure they are accurrate) than build tools
>>>>>>> that
>>>>>>> > don't
>>>>>>> > generate it from data that exists in their original build format
>>>>>>> >
>>>>>>> > Regards,
>>>>>>> >
>>>>>>> > Hervé
>>>>>>> >
>>>>>>> > >
>>>>>>> > >
>>>>>>> > >
>>>>>>> > > On Wed, Aug 24, 2016 at 6:32 PM, Hervé BOUTEMY <
>>>>>>> herve.boutemy@free.fr
>>>>>>> <javascript:;>>
>>>>>>>
>>>>>>> > >
>>>>>>> > > wrote:
>>>>>>> > > > Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit :
>>>>>>> > > > > That should have separation between builder Pom and consumer
>>>>>>> Pom.
>>>>>>> For
>>>>>>> > > > > packaging=pom we deploy the builder Pom using
>>>>>>> classifier=build
>>>>>>> > > > > *for all other packaging a we do not deploy the builder Pom*.
>>>>>>> > > > >
>>>>>>> > > > > I don't like the sound of this. The deployed artefacts should
>>>>>>> include
>>>>>>> > > > > the
>>>>>>> > > > > exact POM in use to build the project, as a reference, even
>>>>>>> if
>>>>>>> under
>>>>>>> > a
>>>>>>> > > > > different name. Yes, they should be in SCM, however down
>>>>>>> stream
>>>>>>> it's
>>>>>>> > > >
>>>>>>> > > > useful
>>>>>>> > > >
>>>>>>> > > > > to see these even when the SCM is offline or gone or private
>>>>>>> or
>>>>>>> > > > > whatever.
>>>>>>> > > > > Or did I misunderstand? If so, please clarify?
>>>>>>> > > >
>>>>>>> > > > when you consume an artifact not build with Maven, do you get
>>>>>>> the
>>>>>>> full
>>>>>>> > > > build
>>>>>>> > > > script?
>>>>>>> > > > no
>>>>>>> > > > I know that, as Maven users, we got used to have the build pom
>>>>>>> > published
>>>>>>> > > > in
>>>>>>> > > > central: this is now an issue, but we like that
>>>>>>> > > >
>>>>>>> > > > notice: the build pom can be injected in the artifact, in
>>>>>>> > META-INF/maven,
>>>>>>> > > > like
>>>>>>> > > > it is currently done
>>>>>>> > > > but I don't see the point in requiring it to be pbulished
>>>>>>> separately
>>>>>>> in
>>>>>>> > > > central: no other build tool does that, and they don't have any
>>>>>>> issue
>>>>>>> > with
>>>>>>> > > > that (and eventually it's a feature: don't publish internal
>>>>>>> details
>>>>>>> you
>>>>>>> > > > don't
>>>>>>> > > > really want people to see)
>>>>>>> > > >
>>>>>>> > > > Regards,
>>>>>>> > > >
>>>>>>> > > > Hervé
>>>>>>> > > >
>>>>>>> > > > > On Wed, Aug 24, 2016 at 1:52 PM, Stephen Connolly <
>>>>>>> > > > >
>>>>>>> > > > > stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>>>>>>> > > > > > On Tuesday 23 August 2016, Paul Benedict <
>>>>>>> pbenedict@apache.org
>>>>>>> <javascript:;>>
>>>>>>>
>>>>>>> > wrote:
>>>>>>> > > > > > > On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <
>>>>>>> > cs@schulte.it <javascript:;>
>>>>>>> > > > > > >
>>>>>>> > > > > > > <javascript:;>> wrote:
>>>>>>> > > > > > > > Am 08/24/16 um 00:08 schrieb Paul Benedict:
>>>>>>> > > > > > > > > POM and a future major version POM? I am hinting at a
>>>>>>> > strategy
>>>>>>> > > >
>>>>>>> > > > for
>>>>>>> > > >
>>>>>>> > > > > > > > forward
>>>>>>> > > > > > > >
>>>>>>> > > > > > > > > compatibility.
>>>>>>> > > > > > > >
>>>>>>> > > > > > > > Is forward compatibility really needed/required?
>>>>>>> > > > > > >
>>>>>>> > > > > > > I honestly don't know, which is why I am asking. An
>>>>>>> answer
>>>>>>> of
>>>>>>> "no
>>>>>>> > > > > > > compatibility" is possible, too.
>>>>>>> > > > > > >
>>>>>>> > > > > > > I can completely see the argument that says POMs must be
>>>>>>> > > > > > > all-parseable-or-nothing -- for the sake of
>>>>>>> reproducibility.
>>>>>>> I
>>>>>>> > > >
>>>>>>> > > > actually
>>>>>>> > > >
>>>>>>> > > > > > > prefer this answer. I think it is sensible to fail a
>>>>>>> build
>>>>>>> when
>>>>>>> > > > > > > encountering a POM version too advanced. If your client
>>>>>>> only
>>>>>>> > > >
>>>>>>> > > > supports up
>>>>>>> > > >
>>>>>>> > > > > > to
>>>>>>> > > > > >
>>>>>>> > > > > > > model 4.0.0, then all artifacts must be specified by
>>>>>>> 4.0.0
>>>>>>> > models,
>>>>>>> > > >
>>>>>>> > > > too.
>>>>>>> > > >
>>>>>>> > > > > > > On the other hand, I wanted to give the benefit of the
>>>>>>> doubt
>>>>>>> to
>>>>>>> > the
>>>>>>> > > > > > > opposite argument. At least one person spoke up and said
>>>>>>> it's
>>>>>>> > > > > >
>>>>>>> > > > > > unacceptable
>>>>>>> > > > > >
>>>>>>> > > > > > > to fail a build on configuration you don't understand.
>>>>>>> Well,
>>>>>>> > that's
>>>>>>> > > >
>>>>>>> > > > an
>>>>>>> > > >
>>>>>>> > > > > > > interesting argument, too. That person doesn't want to
>>>>>>> tank
>>>>>>> the
>>>>>>> > > > > > > build
>>>>>>> > > > > > > for
>>>>>>> > > > > > > the 1% of configuration that can't be understood.... but
>>>>>>> I
>>>>>>> fail
>>>>>>> > to
>>>>>>> > > >
>>>>>>> > > > see
>>>>>>> > > >
>>>>>>> > > > > > > an
>>>>>>> > > > > > > escape hatch here. If a client can't understand what's
>>>>>>> being
>>>>>>> > > >
>>>>>>> > > > specified,
>>>>>>> > > >
>>>>>>> > > > > > > then what else can be done but fail?
>>>>>>> > > > > >
>>>>>>> > > > > > Strip the dependencies a and let the user fix up manually
>>>>>>> (ideally
>>>>>>> > by
>>>>>>> > > > > > logging a warning that you are consuming a dependency
>>>>>>> using a
>>>>>>> newer
>>>>>>> > > > > > modelVersion)
>>>>>>> > > > > >
>>>>>>> > > > > > Everyone forgets that the 4.0.0 ship has sailed already, so
>>>>>>> we
>>>>>>> > have to
>>>>>>> > > > > > deploy best-effort 4.0.0 poms
>>>>>>> > > > > >
>>>>>>> > > > > > Now I say that 3.4 should not have a new modelVersion but
>>>>>>> what
>>>>>>> it
>>>>>>> > > >
>>>>>>> > > > could do
>>>>>>> > > >
>>>>>>> > > > > > is be more forgiving of newer modelVersions or try and
>>>>>>> download
>>>>>>> and
>>>>>>> > > >
>>>>>>> > > > use an
>>>>>>> > > >
>>>>>>> > > > > > XSLT to convert newer modelVersions to 4.0.0 (while
>>>>>>> logging a
>>>>>>> > warning)
>>>>>>> > > > > > with
>>>>>>> > > > > > option flags to allow failing the build if XSLT had to be
>>>>>>> applied
>>>>>>> > > > > >
>>>>>>> > > > > > So let's bump the modelVersion in Maven 5.0.0 (there is no
>>>>>>> Maven
>>>>>>> > 4.x
>>>>>>> > > >
>>>>>>> > > > let's
>>>>>>> > > >
>>>>>>> > > > > > align on the modelVersion)
>>>>>>> > > > > >
>>>>>>> > > > > > That should have separation between builder Pom and
>>>>>>> consumer
>>>>>>> Pom.
>>>>>>> > For
>>>>>>> > > > > > packaging=pom we deploy the builder Pom using
>>>>>>> classifier=build
>>>>>>> for
>>>>>>> > all
>>>>>>> > > > > > other packaging a we do not deploy the builder Pom.
>>>>>>> > > > > >
>>>>>>> > > > > > We deploy a *best effort* conversion of the consumer Pom to
>>>>>>> > > >
>>>>>>> > > > modelVersion
>>>>>>> > > >
>>>>>>> > > > > > 4.0.0 without a classifier and the consumer Pom gets
>>>>>>> deployed
>>>>>>> as
>>>>>>> > > > > > classifier
>>>>>>> > > > > > consumer.
>>>>>>> > > > > >
>>>>>>> > > > > > The consumer Pom format allows for XSLT to transform to a
>>>>>>> parsable
>>>>>>> > > >
>>>>>>> > > > syntax,
>>>>>>> > > >
>>>>>>> > > > > > if transform is required we log a warning (or fail the
>>>>>>> build
>>>>>>> if
>>>>>>> the
>>>>>>> > > > > > builder
>>>>>>> > > > > > Pom indicates strict modelVersion adherence)
>>>>>>> > > > > >
>>>>>>> > > > > > So yeah maven 5.x will be able to parse dependencies with
>>>>>>> > modelVersion
>>>>>>> > > >
>>>>>>> > > > 6.x
>>>>>>> > > >
>>>>>>> > > > > > while logging warnings that the user may not have the
>>>>>>> correct
>>>>>>> > > >
>>>>>>> > > > dependency
>>>>>>> > > >
>>>>>>> > > > > > tree. That is IMHO acceptable forward compatibility
>>>>>>> > > > > >
>>>>>>> > > > > > HTH
>>>>>>> > > > > >
>>>>>>> > > > > > -Stephen
>>>>>>> > > > > >
>>>>>>> > > > > > Ps I'm really hoping someone has a less crappy solution
>>>>>>> that
>>>>>>> > this...
>>>>>>> > > >
>>>>>>> > > > But I
>>>>>>> > > >
>>>>>>> > > > > > believe this is actually *a* solution... And prior to this
>>>>>>> I
>>>>>>> have
>>>>>>> > not
>>>>>>> > > >
>>>>>>> > > > seen
>>>>>>> > > >
>>>>>>> > > > > > any solution
>>>>>>> > > > > >
>>>>>>> > > > > > > Cheers,
>>>>>>> > > > > > > Paul
>>>>>>> > > > > >
>>>>>>> > > > > > --
>>>>>>> > > > > > Sent from my phone
>>>>>>> > > >
>>>>>>> > > > ------------------------------------------------------------
>>>>>>> ---------
>>>>>>> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> <javascript:;>
>>>>>>> > > > For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>> <javascript:;>
>>>>>>> >
>>>>>>> >
>>>>>>> > ------------------------------------------------------------
>>>>>>> ---------
>>>>>>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> <javascript:;>
>>>>>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>> <javascript:;>
>>>>>>> >
>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>>> ---------
>>>>>>
>>>>> 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: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Robert Scholte <rf...@apache.org>]

For both the flattened-pom and consumer-pom the idea is to remove build  
related information. Most of it is only used during build.
The question is: is there other information which should be added?
e.g. In case of JARs: the major version number of the class file format  
being used. Is it interesting to know this BEFORE downloading the jar? And  
if so, there should be a possibility to make choices based on that  
information. The choice-option doesn't exist and would make it all too  
complex.
I would say that it is indeed all about dependencies.

thanks,
Robert

On Thu, 25 Aug 2016 18:25:36 +0200, Paul Benedict <pb...@apache.org>  
wrote:

> The only (minor?) issue I have with the term "consumer POM" is that it
> implies one type of consumption. What is the kind of consumption we're
> addressing -- is it merely the GAV and dependencies?
>
> Cheers,
> Paul
>
> On Thu, Aug 25, 2016 at 3:34 AM, Robert Scholte <rf...@apache.org>
> wrote:
>
>> On Thu, 25 Aug 2016 01:10:36 +0200, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>>
>> On 24 August 2016 at 04:50, Robert Scholte <rf...@apache.org> wrote:
>>>
>>> I realized last ApacheCon that I wasn't clear about my definiton of the
>>>> consumer-pom.
>>>> I don't think it should be a flattened pom with only the dependency
>>>> information. Instead it shouldn't be a pom  (matching the pom.xsd) at
>>>> all.
>>>>
>>>>
>>> I am not in disagreement, but as a concept the name "consumer pom" has
>>> more
>>> traction.
>>>
>>
>> I'd prefer consumer pom too, but it has led to confusion due to the
>> assumption that consumer pom and flattened pom are the same thing. To  
>> me it
>> makes sense to consider a new fileformat for the consumer pom which  
>> matches
>> better the requirements. And yes, the "provides" would fit here.
>>
>>
>>
>>> I see the builder pom as probably ending up not even being XML at all.
>>> Rather IMHO it will end up being a DSL that is easy to author and not
>>> verbose... and certainly not XML
>>>
>>> So the consumer pom should be stripped back to include two sets of
>>> information:
>>>
>>> * dependencies - we are mostly familiar with this... though we may not
>>> expose all the scopes... depends on how we think about things and how  
>>> we
>>> view scopes moving forward
>>>
>>> * provides - this is vitally important IMHO and not handled currently.
>>>
>>> To understand provides we have to look at things like JavaEE (but the
>>> concept has general utility... though I suspect only for about 10-25%  
>>> of
>>> projects)
>>>
>>> If I have a project that says: provides javax.servlet:servlet-api:3.1  
>>> then
>>> that is saying that my project is providing the equivalent content as  
>>> in
>>> javax.servlet:servlet-api:3.1 so for example  
>>> org.jboss.spec.javax.servlet:
>>> jboss-servlet-api_3.1_spec:1.0.0.Final would say
>>> javax.servlet:servlet-api:3.1
>>>
>>> When resolving the dependency tree, maven then knows that any  
>>> transitive
>>> requirement for javax.servlet:servlet-api:3.1 has already been met by  
>>> my
>>> direct dependency on org.jboss.spec.javax.servlet:j
>>> boss-servlet-api_3.1_spec
>>> :1.0.0.Final if we have a direct dependency on
>>> org.apache.tomcat:tomcat-servlet-api:8.5.4 (which would also say
>>> javax.servlet:servlet-api:3.1) then Maven can report an error and fail  
>>> the
>>> build due to dependency conflict.
>>>
>>> There are lots of other improvements we can add, but to start we need  
>>> to
>>> have a way to declare when a project includes duplicate content of  
>>> another
>>> artifact. Convention will be required to make this work correctly...
>>> perhaps we can even introduce a new project type that provides needs to
>>> point at so that a provides has to point at an "empty" specification
>>> project...
>>>
>>> Finally, for the consumer pom refactoring I believe we need to address
>>> architecture specific artifacts as these are a sort of implicit  
>>> provides.
>>>
>>>
>>> Maybe it should be called something like consumer-dom (dependency  
>>> object
>>>> model, though dom is confusing...).
>>>> It should be the most fast and efficient way to resolve the dependency
>>>> tree. That means it should do less roundtrips like Maven must do do  
>>>> right
>>>> now: for every dependency download the pom, for all transitive
>>>> dependencies
>>>> download all poms, etc.
>>>> Why can't it be a pom? I'd like to add the (file)extension too.  
>>>> Otherwise
>>>> Maven needs to initialize the matching ArtifactHandler and translate  
>>>> the
>>>> type to the proper extension.
>>>>
>>>
>>>
>>> I think the consumer pom needs to embed some of the artifact handler
>>> information for it self as otherwise non-maven tooling cannot be  
>>> expected
>>> to understand those details... also we should be making the consumer  
>>> pom
>>> both Maven and Java agnostic... but this is a grand problem alright!
>>>
>>>
>>> The pom doesn't have room for this.
>>>>
>>>>
>>> I saw the whole flattened pom experiment as mostly a waste of time for  
>>> the
>>> consumer pom effort as I envision the consumer pom not looking anything
>>> like the current pom at all... but it is a project model...
>>>
>>> Oh and the consumer pom should include information for the  
>>> side-artifacts
>>> (which would help with reusing tests as we could attach the test
>>> dependencies to the test artifact details in the consumer pom)
>>>
>>> Consumer-dom is an extraction and enriched version of the pom and will  
>>> be
>>> a
>>>
>>>> separate upload to the repository. Build tools who can understand this
>>>> file
>>>> can use it or fall back by downloading all poms.
>>>>
>>>> thanks,
>>>> Robert
>>>>
>>>>
>>>> On Wed, 24 Aug 2016 09:22:03 +0200, Stephen Connolly <
>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>
>>>> The consumer Pom is for machine to machine, it should be human  
>>>> readable
>>>>
>>>>> because that is nice, but intent is never human generated.
>>>>>
>>>>> Switching to this separation allows us to be more radical in the  
>>>>> changes
>>>>> to
>>>>> the build Pom.
>>>>>
>>>>> The only reason we deploy packaging Pom's build Pom is for  
>>>>> inheritance.
>>>>> If
>>>>> we didn't have to deal with that we wouldn't need to deploy any build
>>>>> poms
>>>>> ever.
>>>>>
>>>>> For using a build Pom as a parent, you implicitly pick up the minimum
>>>>> version of maven that your parent requires, so we then are free to
>>>>> evolve
>>>>> the build Pom format without worrying about forward compatibility,  
>>>>> only
>>>>> backwards compatibility on the *build* Pom.
>>>>>
>>>>> The consumer Pom needs partial *forward* compatibility, so that older
>>>>> clients are able to *attempt* to consume...
>>>>>
>>>>> In short there are totally different compatibility constraints on the
>>>>> two,
>>>>> so they should be separate.
>>>>>
>>>>> Mixins would probably also be deployed, once we figure out how they  
>>>>> work
>>>>> with build poms.
>>>>>
>>>>> I think we probably need to rethink version ranges. What I'd like is  
>>>>> to
>>>>> let
>>>>> the consumer Pom treat version ranges more as guidance rather than  
>>>>> hard
>>>>> requirements. It's a pain if you depend transitiveky on Foo:[1.0] but
>>>>> need
>>>>> Foo:[1.0.1,1.1) for the critical security fix... Having to run around
>>>>> applying excludes is not a good plan... Yes the build should  
>>>>> initially
>>>>> fail
>>>>> if I depend on [1.0] and [1.0.1,1.1) in my graph, but I should be  
>>>>> able
>>>>> to
>>>>> resolve the conflict for all my consumers (unless they pull in the
>>>>> conflict
>>>>> again themselves)
>>>>>
>>>>> On Tuesday 23 August 2016, Fred Cooke <fr...@gmail.com> wrote:
>>>>>
>>>>> I still find it a bit off that the original real POM won't always be
>>>>>
>>>>>> directly available anymore.
>>>>>>
>>>>>> Other tools create fake POMs because they *have* to - there's no  
>>>>>> other
>>>>>> option.
>>>>>>
>>>>>> I feel like some fidelity would be lost. Diffability would be lost
>>>>>> (from
>>>>>> a
>>>>>> scenario where there's nothing to diff).
>>>>>>
>>>>>> Unrelated, really, but kind of related: top level deployable  
>>>>>> artefact
>>>>>> deployments, debs, wars, exes, etc. When ranges are in use it'd be  
>>>>>> nice
>>>>>> to
>>>>>> deploy a sort of strict effective pom with fully hard [] versions  
>>>>>> for
>>>>>> all
>>>>>> things. This can be achieved in other ways, though.
>>>>>>
>>>>>> I guess that is to say, don't forget about non-central deployments.  
>>>>>> I
>>>>>> suppose if there's a way to always deploy pom.xml.build through some
>>>>>> plugin
>>>>>> or configuration or some such, then that's fine with me.
>>>>>>
>>>>>> On Wed, Aug 24, 2016 at 6:49 PM, Hervé BOUTEMY  
>>>>>> <herve.boutemy@free.fr
>>>>>> <javascript:;>>
>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> > Le mercredi 24 août 2016 18:41:59 Fred Cooke a écrit :
>>>>>> > > Fair call re embedded pom, however it's quite convenient to just
>>>>>> browse
>>>>>> > to
>>>>>> > > it and read.
>>>>>> > >
>>>>>> > > I've occasionally gone looking for details from poms of  
>>>>>> artefacts
>>>>>> and
>>>>>> > found
>>>>>> > > a mess and missing stuff, and been annoyed. It probably wasn't
>>>>>> gradle's
>>>>>> > > fault, though. Just a sloppy author. If I'm honest I wouldn't  
>>>>>> even
>>>>>> know
>>>>>> > if
>>>>>> > > I've ever consumed a non-maven artefact, certainly none of mine!
>>>>>> :-)
>>>>>> > >
>>>>>> > > No, I am sure, I have, at least one, and it's an ant one with a
>>>>>> hard
>>>>>> > coded
>>>>>> > > POM that doesn't always reflect the contents of the jar. Yuck.
>>>>>> Clearly
>>>>>> > not
>>>>>> > > an issue with automated stuff, though.
>>>>>> > >
>>>>>> > > My only argument now is ease of reading things like project
>>>>>> descriptions,
>>>>>> > > contributors, SCM details, etc rather than having to unpack the
>>>>>> jar.
>>>>>> And
>>>>>> > if
>>>>>> > > you do, and end up with two pom.xmls laying around, that's not
>>>>>> nice.
>>>>>> > Better
>>>>>> > > to just start always suffixing one with pom.xml.build or some
>>>>>> such? I
>>>>>> > think
>>>>>> > > so, but I haven't thought deeply about it aside from reading  
>>>>>> this
>>>>>> thread.
>>>>>> > our consumer pom will be generated from build pom: we can automate
>>>>>> copy
>>>>>> of
>>>>>> > any
>>>>>> > information we want, and for sure, I expect to put at least
>>>>>> description,
>>>>>> > scm
>>>>>> > details, issueManagement, license (of course).
>>>>>> > In your list, there is only constributors that I was not counting  
>>>>>> on
>>>>>> it:
>>>>>> > but
>>>>>> > it's a detailed decision we'll have to make
>>>>>> >
>>>>>> > for sure, Maven consumer poms, since generated from Maven build  
>>>>>> pom,
>>>>>> can
>>>>>> > have
>>>>>> > much more details (and be sure they are accurrate) than build  
>>>>>> tools
>>>>>> that
>>>>>> > don't
>>>>>> > generate it from data that exists in their original build format
>>>>>> >
>>>>>> > Regards,
>>>>>> >
>>>>>> > Hervé
>>>>>> >
>>>>>> > >
>>>>>> > >
>>>>>> > >
>>>>>> > > On Wed, Aug 24, 2016 at 6:32 PM, Hervé BOUTEMY <
>>>>>> herve.boutemy@free.fr
>>>>>> <javascript:;>>
>>>>>>
>>>>>> > >
>>>>>> > > wrote:
>>>>>> > > > Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit :
>>>>>> > > > > That should have separation between builder Pom and consumer
>>>>>> Pom.
>>>>>> For
>>>>>> > > > > packaging=pom we deploy the builder Pom using  
>>>>>> classifier=build
>>>>>> > > > > *for all other packaging a we do not deploy the builder  
>>>>>> Pom*.
>>>>>> > > > >
>>>>>> > > > > I don't like the sound of this. The deployed artefacts  
>>>>>> should
>>>>>> include
>>>>>> > > > > the
>>>>>> > > > > exact POM in use to build the project, as a reference, even  
>>>>>> if
>>>>>> under
>>>>>> > a
>>>>>> > > > > different name. Yes, they should be in SCM, however down  
>>>>>> stream
>>>>>> it's
>>>>>> > > >
>>>>>> > > > useful
>>>>>> > > >
>>>>>> > > > > to see these even when the SCM is offline or gone or  
>>>>>> private or
>>>>>> > > > > whatever.
>>>>>> > > > > Or did I misunderstand? If so, please clarify?
>>>>>> > > >
>>>>>> > > > when you consume an artifact not build with Maven, do you get  
>>>>>> the
>>>>>> full
>>>>>> > > > build
>>>>>> > > > script?
>>>>>> > > > no
>>>>>> > > > I know that, as Maven users, we got used to have the build pom
>>>>>> > published
>>>>>> > > > in
>>>>>> > > > central: this is now an issue, but we like that
>>>>>> > > >
>>>>>> > > > notice: the build pom can be injected in the artifact, in
>>>>>> > META-INF/maven,
>>>>>> > > > like
>>>>>> > > > it is currently done
>>>>>> > > > but I don't see the point in requiring it to be pbulished
>>>>>> separately
>>>>>> in
>>>>>> > > > central: no other build tool does that, and they don't have  
>>>>>> any
>>>>>> issue
>>>>>> > with
>>>>>> > > > that (and eventually it's a feature: don't publish internal
>>>>>> details
>>>>>> you
>>>>>> > > > don't
>>>>>> > > > really want people to see)
>>>>>> > > >
>>>>>> > > > Regards,
>>>>>> > > >
>>>>>> > > > Hervé
>>>>>> > > >
>>>>>> > > > > On Wed, Aug 24, 2016 at 1:52 PM, Stephen Connolly <
>>>>>> > > > >
>>>>>> > > > > stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>>>>>> > > > > > On Tuesday 23 August 2016, Paul Benedict <
>>>>>> pbenedict@apache.org
>>>>>> <javascript:;>>
>>>>>>
>>>>>> > wrote:
>>>>>> > > > > > > On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <
>>>>>> > cs@schulte.it <javascript:;>
>>>>>> > > > > > >
>>>>>> > > > > > > <javascript:;>> wrote:
>>>>>> > > > > > > > Am 08/24/16 um 00:08 schrieb Paul Benedict:
>>>>>> > > > > > > > > POM and a future major version POM? I am hinting at  
>>>>>> a
>>>>>> > strategy
>>>>>> > > >
>>>>>> > > > for
>>>>>> > > >
>>>>>> > > > > > > > forward
>>>>>> > > > > > > >
>>>>>> > > > > > > > > compatibility.
>>>>>> > > > > > > >
>>>>>> > > > > > > > Is forward compatibility really needed/required?
>>>>>> > > > > > >
>>>>>> > > > > > > I honestly don't know, which is why I am asking. An  
>>>>>> answer
>>>>>> of
>>>>>> "no
>>>>>> > > > > > > compatibility" is possible, too.
>>>>>> > > > > > >
>>>>>> > > > > > > I can completely see the argument that says POMs must be
>>>>>> > > > > > > all-parseable-or-nothing -- for the sake of
>>>>>> reproducibility.
>>>>>> I
>>>>>> > > >
>>>>>> > > > actually
>>>>>> > > >
>>>>>> > > > > > > prefer this answer. I think it is sensible to fail a  
>>>>>> build
>>>>>> when
>>>>>> > > > > > > encountering a POM version too advanced. If your client
>>>>>> only
>>>>>> > > >
>>>>>> > > > supports up
>>>>>> > > >
>>>>>> > > > > > to
>>>>>> > > > > >
>>>>>> > > > > > > model 4.0.0, then all artifacts must be specified by  
>>>>>> 4.0.0
>>>>>> > models,
>>>>>> > > >
>>>>>> > > > too.
>>>>>> > > >
>>>>>> > > > > > > On the other hand, I wanted to give the benefit of the
>>>>>> doubt
>>>>>> to
>>>>>> > the
>>>>>> > > > > > > opposite argument. At least one person spoke up and said
>>>>>> it's
>>>>>> > > > > >
>>>>>> > > > > > unacceptable
>>>>>> > > > > >
>>>>>> > > > > > > to fail a build on configuration you don't understand.
>>>>>> Well,
>>>>>> > that's
>>>>>> > > >
>>>>>> > > > an
>>>>>> > > >
>>>>>> > > > > > > interesting argument, too. That person doesn't want to  
>>>>>> tank
>>>>>> the
>>>>>> > > > > > > build
>>>>>> > > > > > > for
>>>>>> > > > > > > the 1% of configuration that can't be understood....  
>>>>>> but I
>>>>>> fail
>>>>>> > to
>>>>>> > > >
>>>>>> > > > see
>>>>>> > > >
>>>>>> > > > > > > an
>>>>>> > > > > > > escape hatch here. If a client can't understand what's
>>>>>> being
>>>>>> > > >
>>>>>> > > > specified,
>>>>>> > > >
>>>>>> > > > > > > then what else can be done but fail?
>>>>>> > > > > >
>>>>>> > > > > > Strip the dependencies a and let the user fix up manually
>>>>>> (ideally
>>>>>> > by
>>>>>> > > > > > logging a warning that you are consuming a dependency  
>>>>>> using a
>>>>>> newer
>>>>>> > > > > > modelVersion)
>>>>>> > > > > >
>>>>>> > > > > > Everyone forgets that the 4.0.0 ship has sailed already,  
>>>>>> so
>>>>>> we
>>>>>> > have to
>>>>>> > > > > > deploy best-effort 4.0.0 poms
>>>>>> > > > > >
>>>>>> > > > > > Now I say that 3.4 should not have a new modelVersion but
>>>>>> what
>>>>>> it
>>>>>> > > >
>>>>>> > > > could do
>>>>>> > > >
>>>>>> > > > > > is be more forgiving of newer modelVersions or try and
>>>>>> download
>>>>>> and
>>>>>> > > >
>>>>>> > > > use an
>>>>>> > > >
>>>>>> > > > > > XSLT to convert newer modelVersions to 4.0.0 (while  
>>>>>> logging a
>>>>>> > warning)
>>>>>> > > > > > with
>>>>>> > > > > > option flags to allow failing the build if XSLT had to be
>>>>>> applied
>>>>>> > > > > >
>>>>>> > > > > > So let's bump the modelVersion in Maven 5.0.0 (there is no
>>>>>> Maven
>>>>>> > 4.x
>>>>>> > > >
>>>>>> > > > let's
>>>>>> > > >
>>>>>> > > > > > align on the modelVersion)
>>>>>> > > > > >
>>>>>> > > > > > That should have separation between builder Pom and  
>>>>>> consumer
>>>>>> Pom.
>>>>>> > For
>>>>>> > > > > > packaging=pom we deploy the builder Pom using
>>>>>> classifier=build
>>>>>> for
>>>>>> > all
>>>>>> > > > > > other packaging a we do not deploy the builder Pom.
>>>>>> > > > > >
>>>>>> > > > > > We deploy a *best effort* conversion of the consumer Pom  
>>>>>> to
>>>>>> > > >
>>>>>> > > > modelVersion
>>>>>> > > >
>>>>>> > > > > > 4.0.0 without a classifier and the consumer Pom gets  
>>>>>> deployed
>>>>>> as
>>>>>> > > > > > classifier
>>>>>> > > > > > consumer.
>>>>>> > > > > >
>>>>>> > > > > > The consumer Pom format allows for XSLT to transform to a
>>>>>> parsable
>>>>>> > > >
>>>>>> > > > syntax,
>>>>>> > > >
>>>>>> > > > > > if transform is required we log a warning (or fail the  
>>>>>> build
>>>>>> if
>>>>>> the
>>>>>> > > > > > builder
>>>>>> > > > > > Pom indicates strict modelVersion adherence)
>>>>>> > > > > >
>>>>>> > > > > > So yeah maven 5.x will be able to parse dependencies with
>>>>>> > modelVersion
>>>>>> > > >
>>>>>> > > > 6.x
>>>>>> > > >
>>>>>> > > > > > while logging warnings that the user may not have the  
>>>>>> correct
>>>>>> > > >
>>>>>> > > > dependency
>>>>>> > > >
>>>>>> > > > > > tree. That is IMHO acceptable forward compatibility
>>>>>> > > > > >
>>>>>> > > > > > HTH
>>>>>> > > > > >
>>>>>> > > > > > -Stephen
>>>>>> > > > > >
>>>>>> > > > > > Ps I'm really hoping someone has a less crappy solution  
>>>>>> that
>>>>>> > this...
>>>>>> > > >
>>>>>> > > > But I
>>>>>> > > >
>>>>>> > > > > > believe this is actually *a* solution... And prior to  
>>>>>> this I
>>>>>> have
>>>>>> > not
>>>>>> > > >
>>>>>> > > > seen
>>>>>> > > >
>>>>>> > > > > > any solution
>>>>>> > > > > >
>>>>>> > > > > > > Cheers,
>>>>>> > > > > > > Paul
>>>>>> > > > > >
>>>>>> > > > > > --
>>>>>> > > > > > Sent from my phone
>>>>>> > > >
>>>>>> > > > ------------------------------------------------------------
>>>>>> ---------
>>>>>> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> <javascript:;>
>>>>>> > > > For additional commands, e-mail: dev-help@maven.apache.org
>>>>>> <javascript:;>
>>>>>> >
>>>>>> >
>>>>>> > ------------------------------------------------------------
>>>>>> ---------
>>>>>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> <javascript:;>
>>>>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>>>>> <javascript:;>
>>>>>> >
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>> 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: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Paul Benedict <pb...@apache.org>]

The only (minor?) issue I have with the term "consumer POM" is that it
implies one type of consumption. What is the kind of consumption we're
addressing -- is it merely the GAV and dependencies?

Cheers,
Paul

On Thu, Aug 25, 2016 at 3:34 AM, Robert Scholte <rf...@apache.org>
wrote:

> On Thu, 25 Aug 2016 01:10:36 +0200, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> On 24 August 2016 at 04:50, Robert Scholte <rf...@apache.org> wrote:
>>
>> I realized last ApacheCon that I wasn't clear about my definiton of the
>>> consumer-pom.
>>> I don't think it should be a flattened pom with only the dependency
>>> information. Instead it shouldn't be a pom  (matching the pom.xsd) at
>>> all.
>>>
>>>
>> I am not in disagreement, but as a concept the name "consumer pom" has
>> more
>> traction.
>>
>
> I'd prefer consumer pom too, but it has led to confusion due to the
> assumption that consumer pom and flattened pom are the same thing. To me it
> makes sense to consider a new fileformat for the consumer pom which matches
> better the requirements. And yes, the "provides" would fit here.
>
>
>
>> I see the builder pom as probably ending up not even being XML at all.
>> Rather IMHO it will end up being a DSL that is easy to author and not
>> verbose... and certainly not XML
>>
>> So the consumer pom should be stripped back to include two sets of
>> information:
>>
>> * dependencies - we are mostly familiar with this... though we may not
>> expose all the scopes... depends on how we think about things and how we
>> view scopes moving forward
>>
>> * provides - this is vitally important IMHO and not handled currently.
>>
>> To understand provides we have to look at things like JavaEE (but the
>> concept has general utility... though I suspect only for about 10-25% of
>> projects)
>>
>> If I have a project that says: provides javax.servlet:servlet-api:3.1 then
>> that is saying that my project is providing the equivalent content as in
>> javax.servlet:servlet-api:3.1 so for example org.jboss.spec.javax.servlet:
>> jboss-servlet-api_3.1_spec:1.0.0.Final would say
>> javax.servlet:servlet-api:3.1
>>
>> When resolving the dependency tree, maven then knows that any transitive
>> requirement for javax.servlet:servlet-api:3.1 has already been met by my
>> direct dependency on org.jboss.spec.javax.servlet:j
>> boss-servlet-api_3.1_spec
>> :1.0.0.Final if we have a direct dependency on
>> org.apache.tomcat:tomcat-servlet-api:8.5.4 (which would also say
>> javax.servlet:servlet-api:3.1) then Maven can report an error and fail the
>> build due to dependency conflict.
>>
>> There are lots of other improvements we can add, but to start we need to
>> have a way to declare when a project includes duplicate content of another
>> artifact. Convention will be required to make this work correctly...
>> perhaps we can even introduce a new project type that provides needs to
>> point at so that a provides has to point at an "empty" specification
>> project...
>>
>> Finally, for the consumer pom refactoring I believe we need to address
>> architecture specific artifacts as these are a sort of implicit provides.
>>
>>
>> Maybe it should be called something like consumer-dom (dependency object
>>> model, though dom is confusing...).
>>> It should be the most fast and efficient way to resolve the dependency
>>> tree. That means it should do less roundtrips like Maven must do do right
>>> now: for every dependency download the pom, for all transitive
>>> dependencies
>>> download all poms, etc.
>>> Why can't it be a pom? I'd like to add the (file)extension too. Otherwise
>>> Maven needs to initialize the matching ArtifactHandler and translate the
>>> type to the proper extension.
>>>
>>
>>
>> I think the consumer pom needs to embed some of the artifact handler
>> information for it self as otherwise non-maven tooling cannot be expected
>> to understand those details... also we should be making the consumer pom
>> both Maven and Java agnostic... but this is a grand problem alright!
>>
>>
>> The pom doesn't have room for this.
>>>
>>>
>> I saw the whole flattened pom experiment as mostly a waste of time for the
>> consumer pom effort as I envision the consumer pom not looking anything
>> like the current pom at all... but it is a project model...
>>
>> Oh and the consumer pom should include information for the side-artifacts
>> (which would help with reusing tests as we could attach the test
>> dependencies to the test artifact details in the consumer pom)
>>
>> Consumer-dom is an extraction and enriched version of the pom and will be
>> a
>>
>>> separate upload to the repository. Build tools who can understand this
>>> file
>>> can use it or fall back by downloading all poms.
>>>
>>> thanks,
>>> Robert
>>>
>>>
>>> On Wed, 24 Aug 2016 09:22:03 +0200, Stephen Connolly <
>>> stephen.alan.connolly@gmail.com> wrote:
>>>
>>> The consumer Pom is for machine to machine, it should be human readable
>>>
>>>> because that is nice, but intent is never human generated.
>>>>
>>>> Switching to this separation allows us to be more radical in the changes
>>>> to
>>>> the build Pom.
>>>>
>>>> The only reason we deploy packaging Pom's build Pom is for inheritance.
>>>> If
>>>> we didn't have to deal with that we wouldn't need to deploy any build
>>>> poms
>>>> ever.
>>>>
>>>> For using a build Pom as a parent, you implicitly pick up the minimum
>>>> version of maven that your parent requires, so we then are free to
>>>> evolve
>>>> the build Pom format without worrying about forward compatibility, only
>>>> backwards compatibility on the *build* Pom.
>>>>
>>>> The consumer Pom needs partial *forward* compatibility, so that older
>>>> clients are able to *attempt* to consume...
>>>>
>>>> In short there are totally different compatibility constraints on the
>>>> two,
>>>> so they should be separate.
>>>>
>>>> Mixins would probably also be deployed, once we figure out how they work
>>>> with build poms.
>>>>
>>>> I think we probably need to rethink version ranges. What I'd like is to
>>>> let
>>>> the consumer Pom treat version ranges more as guidance rather than hard
>>>> requirements. It's a pain if you depend transitiveky on Foo:[1.0] but
>>>> need
>>>> Foo:[1.0.1,1.1) for the critical security fix... Having to run around
>>>> applying excludes is not a good plan... Yes the build should initially
>>>> fail
>>>> if I depend on [1.0] and [1.0.1,1.1) in my graph, but I should be able
>>>> to
>>>> resolve the conflict for all my consumers (unless they pull in the
>>>> conflict
>>>> again themselves)
>>>>
>>>> On Tuesday 23 August 2016, Fred Cooke <fr...@gmail.com> wrote:
>>>>
>>>> I still find it a bit off that the original real POM won't always be
>>>>
>>>>> directly available anymore.
>>>>>
>>>>> Other tools create fake POMs because they *have* to - there's no other
>>>>> option.
>>>>>
>>>>> I feel like some fidelity would be lost. Diffability would be lost
>>>>> (from
>>>>> a
>>>>> scenario where there's nothing to diff).
>>>>>
>>>>> Unrelated, really, but kind of related: top level deployable artefact
>>>>> deployments, debs, wars, exes, etc. When ranges are in use it'd be nice
>>>>> to
>>>>> deploy a sort of strict effective pom with fully hard [] versions for
>>>>> all
>>>>> things. This can be achieved in other ways, though.
>>>>>
>>>>> I guess that is to say, don't forget about non-central deployments. I
>>>>> suppose if there's a way to always deploy pom.xml.build through some
>>>>> plugin
>>>>> or configuration or some such, then that's fine with me.
>>>>>
>>>>> On Wed, Aug 24, 2016 at 6:49 PM, Hervé BOUTEMY <herve.boutemy@free.fr
>>>>> <javascript:;>>
>>>>>
>>>>> wrote:
>>>>>
>>>>> > Le mercredi 24 août 2016 18:41:59 Fred Cooke a écrit :
>>>>> > > Fair call re embedded pom, however it's quite convenient to just
>>>>> browse
>>>>> > to
>>>>> > > it and read.
>>>>> > >
>>>>> > > I've occasionally gone looking for details from poms of artefacts
>>>>> and
>>>>> > found
>>>>> > > a mess and missing stuff, and been annoyed. It probably wasn't
>>>>> gradle's
>>>>> > > fault, though. Just a sloppy author. If I'm honest I wouldn't even
>>>>> know
>>>>> > if
>>>>> > > I've ever consumed a non-maven artefact, certainly none of mine!
>>>>> :-)
>>>>> > >
>>>>> > > No, I am sure, I have, at least one, and it's an ant one with a
>>>>> hard
>>>>> > coded
>>>>> > > POM that doesn't always reflect the contents of the jar. Yuck.
>>>>> Clearly
>>>>> > not
>>>>> > > an issue with automated stuff, though.
>>>>> > >
>>>>> > > My only argument now is ease of reading things like project
>>>>> descriptions,
>>>>> > > contributors, SCM details, etc rather than having to unpack the
>>>>> jar.
>>>>> And
>>>>> > if
>>>>> > > you do, and end up with two pom.xmls laying around, that's not
>>>>> nice.
>>>>> > Better
>>>>> > > to just start always suffixing one with pom.xml.build or some
>>>>> such? I
>>>>> > think
>>>>> > > so, but I haven't thought deeply about it aside from reading this
>>>>> thread.
>>>>> > our consumer pom will be generated from build pom: we can automate
>>>>> copy
>>>>> of
>>>>> > any
>>>>> > information we want, and for sure, I expect to put at least
>>>>> description,
>>>>> > scm
>>>>> > details, issueManagement, license (of course).
>>>>> > In your list, there is only constributors that I was not counting on
>>>>> it:
>>>>> > but
>>>>> > it's a detailed decision we'll have to make
>>>>> >
>>>>> > for sure, Maven consumer poms, since generated from Maven build pom,
>>>>> can
>>>>> > have
>>>>> > much more details (and be sure they are accurrate) than build tools
>>>>> that
>>>>> > don't
>>>>> > generate it from data that exists in their original build format
>>>>> >
>>>>> > Regards,
>>>>> >
>>>>> > Hervé
>>>>> >
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > > On Wed, Aug 24, 2016 at 6:32 PM, Hervé BOUTEMY <
>>>>> herve.boutemy@free.fr
>>>>> <javascript:;>>
>>>>>
>>>>> > >
>>>>> > > wrote:
>>>>> > > > Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit :
>>>>> > > > > That should have separation between builder Pom and consumer
>>>>> Pom.
>>>>> For
>>>>> > > > > packaging=pom we deploy the builder Pom using classifier=build
>>>>> > > > > *for all other packaging a we do not deploy the builder Pom*.
>>>>> > > > >
>>>>> > > > > I don't like the sound of this. The deployed artefacts should
>>>>> include
>>>>> > > > > the
>>>>> > > > > exact POM in use to build the project, as a reference, even if
>>>>> under
>>>>> > a
>>>>> > > > > different name. Yes, they should be in SCM, however down stream
>>>>> it's
>>>>> > > >
>>>>> > > > useful
>>>>> > > >
>>>>> > > > > to see these even when the SCM is offline or gone or private or
>>>>> > > > > whatever.
>>>>> > > > > Or did I misunderstand? If so, please clarify?
>>>>> > > >
>>>>> > > > when you consume an artifact not build with Maven, do you get the
>>>>> full
>>>>> > > > build
>>>>> > > > script?
>>>>> > > > no
>>>>> > > > I know that, as Maven users, we got used to have the build pom
>>>>> > published
>>>>> > > > in
>>>>> > > > central: this is now an issue, but we like that
>>>>> > > >
>>>>> > > > notice: the build pom can be injected in the artifact, in
>>>>> > META-INF/maven,
>>>>> > > > like
>>>>> > > > it is currently done
>>>>> > > > but I don't see the point in requiring it to be pbulished
>>>>> separately
>>>>> in
>>>>> > > > central: no other build tool does that, and they don't have any
>>>>> issue
>>>>> > with
>>>>> > > > that (and eventually it's a feature: don't publish internal
>>>>> details
>>>>> you
>>>>> > > > don't
>>>>> > > > really want people to see)
>>>>> > > >
>>>>> > > > Regards,
>>>>> > > >
>>>>> > > > Hervé
>>>>> > > >
>>>>> > > > > On Wed, Aug 24, 2016 at 1:52 PM, Stephen Connolly <
>>>>> > > > >
>>>>> > > > > stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>>>>> > > > > > On Tuesday 23 August 2016, Paul Benedict <
>>>>> pbenedict@apache.org
>>>>> <javascript:;>>
>>>>>
>>>>> > wrote:
>>>>> > > > > > > On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <
>>>>> > cs@schulte.it <javascript:;>
>>>>> > > > > > >
>>>>> > > > > > > <javascript:;>> wrote:
>>>>> > > > > > > > Am 08/24/16 um 00:08 schrieb Paul Benedict:
>>>>> > > > > > > > > POM and a future major version POM? I am hinting at a
>>>>> > strategy
>>>>> > > >
>>>>> > > > for
>>>>> > > >
>>>>> > > > > > > > forward
>>>>> > > > > > > >
>>>>> > > > > > > > > compatibility.
>>>>> > > > > > > >
>>>>> > > > > > > > Is forward compatibility really needed/required?
>>>>> > > > > > >
>>>>> > > > > > > I honestly don't know, which is why I am asking. An answer
>>>>> of
>>>>> "no
>>>>> > > > > > > compatibility" is possible, too.
>>>>> > > > > > >
>>>>> > > > > > > I can completely see the argument that says POMs must be
>>>>> > > > > > > all-parseable-or-nothing -- for the sake of
>>>>> reproducibility.
>>>>> I
>>>>> > > >
>>>>> > > > actually
>>>>> > > >
>>>>> > > > > > > prefer this answer. I think it is sensible to fail a build
>>>>> when
>>>>> > > > > > > encountering a POM version too advanced. If your client
>>>>> only
>>>>> > > >
>>>>> > > > supports up
>>>>> > > >
>>>>> > > > > > to
>>>>> > > > > >
>>>>> > > > > > > model 4.0.0, then all artifacts must be specified by 4.0.0
>>>>> > models,
>>>>> > > >
>>>>> > > > too.
>>>>> > > >
>>>>> > > > > > > On the other hand, I wanted to give the benefit of the
>>>>> doubt
>>>>> to
>>>>> > the
>>>>> > > > > > > opposite argument. At least one person spoke up and said
>>>>> it's
>>>>> > > > > >
>>>>> > > > > > unacceptable
>>>>> > > > > >
>>>>> > > > > > > to fail a build on configuration you don't understand.
>>>>> Well,
>>>>> > that's
>>>>> > > >
>>>>> > > > an
>>>>> > > >
>>>>> > > > > > > interesting argument, too. That person doesn't want to tank
>>>>> the
>>>>> > > > > > > build
>>>>> > > > > > > for
>>>>> > > > > > > the 1% of configuration that can't be understood.... but I
>>>>> fail
>>>>> > to
>>>>> > > >
>>>>> > > > see
>>>>> > > >
>>>>> > > > > > > an
>>>>> > > > > > > escape hatch here. If a client can't understand what's
>>>>> being
>>>>> > > >
>>>>> > > > specified,
>>>>> > > >
>>>>> > > > > > > then what else can be done but fail?
>>>>> > > > > >
>>>>> > > > > > Strip the dependencies a and let the user fix up manually
>>>>> (ideally
>>>>> > by
>>>>> > > > > > logging a warning that you are consuming a dependency using a
>>>>> newer
>>>>> > > > > > modelVersion)
>>>>> > > > > >
>>>>> > > > > > Everyone forgets that the 4.0.0 ship has sailed already, so
>>>>> we
>>>>> > have to
>>>>> > > > > > deploy best-effort 4.0.0 poms
>>>>> > > > > >
>>>>> > > > > > Now I say that 3.4 should not have a new modelVersion but
>>>>> what
>>>>> it
>>>>> > > >
>>>>> > > > could do
>>>>> > > >
>>>>> > > > > > is be more forgiving of newer modelVersions or try and
>>>>> download
>>>>> and
>>>>> > > >
>>>>> > > > use an
>>>>> > > >
>>>>> > > > > > XSLT to convert newer modelVersions to 4.0.0 (while logging a
>>>>> > warning)
>>>>> > > > > > with
>>>>> > > > > > option flags to allow failing the build if XSLT had to be
>>>>> applied
>>>>> > > > > >
>>>>> > > > > > So let's bump the modelVersion in Maven 5.0.0 (there is no
>>>>> Maven
>>>>> > 4.x
>>>>> > > >
>>>>> > > > let's
>>>>> > > >
>>>>> > > > > > align on the modelVersion)
>>>>> > > > > >
>>>>> > > > > > That should have separation between builder Pom and consumer
>>>>> Pom.
>>>>> > For
>>>>> > > > > > packaging=pom we deploy the builder Pom using
>>>>> classifier=build
>>>>> for
>>>>> > all
>>>>> > > > > > other packaging a we do not deploy the builder Pom.
>>>>> > > > > >
>>>>> > > > > > We deploy a *best effort* conversion of the consumer Pom to
>>>>> > > >
>>>>> > > > modelVersion
>>>>> > > >
>>>>> > > > > > 4.0.0 without a classifier and the consumer Pom gets deployed
>>>>> as
>>>>> > > > > > classifier
>>>>> > > > > > consumer.
>>>>> > > > > >
>>>>> > > > > > The consumer Pom format allows for XSLT to transform to a
>>>>> parsable
>>>>> > > >
>>>>> > > > syntax,
>>>>> > > >
>>>>> > > > > > if transform is required we log a warning (or fail the build
>>>>> if
>>>>> the
>>>>> > > > > > builder
>>>>> > > > > > Pom indicates strict modelVersion adherence)
>>>>> > > > > >
>>>>> > > > > > So yeah maven 5.x will be able to parse dependencies with
>>>>> > modelVersion
>>>>> > > >
>>>>> > > > 6.x
>>>>> > > >
>>>>> > > > > > while logging warnings that the user may not have the correct
>>>>> > > >
>>>>> > > > dependency
>>>>> > > >
>>>>> > > > > > tree. That is IMHO acceptable forward compatibility
>>>>> > > > > >
>>>>> > > > > > HTH
>>>>> > > > > >
>>>>> > > > > > -Stephen
>>>>> > > > > >
>>>>> > > > > > Ps I'm really hoping someone has a less crappy solution that
>>>>> > this...
>>>>> > > >
>>>>> > > > But I
>>>>> > > >
>>>>> > > > > > believe this is actually *a* solution... And prior to this I
>>>>> have
>>>>> > not
>>>>> > > >
>>>>> > > > seen
>>>>> > > >
>>>>> > > > > > any solution
>>>>> > > > > >
>>>>> > > > > > > Cheers,
>>>>> > > > > > > Paul
>>>>> > > > > >
>>>>> > > > > > --
>>>>> > > > > > Sent from my phone
>>>>> > > >
>>>>> > > > ------------------------------------------------------------
>>>>> ---------
>>>>> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> <javascript:;>
>>>>> > > > For additional commands, e-mail: dev-help@maven.apache.org
>>>>> <javascript:;>
>>>>> >
>>>>> >
>>>>> > ------------------------------------------------------------
>>>>> ---------
>>>>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> <javascript:;>
>>>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>>>> <javascript:;>
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>> 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: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Robert Scholte <rf...@apache.org>]

We should probably add repository info too.
Right now dependencies are searched in every repository if it is not  
found. Not very efficient if you now where it should look.
I still like this related  
article:"http://blog.sonatype.com/2012/02/public-service-announcement-your-build-is-leaking-and-how-to-stop-it/

Robert

On Thu, 25 Aug 2016 20:10:52 +0200, Stephen Connolly  
<st...@gmail.com> wrote:

> So content:
>
> * list/tree of dependencies
> * list/tree of provides
> * list/tree of requires
> * repeat same for side artifacts
>
> For a jar the "requires" will basically be "java:runtime:9.0" to indicate
> that it was compiled with -target 9.0
>
> For say a .net DLL the requires may be more complex
>
> For say a .rpm the requires may be "org.kernel.linux:centos:6.0" and
> "com.intel.cpu:x86_64:1.0" to indicate that this rpm is centos x86_64...
> But such an rpm would need to be deployed with an architecture specified
> (I'm still thinking my way through how architecture specification should
> work)
>
> I think we should include some locating information, eg url, name,
> description
>
> License information should be normalised using the SPDX format spec:
> http://spdx.org/licenses/
>
> The license may vary for side artifacts, as would basically everything,  
> but
> we should be able to inherit from the primary artifact
>
> Whether to include scm or repository info is an open question
>
> On Thursday 25 August 2016, Robert Scholte <rf...@apache.org> wrote:
>
>> On Thu, 25 Aug 2016 18:30:50 +0200, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>>
>> On Thursday 25 August 2016, Robert Scholte <rf...@apache.org> wrote:
>>>
>>> On Thu, 25 Aug 2016 01:10:36 +0200, Stephen Connolly <
>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>
>>>> On 24 August 2016 at 04:50, Robert Scholte <rf...@apache.org>  
>>>> wrote:
>>>>
>>>>>
>>>>> I realized last ApacheCon that I wasn't clear about my definiton of  
>>>>> the
>>>>>
>>>>>> consumer-pom.
>>>>>> I don't think it should be a flattened pom with only the dependency
>>>>>> information. Instead it shouldn't be a pom  (matching the pom.xsd)  
>>>>>> at
>>>>>> all.
>>>>>>
>>>>>>
>>>>>> I am not in disagreement, but as a concept the name "consumer pom"  
>>>>>> has
>>>>> more
>>>>> traction.
>>>>>
>>>>>
>>>> I'd prefer consumer pom too, but it has led to confusion due to the
>>>> assumption that consumer pom and flattened pom are the same thing. To  
>>>> me
>>>> it
>>>> makes sense to consider a new fileformat for the consumer pom which
>>>> matches
>>>> better the requirements. And yes, the "provides" would fit here.
>>>>
>>>
>>>
>>> New format or new schema?
>>>
>>> If we accept this is machine generated then we can use a format that  
>>> does
>>> not support comments (eg JSON) but it's hard to beat XSLT for a cross
>>> platform schema migration tool... So XSLT would mandate XML (with all  
>>> the
>>> irrational hate people have for that - I say irrational as the people
>>> laying the hate usually love writing HTML ;-) )
>>>
>>>
>> Yes, it will be generated, so I wonder if there will be any comment. But
>> yes, if we want to keep the option to transform the file with XSLT, XML
>> seems to be the best choice. Most important for me is that this file is
>> doesn't have to be a pom-model 4.0.0 file.
>> We probably need to specify the content first before making a choice of
>> the format.
>>
>>
>>>>
>>>> I see the builder pom as probably ending up not even being XML at all.
>>>>> Rather IMHO it will end up being a DSL that is easy to author and not
>>>>> verbose... and certainly not XML
>>>>>
>>>>> So the consumer pom should be stripped back to include two sets of
>>>>> information:
>>>>>
>>>>> * dependencies - we are mostly familiar with this... though we may  
>>>>> not
>>>>> expose all the scopes... depends on how we think about things and  
>>>>> how we
>>>>> view scopes moving forward
>>>>>
>>>>> * provides - this is vitally important IMHO and not handled  
>>>>> currently.
>>>>>
>>>>> To understand provides we have to look at things like JavaEE (but the
>>>>> concept has general utility... though I suspect only for about  
>>>>> 10-25% of
>>>>> projects)
>>>>>
>>>>> If I have a project that says: provides javax.servlet:servlet-api:3.1
>>>>> then
>>>>> that is saying that my project is providing the equivalent content  
>>>>> as in
>>>>> javax.servlet:servlet-api:3.1 so for example
>>>>> org.jboss.spec.javax.servlet:
>>>>> jboss-servlet-api_3.1_spec:1.0.0.Final would say
>>>>> javax.servlet:servlet-api:3.1
>>>>>
>>>>> When resolving the dependency tree, maven then knows that any  
>>>>> transitive
>>>>> requirement for javax.servlet:servlet-api:3.1 has already been met  
>>>>> by my
>>>>> direct dependency on org.jboss.spec.javax.servlet:j
>>>>> boss-servlet-api_3.1_spec
>>>>> :1.0.0.Final if we have a direct dependency on
>>>>> org.apache.tomcat:tomcat-servlet-api:8.5.4 (which would also say
>>>>> javax.servlet:servlet-api:3.1) then Maven can report an error and  
>>>>> fail
>>>>> the
>>>>> build due to dependency conflict.
>>>>>
>>>>> There are lots of other improvements we can add, but to start we  
>>>>> need to
>>>>> have a way to declare when a project includes duplicate content of
>>>>> another
>>>>> artifact. Convention will be required to make this work correctly...
>>>>> perhaps we can even introduce a new project type that provides needs  
>>>>> to
>>>>> point at so that a provides has to point at an "empty" specification
>>>>> project...
>>>>>
>>>>> Finally, for the consumer pom refactoring I believe we need to  
>>>>> address
>>>>> architecture specific artifacts as these are a sort of implicit
>>>>> provides.
>>>>>
>>>>>
>>>>> Maybe it should be called something like consumer-dom (dependency  
>>>>> object
>>>>>
>>>>>> model, though dom is confusing...).
>>>>>> It should be the most fast and efficient way to resolve the  
>>>>>> dependency
>>>>>> tree. That means it should do less roundtrips like Maven must do do
>>>>>> right
>>>>>> now: for every dependency download the pom, for all transitive
>>>>>> dependencies
>>>>>> download all poms, etc.
>>>>>> Why can't it be a pom? I'd like to add the (file)extension too.
>>>>>> Otherwise
>>>>>> Maven needs to initialize the matching ArtifactHandler and translate
>>>>>> the
>>>>>> type to the proper extension.
>>>>>>
>>>>>>
>>>>>
>>>>> I think the consumer pom needs to embed some of the artifact handler
>>>>> information for it self as otherwise non-maven tooling cannot be
>>>>> expected
>>>>> to understand those details... also we should be making the consumer  
>>>>> pom
>>>>> both Maven and Java agnostic... but this is a grand problem alright!
>>>>>
>>>>>
>>>>> The pom doesn't have room for this.
>>>>>
>>>>>>
>>>>>>
>>>>>> I saw the whole flattened pom experiment as mostly a waste of time  
>>>>>> for
>>>>> the
>>>>> consumer pom effort as I envision the consumer pom not looking  
>>>>> anything
>>>>> like the current pom at all... but it is a project model...
>>>>>
>>>>> Oh and the consumer pom should include information for the
>>>>> side-artifacts
>>>>> (which would help with reusing tests as we could attach the test
>>>>> dependencies to the test artifact details in the consumer pom)
>>>>>
>>>>> Consumer-dom is an extraction and enriched version of the pom and  
>>>>> will
>>>>> be
>>>>> a
>>>>>
>>>>> separate upload to the repository. Build tools who can understand  
>>>>> this
>>>>>> file
>>>>>> can use it or fall back by downloading all poms.
>>>>>>
>>>>>> thanks,
>>>>>> Robert
>>>>>>
>>>>>>
>>>>>> On Wed, 24 Aug 2016 09:22:03 +0200, Stephen Connolly <
>>>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>>>
>>>>>> The consumer Pom is for machine to machine, it should be human  
>>>>>> readable
>>>>>>
>>>>>> because that is nice, but intent is never human generated.
>>>>>>>
>>>>>>> Switching to this separation allows us to be more radical in the
>>>>>>> changes
>>>>>>> to
>>>>>>> the build Pom.
>>>>>>>
>>>>>>> The only reason we deploy packaging Pom's build Pom is for
>>>>>>> inheritance.
>>>>>>> If
>>>>>>> we didn't have to deal with that we wouldn't need to deploy any  
>>>>>>> build
>>>>>>> poms
>>>>>>> ever.
>>>>>>>
>>>>>>> For using a build Pom as a parent, you implicitly pick up the  
>>>>>>> minimum
>>>>>>> version of maven that your parent requires, so we then are free to
>>>>>>> evolve
>>>>>>> the build Pom format without worrying about forward compatibility,
>>>>>>> only
>>>>>>> backwards compatibility on the *build* Pom.
>>>>>>>
>>>>>>> The consumer Pom needs partial *forward* compatibility, so that  
>>>>>>> older
>>>>>>> clients are able to *attempt* to consume...
>>>>>>>
>>>>>>> In short there are totally different compatibility constraints on  
>>>>>>> the
>>>>>>> two,
>>>>>>> so they should be separate.
>>>>>>>
>>>>>>> Mixins would probably also be deployed, once we figure out how they
>>>>>>> work
>>>>>>> with build poms.
>>>>>>>
>>>>>>> I think we probably need to rethink version ranges. What I'd like  
>>>>>>> is
>>>>>>> to
>>>>>>> let
>>>>>>> the consumer Pom treat version ranges more as guidance rather than
>>>>>>> hard
>>>>>>> requirements. It's a pain if you depend transitiveky on Foo:[1.0]  
>>>>>>> but
>>>>>>> need
>>>>>>> Foo:[1.0.1,1.1) for the critical security fix... Having to run  
>>>>>>> around
>>>>>>> applying excludes is not a good plan... Yes the build should  
>>>>>>> initially
>>>>>>> fail
>>>>>>> if I depend on [1.0] and [1.0.1,1.1) in my graph, but I should be  
>>>>>>> able
>>>>>>> to
>>>>>>> resolve the conflict for all my consumers (unless they pull in the
>>>>>>> conflict
>>>>>>> again themselves)
>>>>>>>
>>>>>>> On Tuesday 23 August 2016, Fred Cooke <fr...@gmail.com> wrote:
>>>>>>>
>>>>>>> I still find it a bit off that the original real POM won't always  
>>>>>>> be
>>>>>>>
>>>>>>> directly available anymore.
>>>>>>>>
>>>>>>>> Other tools create fake POMs because they *have* to - there's no
>>>>>>>> other
>>>>>>>> option.
>>>>>>>>
>>>>>>>> I feel like some fidelity would be lost. Diffability would be lost
>>>>>>>> (from
>>>>>>>> a
>>>>>>>> scenario where there's nothing to diff).
>>>>>>>>
>>>>>>>> Unrelated, really, but kind of related: top level deployable  
>>>>>>>> artefact
>>>>>>>> deployments, debs, wars, exes, etc. When ranges are in use it'd be
>>>>>>>> nice
>>>>>>>> to
>>>>>>>> deploy a sort of strict effective pom with fully hard [] versions  
>>>>>>>> for
>>>>>>>> all
>>>>>>>> things. This can be achieved in other ways, though.
>>>>>>>>
>>>>>>>> I guess that is to say, don't forget about non-central  
>>>>>>>> deployments. I
>>>>>>>> suppose if there's a way to always deploy pom.xml.build through  
>>>>>>>> some
>>>>>>>> plugin
>>>>>>>> or configuration or some such, then that's fine with me.
>>>>>>>>
>>>>>>>> On Wed, Aug 24, 2016 at 6:49 PM, Hervé BOUTEMY <
>>>>>>>> herve.boutemy@free.fr
>>>>>>>> <javascript:;>>
>>>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> > Le mercredi 24 août 2016 18:41:59 Fred Cooke a écrit :
>>>>>>>> > > Fair call re embedded pom, however it's quite convenient to  
>>>>>>>> just
>>>>>>>> browse
>>>>>>>> > to
>>>>>>>> > > it and read.
>>>>>>>> > >
>>>>>>>> > > I've occasionally gone looking for details from poms of  
>>>>>>>> artefacts
>>>>>>>> and
>>>>>>>> > found
>>>>>>>> > > a mess and missing stuff, and been annoyed. It probably wasn't
>>>>>>>> gradle's
>>>>>>>> > > fault, though. Just a sloppy author. If I'm honest I wouldn't
>>>>>>>> even
>>>>>>>> know
>>>>>>>> > if
>>>>>>>> > > I've ever consumed a non-maven artefact, certainly none of  
>>>>>>>> mine!
>>>>>>>> :-)
>>>>>>>> > >
>>>>>>>> > > No, I am sure, I have, at least one, and it's an ant one with  
>>>>>>>> a
>>>>>>>> hard
>>>>>>>> > coded
>>>>>>>> > > POM that doesn't always reflect the contents of the jar. Yuck.
>>>>>>>> Clearly
>>>>>>>> > not
>>>>>>>> > > an issue with automated stuff, though.
>>>>>>>> > >
>>>>>>>> > > My only argument now is ease of reading things like project
>>>>>>>> descriptions,
>>>>>>>> > > contributors, SCM details, etc rather than having to unpack  
>>>>>>>> the
>>>>>>>> jar.
>>>>>>>> And
>>>>>>>> > if
>>>>>>>> > > you do, and end up with two pom.xmls laying around, that's not
>>>>>>>> nice.
>>>>>>>> > Better
>>>>>>>> > > to just start always suffixing one with pom.xml.build or some
>>>>>>>> such? I
>>>>>>>> > think
>>>>>>>> > > so, but I haven't thought deeply about it aside from reading  
>>>>>>>> this
>>>>>>>> thread.
>>>>>>>> > our consumer pom will be generated from build pom: we can  
>>>>>>>> automate
>>>>>>>> copy
>>>>>>>> of
>>>>>>>> > any
>>>>>>>> > information we want, and for sure, I expect to put at least
>>>>>>>> description,
>>>>>>>> > scm
>>>>>>>> > details, issueManagement, license (of course).
>>>>>>>> > In your list, there is only constributors that I was not  
>>>>>>>> counting
>>>>>>>> on
>>>>>>>> it:
>>>>>>>> > but
>>>>>>>> > it's a detailed decision we'll have to make
>>>>>>>> >
>>>>>>>> > for sure, Maven consumer poms, since generated from Maven build
>>>>>>>> pom,
>>>>>>>> can
>>>>>>>> > have
>>>>>>>> > much more details (and be sure they are accurrate) than build  
>>>>>>>> tools
>>>>>>>> that
>>>>>>>> > don't
>>>>>>>> > generate it from data that exists in their original build format
>>>>>>>> >
>>>>>>>> > Regards,
>>>>>>>> >
>>>>>>>> > Hervé
>>>>>>>> >
>>>>>>>> > >
>>>>>>>> > >
>>>>>>>> > >
>>>>>>>> > > On Wed, Aug 24, 2016 at 6:32 PM, Hervé BOUTEMY <
>>>>>>>> herve.boutemy@free.fr
>>>>>>>> <javascript:;>>
>>>>>>>>
>>>>>>>> > >
>>>>>>>> > > wrote:
>>>>>>>> > > > Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit :
>>>>>>>> > > > > That should have separation between builder Pom and  
>>>>>>>> consumer
>>>>>>>> Pom.
>>>>>>>> For
>>>>>>>> > > > > packaging=pom we deploy the builder Pom using
>>>>>>>> classifier=build
>>>>>>>> > > > > *for all other packaging a we do not deploy the builder  
>>>>>>>> Pom*.
>>>>>>>> > > > >
>>>>>>>> > > > > I don't like the sound of this. The deployed artefacts  
>>>>>>>> should
>>>>>>>> include
>>>>>>>> > > > > the
>>>>>>>> > > > > exact POM in use to build the project, as a reference,  
>>>>>>>> even
>>>>>>>> if
>>>>>>>> under
>>>>>>>> > a
>>>>>>>> > > > > different name. Yes, they should be in SCM, however down
>>>>>>>> stream
>>>>>>>> it's
>>>>>>>> > > >
>>>>>>>> > > > useful
>>>>>>>> > > >
>>>>>>>> > > > > to see these even when the SCM is offline or gone or  
>>>>>>>> private
>>>>>>>> or
>>>>>>>> > > > > whatever.
>>>>>>>> > > > > Or did I misunderstand? If so, please clarify?
>>>>>>>> > > >
>>>>>>>> > > > when you consume an artifact not build with Maven, do you  
>>>>>>>> get
>>>>>>>> the
>>>>>>>> full
>>>>>>>> > > > build
>>>>>>>> > > > script?
>>>>>>>> > > > no
>>>>>>>> > > > I know that, as Maven users, we got used to have the build  
>>>>>>>> pom
>>>>>>>> > published
>>>>>>>> > > > in
>>>>>>>> > > > central: this is now an issue, but we like that
>>>>>>>> > > >
>>>>>>>> > > > notice: the build pom can be injected in the artifact, in
>>>>>>>> > META-INF/maven,
>>>>>>>> > > > like
>>>>>>>> > > > it is currently done
>>>>>>>> > > > but I don't see the point in requiring it to be pbulished
>>>>>>>> separately
>>>>>>>> in
>>>>>>>> > > > central: no other build tool does that, and they don't have  
>>>>>>>> any
>>>>>>>> issue
>>>>>>>> > with
>>>>>>>> > > > that (and eventually it's a feature: don't publish internal
>>>>>>>> details
>>>>>>>> you
>>>>>>>> > > > don't
>>>>>>>> > > > really want people to see)
>>>>>>>> > > >
>>>>>>>> > > > Regards,
>>>>>>>> > > >
>>>>>>>> > > > Hervé
>>>>>>>> > > >
>>>>>>>> > > > > On Wed, Aug 24, 2016 at 1:52 PM, Stephen Connolly <
>>>>>>>> > > > >
>>>>>>>> > > > > stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>>>>>>>> > > > > > On Tuesday 23 August 2016, Paul Benedict <
>>>>>>>> pbenedict@apache.org
>>>>>>>> <javascript:;>>
>>>>>>>>
>>>>>>>> > wrote:
>>>>>>>> > > > > > > On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <
>>>>>>>> > cs@schulte.it <javascript:;>
>>>>>>>> > > > > > >
>>>>>>>> > > > > > > <javascript:;>> wrote:
>>>>>>>> > > > > > > > Am 08/24/16 um 00:08 schrieb Paul Benedict:
>>>>>>>> > > > > > > > > POM and a future major version POM? I am hinting  
>>>>>>>> at a
>>>>>>>> > strategy
>>>>>>>> > > >
>>>>>>>> > > > for
>>>>>>>> > > >
>>>>>>>> > > > > > > > forward
>>>>>>>> > > > > > > >
>>>>>>>> > > > > > > > > compatibility.
>>>>>>>> > > > > > > >
>>>>>>>> > > > > > > > Is forward compatibility really needed/required?
>>>>>>>> > > > > > >
>>>>>>>> > > > > > > I honestly don't know, which is why I am asking. An
>>>>>>>> answer
>>>>>>>> of
>>>>>>>> "no
>>>>>>>> > > > > > > compatibility" is possible, too.
>>>>>>>> > > > > > >
>>>>>>>> > > > > > > I can completely see the argument that says POMs must  
>>>>>>>> be
>>>>>>>> > > > > > > all-parseable-or-nothing -- for the sake of
>>>>>>>> reproducibility.
>>>>>>>> I
>>>>>>>> > > >
>>>>>>>> > > > actually
>>>>>>>> > > >
>>>>>>>> > > > > > > prefer this answer. I think it is sensible to fail a
>>>>>>>> build
>>>>>>>> when
>>>>>>>> > > > > > > encountering a POM version too advanced. If your  
>>>>>>>> client
>>>>>>>> only
>>>>>>>> > > >
>>>>>>>> > > > supports up
>>>>>>>> > > >
>>>>>>>> > > > > > to
>>>>>>>> > > > > >
>>>>>>>> > > > > > > model 4.0.0, then all artifacts must be specified by
>>>>>>>> 4.0.0
>>>>>>>> > models,
>>>>>>>> > > >
>>>>>>>> > > > too.
>>>>>>>> > > >
>>>>>>>> > > > > > > On the other hand, I wanted to give the benefit of the
>>>>>>>> doubt
>>>>>>>> to
>>>>>>>> > the
>>>>>>>> > > > > > > opposite argument. At least one person spoke up and  
>>>>>>>> said
>>>>>>>> it's
>>>>>>>> > > > > >
>>>>>>>> > > > > > unacceptable
>>>>>>>> > > > > >
>>>>>>>> > > > > > > to fail a build on configuration you don't understand.
>>>>>>>> Well,
>>>>>>>> > that's
>>>>>>>> > > >
>>>>>>>> > > > an
>>>>>>>> > > >
>>>>>>>> > > > > > > interesting argument, too. That person doesn't want to
>>>>>>>> tank
>>>>>>>> the
>>>>>>>> > > > > > > build
>>>>>>>> > > > > > > for
>>>>>>>> > > > > > > the 1% of configuration that can't be understood....  
>>>>>>>> but
>>>>>>>> I
>>>>>>>> fail
>>>>>>>> > to
>>>>>>>> > > >
>>>>>>>> > > > see
>>>>>>>> > > >
>>>>>>>> > > > > > > an
>>>>>>>> > > > > > > escape hatch here. If a client can't understand what's
>>>>>>>> being
>>>>>>>> > > >
>>>>>>>> > > > specified,
>>>>>>>> > > >
>>>>>>>> > > > > > > then what else can be done but fail?
>>>>>>>> > > > > >
>>>>>>>> > > > > > Strip the dependencies a and let the user fix up  
>>>>>>>> manually
>>>>>>>> (ideally
>>>>>>>> > by
>>>>>>>> > > > > > logging a warning that you are consuming a dependency
>>>>>>>> using a
>>>>>>>> newer
>>>>>>>> > > > > > modelVersion)
>>>>>>>> > > > > >
>>>>>>>> > > > > > Everyone forgets that the 4.0.0 ship has sailed  
>>>>>>>> already, so
>>>>>>>> we
>>>>>>>> > have to
>>>>>>>> > > > > > deploy best-effort 4.0.0 poms
>>>>>>>> > > > > >
>>>>>>>> > > > > > Now I say that 3.4 should not have a new modelVersion  
>>>>>>>> but
>>>>>>>> what
>>>>>>>> it
>>>>>>>> > > >
>>>>>>>> > > > could do
>>>>>>>> > > >
>>>>>>>> > > > > > is be more forgiving of newer modelVersions or try and
>>>>>>>> download
>>>>>>>> and
>>>>>>>> > > >
>>>>>>>> > > > use an
>>>>>>>> > > >
>>>>>>>> > > > > > XSLT to convert newer modelVersions to 4.0.0 (while
>>>>>>>> logging a
>>>>>>>> > warning)
>>>>>>>> > > > > > with
>>>>>>>> > > > > > option flags to allow failing the build if XSLT had to  
>>>>>>>> be
>>>>>>>> applied
>>>>>>>> > > > > >
>>>>>>>> > > > > > So let's bump the modelVersion in Maven 5.0.0 (there is  
>>>>>>>> no
>>>>>>>> Maven
>>>>>>>> > 4.x
>>>>>>>> > > >
>>>>>>>> > > > let's
>>>>>>>> > > >
>>>>>>>> > > > > > align on the modelVersion)
>>>>>>>> > > > > >
>>>>>>>> > > > > > That should have separation between builder Pom and
>>>>>>>> consumer
>>>>>>>> Pom.
>>>>>>>> > For
>>>>>>>> > > > > > packaging=pom we deploy the builder Pom using
>>>>>>>> classifier=build
>>>>>>>> for
>>>>>>>> > all
>>>>>>>> > > > > > other packaging a we do not deploy the builder Pom.
>>>>>>>> > > > > >
>>>>>>>> > > > > > We deploy a *best effort* conversion of the consumer  
>>>>>>>> Pom to
>>>>>>>> > > >
>>>>>>>> > > > modelVersion
>>>>>>>> > > >
>>>>>>>> > > > > > 4.0.0 without a classifier and the consumer Pom gets
>>>>>>>> deployed
>>>>>>>> as
>>>>>>>> > > > > > classifier
>>>>>>>> > > > > > consumer.
>>>>>>>> > > > > >
>>>>>>>> > > > > > The consumer Pom format allows for XSLT to transform to  
>>>>>>>> a
>>>>>>>> parsable
>>>>>>>> > > >
>>>>>>>> > > > syntax,
>>>>>>>> > > >
>>>>>>>> > > > > > if transform is required we log a warning (or fail the
>>>>>>>> build
>>>>>>>> if
>>>>>>>> the
>>>>>>>> > > > > > builder
>>>>>>>> > > > > > Pom indicates strict modelVersion adherence)
>>>>>>>> > > > > >
>>>>>>>> > > > > > So yeah maven 5.x will be able to parse dependencies  
>>>>>>>> with
>>>>>>>> > modelVersion
>>>>>>>> > > >
>>>>>>>> > > > 6.x
>>>>>>>> > > >
>>>>>>>> > > > > > while logging warnings that the user may not have the
>>>>>>>> correct
>>>>>>>> > > >
>>>>>>>> > > > dependency
>>>>>>>> > > >
>>>>>>>> > > > > > tree. That is IMHO acceptable forward compatibility
>>>>>>>> > > > > >
>>>>>>>> > > > > > HTH
>>>>>>>> > > > > >
>>>>>>>> > > > > > -Stephen
>>>>>>>> > > > > >
>>>>>>>> > > > > > Ps I'm really hoping someone has a less crappy solution
>>>>>>>> that
>>>>>>>> > this...
>>>>>>>> > > >
>>>>>>>> > > > But I
>>>>>>>> > > >
>>>>>>>> > > > > > believe this is actually *a* solution... And prior to  
>>>>>>>> this
>>>>>>>> I
>>>>>>>> have
>>>>>>>> > not
>>>>>>>> > > >
>>>>>>>> > > > seen
>>>>>>>> > > >
>>>>>>>> > > > > > any solution
>>>>>>>> > > > > >
>>>>>>>> > > > > > > Cheers,
>>>>>>>> > > > > > > Paul
>>>>>>>> > > > > >
>>>>>>>> > > > > > --
>>>>>>>> > > > > > Sent from my phone
>>>>>>>> > > >
>>>>>>>> > > > ------------------------------------------------------------
>>>>>>>> ---------
>>>>>>>> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> <javascript:;>
>>>>>>>> > > > For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>> <javascript:;>
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > ------------------------------------------------------------
>>>>>>>> ---------
>>>>>>>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> <javascript:;>
>>>>>>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>> <javascript:;>
>>>>>>>> >
>>>>>>>> >
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------
>>>>>>> ---------
>>>>>>>
>>>>>> 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: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Stephen Connolly <st...@gmail.com>]

So content:

* list/tree of dependencies
* list/tree of provides
* list/tree of requires
* repeat same for side artifacts

For a jar the "requires" will basically be "java:runtime:9.0" to indicate
that it was compiled with -target 9.0

For say a .net DLL the requires may be more complex

For say a .rpm the requires may be "org.kernel.linux:centos:6.0" and
"com.intel.cpu:x86_64:1.0" to indicate that this rpm is centos x86_64...
But such an rpm would need to be deployed with an architecture specified
(I'm still thinking my way through how architecture specification should
work)

I think we should include some locating information, eg url, name,
description

License information should be normalised using the SPDX format spec:
http://spdx.org/licenses/

The license may vary for side artifacts, as would basically everything, but
we should be able to inherit from the primary artifact

Whether to include scm or repository info is an open question

On Thursday 25 August 2016, Robert Scholte <rf...@apache.org> wrote:

> On Thu, 25 Aug 2016 18:30:50 +0200, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> On Thursday 25 August 2016, Robert Scholte <rf...@apache.org> wrote:
>>
>> On Thu, 25 Aug 2016 01:10:36 +0200, Stephen Connolly <
>>> stephen.alan.connolly@gmail.com> wrote:
>>>
>>> On 24 August 2016 at 04:50, Robert Scholte <rf...@apache.org> wrote:
>>>
>>>>
>>>> I realized last ApacheCon that I wasn't clear about my definiton of the
>>>>
>>>>> consumer-pom.
>>>>> I don't think it should be a flattened pom with only the dependency
>>>>> information. Instead it shouldn't be a pom  (matching the pom.xsd) at
>>>>> all.
>>>>>
>>>>>
>>>>> I am not in disagreement, but as a concept the name "consumer pom" has
>>>> more
>>>> traction.
>>>>
>>>>
>>> I'd prefer consumer pom too, but it has led to confusion due to the
>>> assumption that consumer pom and flattened pom are the same thing. To me
>>> it
>>> makes sense to consider a new fileformat for the consumer pom which
>>> matches
>>> better the requirements. And yes, the "provides" would fit here.
>>>
>>
>>
>> New format or new schema?
>>
>> If we accept this is machine generated then we can use a format that does
>> not support comments (eg JSON) but it's hard to beat XSLT for a cross
>> platform schema migration tool... So XSLT would mandate XML (with all the
>> irrational hate people have for that - I say irrational as the people
>> laying the hate usually love writing HTML ;-) )
>>
>>
> Yes, it will be generated, so I wonder if there will be any comment. But
> yes, if we want to keep the option to transform the file with XSLT, XML
> seems to be the best choice. Most important for me is that this file is
> doesn't have to be a pom-model 4.0.0 file.
> We probably need to specify the content first before making a choice of
> the format.
>
>
>>>
>>> I see the builder pom as probably ending up not even being XML at all.
>>>> Rather IMHO it will end up being a DSL that is easy to author and not
>>>> verbose... and certainly not XML
>>>>
>>>> So the consumer pom should be stripped back to include two sets of
>>>> information:
>>>>
>>>> * dependencies - we are mostly familiar with this... though we may not
>>>> expose all the scopes... depends on how we think about things and how we
>>>> view scopes moving forward
>>>>
>>>> * provides - this is vitally important IMHO and not handled currently.
>>>>
>>>> To understand provides we have to look at things like JavaEE (but the
>>>> concept has general utility... though I suspect only for about 10-25% of
>>>> projects)
>>>>
>>>> If I have a project that says: provides javax.servlet:servlet-api:3.1
>>>> then
>>>> that is saying that my project is providing the equivalent content as in
>>>> javax.servlet:servlet-api:3.1 so for example
>>>> org.jboss.spec.javax.servlet:
>>>> jboss-servlet-api_3.1_spec:1.0.0.Final would say
>>>> javax.servlet:servlet-api:3.1
>>>>
>>>> When resolving the dependency tree, maven then knows that any transitive
>>>> requirement for javax.servlet:servlet-api:3.1 has already been met by my
>>>> direct dependency on org.jboss.spec.javax.servlet:j
>>>> boss-servlet-api_3.1_spec
>>>> :1.0.0.Final if we have a direct dependency on
>>>> org.apache.tomcat:tomcat-servlet-api:8.5.4 (which would also say
>>>> javax.servlet:servlet-api:3.1) then Maven can report an error and fail
>>>> the
>>>> build due to dependency conflict.
>>>>
>>>> There are lots of other improvements we can add, but to start we need to
>>>> have a way to declare when a project includes duplicate content of
>>>> another
>>>> artifact. Convention will be required to make this work correctly...
>>>> perhaps we can even introduce a new project type that provides needs to
>>>> point at so that a provides has to point at an "empty" specification
>>>> project...
>>>>
>>>> Finally, for the consumer pom refactoring I believe we need to address
>>>> architecture specific artifacts as these are a sort of implicit
>>>> provides.
>>>>
>>>>
>>>> Maybe it should be called something like consumer-dom (dependency object
>>>>
>>>>> model, though dom is confusing...).
>>>>> It should be the most fast and efficient way to resolve the dependency
>>>>> tree. That means it should do less roundtrips like Maven must do do
>>>>> right
>>>>> now: for every dependency download the pom, for all transitive
>>>>> dependencies
>>>>> download all poms, etc.
>>>>> Why can't it be a pom? I'd like to add the (file)extension too.
>>>>> Otherwise
>>>>> Maven needs to initialize the matching ArtifactHandler and translate
>>>>> the
>>>>> type to the proper extension.
>>>>>
>>>>>
>>>>
>>>> I think the consumer pom needs to embed some of the artifact handler
>>>> information for it self as otherwise non-maven tooling cannot be
>>>> expected
>>>> to understand those details... also we should be making the consumer pom
>>>> both Maven and Java agnostic... but this is a grand problem alright!
>>>>
>>>>
>>>> The pom doesn't have room for this.
>>>>
>>>>>
>>>>>
>>>>> I saw the whole flattened pom experiment as mostly a waste of time for
>>>> the
>>>> consumer pom effort as I envision the consumer pom not looking anything
>>>> like the current pom at all... but it is a project model...
>>>>
>>>> Oh and the consumer pom should include information for the
>>>> side-artifacts
>>>> (which would help with reusing tests as we could attach the test
>>>> dependencies to the test artifact details in the consumer pom)
>>>>
>>>> Consumer-dom is an extraction and enriched version of the pom and will
>>>> be
>>>> a
>>>>
>>>> separate upload to the repository. Build tools who can understand this
>>>>> file
>>>>> can use it or fall back by downloading all poms.
>>>>>
>>>>> thanks,
>>>>> Robert
>>>>>
>>>>>
>>>>> On Wed, 24 Aug 2016 09:22:03 +0200, Stephen Connolly <
>>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>>
>>>>> The consumer Pom is for machine to machine, it should be human readable
>>>>>
>>>>> because that is nice, but intent is never human generated.
>>>>>>
>>>>>> Switching to this separation allows us to be more radical in the
>>>>>> changes
>>>>>> to
>>>>>> the build Pom.
>>>>>>
>>>>>> The only reason we deploy packaging Pom's build Pom is for
>>>>>> inheritance.
>>>>>> If
>>>>>> we didn't have to deal with that we wouldn't need to deploy any build
>>>>>> poms
>>>>>> ever.
>>>>>>
>>>>>> For using a build Pom as a parent, you implicitly pick up the minimum
>>>>>> version of maven that your parent requires, so we then are free to
>>>>>> evolve
>>>>>> the build Pom format without worrying about forward compatibility,
>>>>>> only
>>>>>> backwards compatibility on the *build* Pom.
>>>>>>
>>>>>> The consumer Pom needs partial *forward* compatibility, so that older
>>>>>> clients are able to *attempt* to consume...
>>>>>>
>>>>>> In short there are totally different compatibility constraints on the
>>>>>> two,
>>>>>> so they should be separate.
>>>>>>
>>>>>> Mixins would probably also be deployed, once we figure out how they
>>>>>> work
>>>>>> with build poms.
>>>>>>
>>>>>> I think we probably need to rethink version ranges. What I'd like is
>>>>>> to
>>>>>> let
>>>>>> the consumer Pom treat version ranges more as guidance rather than
>>>>>> hard
>>>>>> requirements. It's a pain if you depend transitiveky on Foo:[1.0] but
>>>>>> need
>>>>>> Foo:[1.0.1,1.1) for the critical security fix... Having to run around
>>>>>> applying excludes is not a good plan... Yes the build should initially
>>>>>> fail
>>>>>> if I depend on [1.0] and [1.0.1,1.1) in my graph, but I should be able
>>>>>> to
>>>>>> resolve the conflict for all my consumers (unless they pull in the
>>>>>> conflict
>>>>>> again themselves)
>>>>>>
>>>>>> On Tuesday 23 August 2016, Fred Cooke <fr...@gmail.com> wrote:
>>>>>>
>>>>>> I still find it a bit off that the original real POM won't always be
>>>>>>
>>>>>> directly available anymore.
>>>>>>>
>>>>>>> Other tools create fake POMs because they *have* to - there's no
>>>>>>> other
>>>>>>> option.
>>>>>>>
>>>>>>> I feel like some fidelity would be lost. Diffability would be lost
>>>>>>> (from
>>>>>>> a
>>>>>>> scenario where there's nothing to diff).
>>>>>>>
>>>>>>> Unrelated, really, but kind of related: top level deployable artefact
>>>>>>> deployments, debs, wars, exes, etc. When ranges are in use it'd be
>>>>>>> nice
>>>>>>> to
>>>>>>> deploy a sort of strict effective pom with fully hard [] versions for
>>>>>>> all
>>>>>>> things. This can be achieved in other ways, though.
>>>>>>>
>>>>>>> I guess that is to say, don't forget about non-central deployments. I
>>>>>>> suppose if there's a way to always deploy pom.xml.build through some
>>>>>>> plugin
>>>>>>> or configuration or some such, then that's fine with me.
>>>>>>>
>>>>>>> On Wed, Aug 24, 2016 at 6:49 PM, Hervé BOUTEMY <
>>>>>>> herve.boutemy@free.fr
>>>>>>> <javascript:;>>
>>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> > Le mercredi 24 août 2016 18:41:59 Fred Cooke a écrit :
>>>>>>> > > Fair call re embedded pom, however it's quite convenient to just
>>>>>>> browse
>>>>>>> > to
>>>>>>> > > it and read.
>>>>>>> > >
>>>>>>> > > I've occasionally gone looking for details from poms of artefacts
>>>>>>> and
>>>>>>> > found
>>>>>>> > > a mess and missing stuff, and been annoyed. It probably wasn't
>>>>>>> gradle's
>>>>>>> > > fault, though. Just a sloppy author. If I'm honest I wouldn't
>>>>>>> even
>>>>>>> know
>>>>>>> > if
>>>>>>> > > I've ever consumed a non-maven artefact, certainly none of mine!
>>>>>>> :-)
>>>>>>> > >
>>>>>>> > > No, I am sure, I have, at least one, and it's an ant one with a
>>>>>>> hard
>>>>>>> > coded
>>>>>>> > > POM that doesn't always reflect the contents of the jar. Yuck.
>>>>>>> Clearly
>>>>>>> > not
>>>>>>> > > an issue with automated stuff, though.
>>>>>>> > >
>>>>>>> > > My only argument now is ease of reading things like project
>>>>>>> descriptions,
>>>>>>> > > contributors, SCM details, etc rather than having to unpack the
>>>>>>> jar.
>>>>>>> And
>>>>>>> > if
>>>>>>> > > you do, and end up with two pom.xmls laying around, that's not
>>>>>>> nice.
>>>>>>> > Better
>>>>>>> > > to just start always suffixing one with pom.xml.build or some
>>>>>>> such? I
>>>>>>> > think
>>>>>>> > > so, but I haven't thought deeply about it aside from reading this
>>>>>>> thread.
>>>>>>> > our consumer pom will be generated from build pom: we can automate
>>>>>>> copy
>>>>>>> of
>>>>>>> > any
>>>>>>> > information we want, and for sure, I expect to put at least
>>>>>>> description,
>>>>>>> > scm
>>>>>>> > details, issueManagement, license (of course).
>>>>>>> > In your list, there is only constributors that I was not counting
>>>>>>> on
>>>>>>> it:
>>>>>>> > but
>>>>>>> > it's a detailed decision we'll have to make
>>>>>>> >
>>>>>>> > for sure, Maven consumer poms, since generated from Maven build
>>>>>>> pom,
>>>>>>> can
>>>>>>> > have
>>>>>>> > much more details (and be sure they are accurrate) than build tools
>>>>>>> that
>>>>>>> > don't
>>>>>>> > generate it from data that exists in their original build format
>>>>>>> >
>>>>>>> > Regards,
>>>>>>> >
>>>>>>> > Hervé
>>>>>>> >
>>>>>>> > >
>>>>>>> > >
>>>>>>> > >
>>>>>>> > > On Wed, Aug 24, 2016 at 6:32 PM, Hervé BOUTEMY <
>>>>>>> herve.boutemy@free.fr
>>>>>>> <javascript:;>>
>>>>>>>
>>>>>>> > >
>>>>>>> > > wrote:
>>>>>>> > > > Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit :
>>>>>>> > > > > That should have separation between builder Pom and consumer
>>>>>>> Pom.
>>>>>>> For
>>>>>>> > > > > packaging=pom we deploy the builder Pom using
>>>>>>> classifier=build
>>>>>>> > > > > *for all other packaging a we do not deploy the builder Pom*.
>>>>>>> > > > >
>>>>>>> > > > > I don't like the sound of this. The deployed artefacts should
>>>>>>> include
>>>>>>> > > > > the
>>>>>>> > > > > exact POM in use to build the project, as a reference, even
>>>>>>> if
>>>>>>> under
>>>>>>> > a
>>>>>>> > > > > different name. Yes, they should be in SCM, however down
>>>>>>> stream
>>>>>>> it's
>>>>>>> > > >
>>>>>>> > > > useful
>>>>>>> > > >
>>>>>>> > > > > to see these even when the SCM is offline or gone or private
>>>>>>> or
>>>>>>> > > > > whatever.
>>>>>>> > > > > Or did I misunderstand? If so, please clarify?
>>>>>>> > > >
>>>>>>> > > > when you consume an artifact not build with Maven, do you get
>>>>>>> the
>>>>>>> full
>>>>>>> > > > build
>>>>>>> > > > script?
>>>>>>> > > > no
>>>>>>> > > > I know that, as Maven users, we got used to have the build pom
>>>>>>> > published
>>>>>>> > > > in
>>>>>>> > > > central: this is now an issue, but we like that
>>>>>>> > > >
>>>>>>> > > > notice: the build pom can be injected in the artifact, in
>>>>>>> > META-INF/maven,
>>>>>>> > > > like
>>>>>>> > > > it is currently done
>>>>>>> > > > but I don't see the point in requiring it to be pbulished
>>>>>>> separately
>>>>>>> in
>>>>>>> > > > central: no other build tool does that, and they don't have any
>>>>>>> issue
>>>>>>> > with
>>>>>>> > > > that (and eventually it's a feature: don't publish internal
>>>>>>> details
>>>>>>> you
>>>>>>> > > > don't
>>>>>>> > > > really want people to see)
>>>>>>> > > >
>>>>>>> > > > Regards,
>>>>>>> > > >
>>>>>>> > > > Hervé
>>>>>>> > > >
>>>>>>> > > > > On Wed, Aug 24, 2016 at 1:52 PM, Stephen Connolly <
>>>>>>> > > > >
>>>>>>> > > > > stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>>>>>>> > > > > > On Tuesday 23 August 2016, Paul Benedict <
>>>>>>> pbenedict@apache.org
>>>>>>> <javascript:;>>
>>>>>>>
>>>>>>> > wrote:
>>>>>>> > > > > > > On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <
>>>>>>> > cs@schulte.it <javascript:;>
>>>>>>> > > > > > >
>>>>>>> > > > > > > <javascript:;>> wrote:
>>>>>>> > > > > > > > Am 08/24/16 um 00:08 schrieb Paul Benedict:
>>>>>>> > > > > > > > > POM and a future major version POM? I am hinting at a
>>>>>>> > strategy
>>>>>>> > > >
>>>>>>> > > > for
>>>>>>> > > >
>>>>>>> > > > > > > > forward
>>>>>>> > > > > > > >
>>>>>>> > > > > > > > > compatibility.
>>>>>>> > > > > > > >
>>>>>>> > > > > > > > Is forward compatibility really needed/required?
>>>>>>> > > > > > >
>>>>>>> > > > > > > I honestly don't know, which is why I am asking. An
>>>>>>> answer
>>>>>>> of
>>>>>>> "no
>>>>>>> > > > > > > compatibility" is possible, too.
>>>>>>> > > > > > >
>>>>>>> > > > > > > I can completely see the argument that says POMs must be
>>>>>>> > > > > > > all-parseable-or-nothing -- for the sake of
>>>>>>> reproducibility.
>>>>>>> I
>>>>>>> > > >
>>>>>>> > > > actually
>>>>>>> > > >
>>>>>>> > > > > > > prefer this answer. I think it is sensible to fail a
>>>>>>> build
>>>>>>> when
>>>>>>> > > > > > > encountering a POM version too advanced. If your client
>>>>>>> only
>>>>>>> > > >
>>>>>>> > > > supports up
>>>>>>> > > >
>>>>>>> > > > > > to
>>>>>>> > > > > >
>>>>>>> > > > > > > model 4.0.0, then all artifacts must be specified by
>>>>>>> 4.0.0
>>>>>>> > models,
>>>>>>> > > >
>>>>>>> > > > too.
>>>>>>> > > >
>>>>>>> > > > > > > On the other hand, I wanted to give the benefit of the
>>>>>>> doubt
>>>>>>> to
>>>>>>> > the
>>>>>>> > > > > > > opposite argument. At least one person spoke up and said
>>>>>>> it's
>>>>>>> > > > > >
>>>>>>> > > > > > unacceptable
>>>>>>> > > > > >
>>>>>>> > > > > > > to fail a build on configuration you don't understand.
>>>>>>> Well,
>>>>>>> > that's
>>>>>>> > > >
>>>>>>> > > > an
>>>>>>> > > >
>>>>>>> > > > > > > interesting argument, too. That person doesn't want to
>>>>>>> tank
>>>>>>> the
>>>>>>> > > > > > > build
>>>>>>> > > > > > > for
>>>>>>> > > > > > > the 1% of configuration that can't be understood.... but
>>>>>>> I
>>>>>>> fail
>>>>>>> > to
>>>>>>> > > >
>>>>>>> > > > see
>>>>>>> > > >
>>>>>>> > > > > > > an
>>>>>>> > > > > > > escape hatch here. If a client can't understand what's
>>>>>>> being
>>>>>>> > > >
>>>>>>> > > > specified,
>>>>>>> > > >
>>>>>>> > > > > > > then what else can be done but fail?
>>>>>>> > > > > >
>>>>>>> > > > > > Strip the dependencies a and let the user fix up manually
>>>>>>> (ideally
>>>>>>> > by
>>>>>>> > > > > > logging a warning that you are consuming a dependency
>>>>>>> using a
>>>>>>> newer
>>>>>>> > > > > > modelVersion)
>>>>>>> > > > > >
>>>>>>> > > > > > Everyone forgets that the 4.0.0 ship has sailed already, so
>>>>>>> we
>>>>>>> > have to
>>>>>>> > > > > > deploy best-effort 4.0.0 poms
>>>>>>> > > > > >
>>>>>>> > > > > > Now I say that 3.4 should not have a new modelVersion but
>>>>>>> what
>>>>>>> it
>>>>>>> > > >
>>>>>>> > > > could do
>>>>>>> > > >
>>>>>>> > > > > > is be more forgiving of newer modelVersions or try and
>>>>>>> download
>>>>>>> and
>>>>>>> > > >
>>>>>>> > > > use an
>>>>>>> > > >
>>>>>>> > > > > > XSLT to convert newer modelVersions to 4.0.0 (while
>>>>>>> logging a
>>>>>>> > warning)
>>>>>>> > > > > > with
>>>>>>> > > > > > option flags to allow failing the build if XSLT had to be
>>>>>>> applied
>>>>>>> > > > > >
>>>>>>> > > > > > So let's bump the modelVersion in Maven 5.0.0 (there is no
>>>>>>> Maven
>>>>>>> > 4.x
>>>>>>> > > >
>>>>>>> > > > let's
>>>>>>> > > >
>>>>>>> > > > > > align on the modelVersion)
>>>>>>> > > > > >
>>>>>>> > > > > > That should have separation between builder Pom and
>>>>>>> consumer
>>>>>>> Pom.
>>>>>>> > For
>>>>>>> > > > > > packaging=pom we deploy the builder Pom using
>>>>>>> classifier=build
>>>>>>> for
>>>>>>> > all
>>>>>>> > > > > > other packaging a we do not deploy the builder Pom.
>>>>>>> > > > > >
>>>>>>> > > > > > We deploy a *best effort* conversion of the consumer Pom to
>>>>>>> > > >
>>>>>>> > > > modelVersion
>>>>>>> > > >
>>>>>>> > > > > > 4.0.0 without a classifier and the consumer Pom gets
>>>>>>> deployed
>>>>>>> as
>>>>>>> > > > > > classifier
>>>>>>> > > > > > consumer.
>>>>>>> > > > > >
>>>>>>> > > > > > The consumer Pom format allows for XSLT to transform to a
>>>>>>> parsable
>>>>>>> > > >
>>>>>>> > > > syntax,
>>>>>>> > > >
>>>>>>> > > > > > if transform is required we log a warning (or fail the
>>>>>>> build
>>>>>>> if
>>>>>>> the
>>>>>>> > > > > > builder
>>>>>>> > > > > > Pom indicates strict modelVersion adherence)
>>>>>>> > > > > >
>>>>>>> > > > > > So yeah maven 5.x will be able to parse dependencies with
>>>>>>> > modelVersion
>>>>>>> > > >
>>>>>>> > > > 6.x
>>>>>>> > > >
>>>>>>> > > > > > while logging warnings that the user may not have the
>>>>>>> correct
>>>>>>> > > >
>>>>>>> > > > dependency
>>>>>>> > > >
>>>>>>> > > > > > tree. That is IMHO acceptable forward compatibility
>>>>>>> > > > > >
>>>>>>> > > > > > HTH
>>>>>>> > > > > >
>>>>>>> > > > > > -Stephen
>>>>>>> > > > > >
>>>>>>> > > > > > Ps I'm really hoping someone has a less crappy solution
>>>>>>> that
>>>>>>> > this...
>>>>>>> > > >
>>>>>>> > > > But I
>>>>>>> > > >
>>>>>>> > > > > > believe this is actually *a* solution... And prior to this
>>>>>>> I
>>>>>>> have
>>>>>>> > not
>>>>>>> > > >
>>>>>>> > > > seen
>>>>>>> > > >
>>>>>>> > > > > > any solution
>>>>>>> > > > > >
>>>>>>> > > > > > > Cheers,
>>>>>>> > > > > > > Paul
>>>>>>> > > > > >
>>>>>>> > > > > > --
>>>>>>> > > > > > Sent from my phone
>>>>>>> > > >
>>>>>>> > > > ------------------------------------------------------------
>>>>>>> ---------
>>>>>>> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> <javascript:;>
>>>>>>> > > > For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>> <javascript:;>
>>>>>>> >
>>>>>>> >
>>>>>>> > ------------------------------------------------------------
>>>>>>> ---------
>>>>>>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> <javascript:;>
>>>>>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>> <javascript:;>
>>>>>>> >
>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>>> ---------
>>>>>>
>>>>> 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: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Robert Scholte <rf...@apache.org>]

On Thu, 25 Aug 2016 18:30:50 +0200, Stephen Connolly  
<st...@gmail.com> wrote:

> On Thursday 25 August 2016, Robert Scholte <rf...@apache.org> wrote:
>
>> On Thu, 25 Aug 2016 01:10:36 +0200, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>>
>> On 24 August 2016 at 04:50, Robert Scholte <rf...@apache.org> wrote:
>>>
>>> I realized last ApacheCon that I wasn't clear about my definiton of the
>>>> consumer-pom.
>>>> I don't think it should be a flattened pom with only the dependency
>>>> information. Instead it shouldn't be a pom  (matching the pom.xsd) at
>>>> all.
>>>>
>>>>
>>> I am not in disagreement, but as a concept the name "consumer pom" has
>>> more
>>> traction.
>>>
>>
>> I'd prefer consumer pom too, but it has led to confusion due to the
>> assumption that consumer pom and flattened pom are the same thing. To  
>> me it
>> makes sense to consider a new fileformat for the consumer pom which  
>> matches
>> better the requirements. And yes, the "provides" would fit here.
>
>
> New format or new schema?
>
> If we accept this is machine generated then we can use a format that does
> not support comments (eg JSON) but it's hard to beat XSLT for a cross
> platform schema migration tool... So XSLT would mandate XML (with all the
> irrational hate people have for that - I say irrational as the people
> laying the hate usually love writing HTML ;-) )
>

Yes, it will be generated, so I wonder if there will be any comment. But  
yes, if we want to keep the option to transform the file with XSLT, XML  
seems to be the best choice. Most important for me is that this file is  
doesn't have to be a pom-model 4.0.0 file.
We probably need to specify the content first before making a choice of  
the format.

>>
>>
>>> I see the builder pom as probably ending up not even being XML at all.
>>> Rather IMHO it will end up being a DSL that is easy to author and not
>>> verbose... and certainly not XML
>>>
>>> So the consumer pom should be stripped back to include two sets of
>>> information:
>>>
>>> * dependencies - we are mostly familiar with this... though we may not
>>> expose all the scopes... depends on how we think about things and how  
>>> we
>>> view scopes moving forward
>>>
>>> * provides - this is vitally important IMHO and not handled currently.
>>>
>>> To understand provides we have to look at things like JavaEE (but the
>>> concept has general utility... though I suspect only for about 10-25%  
>>> of
>>> projects)
>>>
>>> If I have a project that says: provides javax.servlet:servlet-api:3.1  
>>> then
>>> that is saying that my project is providing the equivalent content as  
>>> in
>>> javax.servlet:servlet-api:3.1 so for example  
>>> org.jboss.spec.javax.servlet:
>>> jboss-servlet-api_3.1_spec:1.0.0.Final would say
>>> javax.servlet:servlet-api:3.1
>>>
>>> When resolving the dependency tree, maven then knows that any  
>>> transitive
>>> requirement for javax.servlet:servlet-api:3.1 has already been met by  
>>> my
>>> direct dependency on org.jboss.spec.javax.servlet:j
>>> boss-servlet-api_3.1_spec
>>> :1.0.0.Final if we have a direct dependency on
>>> org.apache.tomcat:tomcat-servlet-api:8.5.4 (which would also say
>>> javax.servlet:servlet-api:3.1) then Maven can report an error and fail  
>>> the
>>> build due to dependency conflict.
>>>
>>> There are lots of other improvements we can add, but to start we need  
>>> to
>>> have a way to declare when a project includes duplicate content of  
>>> another
>>> artifact. Convention will be required to make this work correctly...
>>> perhaps we can even introduce a new project type that provides needs to
>>> point at so that a provides has to point at an "empty" specification
>>> project...
>>>
>>> Finally, for the consumer pom refactoring I believe we need to address
>>> architecture specific artifacts as these are a sort of implicit  
>>> provides.
>>>
>>>
>>> Maybe it should be called something like consumer-dom (dependency  
>>> object
>>>> model, though dom is confusing...).
>>>> It should be the most fast and efficient way to resolve the dependency
>>>> tree. That means it should do less roundtrips like Maven must do do  
>>>> right
>>>> now: for every dependency download the pom, for all transitive
>>>> dependencies
>>>> download all poms, etc.
>>>> Why can't it be a pom? I'd like to add the (file)extension too.  
>>>> Otherwise
>>>> Maven needs to initialize the matching ArtifactHandler and translate  
>>>> the
>>>> type to the proper extension.
>>>>
>>>
>>>
>>> I think the consumer pom needs to embed some of the artifact handler
>>> information for it self as otherwise non-maven tooling cannot be  
>>> expected
>>> to understand those details... also we should be making the consumer  
>>> pom
>>> both Maven and Java agnostic... but this is a grand problem alright!
>>>
>>>
>>> The pom doesn't have room for this.
>>>>
>>>>
>>> I saw the whole flattened pom experiment as mostly a waste of time for  
>>> the
>>> consumer pom effort as I envision the consumer pom not looking anything
>>> like the current pom at all... but it is a project model...
>>>
>>> Oh and the consumer pom should include information for the  
>>> side-artifacts
>>> (which would help with reusing tests as we could attach the test
>>> dependencies to the test artifact details in the consumer pom)
>>>
>>> Consumer-dom is an extraction and enriched version of the pom and will  
>>> be
>>> a
>>>
>>>> separate upload to the repository. Build tools who can understand this
>>>> file
>>>> can use it or fall back by downloading all poms.
>>>>
>>>> thanks,
>>>> Robert
>>>>
>>>>
>>>> On Wed, 24 Aug 2016 09:22:03 +0200, Stephen Connolly <
>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>
>>>> The consumer Pom is for machine to machine, it should be human  
>>>> readable
>>>>
>>>>> because that is nice, but intent is never human generated.
>>>>>
>>>>> Switching to this separation allows us to be more radical in the  
>>>>> changes
>>>>> to
>>>>> the build Pom.
>>>>>
>>>>> The only reason we deploy packaging Pom's build Pom is for  
>>>>> inheritance.
>>>>> If
>>>>> we didn't have to deal with that we wouldn't need to deploy any build
>>>>> poms
>>>>> ever.
>>>>>
>>>>> For using a build Pom as a parent, you implicitly pick up the minimum
>>>>> version of maven that your parent requires, so we then are free to
>>>>> evolve
>>>>> the build Pom format without worrying about forward compatibility,  
>>>>> only
>>>>> backwards compatibility on the *build* Pom.
>>>>>
>>>>> The consumer Pom needs partial *forward* compatibility, so that older
>>>>> clients are able to *attempt* to consume...
>>>>>
>>>>> In short there are totally different compatibility constraints on the
>>>>> two,
>>>>> so they should be separate.
>>>>>
>>>>> Mixins would probably also be deployed, once we figure out how they  
>>>>> work
>>>>> with build poms.
>>>>>
>>>>> I think we probably need to rethink version ranges. What I'd like is  
>>>>> to
>>>>> let
>>>>> the consumer Pom treat version ranges more as guidance rather than  
>>>>> hard
>>>>> requirements. It's a pain if you depend transitiveky on Foo:[1.0] but
>>>>> need
>>>>> Foo:[1.0.1,1.1) for the critical security fix... Having to run around
>>>>> applying excludes is not a good plan... Yes the build should  
>>>>> initially
>>>>> fail
>>>>> if I depend on [1.0] and [1.0.1,1.1) in my graph, but I should be  
>>>>> able
>>>>> to
>>>>> resolve the conflict for all my consumers (unless they pull in the
>>>>> conflict
>>>>> again themselves)
>>>>>
>>>>> On Tuesday 23 August 2016, Fred Cooke <fr...@gmail.com> wrote:
>>>>>
>>>>> I still find it a bit off that the original real POM won't always be
>>>>>
>>>>>> directly available anymore.
>>>>>>
>>>>>> Other tools create fake POMs because they *have* to - there's no  
>>>>>> other
>>>>>> option.
>>>>>>
>>>>>> I feel like some fidelity would be lost. Diffability would be lost
>>>>>> (from
>>>>>> a
>>>>>> scenario where there's nothing to diff).
>>>>>>
>>>>>> Unrelated, really, but kind of related: top level deployable  
>>>>>> artefact
>>>>>> deployments, debs, wars, exes, etc. When ranges are in use it'd be  
>>>>>> nice
>>>>>> to
>>>>>> deploy a sort of strict effective pom with fully hard [] versions  
>>>>>> for
>>>>>> all
>>>>>> things. This can be achieved in other ways, though.
>>>>>>
>>>>>> I guess that is to say, don't forget about non-central deployments.  
>>>>>> I
>>>>>> suppose if there's a way to always deploy pom.xml.build through some
>>>>>> plugin
>>>>>> or configuration or some such, then that's fine with me.
>>>>>>
>>>>>> On Wed, Aug 24, 2016 at 6:49 PM, Hervé BOUTEMY  
>>>>>> <herve.boutemy@free.fr
>>>>>> <javascript:;>>
>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> > Le mercredi 24 août 2016 18:41:59 Fred Cooke a écrit :
>>>>>> > > Fair call re embedded pom, however it's quite convenient to just
>>>>>> browse
>>>>>> > to
>>>>>> > > it and read.
>>>>>> > >
>>>>>> > > I've occasionally gone looking for details from poms of  
>>>>>> artefacts
>>>>>> and
>>>>>> > found
>>>>>> > > a mess and missing stuff, and been annoyed. It probably wasn't
>>>>>> gradle's
>>>>>> > > fault, though. Just a sloppy author. If I'm honest I wouldn't  
>>>>>> even
>>>>>> know
>>>>>> > if
>>>>>> > > I've ever consumed a non-maven artefact, certainly none of mine!
>>>>>> :-)
>>>>>> > >
>>>>>> > > No, I am sure, I have, at least one, and it's an ant one with a
>>>>>> hard
>>>>>> > coded
>>>>>> > > POM that doesn't always reflect the contents of the jar. Yuck.
>>>>>> Clearly
>>>>>> > not
>>>>>> > > an issue with automated stuff, though.
>>>>>> > >
>>>>>> > > My only argument now is ease of reading things like project
>>>>>> descriptions,
>>>>>> > > contributors, SCM details, etc rather than having to unpack the
>>>>>> jar.
>>>>>> And
>>>>>> > if
>>>>>> > > you do, and end up with two pom.xmls laying around, that's not
>>>>>> nice.
>>>>>> > Better
>>>>>> > > to just start always suffixing one with pom.xml.build or some
>>>>>> such? I
>>>>>> > think
>>>>>> > > so, but I haven't thought deeply about it aside from reading  
>>>>>> this
>>>>>> thread.
>>>>>> > our consumer pom will be generated from build pom: we can automate
>>>>>> copy
>>>>>> of
>>>>>> > any
>>>>>> > information we want, and for sure, I expect to put at least
>>>>>> description,
>>>>>> > scm
>>>>>> > details, issueManagement, license (of course).
>>>>>> > In your list, there is only constributors that I was not counting  
>>>>>> on
>>>>>> it:
>>>>>> > but
>>>>>> > it's a detailed decision we'll have to make
>>>>>> >
>>>>>> > for sure, Maven consumer poms, since generated from Maven build  
>>>>>> pom,
>>>>>> can
>>>>>> > have
>>>>>> > much more details (and be sure they are accurrate) than build  
>>>>>> tools
>>>>>> that
>>>>>> > don't
>>>>>> > generate it from data that exists in their original build format
>>>>>> >
>>>>>> > Regards,
>>>>>> >
>>>>>> > Hervé
>>>>>> >
>>>>>> > >
>>>>>> > >
>>>>>> > >
>>>>>> > > On Wed, Aug 24, 2016 at 6:32 PM, Hervé BOUTEMY <
>>>>>> herve.boutemy@free.fr
>>>>>> <javascript:;>>
>>>>>>
>>>>>> > >
>>>>>> > > wrote:
>>>>>> > > > Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit :
>>>>>> > > > > That should have separation between builder Pom and consumer
>>>>>> Pom.
>>>>>> For
>>>>>> > > > > packaging=pom we deploy the builder Pom using  
>>>>>> classifier=build
>>>>>> > > > > *for all other packaging a we do not deploy the builder  
>>>>>> Pom*.
>>>>>> > > > >
>>>>>> > > > > I don't like the sound of this. The deployed artefacts  
>>>>>> should
>>>>>> include
>>>>>> > > > > the
>>>>>> > > > > exact POM in use to build the project, as a reference, even  
>>>>>> if
>>>>>> under
>>>>>> > a
>>>>>> > > > > different name. Yes, they should be in SCM, however down  
>>>>>> stream
>>>>>> it's
>>>>>> > > >
>>>>>> > > > useful
>>>>>> > > >
>>>>>> > > > > to see these even when the SCM is offline or gone or  
>>>>>> private or
>>>>>> > > > > whatever.
>>>>>> > > > > Or did I misunderstand? If so, please clarify?
>>>>>> > > >
>>>>>> > > > when you consume an artifact not build with Maven, do you get  
>>>>>> the
>>>>>> full
>>>>>> > > > build
>>>>>> > > > script?
>>>>>> > > > no
>>>>>> > > > I know that, as Maven users, we got used to have the build pom
>>>>>> > published
>>>>>> > > > in
>>>>>> > > > central: this is now an issue, but we like that
>>>>>> > > >
>>>>>> > > > notice: the build pom can be injected in the artifact, in
>>>>>> > META-INF/maven,
>>>>>> > > > like
>>>>>> > > > it is currently done
>>>>>> > > > but I don't see the point in requiring it to be pbulished
>>>>>> separately
>>>>>> in
>>>>>> > > > central: no other build tool does that, and they don't have  
>>>>>> any
>>>>>> issue
>>>>>> > with
>>>>>> > > > that (and eventually it's a feature: don't publish internal
>>>>>> details
>>>>>> you
>>>>>> > > > don't
>>>>>> > > > really want people to see)
>>>>>> > > >
>>>>>> > > > Regards,
>>>>>> > > >
>>>>>> > > > Hervé
>>>>>> > > >
>>>>>> > > > > On Wed, Aug 24, 2016 at 1:52 PM, Stephen Connolly <
>>>>>> > > > >
>>>>>> > > > > stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>>>>>> > > > > > On Tuesday 23 August 2016, Paul Benedict <
>>>>>> pbenedict@apache.org
>>>>>> <javascript:;>>
>>>>>>
>>>>>> > wrote:
>>>>>> > > > > > > On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <
>>>>>> > cs@schulte.it <javascript:;>
>>>>>> > > > > > >
>>>>>> > > > > > > <javascript:;>> wrote:
>>>>>> > > > > > > > Am 08/24/16 um 00:08 schrieb Paul Benedict:
>>>>>> > > > > > > > > POM and a future major version POM? I am hinting at  
>>>>>> a
>>>>>> > strategy
>>>>>> > > >
>>>>>> > > > for
>>>>>> > > >
>>>>>> > > > > > > > forward
>>>>>> > > > > > > >
>>>>>> > > > > > > > > compatibility.
>>>>>> > > > > > > >
>>>>>> > > > > > > > Is forward compatibility really needed/required?
>>>>>> > > > > > >
>>>>>> > > > > > > I honestly don't know, which is why I am asking. An  
>>>>>> answer
>>>>>> of
>>>>>> "no
>>>>>> > > > > > > compatibility" is possible, too.
>>>>>> > > > > > >
>>>>>> > > > > > > I can completely see the argument that says POMs must be
>>>>>> > > > > > > all-parseable-or-nothing -- for the sake of
>>>>>> reproducibility.
>>>>>> I
>>>>>> > > >
>>>>>> > > > actually
>>>>>> > > >
>>>>>> > > > > > > prefer this answer. I think it is sensible to fail a  
>>>>>> build
>>>>>> when
>>>>>> > > > > > > encountering a POM version too advanced. If your client
>>>>>> only
>>>>>> > > >
>>>>>> > > > supports up
>>>>>> > > >
>>>>>> > > > > > to
>>>>>> > > > > >
>>>>>> > > > > > > model 4.0.0, then all artifacts must be specified by  
>>>>>> 4.0.0
>>>>>> > models,
>>>>>> > > >
>>>>>> > > > too.
>>>>>> > > >
>>>>>> > > > > > > On the other hand, I wanted to give the benefit of the
>>>>>> doubt
>>>>>> to
>>>>>> > the
>>>>>> > > > > > > opposite argument. At least one person spoke up and said
>>>>>> it's
>>>>>> > > > > >
>>>>>> > > > > > unacceptable
>>>>>> > > > > >
>>>>>> > > > > > > to fail a build on configuration you don't understand.
>>>>>> Well,
>>>>>> > that's
>>>>>> > > >
>>>>>> > > > an
>>>>>> > > >
>>>>>> > > > > > > interesting argument, too. That person doesn't want to  
>>>>>> tank
>>>>>> the
>>>>>> > > > > > > build
>>>>>> > > > > > > for
>>>>>> > > > > > > the 1% of configuration that can't be understood....  
>>>>>> but I
>>>>>> fail
>>>>>> > to
>>>>>> > > >
>>>>>> > > > see
>>>>>> > > >
>>>>>> > > > > > > an
>>>>>> > > > > > > escape hatch here. If a client can't understand what's
>>>>>> being
>>>>>> > > >
>>>>>> > > > specified,
>>>>>> > > >
>>>>>> > > > > > > then what else can be done but fail?
>>>>>> > > > > >
>>>>>> > > > > > Strip the dependencies a and let the user fix up manually
>>>>>> (ideally
>>>>>> > by
>>>>>> > > > > > logging a warning that you are consuming a dependency  
>>>>>> using a
>>>>>> newer
>>>>>> > > > > > modelVersion)
>>>>>> > > > > >
>>>>>> > > > > > Everyone forgets that the 4.0.0 ship has sailed already,  
>>>>>> so
>>>>>> we
>>>>>> > have to
>>>>>> > > > > > deploy best-effort 4.0.0 poms
>>>>>> > > > > >
>>>>>> > > > > > Now I say that 3.4 should not have a new modelVersion but
>>>>>> what
>>>>>> it
>>>>>> > > >
>>>>>> > > > could do
>>>>>> > > >
>>>>>> > > > > > is be more forgiving of newer modelVersions or try and
>>>>>> download
>>>>>> and
>>>>>> > > >
>>>>>> > > > use an
>>>>>> > > >
>>>>>> > > > > > XSLT to convert newer modelVersions to 4.0.0 (while  
>>>>>> logging a
>>>>>> > warning)
>>>>>> > > > > > with
>>>>>> > > > > > option flags to allow failing the build if XSLT had to be
>>>>>> applied
>>>>>> > > > > >
>>>>>> > > > > > So let's bump the modelVersion in Maven 5.0.0 (there is no
>>>>>> Maven
>>>>>> > 4.x
>>>>>> > > >
>>>>>> > > > let's
>>>>>> > > >
>>>>>> > > > > > align on the modelVersion)
>>>>>> > > > > >
>>>>>> > > > > > That should have separation between builder Pom and  
>>>>>> consumer
>>>>>> Pom.
>>>>>> > For
>>>>>> > > > > > packaging=pom we deploy the builder Pom using
>>>>>> classifier=build
>>>>>> for
>>>>>> > all
>>>>>> > > > > > other packaging a we do not deploy the builder Pom.
>>>>>> > > > > >
>>>>>> > > > > > We deploy a *best effort* conversion of the consumer Pom  
>>>>>> to
>>>>>> > > >
>>>>>> > > > modelVersion
>>>>>> > > >
>>>>>> > > > > > 4.0.0 without a classifier and the consumer Pom gets  
>>>>>> deployed
>>>>>> as
>>>>>> > > > > > classifier
>>>>>> > > > > > consumer.
>>>>>> > > > > >
>>>>>> > > > > > The consumer Pom format allows for XSLT to transform to a
>>>>>> parsable
>>>>>> > > >
>>>>>> > > > syntax,
>>>>>> > > >
>>>>>> > > > > > if transform is required we log a warning (or fail the  
>>>>>> build
>>>>>> if
>>>>>> the
>>>>>> > > > > > builder
>>>>>> > > > > > Pom indicates strict modelVersion adherence)
>>>>>> > > > > >
>>>>>> > > > > > So yeah maven 5.x will be able to parse dependencies with
>>>>>> > modelVersion
>>>>>> > > >
>>>>>> > > > 6.x
>>>>>> > > >
>>>>>> > > > > > while logging warnings that the user may not have the  
>>>>>> correct
>>>>>> > > >
>>>>>> > > > dependency
>>>>>> > > >
>>>>>> > > > > > tree. That is IMHO acceptable forward compatibility
>>>>>> > > > > >
>>>>>> > > > > > HTH
>>>>>> > > > > >
>>>>>> > > > > > -Stephen
>>>>>> > > > > >
>>>>>> > > > > > Ps I'm really hoping someone has a less crappy solution  
>>>>>> that
>>>>>> > this...
>>>>>> > > >
>>>>>> > > > But I
>>>>>> > > >
>>>>>> > > > > > believe this is actually *a* solution... And prior to  
>>>>>> this I
>>>>>> have
>>>>>> > not
>>>>>> > > >
>>>>>> > > > seen
>>>>>> > > >
>>>>>> > > > > > any solution
>>>>>> > > > > >
>>>>>> > > > > > > Cheers,
>>>>>> > > > > > > Paul
>>>>>> > > > > >
>>>>>> > > > > > --
>>>>>> > > > > > Sent from my phone
>>>>>> > > >
>>>>>> > > > ------------------------------------------------------------
>>>>>> ---------
>>>>>> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> <javascript:;>
>>>>>> > > > For additional commands, e-mail: dev-help@maven.apache.org
>>>>>> <javascript:;>
>>>>>> >
>>>>>> >
>>>>>> > ------------------------------------------------------------
>>>>>> ---------
>>>>>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> <javascript:;>
>>>>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>>>>> <javascript:;>
>>>>>> >
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>> 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: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Stephen Connolly <st...@gmail.com>]

On Thursday 25 August 2016, Robert Scholte <rf...@apache.org> wrote:

> On Thu, 25 Aug 2016 01:10:36 +0200, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> On 24 August 2016 at 04:50, Robert Scholte <rf...@apache.org> wrote:
>>
>> I realized last ApacheCon that I wasn't clear about my definiton of the
>>> consumer-pom.
>>> I don't think it should be a flattened pom with only the dependency
>>> information. Instead it shouldn't be a pom  (matching the pom.xsd) at
>>> all.
>>>
>>>
>> I am not in disagreement, but as a concept the name "consumer pom" has
>> more
>> traction.
>>
>
> I'd prefer consumer pom too, but it has led to confusion due to the
> assumption that consumer pom and flattened pom are the same thing. To me it
> makes sense to consider a new fileformat for the consumer pom which matches
> better the requirements. And yes, the "provides" would fit here.


New format or new schema?

If we accept this is machine generated then we can use a format that does
not support comments (eg JSON) but it's hard to beat XSLT for a cross
platform schema migration tool... So XSLT would mandate XML (with all the
irrational hate people have for that - I say irrational as the people
laying the hate usually love writing HTML ;-) )


>
>
>> I see the builder pom as probably ending up not even being XML at all.
>> Rather IMHO it will end up being a DSL that is easy to author and not
>> verbose... and certainly not XML
>>
>> So the consumer pom should be stripped back to include two sets of
>> information:
>>
>> * dependencies - we are mostly familiar with this... though we may not
>> expose all the scopes... depends on how we think about things and how we
>> view scopes moving forward
>>
>> * provides - this is vitally important IMHO and not handled currently.
>>
>> To understand provides we have to look at things like JavaEE (but the
>> concept has general utility... though I suspect only for about 10-25% of
>> projects)
>>
>> If I have a project that says: provides javax.servlet:servlet-api:3.1 then
>> that is saying that my project is providing the equivalent content as in
>> javax.servlet:servlet-api:3.1 so for example org.jboss.spec.javax.servlet:
>> jboss-servlet-api_3.1_spec:1.0.0.Final would say
>> javax.servlet:servlet-api:3.1
>>
>> When resolving the dependency tree, maven then knows that any transitive
>> requirement for javax.servlet:servlet-api:3.1 has already been met by my
>> direct dependency on org.jboss.spec.javax.servlet:j
>> boss-servlet-api_3.1_spec
>> :1.0.0.Final if we have a direct dependency on
>> org.apache.tomcat:tomcat-servlet-api:8.5.4 (which would also say
>> javax.servlet:servlet-api:3.1) then Maven can report an error and fail the
>> build due to dependency conflict.
>>
>> There are lots of other improvements we can add, but to start we need to
>> have a way to declare when a project includes duplicate content of another
>> artifact. Convention will be required to make this work correctly...
>> perhaps we can even introduce a new project type that provides needs to
>> point at so that a provides has to point at an "empty" specification
>> project...
>>
>> Finally, for the consumer pom refactoring I believe we need to address
>> architecture specific artifacts as these are a sort of implicit provides.
>>
>>
>> Maybe it should be called something like consumer-dom (dependency object
>>> model, though dom is confusing...).
>>> It should be the most fast and efficient way to resolve the dependency
>>> tree. That means it should do less roundtrips like Maven must do do right
>>> now: for every dependency download the pom, for all transitive
>>> dependencies
>>> download all poms, etc.
>>> Why can't it be a pom? I'd like to add the (file)extension too. Otherwise
>>> Maven needs to initialize the matching ArtifactHandler and translate the
>>> type to the proper extension.
>>>
>>
>>
>> I think the consumer pom needs to embed some of the artifact handler
>> information for it self as otherwise non-maven tooling cannot be expected
>> to understand those details... also we should be making the consumer pom
>> both Maven and Java agnostic... but this is a grand problem alright!
>>
>>
>> The pom doesn't have room for this.
>>>
>>>
>> I saw the whole flattened pom experiment as mostly a waste of time for the
>> consumer pom effort as I envision the consumer pom not looking anything
>> like the current pom at all... but it is a project model...
>>
>> Oh and the consumer pom should include information for the side-artifacts
>> (which would help with reusing tests as we could attach the test
>> dependencies to the test artifact details in the consumer pom)
>>
>> Consumer-dom is an extraction and enriched version of the pom and will be
>> a
>>
>>> separate upload to the repository. Build tools who can understand this
>>> file
>>> can use it or fall back by downloading all poms.
>>>
>>> thanks,
>>> Robert
>>>
>>>
>>> On Wed, 24 Aug 2016 09:22:03 +0200, Stephen Connolly <
>>> stephen.alan.connolly@gmail.com> wrote:
>>>
>>> The consumer Pom is for machine to machine, it should be human readable
>>>
>>>> because that is nice, but intent is never human generated.
>>>>
>>>> Switching to this separation allows us to be more radical in the changes
>>>> to
>>>> the build Pom.
>>>>
>>>> The only reason we deploy packaging Pom's build Pom is for inheritance.
>>>> If
>>>> we didn't have to deal with that we wouldn't need to deploy any build
>>>> poms
>>>> ever.
>>>>
>>>> For using a build Pom as a parent, you implicitly pick up the minimum
>>>> version of maven that your parent requires, so we then are free to
>>>> evolve
>>>> the build Pom format without worrying about forward compatibility, only
>>>> backwards compatibility on the *build* Pom.
>>>>
>>>> The consumer Pom needs partial *forward* compatibility, so that older
>>>> clients are able to *attempt* to consume...
>>>>
>>>> In short there are totally different compatibility constraints on the
>>>> two,
>>>> so they should be separate.
>>>>
>>>> Mixins would probably also be deployed, once we figure out how they work
>>>> with build poms.
>>>>
>>>> I think we probably need to rethink version ranges. What I'd like is to
>>>> let
>>>> the consumer Pom treat version ranges more as guidance rather than hard
>>>> requirements. It's a pain if you depend transitiveky on Foo:[1.0] but
>>>> need
>>>> Foo:[1.0.1,1.1) for the critical security fix... Having to run around
>>>> applying excludes is not a good plan... Yes the build should initially
>>>> fail
>>>> if I depend on [1.0] and [1.0.1,1.1) in my graph, but I should be able
>>>> to
>>>> resolve the conflict for all my consumers (unless they pull in the
>>>> conflict
>>>> again themselves)
>>>>
>>>> On Tuesday 23 August 2016, Fred Cooke <fr...@gmail.com> wrote:
>>>>
>>>> I still find it a bit off that the original real POM won't always be
>>>>
>>>>> directly available anymore.
>>>>>
>>>>> Other tools create fake POMs because they *have* to - there's no other
>>>>> option.
>>>>>
>>>>> I feel like some fidelity would be lost. Diffability would be lost
>>>>> (from
>>>>> a
>>>>> scenario where there's nothing to diff).
>>>>>
>>>>> Unrelated, really, but kind of related: top level deployable artefact
>>>>> deployments, debs, wars, exes, etc. When ranges are in use it'd be nice
>>>>> to
>>>>> deploy a sort of strict effective pom with fully hard [] versions for
>>>>> all
>>>>> things. This can be achieved in other ways, though.
>>>>>
>>>>> I guess that is to say, don't forget about non-central deployments. I
>>>>> suppose if there's a way to always deploy pom.xml.build through some
>>>>> plugin
>>>>> or configuration or some such, then that's fine with me.
>>>>>
>>>>> On Wed, Aug 24, 2016 at 6:49 PM, Hervé BOUTEMY <herve.boutemy@free.fr
>>>>> <javascript:;>>
>>>>>
>>>>> wrote:
>>>>>
>>>>> > Le mercredi 24 août 2016 18:41:59 Fred Cooke a écrit :
>>>>> > > Fair call re embedded pom, however it's quite convenient to just
>>>>> browse
>>>>> > to
>>>>> > > it and read.
>>>>> > >
>>>>> > > I've occasionally gone looking for details from poms of artefacts
>>>>> and
>>>>> > found
>>>>> > > a mess and missing stuff, and been annoyed. It probably wasn't
>>>>> gradle's
>>>>> > > fault, though. Just a sloppy author. If I'm honest I wouldn't even
>>>>> know
>>>>> > if
>>>>> > > I've ever consumed a non-maven artefact, certainly none of mine!
>>>>> :-)
>>>>> > >
>>>>> > > No, I am sure, I have, at least one, and it's an ant one with a
>>>>> hard
>>>>> > coded
>>>>> > > POM that doesn't always reflect the contents of the jar. Yuck.
>>>>> Clearly
>>>>> > not
>>>>> > > an issue with automated stuff, though.
>>>>> > >
>>>>> > > My only argument now is ease of reading things like project
>>>>> descriptions,
>>>>> > > contributors, SCM details, etc rather than having to unpack the
>>>>> jar.
>>>>> And
>>>>> > if
>>>>> > > you do, and end up with two pom.xmls laying around, that's not
>>>>> nice.
>>>>> > Better
>>>>> > > to just start always suffixing one with pom.xml.build or some
>>>>> such? I
>>>>> > think
>>>>> > > so, but I haven't thought deeply about it aside from reading this
>>>>> thread.
>>>>> > our consumer pom will be generated from build pom: we can automate
>>>>> copy
>>>>> of
>>>>> > any
>>>>> > information we want, and for sure, I expect to put at least
>>>>> description,
>>>>> > scm
>>>>> > details, issueManagement, license (of course).
>>>>> > In your list, there is only constributors that I was not counting on
>>>>> it:
>>>>> > but
>>>>> > it's a detailed decision we'll have to make
>>>>> >
>>>>> > for sure, Maven consumer poms, since generated from Maven build pom,
>>>>> can
>>>>> > have
>>>>> > much more details (and be sure they are accurrate) than build tools
>>>>> that
>>>>> > don't
>>>>> > generate it from data that exists in their original build format
>>>>> >
>>>>> > Regards,
>>>>> >
>>>>> > Hervé
>>>>> >
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > > On Wed, Aug 24, 2016 at 6:32 PM, Hervé BOUTEMY <
>>>>> herve.boutemy@free.fr
>>>>> <javascript:;>>
>>>>>
>>>>> > >
>>>>> > > wrote:
>>>>> > > > Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit :
>>>>> > > > > That should have separation between builder Pom and consumer
>>>>> Pom.
>>>>> For
>>>>> > > > > packaging=pom we deploy the builder Pom using classifier=build
>>>>> > > > > *for all other packaging a we do not deploy the builder Pom*.
>>>>> > > > >
>>>>> > > > > I don't like the sound of this. The deployed artefacts should
>>>>> include
>>>>> > > > > the
>>>>> > > > > exact POM in use to build the project, as a reference, even if
>>>>> under
>>>>> > a
>>>>> > > > > different name. Yes, they should be in SCM, however down stream
>>>>> it's
>>>>> > > >
>>>>> > > > useful
>>>>> > > >
>>>>> > > > > to see these even when the SCM is offline or gone or private or
>>>>> > > > > whatever.
>>>>> > > > > Or did I misunderstand? If so, please clarify?
>>>>> > > >
>>>>> > > > when you consume an artifact not build with Maven, do you get the
>>>>> full
>>>>> > > > build
>>>>> > > > script?
>>>>> > > > no
>>>>> > > > I know that, as Maven users, we got used to have the build pom
>>>>> > published
>>>>> > > > in
>>>>> > > > central: this is now an issue, but we like that
>>>>> > > >
>>>>> > > > notice: the build pom can be injected in the artifact, in
>>>>> > META-INF/maven,
>>>>> > > > like
>>>>> > > > it is currently done
>>>>> > > > but I don't see the point in requiring it to be pbulished
>>>>> separately
>>>>> in
>>>>> > > > central: no other build tool does that, and they don't have any
>>>>> issue
>>>>> > with
>>>>> > > > that (and eventually it's a feature: don't publish internal
>>>>> details
>>>>> you
>>>>> > > > don't
>>>>> > > > really want people to see)
>>>>> > > >
>>>>> > > > Regards,
>>>>> > > >
>>>>> > > > Hervé
>>>>> > > >
>>>>> > > > > On Wed, Aug 24, 2016 at 1:52 PM, Stephen Connolly <
>>>>> > > > >
>>>>> > > > > stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>>>>> > > > > > On Tuesday 23 August 2016, Paul Benedict <
>>>>> pbenedict@apache.org
>>>>> <javascript:;>>
>>>>>
>>>>> > wrote:
>>>>> > > > > > > On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <
>>>>> > cs@schulte.it <javascript:;>
>>>>> > > > > > >
>>>>> > > > > > > <javascript:;>> wrote:
>>>>> > > > > > > > Am 08/24/16 um 00:08 schrieb Paul Benedict:
>>>>> > > > > > > > > POM and a future major version POM? I am hinting at a
>>>>> > strategy
>>>>> > > >
>>>>> > > > for
>>>>> > > >
>>>>> > > > > > > > forward
>>>>> > > > > > > >
>>>>> > > > > > > > > compatibility.
>>>>> > > > > > > >
>>>>> > > > > > > > Is forward compatibility really needed/required?
>>>>> > > > > > >
>>>>> > > > > > > I honestly don't know, which is why I am asking. An answer
>>>>> of
>>>>> "no
>>>>> > > > > > > compatibility" is possible, too.
>>>>> > > > > > >
>>>>> > > > > > > I can completely see the argument that says POMs must be
>>>>> > > > > > > all-parseable-or-nothing -- for the sake of
>>>>> reproducibility.
>>>>> I
>>>>> > > >
>>>>> > > > actually
>>>>> > > >
>>>>> > > > > > > prefer this answer. I think it is sensible to fail a build
>>>>> when
>>>>> > > > > > > encountering a POM version too advanced. If your client
>>>>> only
>>>>> > > >
>>>>> > > > supports up
>>>>> > > >
>>>>> > > > > > to
>>>>> > > > > >
>>>>> > > > > > > model 4.0.0, then all artifacts must be specified by 4.0.0
>>>>> > models,
>>>>> > > >
>>>>> > > > too.
>>>>> > > >
>>>>> > > > > > > On the other hand, I wanted to give the benefit of the
>>>>> doubt
>>>>> to
>>>>> > the
>>>>> > > > > > > opposite argument. At least one person spoke up and said
>>>>> it's
>>>>> > > > > >
>>>>> > > > > > unacceptable
>>>>> > > > > >
>>>>> > > > > > > to fail a build on configuration you don't understand.
>>>>> Well,
>>>>> > that's
>>>>> > > >
>>>>> > > > an
>>>>> > > >
>>>>> > > > > > > interesting argument, too. That person doesn't want to tank
>>>>> the
>>>>> > > > > > > build
>>>>> > > > > > > for
>>>>> > > > > > > the 1% of configuration that can't be understood.... but I
>>>>> fail
>>>>> > to
>>>>> > > >
>>>>> > > > see
>>>>> > > >
>>>>> > > > > > > an
>>>>> > > > > > > escape hatch here. If a client can't understand what's
>>>>> being
>>>>> > > >
>>>>> > > > specified,
>>>>> > > >
>>>>> > > > > > > then what else can be done but fail?
>>>>> > > > > >
>>>>> > > > > > Strip the dependencies a and let the user fix up manually
>>>>> (ideally
>>>>> > by
>>>>> > > > > > logging a warning that you are consuming a dependency using a
>>>>> newer
>>>>> > > > > > modelVersion)
>>>>> > > > > >
>>>>> > > > > > Everyone forgets that the 4.0.0 ship has sailed already, so
>>>>> we
>>>>> > have to
>>>>> > > > > > deploy best-effort 4.0.0 poms
>>>>> > > > > >
>>>>> > > > > > Now I say that 3.4 should not have a new modelVersion but
>>>>> what
>>>>> it
>>>>> > > >
>>>>> > > > could do
>>>>> > > >
>>>>> > > > > > is be more forgiving of newer modelVersions or try and
>>>>> download
>>>>> and
>>>>> > > >
>>>>> > > > use an
>>>>> > > >
>>>>> > > > > > XSLT to convert newer modelVersions to 4.0.0 (while logging a
>>>>> > warning)
>>>>> > > > > > with
>>>>> > > > > > option flags to allow failing the build if XSLT had to be
>>>>> applied
>>>>> > > > > >
>>>>> > > > > > So let's bump the modelVersion in Maven 5.0.0 (there is no
>>>>> Maven
>>>>> > 4.x
>>>>> > > >
>>>>> > > > let's
>>>>> > > >
>>>>> > > > > > align on the modelVersion)
>>>>> > > > > >
>>>>> > > > > > That should have separation between builder Pom and consumer
>>>>> Pom.
>>>>> > For
>>>>> > > > > > packaging=pom we deploy the builder Pom using
>>>>> classifier=build
>>>>> for
>>>>> > all
>>>>> > > > > > other packaging a we do not deploy the builder Pom.
>>>>> > > > > >
>>>>> > > > > > We deploy a *best effort* conversion of the consumer Pom to
>>>>> > > >
>>>>> > > > modelVersion
>>>>> > > >
>>>>> > > > > > 4.0.0 without a classifier and the consumer Pom gets deployed
>>>>> as
>>>>> > > > > > classifier
>>>>> > > > > > consumer.
>>>>> > > > > >
>>>>> > > > > > The consumer Pom format allows for XSLT to transform to a
>>>>> parsable
>>>>> > > >
>>>>> > > > syntax,
>>>>> > > >
>>>>> > > > > > if transform is required we log a warning (or fail the build
>>>>> if
>>>>> the
>>>>> > > > > > builder
>>>>> > > > > > Pom indicates strict modelVersion adherence)
>>>>> > > > > >
>>>>> > > > > > So yeah maven 5.x will be able to parse dependencies with
>>>>> > modelVersion
>>>>> > > >
>>>>> > > > 6.x
>>>>> > > >
>>>>> > > > > > while logging warnings that the user may not have the correct
>>>>> > > >
>>>>> > > > dependency
>>>>> > > >
>>>>> > > > > > tree. That is IMHO acceptable forward compatibility
>>>>> > > > > >
>>>>> > > > > > HTH
>>>>> > > > > >
>>>>> > > > > > -Stephen
>>>>> > > > > >
>>>>> > > > > > Ps I'm really hoping someone has a less crappy solution that
>>>>> > this...
>>>>> > > >
>>>>> > > > But I
>>>>> > > >
>>>>> > > > > > believe this is actually *a* solution... And prior to this I
>>>>> have
>>>>> > not
>>>>> > > >
>>>>> > > > seen
>>>>> > > >
>>>>> > > > > > any solution
>>>>> > > > > >
>>>>> > > > > > > Cheers,
>>>>> > > > > > > Paul
>>>>> > > > > >
>>>>> > > > > > --
>>>>> > > > > > Sent from my phone
>>>>> > > >
>>>>> > > > ------------------------------------------------------------
>>>>> ---------
>>>>> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> <javascript:;>
>>>>> > > > For additional commands, e-mail: dev-help@maven.apache.org
>>>>> <javascript:;>
>>>>> >
>>>>> >
>>>>> > ------------------------------------------------------------
>>>>> ---------
>>>>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> <javascript:;>
>>>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>>>> <javascript:;>
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>> 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: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Robert Scholte <rf...@apache.org>]

On Thu, 25 Aug 2016 01:10:36 +0200, Stephen Connolly  
<st...@gmail.com> wrote:

> On 24 August 2016 at 04:50, Robert Scholte <rf...@apache.org> wrote:
>
>> I realized last ApacheCon that I wasn't clear about my definiton of the
>> consumer-pom.
>> I don't think it should be a flattened pom with only the dependency
>> information. Instead it shouldn't be a pom  (matching the pom.xsd) at  
>> all.
>>
>
> I am not in disagreement, but as a concept the name "consumer pom" has  
> more
> traction.

I'd prefer consumer pom too, but it has led to confusion due to the  
assumption that consumer pom and flattened pom are the same thing. To me  
it makes sense to consider a new fileformat for the consumer pom which  
matches better the requirements. And yes, the "provides" would fit here.

>
> I see the builder pom as probably ending up not even being XML at all.
> Rather IMHO it will end up being a DSL that is easy to author and not
> verbose... and certainly not XML
>
> So the consumer pom should be stripped back to include two sets of
> information:
>
> * dependencies - we are mostly familiar with this... though we may not
> expose all the scopes... depends on how we think about things and how we
> view scopes moving forward
>
> * provides - this is vitally important IMHO and not handled currently.
>
> To understand provides we have to look at things like JavaEE (but the
> concept has general utility... though I suspect only for about 10-25% of
> projects)
>
> If I have a project that says: provides javax.servlet:servlet-api:3.1  
> then
> that is saying that my project is providing the equivalent content as in
> javax.servlet:servlet-api:3.1 so for example  
> org.jboss.spec.javax.servlet:
> jboss-servlet-api_3.1_spec:1.0.0.Final would say
> javax.servlet:servlet-api:3.1
>
> When resolving the dependency tree, maven then knows that any transitive
> requirement for javax.servlet:servlet-api:3.1 has already been met by my
> direct dependency on  
> org.jboss.spec.javax.servlet:jboss-servlet-api_3.1_spec
> :1.0.0.Final if we have a direct dependency on
> org.apache.tomcat:tomcat-servlet-api:8.5.4 (which would also say
> javax.servlet:servlet-api:3.1) then Maven can report an error and fail  
> the
> build due to dependency conflict.
>
> There are lots of other improvements we can add, but to start we need to
> have a way to declare when a project includes duplicate content of  
> another
> artifact. Convention will be required to make this work correctly...
> perhaps we can even introduce a new project type that provides needs to
> point at so that a provides has to point at an "empty" specification
> project...
>
> Finally, for the consumer pom refactoring I believe we need to address
> architecture specific artifacts as these are a sort of implicit provides.
>
>
>> Maybe it should be called something like consumer-dom (dependency object
>> model, though dom is confusing...).
>> It should be the most fast and efficient way to resolve the dependency
>> tree. That means it should do less roundtrips like Maven must do do  
>> right
>> now: for every dependency download the pom, for all transitive  
>> dependencies
>> download all poms, etc.
>> Why can't it be a pom? I'd like to add the (file)extension too.  
>> Otherwise
>> Maven needs to initialize the matching ArtifactHandler and translate the
>> type to the proper extension.
>
>
> I think the consumer pom needs to embed some of the artifact handler
> information for it self as otherwise non-maven tooling cannot be expected
> to understand those details... also we should be making the consumer pom
> both Maven and Java agnostic... but this is a grand problem alright!
>
>
>> The pom doesn't have room for this.
>>
>
> I saw the whole flattened pom experiment as mostly a waste of time for  
> the
> consumer pom effort as I envision the consumer pom not looking anything
> like the current pom at all... but it is a project model...
>
> Oh and the consumer pom should include information for the side-artifacts
> (which would help with reusing tests as we could attach the test
> dependencies to the test artifact details in the consumer pom)
>
> Consumer-dom is an extraction and enriched version of the pom and will  
> be a
>> separate upload to the repository. Build tools who can understand this  
>> file
>> can use it or fall back by downloading all poms.
>>
>> thanks,
>> Robert
>>
>>
>> On Wed, 24 Aug 2016 09:22:03 +0200, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>>
>> The consumer Pom is for machine to machine, it should be human readable
>>> because that is nice, but intent is never human generated.
>>>
>>> Switching to this separation allows us to be more radical in the  
>>> changes
>>> to
>>> the build Pom.
>>>
>>> The only reason we deploy packaging Pom's build Pom is for  
>>> inheritance. If
>>> we didn't have to deal with that we wouldn't need to deploy any build  
>>> poms
>>> ever.
>>>
>>> For using a build Pom as a parent, you implicitly pick up the minimum
>>> version of maven that your parent requires, so we then are free to  
>>> evolve
>>> the build Pom format without worrying about forward compatibility, only
>>> backwards compatibility on the *build* Pom.
>>>
>>> The consumer Pom needs partial *forward* compatibility, so that older
>>> clients are able to *attempt* to consume...
>>>
>>> In short there are totally different compatibility constraints on the  
>>> two,
>>> so they should be separate.
>>>
>>> Mixins would probably also be deployed, once we figure out how they  
>>> work
>>> with build poms.
>>>
>>> I think we probably need to rethink version ranges. What I'd like is to
>>> let
>>> the consumer Pom treat version ranges more as guidance rather than hard
>>> requirements. It's a pain if you depend transitiveky on Foo:[1.0] but  
>>> need
>>> Foo:[1.0.1,1.1) for the critical security fix... Having to run around
>>> applying excludes is not a good plan... Yes the build should initially
>>> fail
>>> if I depend on [1.0] and [1.0.1,1.1) in my graph, but I should be able  
>>> to
>>> resolve the conflict for all my consumers (unless they pull in the
>>> conflict
>>> again themselves)
>>>
>>> On Tuesday 23 August 2016, Fred Cooke <fr...@gmail.com> wrote:
>>>
>>> I still find it a bit off that the original real POM won't always be
>>>> directly available anymore.
>>>>
>>>> Other tools create fake POMs because they *have* to - there's no other
>>>> option.
>>>>
>>>> I feel like some fidelity would be lost. Diffability would be lost  
>>>> (from
>>>> a
>>>> scenario where there's nothing to diff).
>>>>
>>>> Unrelated, really, but kind of related: top level deployable artefact
>>>> deployments, debs, wars, exes, etc. When ranges are in use it'd be  
>>>> nice
>>>> to
>>>> deploy a sort of strict effective pom with fully hard [] versions for  
>>>> all
>>>> things. This can be achieved in other ways, though.
>>>>
>>>> I guess that is to say, don't forget about non-central deployments. I
>>>> suppose if there's a way to always deploy pom.xml.build through some
>>>> plugin
>>>> or configuration or some such, then that's fine with me.
>>>>
>>>> On Wed, Aug 24, 2016 at 6:49 PM, Hervé BOUTEMY <herve.boutemy@free.fr
>>>> <javascript:;>>
>>>>
>>>> wrote:
>>>>
>>>> > Le mercredi 24 août 2016 18:41:59 Fred Cooke a écrit :
>>>> > > Fair call re embedded pom, however it's quite convenient to just
>>>> browse
>>>> > to
>>>> > > it and read.
>>>> > >
>>>> > > I've occasionally gone looking for details from poms of artefacts  
>>>> and
>>>> > found
>>>> > > a mess and missing stuff, and been annoyed. It probably wasn't
>>>> gradle's
>>>> > > fault, though. Just a sloppy author. If I'm honest I wouldn't even
>>>> know
>>>> > if
>>>> > > I've ever consumed a non-maven artefact, certainly none of mine!  
>>>> :-)
>>>> > >
>>>> > > No, I am sure, I have, at least one, and it's an ant one with a  
>>>> hard
>>>> > coded
>>>> > > POM that doesn't always reflect the contents of the jar. Yuck.
>>>> Clearly
>>>> > not
>>>> > > an issue with automated stuff, though.
>>>> > >
>>>> > > My only argument now is ease of reading things like project
>>>> descriptions,
>>>> > > contributors, SCM details, etc rather than having to unpack the  
>>>> jar.
>>>> And
>>>> > if
>>>> > > you do, and end up with two pom.xmls laying around, that's not  
>>>> nice.
>>>> > Better
>>>> > > to just start always suffixing one with pom.xml.build or some  
>>>> such? I
>>>> > think
>>>> > > so, but I haven't thought deeply about it aside from reading this
>>>> thread.
>>>> > our consumer pom will be generated from build pom: we can automate  
>>>> copy
>>>> of
>>>> > any
>>>> > information we want, and for sure, I expect to put at least
>>>> description,
>>>> > scm
>>>> > details, issueManagement, license (of course).
>>>> > In your list, there is only constributors that I was not counting on
>>>> it:
>>>> > but
>>>> > it's a detailed decision we'll have to make
>>>> >
>>>> > for sure, Maven consumer poms, since generated from Maven build pom,
>>>> can
>>>> > have
>>>> > much more details (and be sure they are accurrate) than build tools
>>>> that
>>>> > don't
>>>> > generate it from data that exists in their original build format
>>>> >
>>>> > Regards,
>>>> >
>>>> > Hervé
>>>> >
>>>> > >
>>>> > >
>>>> > >
>>>> > > On Wed, Aug 24, 2016 at 6:32 PM, Hervé BOUTEMY <
>>>> herve.boutemy@free.fr
>>>> <javascript:;>>
>>>>
>>>> > >
>>>> > > wrote:
>>>> > > > Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit :
>>>> > > > > That should have separation between builder Pom and consumer  
>>>> Pom.
>>>> For
>>>> > > > > packaging=pom we deploy the builder Pom using classifier=build
>>>> > > > > *for all other packaging a we do not deploy the builder Pom*.
>>>> > > > >
>>>> > > > > I don't like the sound of this. The deployed artefacts should
>>>> include
>>>> > > > > the
>>>> > > > > exact POM in use to build the project, as a reference, even if
>>>> under
>>>> > a
>>>> > > > > different name. Yes, they should be in SCM, however down  
>>>> stream
>>>> it's
>>>> > > >
>>>> > > > useful
>>>> > > >
>>>> > > > > to see these even when the SCM is offline or gone or private  
>>>> or
>>>> > > > > whatever.
>>>> > > > > Or did I misunderstand? If so, please clarify?
>>>> > > >
>>>> > > > when you consume an artifact not build with Maven, do you get  
>>>> the
>>>> full
>>>> > > > build
>>>> > > > script?
>>>> > > > no
>>>> > > > I know that, as Maven users, we got used to have the build pom
>>>> > published
>>>> > > > in
>>>> > > > central: this is now an issue, but we like that
>>>> > > >
>>>> > > > notice: the build pom can be injected in the artifact, in
>>>> > META-INF/maven,
>>>> > > > like
>>>> > > > it is currently done
>>>> > > > but I don't see the point in requiring it to be pbulished
>>>> separately
>>>> in
>>>> > > > central: no other build tool does that, and they don't have any
>>>> issue
>>>> > with
>>>> > > > that (and eventually it's a feature: don't publish internal  
>>>> details
>>>> you
>>>> > > > don't
>>>> > > > really want people to see)
>>>> > > >
>>>> > > > Regards,
>>>> > > >
>>>> > > > Hervé
>>>> > > >
>>>> > > > > On Wed, Aug 24, 2016 at 1:52 PM, Stephen Connolly <
>>>> > > > >
>>>> > > > > stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>>>> > > > > > On Tuesday 23 August 2016, Paul Benedict  
>>>> <pbenedict@apache.org
>>>> <javascript:;>>
>>>>
>>>> > wrote:
>>>> > > > > > > On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <
>>>> > cs@schulte.it <javascript:;>
>>>> > > > > > >
>>>> > > > > > > <javascript:;>> wrote:
>>>> > > > > > > > Am 08/24/16 um 00:08 schrieb Paul Benedict:
>>>> > > > > > > > > POM and a future major version POM? I am hinting at a
>>>> > strategy
>>>> > > >
>>>> > > > for
>>>> > > >
>>>> > > > > > > > forward
>>>> > > > > > > >
>>>> > > > > > > > > compatibility.
>>>> > > > > > > >
>>>> > > > > > > > Is forward compatibility really needed/required?
>>>> > > > > > >
>>>> > > > > > > I honestly don't know, which is why I am asking. An  
>>>> answer of
>>>> "no
>>>> > > > > > > compatibility" is possible, too.
>>>> > > > > > >
>>>> > > > > > > I can completely see the argument that says POMs must be
>>>> > > > > > > all-parseable-or-nothing -- for the sake of  
>>>> reproducibility.
>>>> I
>>>> > > >
>>>> > > > actually
>>>> > > >
>>>> > > > > > > prefer this answer. I think it is sensible to fail a build
>>>> when
>>>> > > > > > > encountering a POM version too advanced. If your client  
>>>> only
>>>> > > >
>>>> > > > supports up
>>>> > > >
>>>> > > > > > to
>>>> > > > > >
>>>> > > > > > > model 4.0.0, then all artifacts must be specified by 4.0.0
>>>> > models,
>>>> > > >
>>>> > > > too.
>>>> > > >
>>>> > > > > > > On the other hand, I wanted to give the benefit of the  
>>>> doubt
>>>> to
>>>> > the
>>>> > > > > > > opposite argument. At least one person spoke up and said  
>>>> it's
>>>> > > > > >
>>>> > > > > > unacceptable
>>>> > > > > >
>>>> > > > > > > to fail a build on configuration you don't understand.  
>>>> Well,
>>>> > that's
>>>> > > >
>>>> > > > an
>>>> > > >
>>>> > > > > > > interesting argument, too. That person doesn't want to  
>>>> tank
>>>> the
>>>> > > > > > > build
>>>> > > > > > > for
>>>> > > > > > > the 1% of configuration that can't be understood.... but I
>>>> fail
>>>> > to
>>>> > > >
>>>> > > > see
>>>> > > >
>>>> > > > > > > an
>>>> > > > > > > escape hatch here. If a client can't understand what's  
>>>> being
>>>> > > >
>>>> > > > specified,
>>>> > > >
>>>> > > > > > > then what else can be done but fail?
>>>> > > > > >
>>>> > > > > > Strip the dependencies a and let the user fix up manually
>>>> (ideally
>>>> > by
>>>> > > > > > logging a warning that you are consuming a dependency using  
>>>> a
>>>> newer
>>>> > > > > > modelVersion)
>>>> > > > > >
>>>> > > > > > Everyone forgets that the 4.0.0 ship has sailed already, so  
>>>> we
>>>> > have to
>>>> > > > > > deploy best-effort 4.0.0 poms
>>>> > > > > >
>>>> > > > > > Now I say that 3.4 should not have a new modelVersion but  
>>>> what
>>>> it
>>>> > > >
>>>> > > > could do
>>>> > > >
>>>> > > > > > is be more forgiving of newer modelVersions or try and  
>>>> download
>>>> and
>>>> > > >
>>>> > > > use an
>>>> > > >
>>>> > > > > > XSLT to convert newer modelVersions to 4.0.0 (while logging  
>>>> a
>>>> > warning)
>>>> > > > > > with
>>>> > > > > > option flags to allow failing the build if XSLT had to be
>>>> applied
>>>> > > > > >
>>>> > > > > > So let's bump the modelVersion in Maven 5.0.0 (there is no
>>>> Maven
>>>> > 4.x
>>>> > > >
>>>> > > > let's
>>>> > > >
>>>> > > > > > align on the modelVersion)
>>>> > > > > >
>>>> > > > > > That should have separation between builder Pom and consumer
>>>> Pom.
>>>> > For
>>>> > > > > > packaging=pom we deploy the builder Pom using  
>>>> classifier=build
>>>> for
>>>> > all
>>>> > > > > > other packaging a we do not deploy the builder Pom.
>>>> > > > > >
>>>> > > > > > We deploy a *best effort* conversion of the consumer Pom to
>>>> > > >
>>>> > > > modelVersion
>>>> > > >
>>>> > > > > > 4.0.0 without a classifier and the consumer Pom gets  
>>>> deployed
>>>> as
>>>> > > > > > classifier
>>>> > > > > > consumer.
>>>> > > > > >
>>>> > > > > > The consumer Pom format allows for XSLT to transform to a
>>>> parsable
>>>> > > >
>>>> > > > syntax,
>>>> > > >
>>>> > > > > > if transform is required we log a warning (or fail the  
>>>> build if
>>>> the
>>>> > > > > > builder
>>>> > > > > > Pom indicates strict modelVersion adherence)
>>>> > > > > >
>>>> > > > > > So yeah maven 5.x will be able to parse dependencies with
>>>> > modelVersion
>>>> > > >
>>>> > > > 6.x
>>>> > > >
>>>> > > > > > while logging warnings that the user may not have the  
>>>> correct
>>>> > > >
>>>> > > > dependency
>>>> > > >
>>>> > > > > > tree. That is IMHO acceptable forward compatibility
>>>> > > > > >
>>>> > > > > > HTH
>>>> > > > > >
>>>> > > > > > -Stephen
>>>> > > > > >
>>>> > > > > > Ps I'm really hoping someone has a less crappy solution that
>>>> > this...
>>>> > > >
>>>> > > > But I
>>>> > > >
>>>> > > > > > believe this is actually *a* solution... And prior to this I
>>>> have
>>>> > not
>>>> > > >
>>>> > > > seen
>>>> > > >
>>>> > > > > > any solution
>>>> > > > > >
>>>> > > > > > > Cheers,
>>>> > > > > > > Paul
>>>> > > > > >
>>>> > > > > > --
>>>> > > > > > Sent from my phone
>>>> > > >
>>>> > > > ------------------------------------------------------------
>>>> ---------
>>>> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> <javascript:;>
>>>> > > > For additional commands, e-mail: dev-help@maven.apache.org
>>>> <javascript:;>
>>>> >
>>>> >
>>>> >  
>>>> ---------------------------------------------------------------------
>>>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> <javascript:;>
>>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>>> <javascript:;>
>>>> >
>>>> >
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>> 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: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Stephen Connolly <st...@gmail.com>]

On 24 August 2016 at 04:50, Robert Scholte <rf...@apache.org> wrote:

> I realized last ApacheCon that I wasn't clear about my definiton of the
> consumer-pom.
> I don't think it should be a flattened pom with only the dependency
> information. Instead it shouldn't be a pom  (matching the pom.xsd) at all.
>

I am not in disagreement, but as a concept the name "consumer pom" has more
traction.

I see the builder pom as probably ending up not even being XML at all.
Rather IMHO it will end up being a DSL that is easy to author and not
verbose... and certainly not XML

So the consumer pom should be stripped back to include two sets of
information:

* dependencies - we are mostly familiar with this... though we may not
expose all the scopes... depends on how we think about things and how we
view scopes moving forward

* provides - this is vitally important IMHO and not handled currently.

To understand provides we have to look at things like JavaEE (but the
concept has general utility... though I suspect only for about 10-25% of
projects)

If I have a project that says: provides javax.servlet:servlet-api:3.1 then
that is saying that my project is providing the equivalent content as in
javax.servlet:servlet-api:3.1 so for example org.jboss.spec.javax.servlet:
jboss-servlet-api_3.1_spec:1.0.0.Final would say
javax.servlet:servlet-api:3.1

When resolving the dependency tree, maven then knows that any transitive
requirement for javax.servlet:servlet-api:3.1 has already been met by my
direct dependency on org.jboss.spec.javax.servlet:jboss-servlet-api_3.1_spec
:1.0.0.Final if we have a direct dependency on
org.apache.tomcat:tomcat-servlet-api:8.5.4 (which would also say
javax.servlet:servlet-api:3.1) then Maven can report an error and fail the
build due to dependency conflict.

There are lots of other improvements we can add, but to start we need to
have a way to declare when a project includes duplicate content of another
artifact. Convention will be required to make this work correctly...
perhaps we can even introduce a new project type that provides needs to
point at so that a provides has to point at an "empty" specification
project...

Finally, for the consumer pom refactoring I believe we need to address
architecture specific artifacts as these are a sort of implicit provides.


> Maybe it should be called something like consumer-dom (dependency object
> model, though dom is confusing...).
> It should be the most fast and efficient way to resolve the dependency
> tree. That means it should do less roundtrips like Maven must do do right
> now: for every dependency download the pom, for all transitive dependencies
> download all poms, etc.
> Why can't it be a pom? I'd like to add the (file)extension too. Otherwise
> Maven needs to initialize the matching ArtifactHandler and translate the
> type to the proper extension.


I think the consumer pom needs to embed some of the artifact handler
information for it self as otherwise non-maven tooling cannot be expected
to understand those details... also we should be making the consumer pom
both Maven and Java agnostic... but this is a grand problem alright!


> The pom doesn't have room for this.
>

I saw the whole flattened pom experiment as mostly a waste of time for the
consumer pom effort as I envision the consumer pom not looking anything
like the current pom at all... but it is a project model...

Oh and the consumer pom should include information for the side-artifacts
(which would help with reusing tests as we could attach the test
dependencies to the test artifact details in the consumer pom)

Consumer-dom is an extraction and enriched version of the pom and will be a
> separate upload to the repository. Build tools who can understand this file
> can use it or fall back by downloading all poms.
>
> thanks,
> Robert
>
>
> On Wed, 24 Aug 2016 09:22:03 +0200, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> The consumer Pom is for machine to machine, it should be human readable
>> because that is nice, but intent is never human generated.
>>
>> Switching to this separation allows us to be more radical in the changes
>> to
>> the build Pom.
>>
>> The only reason we deploy packaging Pom's build Pom is for inheritance. If
>> we didn't have to deal with that we wouldn't need to deploy any build poms
>> ever.
>>
>> For using a build Pom as a parent, you implicitly pick up the minimum
>> version of maven that your parent requires, so we then are free to evolve
>> the build Pom format without worrying about forward compatibility, only
>> backwards compatibility on the *build* Pom.
>>
>> The consumer Pom needs partial *forward* compatibility, so that older
>> clients are able to *attempt* to consume...
>>
>> In short there are totally different compatibility constraints on the two,
>> so they should be separate.
>>
>> Mixins would probably also be deployed, once we figure out how they work
>> with build poms.
>>
>> I think we probably need to rethink version ranges. What I'd like is to
>> let
>> the consumer Pom treat version ranges more as guidance rather than hard
>> requirements. It's a pain if you depend transitiveky on Foo:[1.0] but need
>> Foo:[1.0.1,1.1) for the critical security fix... Having to run around
>> applying excludes is not a good plan... Yes the build should initially
>> fail
>> if I depend on [1.0] and [1.0.1,1.1) in my graph, but I should be able to
>> resolve the conflict for all my consumers (unless they pull in the
>> conflict
>> again themselves)
>>
>> On Tuesday 23 August 2016, Fred Cooke <fr...@gmail.com> wrote:
>>
>> I still find it a bit off that the original real POM won't always be
>>> directly available anymore.
>>>
>>> Other tools create fake POMs because they *have* to - there's no other
>>> option.
>>>
>>> I feel like some fidelity would be lost. Diffability would be lost (from
>>> a
>>> scenario where there's nothing to diff).
>>>
>>> Unrelated, really, but kind of related: top level deployable artefact
>>> deployments, debs, wars, exes, etc. When ranges are in use it'd be nice
>>> to
>>> deploy a sort of strict effective pom with fully hard [] versions for all
>>> things. This can be achieved in other ways, though.
>>>
>>> I guess that is to say, don't forget about non-central deployments. I
>>> suppose if there's a way to always deploy pom.xml.build through some
>>> plugin
>>> or configuration or some such, then that's fine with me.
>>>
>>> On Wed, Aug 24, 2016 at 6:49 PM, Hervé BOUTEMY <herve.boutemy@free.fr
>>> <javascript:;>>
>>>
>>> wrote:
>>>
>>> > Le mercredi 24 août 2016 18:41:59 Fred Cooke a écrit :
>>> > > Fair call re embedded pom, however it's quite convenient to just
>>> browse
>>> > to
>>> > > it and read.
>>> > >
>>> > > I've occasionally gone looking for details from poms of artefacts and
>>> > found
>>> > > a mess and missing stuff, and been annoyed. It probably wasn't
>>> gradle's
>>> > > fault, though. Just a sloppy author. If I'm honest I wouldn't even
>>> know
>>> > if
>>> > > I've ever consumed a non-maven artefact, certainly none of mine! :-)
>>> > >
>>> > > No, I am sure, I have, at least one, and it's an ant one with a hard
>>> > coded
>>> > > POM that doesn't always reflect the contents of the jar. Yuck.
>>> Clearly
>>> > not
>>> > > an issue with automated stuff, though.
>>> > >
>>> > > My only argument now is ease of reading things like project
>>> descriptions,
>>> > > contributors, SCM details, etc rather than having to unpack the jar.
>>> And
>>> > if
>>> > > you do, and end up with two pom.xmls laying around, that's not nice.
>>> > Better
>>> > > to just start always suffixing one with pom.xml.build or some such? I
>>> > think
>>> > > so, but I haven't thought deeply about it aside from reading this
>>> thread.
>>> > our consumer pom will be generated from build pom: we can automate copy
>>> of
>>> > any
>>> > information we want, and for sure, I expect to put at least
>>> description,
>>> > scm
>>> > details, issueManagement, license (of course).
>>> > In your list, there is only constributors that I was not counting on
>>> it:
>>> > but
>>> > it's a detailed decision we'll have to make
>>> >
>>> > for sure, Maven consumer poms, since generated from Maven build pom,
>>> can
>>> > have
>>> > much more details (and be sure they are accurrate) than build tools
>>> that
>>> > don't
>>> > generate it from data that exists in their original build format
>>> >
>>> > Regards,
>>> >
>>> > Hervé
>>> >
>>> > >
>>> > >
>>> > >
>>> > > On Wed, Aug 24, 2016 at 6:32 PM, Hervé BOUTEMY <
>>> herve.boutemy@free.fr
>>> <javascript:;>>
>>>
>>> > >
>>> > > wrote:
>>> > > > Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit :
>>> > > > > That should have separation between builder Pom and consumer Pom.
>>> For
>>> > > > > packaging=pom we deploy the builder Pom using classifier=build
>>> > > > > *for all other packaging a we do not deploy the builder Pom*.
>>> > > > >
>>> > > > > I don't like the sound of this. The deployed artefacts should
>>> include
>>> > > > > the
>>> > > > > exact POM in use to build the project, as a reference, even if
>>> under
>>> > a
>>> > > > > different name. Yes, they should be in SCM, however down stream
>>> it's
>>> > > >
>>> > > > useful
>>> > > >
>>> > > > > to see these even when the SCM is offline or gone or private or
>>> > > > > whatever.
>>> > > > > Or did I misunderstand? If so, please clarify?
>>> > > >
>>> > > > when you consume an artifact not build with Maven, do you get the
>>> full
>>> > > > build
>>> > > > script?
>>> > > > no
>>> > > > I know that, as Maven users, we got used to have the build pom
>>> > published
>>> > > > in
>>> > > > central: this is now an issue, but we like that
>>> > > >
>>> > > > notice: the build pom can be injected in the artifact, in
>>> > META-INF/maven,
>>> > > > like
>>> > > > it is currently done
>>> > > > but I don't see the point in requiring it to be pbulished
>>> separately
>>> in
>>> > > > central: no other build tool does that, and they don't have any
>>> issue
>>> > with
>>> > > > that (and eventually it's a feature: don't publish internal details
>>> you
>>> > > > don't
>>> > > > really want people to see)
>>> > > >
>>> > > > Regards,
>>> > > >
>>> > > > Hervé
>>> > > >
>>> > > > > On Wed, Aug 24, 2016 at 1:52 PM, Stephen Connolly <
>>> > > > >
>>> > > > > stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>>> > > > > > On Tuesday 23 August 2016, Paul Benedict <pbenedict@apache.org
>>> <javascript:;>>
>>>
>>> > wrote:
>>> > > > > > > On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <
>>> > cs@schulte.it <javascript:;>
>>> > > > > > >
>>> > > > > > > <javascript:;>> wrote:
>>> > > > > > > > Am 08/24/16 um 00:08 schrieb Paul Benedict:
>>> > > > > > > > > POM and a future major version POM? I am hinting at a
>>> > strategy
>>> > > >
>>> > > > for
>>> > > >
>>> > > > > > > > forward
>>> > > > > > > >
>>> > > > > > > > > compatibility.
>>> > > > > > > >
>>> > > > > > > > Is forward compatibility really needed/required?
>>> > > > > > >
>>> > > > > > > I honestly don't know, which is why I am asking. An answer of
>>> "no
>>> > > > > > > compatibility" is possible, too.
>>> > > > > > >
>>> > > > > > > I can completely see the argument that says POMs must be
>>> > > > > > > all-parseable-or-nothing -- for the sake of reproducibility.
>>> I
>>> > > >
>>> > > > actually
>>> > > >
>>> > > > > > > prefer this answer. I think it is sensible to fail a build
>>> when
>>> > > > > > > encountering a POM version too advanced. If your client only
>>> > > >
>>> > > > supports up
>>> > > >
>>> > > > > > to
>>> > > > > >
>>> > > > > > > model 4.0.0, then all artifacts must be specified by 4.0.0
>>> > models,
>>> > > >
>>> > > > too.
>>> > > >
>>> > > > > > > On the other hand, I wanted to give the benefit of the doubt
>>> to
>>> > the
>>> > > > > > > opposite argument. At least one person spoke up and said it's
>>> > > > > >
>>> > > > > > unacceptable
>>> > > > > >
>>> > > > > > > to fail a build on configuration you don't understand. Well,
>>> > that's
>>> > > >
>>> > > > an
>>> > > >
>>> > > > > > > interesting argument, too. That person doesn't want to tank
>>> the
>>> > > > > > > build
>>> > > > > > > for
>>> > > > > > > the 1% of configuration that can't be understood.... but I
>>> fail
>>> > to
>>> > > >
>>> > > > see
>>> > > >
>>> > > > > > > an
>>> > > > > > > escape hatch here. If a client can't understand what's being
>>> > > >
>>> > > > specified,
>>> > > >
>>> > > > > > > then what else can be done but fail?
>>> > > > > >
>>> > > > > > Strip the dependencies a and let the user fix up manually
>>> (ideally
>>> > by
>>> > > > > > logging a warning that you are consuming a dependency using a
>>> newer
>>> > > > > > modelVersion)
>>> > > > > >
>>> > > > > > Everyone forgets that the 4.0.0 ship has sailed already, so we
>>> > have to
>>> > > > > > deploy best-effort 4.0.0 poms
>>> > > > > >
>>> > > > > > Now I say that 3.4 should not have a new modelVersion but what
>>> it
>>> > > >
>>> > > > could do
>>> > > >
>>> > > > > > is be more forgiving of newer modelVersions or try and download
>>> and
>>> > > >
>>> > > > use an
>>> > > >
>>> > > > > > XSLT to convert newer modelVersions to 4.0.0 (while logging a
>>> > warning)
>>> > > > > > with
>>> > > > > > option flags to allow failing the build if XSLT had to be
>>> applied
>>> > > > > >
>>> > > > > > So let's bump the modelVersion in Maven 5.0.0 (there is no
>>> Maven
>>> > 4.x
>>> > > >
>>> > > > let's
>>> > > >
>>> > > > > > align on the modelVersion)
>>> > > > > >
>>> > > > > > That should have separation between builder Pom and consumer
>>> Pom.
>>> > For
>>> > > > > > packaging=pom we deploy the builder Pom using classifier=build
>>> for
>>> > all
>>> > > > > > other packaging a we do not deploy the builder Pom.
>>> > > > > >
>>> > > > > > We deploy a *best effort* conversion of the consumer Pom to
>>> > > >
>>> > > > modelVersion
>>> > > >
>>> > > > > > 4.0.0 without a classifier and the consumer Pom gets deployed
>>> as
>>> > > > > > classifier
>>> > > > > > consumer.
>>> > > > > >
>>> > > > > > The consumer Pom format allows for XSLT to transform to a
>>> parsable
>>> > > >
>>> > > > syntax,
>>> > > >
>>> > > > > > if transform is required we log a warning (or fail the build if
>>> the
>>> > > > > > builder
>>> > > > > > Pom indicates strict modelVersion adherence)
>>> > > > > >
>>> > > > > > So yeah maven 5.x will be able to parse dependencies with
>>> > modelVersion
>>> > > >
>>> > > > 6.x
>>> > > >
>>> > > > > > while logging warnings that the user may not have the correct
>>> > > >
>>> > > > dependency
>>> > > >
>>> > > > > > tree. That is IMHO acceptable forward compatibility
>>> > > > > >
>>> > > > > > HTH
>>> > > > > >
>>> > > > > > -Stephen
>>> > > > > >
>>> > > > > > Ps I'm really hoping someone has a less crappy solution that
>>> > this...
>>> > > >
>>> > > > But I
>>> > > >
>>> > > > > > believe this is actually *a* solution... And prior to this I
>>> have
>>> > not
>>> > > >
>>> > > > seen
>>> > > >
>>> > > > > > any solution
>>> > > > > >
>>> > > > > > > Cheers,
>>> > > > > > > Paul
>>> > > > > >
>>> > > > > > --
>>> > > > > > Sent from my phone
>>> > > >
>>> > > > ------------------------------------------------------------
>>> ---------
>>> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> <javascript:;>
>>> > > > For additional commands, e-mail: dev-help@maven.apache.org
>>> <javascript:;>
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> <javascript:;>
>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>> <javascript:;>
>>> >
>>> >
>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Robert Scholte <rf...@apache.org>]

I realized last ApacheCon that I wasn't clear about my definiton of the  
consumer-pom.
I don't think it should be a flattened pom with only the dependency  
information. Instead it shouldn't be a pom  (matching the pom.xsd) at all.
Maybe it should be called something like consumer-dom (dependency object  
model, though dom is confusing...).
It should be the most fast and efficient way to resolve the dependency  
tree. That means it should do less roundtrips like Maven must do do right  
now: for every dependency download the pom, for all transitive  
dependencies download all poms, etc.
Why can't it be a pom? I'd like to add the (file)extension too. Otherwise  
Maven needs to initialize the matching ArtifactHandler and translate the  
type to the proper extension. The pom doesn't have room for this.
Consumer-dom is an extraction and enriched version of the pom and will be  
a separate upload to the repository. Build tools who can understand this  
file can use it or fall back by downloading all poms.

thanks,
Robert

On Wed, 24 Aug 2016 09:22:03 +0200, Stephen Connolly  
<st...@gmail.com> wrote:

> The consumer Pom is for machine to machine, it should be human readable
> because that is nice, but intent is never human generated.
>
> Switching to this separation allows us to be more radical in the changes  
> to
> the build Pom.
>
> The only reason we deploy packaging Pom's build Pom is for inheritance.  
> If
> we didn't have to deal with that we wouldn't need to deploy any build  
> poms
> ever.
>
> For using a build Pom as a parent, you implicitly pick up the minimum
> version of maven that your parent requires, so we then are free to evolve
> the build Pom format without worrying about forward compatibility, only
> backwards compatibility on the *build* Pom.
>
> The consumer Pom needs partial *forward* compatibility, so that older
> clients are able to *attempt* to consume...
>
> In short there are totally different compatibility constraints on the  
> two,
> so they should be separate.
>
> Mixins would probably also be deployed, once we figure out how they work
> with build poms.
>
> I think we probably need to rethink version ranges. What I'd like is to  
> let
> the consumer Pom treat version ranges more as guidance rather than hard
> requirements. It's a pain if you depend transitiveky on Foo:[1.0] but  
> need
> Foo:[1.0.1,1.1) for the critical security fix... Having to run around
> applying excludes is not a good plan... Yes the build should initially  
> fail
> if I depend on [1.0] and [1.0.1,1.1) in my graph, but I should be able to
> resolve the conflict for all my consumers (unless they pull in the  
> conflict
> again themselves)
>
> On Tuesday 23 August 2016, Fred Cooke <fr...@gmail.com> wrote:
>
>> I still find it a bit off that the original real POM won't always be
>> directly available anymore.
>>
>> Other tools create fake POMs because they *have* to - there's no other
>> option.
>>
>> I feel like some fidelity would be lost. Diffability would be lost  
>> (from a
>> scenario where there's nothing to diff).
>>
>> Unrelated, really, but kind of related: top level deployable artefact
>> deployments, debs, wars, exes, etc. When ranges are in use it'd be nice  
>> to
>> deploy a sort of strict effective pom with fully hard [] versions for  
>> all
>> things. This can be achieved in other ways, though.
>>
>> I guess that is to say, don't forget about non-central deployments. I
>> suppose if there's a way to always deploy pom.xml.build through some  
>> plugin
>> or configuration or some such, then that's fine with me.
>>
>> On Wed, Aug 24, 2016 at 6:49 PM, Hervé BOUTEMY <herve.boutemy@free.fr
>> <javascript:;>>
>> wrote:
>>
>> > Le mercredi 24 août 2016 18:41:59 Fred Cooke a écrit :
>> > > Fair call re embedded pom, however it's quite convenient to just  
>> browse
>> > to
>> > > it and read.
>> > >
>> > > I've occasionally gone looking for details from poms of artefacts  
>> and
>> > found
>> > > a mess and missing stuff, and been annoyed. It probably wasn't  
>> gradle's
>> > > fault, though. Just a sloppy author. If I'm honest I wouldn't even  
>> know
>> > if
>> > > I've ever consumed a non-maven artefact, certainly none of mine! :-)
>> > >
>> > > No, I am sure, I have, at least one, and it's an ant one with a hard
>> > coded
>> > > POM that doesn't always reflect the contents of the jar. Yuck.  
>> Clearly
>> > not
>> > > an issue with automated stuff, though.
>> > >
>> > > My only argument now is ease of reading things like project
>> descriptions,
>> > > contributors, SCM details, etc rather than having to unpack the jar.
>> And
>> > if
>> > > you do, and end up with two pom.xmls laying around, that's not nice.
>> > Better
>> > > to just start always suffixing one with pom.xml.build or some such?  
>> I
>> > think
>> > > so, but I haven't thought deeply about it aside from reading this
>> thread.
>> > our consumer pom will be generated from build pom: we can automate  
>> copy
>> of
>> > any
>> > information we want, and for sure, I expect to put at least  
>> description,
>> > scm
>> > details, issueManagement, license (of course).
>> > In your list, there is only constributors that I was not counting on  
>> it:
>> > but
>> > it's a detailed decision we'll have to make
>> >
>> > for sure, Maven consumer poms, since generated from Maven build pom,  
>> can
>> > have
>> > much more details (and be sure they are accurrate) than build tools  
>> that
>> > don't
>> > generate it from data that exists in their original build format
>> >
>> > Regards,
>> >
>> > Hervé
>> >
>> > >
>> > >
>> > >
>> > > On Wed, Aug 24, 2016 at 6:32 PM, Hervé BOUTEMY  
>> <herve.boutemy@free.fr
>> <javascript:;>>
>> > >
>> > > wrote:
>> > > > Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit :
>> > > > > That should have separation between builder Pom and consumer  
>> Pom.
>> For
>> > > > > packaging=pom we deploy the builder Pom using classifier=build
>> > > > > *for all other packaging a we do not deploy the builder Pom*.
>> > > > >
>> > > > > I don't like the sound of this. The deployed artefacts should
>> include
>> > > > > the
>> > > > > exact POM in use to build the project, as a reference, even if
>> under
>> > a
>> > > > > different name. Yes, they should be in SCM, however down stream
>> it's
>> > > >
>> > > > useful
>> > > >
>> > > > > to see these even when the SCM is offline or gone or private or
>> > > > > whatever.
>> > > > > Or did I misunderstand? If so, please clarify?
>> > > >
>> > > > when you consume an artifact not build with Maven, do you get the
>> full
>> > > > build
>> > > > script?
>> > > > no
>> > > > I know that, as Maven users, we got used to have the build pom
>> > published
>> > > > in
>> > > > central: this is now an issue, but we like that
>> > > >
>> > > > notice: the build pom can be injected in the artifact, in
>> > META-INF/maven,
>> > > > like
>> > > > it is currently done
>> > > > but I don't see the point in requiring it to be pbulished  
>> separately
>> in
>> > > > central: no other build tool does that, and they don't have any  
>> issue
>> > with
>> > > > that (and eventually it's a feature: don't publish internal  
>> details
>> you
>> > > > don't
>> > > > really want people to see)
>> > > >
>> > > > Regards,
>> > > >
>> > > > Hervé
>> > > >
>> > > > > On Wed, Aug 24, 2016 at 1:52 PM, Stephen Connolly <
>> > > > >
>> > > > > stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>> > > > > > On Tuesday 23 August 2016, Paul Benedict <pbenedict@apache.org
>> <javascript:;>>
>> > wrote:
>> > > > > > > On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <
>> > cs@schulte.it <javascript:;>
>> > > > > > >
>> > > > > > > <javascript:;>> wrote:
>> > > > > > > > Am 08/24/16 um 00:08 schrieb Paul Benedict:
>> > > > > > > > > POM and a future major version POM? I am hinting at a
>> > strategy
>> > > >
>> > > > for
>> > > >
>> > > > > > > > forward
>> > > > > > > >
>> > > > > > > > > compatibility.
>> > > > > > > >
>> > > > > > > > Is forward compatibility really needed/required?
>> > > > > > >
>> > > > > > > I honestly don't know, which is why I am asking. An answer  
>> of
>> "no
>> > > > > > > compatibility" is possible, too.
>> > > > > > >
>> > > > > > > I can completely see the argument that says POMs must be
>> > > > > > > all-parseable-or-nothing -- for the sake of  
>> reproducibility. I
>> > > >
>> > > > actually
>> > > >
>> > > > > > > prefer this answer. I think it is sensible to fail a build  
>> when
>> > > > > > > encountering a POM version too advanced. If your client only
>> > > >
>> > > > supports up
>> > > >
>> > > > > > to
>> > > > > >
>> > > > > > > model 4.0.0, then all artifacts must be specified by 4.0.0
>> > models,
>> > > >
>> > > > too.
>> > > >
>> > > > > > > On the other hand, I wanted to give the benefit of the  
>> doubt to
>> > the
>> > > > > > > opposite argument. At least one person spoke up and said  
>> it's
>> > > > > >
>> > > > > > unacceptable
>> > > > > >
>> > > > > > > to fail a build on configuration you don't understand. Well,
>> > that's
>> > > >
>> > > > an
>> > > >
>> > > > > > > interesting argument, too. That person doesn't want to tank  
>> the
>> > > > > > > build
>> > > > > > > for
>> > > > > > > the 1% of configuration that can't be understood.... but I  
>> fail
>> > to
>> > > >
>> > > > see
>> > > >
>> > > > > > > an
>> > > > > > > escape hatch here. If a client can't understand what's being
>> > > >
>> > > > specified,
>> > > >
>> > > > > > > then what else can be done but fail?
>> > > > > >
>> > > > > > Strip the dependencies a and let the user fix up manually
>> (ideally
>> > by
>> > > > > > logging a warning that you are consuming a dependency using a
>> newer
>> > > > > > modelVersion)
>> > > > > >
>> > > > > > Everyone forgets that the 4.0.0 ship has sailed already, so we
>> > have to
>> > > > > > deploy best-effort 4.0.0 poms
>> > > > > >
>> > > > > > Now I say that 3.4 should not have a new modelVersion but  
>> what it
>> > > >
>> > > > could do
>> > > >
>> > > > > > is be more forgiving of newer modelVersions or try and  
>> download
>> and
>> > > >
>> > > > use an
>> > > >
>> > > > > > XSLT to convert newer modelVersions to 4.0.0 (while logging a
>> > warning)
>> > > > > > with
>> > > > > > option flags to allow failing the build if XSLT had to be  
>> applied
>> > > > > >
>> > > > > > So let's bump the modelVersion in Maven 5.0.0 (there is no  
>> Maven
>> > 4.x
>> > > >
>> > > > let's
>> > > >
>> > > > > > align on the modelVersion)
>> > > > > >
>> > > > > > That should have separation between builder Pom and consumer  
>> Pom.
>> > For
>> > > > > > packaging=pom we deploy the builder Pom using classifier=build
>> for
>> > all
>> > > > > > other packaging a we do not deploy the builder Pom.
>> > > > > >
>> > > > > > We deploy a *best effort* conversion of the consumer Pom to
>> > > >
>> > > > modelVersion
>> > > >
>> > > > > > 4.0.0 without a classifier and the consumer Pom gets deployed  
>> as
>> > > > > > classifier
>> > > > > > consumer.
>> > > > > >
>> > > > > > The consumer Pom format allows for XSLT to transform to a
>> parsable
>> > > >
>> > > > syntax,
>> > > >
>> > > > > > if transform is required we log a warning (or fail the build  
>> if
>> the
>> > > > > > builder
>> > > > > > Pom indicates strict modelVersion adherence)
>> > > > > >
>> > > > > > So yeah maven 5.x will be able to parse dependencies with
>> > modelVersion
>> > > >
>> > > > 6.x
>> > > >
>> > > > > > while logging warnings that the user may not have the correct
>> > > >
>> > > > dependency
>> > > >
>> > > > > > tree. That is IMHO acceptable forward compatibility
>> > > > > >
>> > > > > > HTH
>> > > > > >
>> > > > > > -Stephen
>> > > > > >
>> > > > > > Ps I'm really hoping someone has a less crappy solution that
>> > this...
>> > > >
>> > > > But I
>> > > >
>> > > > > > believe this is actually *a* solution... And prior to this I  
>> have
>> > not
>> > > >
>> > > > seen
>> > > >
>> > > > > > any solution
>> > > > > >
>> > > > > > > Cheers,
>> > > > > > > Paul
>> > > > > >
>> > > > > > --
>> > > > > > Sent from my phone
>> > > >
>> > > > ------------------------------------------------------------
>> ---------
>> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> <javascript:;>
>> > > > For additional commands, e-mail: dev-help@maven.apache.org
>> <javascript:;>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org  
>> <javascript:;>
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> <javascript:;>
>> >
>> >
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 08/24/16 um 09:22 schrieb Stephen Connolly:
> I think we probably need to rethink version ranges. What I'd like is to let
> the consumer Pom treat version ranges more as guidance rather than hard
> requirements. It's a pain if you depend transitiveky on Foo:[1.0] but need
> Foo:[1.0.1,1.1) for the critical security fix... Having to run around
> applying excludes is not a good plan... Yes the build should initially fail
> if I depend on [1.0] and [1.0.1,1.1) in my graph, but I should be able to
> resolve the conflict for all my consumers (unless they pull in the conflict
> again themselves)

This could be solved using dependency management. See the following
links. This is yet another change in semantics of the consumer pom, not
the syntax. This cannot be solved using XSLT. We need to apply some kind
of versioning like the model version for the consumer pom as well.

[0] <https://issues.apache.org/jira/browse/MNG-5761>
[1]
<https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=d69dd31389b62264686e339e6c60dc5d7c26d4b1>

Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Stephen Connolly <st...@gmail.com>]

The consumer Pom is for machine to machine, it should be human readable
because that is nice, but intent is never human generated.

Switching to this separation allows us to be more radical in the changes to
the build Pom.

The only reason we deploy packaging Pom's build Pom is for inheritance. If
we didn't have to deal with that we wouldn't need to deploy any build poms
ever.

For using a build Pom as a parent, you implicitly pick up the minimum
version of maven that your parent requires, so we then are free to evolve
the build Pom format without worrying about forward compatibility, only
backwards compatibility on the *build* Pom.

The consumer Pom needs partial *forward* compatibility, so that older
clients are able to *attempt* to consume...

In short there are totally different compatibility constraints on the two,
so they should be separate.

Mixins would probably also be deployed, once we figure out how they work
with build poms.

I think we probably need to rethink version ranges. What I'd like is to let
the consumer Pom treat version ranges more as guidance rather than hard
requirements. It's a pain if you depend transitiveky on Foo:[1.0] but need
Foo:[1.0.1,1.1) for the critical security fix... Having to run around
applying excludes is not a good plan... Yes the build should initially fail
if I depend on [1.0] and [1.0.1,1.1) in my graph, but I should be able to
resolve the conflict for all my consumers (unless they pull in the conflict
again themselves)

On Tuesday 23 August 2016, Fred Cooke <fr...@gmail.com> wrote:

> I still find it a bit off that the original real POM won't always be
> directly available anymore.
>
> Other tools create fake POMs because they *have* to - there's no other
> option.
>
> I feel like some fidelity would be lost. Diffability would be lost (from a
> scenario where there's nothing to diff).
>
> Unrelated, really, but kind of related: top level deployable artefact
> deployments, debs, wars, exes, etc. When ranges are in use it'd be nice to
> deploy a sort of strict effective pom with fully hard [] versions for all
> things. This can be achieved in other ways, though.
>
> I guess that is to say, don't forget about non-central deployments. I
> suppose if there's a way to always deploy pom.xml.build through some plugin
> or configuration or some such, then that's fine with me.
>
> On Wed, Aug 24, 2016 at 6:49 PM, Hervé BOUTEMY <herve.boutemy@free.fr
> <javascript:;>>
> wrote:
>
> > Le mercredi 24 août 2016 18:41:59 Fred Cooke a écrit :
> > > Fair call re embedded pom, however it's quite convenient to just browse
> > to
> > > it and read.
> > >
> > > I've occasionally gone looking for details from poms of artefacts and
> > found
> > > a mess and missing stuff, and been annoyed. It probably wasn't gradle's
> > > fault, though. Just a sloppy author. If I'm honest I wouldn't even know
> > if
> > > I've ever consumed a non-maven artefact, certainly none of mine! :-)
> > >
> > > No, I am sure, I have, at least one, and it's an ant one with a hard
> > coded
> > > POM that doesn't always reflect the contents of the jar. Yuck. Clearly
> > not
> > > an issue with automated stuff, though.
> > >
> > > My only argument now is ease of reading things like project
> descriptions,
> > > contributors, SCM details, etc rather than having to unpack the jar.
> And
> > if
> > > you do, and end up with two pom.xmls laying around, that's not nice.
> > Better
> > > to just start always suffixing one with pom.xml.build or some such? I
> > think
> > > so, but I haven't thought deeply about it aside from reading this
> thread.
> > our consumer pom will be generated from build pom: we can automate copy
> of
> > any
> > information we want, and for sure, I expect to put at least description,
> > scm
> > details, issueManagement, license (of course).
> > In your list, there is only constributors that I was not counting on it:
> > but
> > it's a detailed decision we'll have to make
> >
> > for sure, Maven consumer poms, since generated from Maven build pom, can
> > have
> > much more details (and be sure they are accurrate) than build tools that
> > don't
> > generate it from data that exists in their original build format
> >
> > Regards,
> >
> > Hervé
> >
> > >
> > >
> > >
> > > On Wed, Aug 24, 2016 at 6:32 PM, Hervé BOUTEMY <herve.boutemy@free.fr
> <javascript:;>>
> > >
> > > wrote:
> > > > Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit :
> > > > > That should have separation between builder Pom and consumer Pom.
> For
> > > > > packaging=pom we deploy the builder Pom using classifier=build
> > > > > *for all other packaging a we do not deploy the builder Pom*.
> > > > >
> > > > > I don't like the sound of this. The deployed artefacts should
> include
> > > > > the
> > > > > exact POM in use to build the project, as a reference, even if
> under
> > a
> > > > > different name. Yes, they should be in SCM, however down stream
> it's
> > > >
> > > > useful
> > > >
> > > > > to see these even when the SCM is offline or gone or private or
> > > > > whatever.
> > > > > Or did I misunderstand? If so, please clarify?
> > > >
> > > > when you consume an artifact not build with Maven, do you get the
> full
> > > > build
> > > > script?
> > > > no
> > > > I know that, as Maven users, we got used to have the build pom
> > published
> > > > in
> > > > central: this is now an issue, but we like that
> > > >
> > > > notice: the build pom can be injected in the artifact, in
> > META-INF/maven,
> > > > like
> > > > it is currently done
> > > > but I don't see the point in requiring it to be pbulished separately
> in
> > > > central: no other build tool does that, and they don't have any issue
> > with
> > > > that (and eventually it's a feature: don't publish internal details
> you
> > > > don't
> > > > really want people to see)
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > > On Wed, Aug 24, 2016 at 1:52 PM, Stephen Connolly <
> > > > >
> > > > > stephen.alan.connolly@gmail.com <javascript:;>> wrote:
> > > > > > On Tuesday 23 August 2016, Paul Benedict <pbenedict@apache.org
> <javascript:;>>
> > wrote:
> > > > > > > On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <
> > cs@schulte.it <javascript:;>
> > > > > > >
> > > > > > > <javascript:;>> wrote:
> > > > > > > > Am 08/24/16 um 00:08 schrieb Paul Benedict:
> > > > > > > > > POM and a future major version POM? I am hinting at a
> > strategy
> > > >
> > > > for
> > > >
> > > > > > > > forward
> > > > > > > >
> > > > > > > > > compatibility.
> > > > > > > >
> > > > > > > > Is forward compatibility really needed/required?
> > > > > > >
> > > > > > > I honestly don't know, which is why I am asking. An answer of
> "no
> > > > > > > compatibility" is possible, too.
> > > > > > >
> > > > > > > I can completely see the argument that says POMs must be
> > > > > > > all-parseable-or-nothing -- for the sake of reproducibility. I
> > > >
> > > > actually
> > > >
> > > > > > > prefer this answer. I think it is sensible to fail a build when
> > > > > > > encountering a POM version too advanced. If your client only
> > > >
> > > > supports up
> > > >
> > > > > > to
> > > > > >
> > > > > > > model 4.0.0, then all artifacts must be specified by 4.0.0
> > models,
> > > >
> > > > too.
> > > >
> > > > > > > On the other hand, I wanted to give the benefit of the doubt to
> > the
> > > > > > > opposite argument. At least one person spoke up and said it's
> > > > > >
> > > > > > unacceptable
> > > > > >
> > > > > > > to fail a build on configuration you don't understand. Well,
> > that's
> > > >
> > > > an
> > > >
> > > > > > > interesting argument, too. That person doesn't want to tank the
> > > > > > > build
> > > > > > > for
> > > > > > > the 1% of configuration that can't be understood.... but I fail
> > to
> > > >
> > > > see
> > > >
> > > > > > > an
> > > > > > > escape hatch here. If a client can't understand what's being
> > > >
> > > > specified,
> > > >
> > > > > > > then what else can be done but fail?
> > > > > >
> > > > > > Strip the dependencies a and let the user fix up manually
> (ideally
> > by
> > > > > > logging a warning that you are consuming a dependency using a
> newer
> > > > > > modelVersion)
> > > > > >
> > > > > > Everyone forgets that the 4.0.0 ship has sailed already, so we
> > have to
> > > > > > deploy best-effort 4.0.0 poms
> > > > > >
> > > > > > Now I say that 3.4 should not have a new modelVersion but what it
> > > >
> > > > could do
> > > >
> > > > > > is be more forgiving of newer modelVersions or try and download
> and
> > > >
> > > > use an
> > > >
> > > > > > XSLT to convert newer modelVersions to 4.0.0 (while logging a
> > warning)
> > > > > > with
> > > > > > option flags to allow failing the build if XSLT had to be applied
> > > > > >
> > > > > > So let's bump the modelVersion in Maven 5.0.0 (there is no Maven
> > 4.x
> > > >
> > > > let's
> > > >
> > > > > > align on the modelVersion)
> > > > > >
> > > > > > That should have separation between builder Pom and consumer Pom.
> > For
> > > > > > packaging=pom we deploy the builder Pom using classifier=build
> for
> > all
> > > > > > other packaging a we do not deploy the builder Pom.
> > > > > >
> > > > > > We deploy a *best effort* conversion of the consumer Pom to
> > > >
> > > > modelVersion
> > > >
> > > > > > 4.0.0 without a classifier and the consumer Pom gets deployed as
> > > > > > classifier
> > > > > > consumer.
> > > > > >
> > > > > > The consumer Pom format allows for XSLT to transform to a
> parsable
> > > >
> > > > syntax,
> > > >
> > > > > > if transform is required we log a warning (or fail the build if
> the
> > > > > > builder
> > > > > > Pom indicates strict modelVersion adherence)
> > > > > >
> > > > > > So yeah maven 5.x will be able to parse dependencies with
> > modelVersion
> > > >
> > > > 6.x
> > > >
> > > > > > while logging warnings that the user may not have the correct
> > > >
> > > > dependency
> > > >
> > > > > > tree. That is IMHO acceptable forward compatibility
> > > > > >
> > > > > > HTH
> > > > > >
> > > > > > -Stephen
> > > > > >
> > > > > > Ps I'm really hoping someone has a less crappy solution that
> > this...
> > > >
> > > > But I
> > > >
> > > > > > believe this is actually *a* solution... And prior to this I have
> > not
> > > >
> > > > seen
> > > >
> > > > > > any solution
> > > > > >
> > > > > > > Cheers,
> > > > > > > Paul
> > > > > >
> > > > > > --
> > > > > > Sent from my phone
> > > >
> > > > ------------------------------------------------------------
> ---------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> <javascript:;>
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> > For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;>
> >
> >
>


-- 
Sent from my phone

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Fred Cooke <fr...@gmail.com>]

I still find it a bit off that the original real POM won't always be
directly available anymore.

Other tools create fake POMs because they *have* to - there's no other
option.

I feel like some fidelity would be lost. Diffability would be lost (from a
scenario where there's nothing to diff).

Unrelated, really, but kind of related: top level deployable artefact
deployments, debs, wars, exes, etc. When ranges are in use it'd be nice to
deploy a sort of strict effective pom with fully hard [] versions for all
things. This can be achieved in other ways, though.

I guess that is to say, don't forget about non-central deployments. I
suppose if there's a way to always deploy pom.xml.build through some plugin
or configuration or some such, then that's fine with me.

On Wed, Aug 24, 2016 at 6:49 PM, Hervé BOUTEMY <he...@free.fr>
wrote:

> Le mercredi 24 août 2016 18:41:59 Fred Cooke a écrit :
> > Fair call re embedded pom, however it's quite convenient to just browse
> to
> > it and read.
> >
> > I've occasionally gone looking for details from poms of artefacts and
> found
> > a mess and missing stuff, and been annoyed. It probably wasn't gradle's
> > fault, though. Just a sloppy author. If I'm honest I wouldn't even know
> if
> > I've ever consumed a non-maven artefact, certainly none of mine! :-)
> >
> > No, I am sure, I have, at least one, and it's an ant one with a hard
> coded
> > POM that doesn't always reflect the contents of the jar. Yuck. Clearly
> not
> > an issue with automated stuff, though.
> >
> > My only argument now is ease of reading things like project descriptions,
> > contributors, SCM details, etc rather than having to unpack the jar. And
> if
> > you do, and end up with two pom.xmls laying around, that's not nice.
> Better
> > to just start always suffixing one with pom.xml.build or some such? I
> think
> > so, but I haven't thought deeply about it aside from reading this thread.
> our consumer pom will be generated from build pom: we can automate copy of
> any
> information we want, and for sure, I expect to put at least description,
> scm
> details, issueManagement, license (of course).
> In your list, there is only constributors that I was not counting on it:
> but
> it's a detailed decision we'll have to make
>
> for sure, Maven consumer poms, since generated from Maven build pom, can
> have
> much more details (and be sure they are accurrate) than build tools that
> don't
> generate it from data that exists in their original build format
>
> Regards,
>
> Hervé
>
> >
> >
> >
> > On Wed, Aug 24, 2016 at 6:32 PM, Hervé BOUTEMY <he...@free.fr>
> >
> > wrote:
> > > Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit :
> > > > That should have separation between builder Pom and consumer Pom. For
> > > > packaging=pom we deploy the builder Pom using classifier=build
> > > > *for all other packaging a we do not deploy the builder Pom*.
> > > >
> > > > I don't like the sound of this. The deployed artefacts should include
> > > > the
> > > > exact POM in use to build the project, as a reference, even if under
> a
> > > > different name. Yes, they should be in SCM, however down stream it's
> > >
> > > useful
> > >
> > > > to see these even when the SCM is offline or gone or private or
> > > > whatever.
> > > > Or did I misunderstand? If so, please clarify?
> > >
> > > when you consume an artifact not build with Maven, do you get the full
> > > build
> > > script?
> > > no
> > > I know that, as Maven users, we got used to have the build pom
> published
> > > in
> > > central: this is now an issue, but we like that
> > >
> > > notice: the build pom can be injected in the artifact, in
> META-INF/maven,
> > > like
> > > it is currently done
> > > but I don't see the point in requiring it to be pbulished separately in
> > > central: no other build tool does that, and they don't have any issue
> with
> > > that (and eventually it's a feature: don't publish internal details you
> > > don't
> > > really want people to see)
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > > On Wed, Aug 24, 2016 at 1:52 PM, Stephen Connolly <
> > > >
> > > > stephen.alan.connolly@gmail.com> wrote:
> > > > > On Tuesday 23 August 2016, Paul Benedict <pb...@apache.org>
> wrote:
> > > > > > On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <
> cs@schulte.it
> > > > > >
> > > > > > <javascript:;>> wrote:
> > > > > > > Am 08/24/16 um 00:08 schrieb Paul Benedict:
> > > > > > > > POM and a future major version POM? I am hinting at a
> strategy
> > >
> > > for
> > >
> > > > > > > forward
> > > > > > >
> > > > > > > > compatibility.
> > > > > > >
> > > > > > > Is forward compatibility really needed/required?
> > > > > >
> > > > > > I honestly don't know, which is why I am asking. An answer of "no
> > > > > > compatibility" is possible, too.
> > > > > >
> > > > > > I can completely see the argument that says POMs must be
> > > > > > all-parseable-or-nothing -- for the sake of reproducibility. I
> > >
> > > actually
> > >
> > > > > > prefer this answer. I think it is sensible to fail a build when
> > > > > > encountering a POM version too advanced. If your client only
> > >
> > > supports up
> > >
> > > > > to
> > > > >
> > > > > > model 4.0.0, then all artifacts must be specified by 4.0.0
> models,
> > >
> > > too.
> > >
> > > > > > On the other hand, I wanted to give the benefit of the doubt to
> the
> > > > > > opposite argument. At least one person spoke up and said it's
> > > > >
> > > > > unacceptable
> > > > >
> > > > > > to fail a build on configuration you don't understand. Well,
> that's
> > >
> > > an
> > >
> > > > > > interesting argument, too. That person doesn't want to tank the
> > > > > > build
> > > > > > for
> > > > > > the 1% of configuration that can't be understood.... but I fail
> to
> > >
> > > see
> > >
> > > > > > an
> > > > > > escape hatch here. If a client can't understand what's being
> > >
> > > specified,
> > >
> > > > > > then what else can be done but fail?
> > > > >
> > > > > Strip the dependencies a and let the user fix up manually (ideally
> by
> > > > > logging a warning that you are consuming a dependency using a newer
> > > > > modelVersion)
> > > > >
> > > > > Everyone forgets that the 4.0.0 ship has sailed already, so we
> have to
> > > > > deploy best-effort 4.0.0 poms
> > > > >
> > > > > Now I say that 3.4 should not have a new modelVersion but what it
> > >
> > > could do
> > >
> > > > > is be more forgiving of newer modelVersions or try and download and
> > >
> > > use an
> > >
> > > > > XSLT to convert newer modelVersions to 4.0.0 (while logging a
> warning)
> > > > > with
> > > > > option flags to allow failing the build if XSLT had to be applied
> > > > >
> > > > > So let's bump the modelVersion in Maven 5.0.0 (there is no Maven
> 4.x
> > >
> > > let's
> > >
> > > > > align on the modelVersion)
> > > > >
> > > > > That should have separation between builder Pom and consumer Pom.
> For
> > > > > packaging=pom we deploy the builder Pom using classifier=build for
> all
> > > > > other packaging a we do not deploy the builder Pom.
> > > > >
> > > > > We deploy a *best effort* conversion of the consumer Pom to
> > >
> > > modelVersion
> > >
> > > > > 4.0.0 without a classifier and the consumer Pom gets deployed as
> > > > > classifier
> > > > > consumer.
> > > > >
> > > > > The consumer Pom format allows for XSLT to transform to a parsable
> > >
> > > syntax,
> > >
> > > > > if transform is required we log a warning (or fail the build if the
> > > > > builder
> > > > > Pom indicates strict modelVersion adherence)
> > > > >
> > > > > So yeah maven 5.x will be able to parse dependencies with
> modelVersion
> > >
> > > 6.x
> > >
> > > > > while logging warnings that the user may not have the correct
> > >
> > > dependency
> > >
> > > > > tree. That is IMHO acceptable forward compatibility
> > > > >
> > > > > HTH
> > > > >
> > > > > -Stephen
> > > > >
> > > > > Ps I'm really hoping someone has a less crappy solution that
> this...
> > >
> > > But I
> > >
> > > > > believe this is actually *a* solution... And prior to this I have
> not
> > >
> > > seen
> > >
> > > > > any solution
> > > > >
> > > > > > Cheers,
> > > > > > Paul
> > > > >
> > > > > --
> > > > > Sent from my phone
> > >
> > > ---------------------------------------------------------------------
> > > 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: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Hervé BOUTEMY <he...@free.fr>]

Le mercredi 24 août 2016 18:41:59 Fred Cooke a écrit :
> Fair call re embedded pom, however it's quite convenient to just browse to
> it and read.
> 
> I've occasionally gone looking for details from poms of artefacts and found
> a mess and missing stuff, and been annoyed. It probably wasn't gradle's
> fault, though. Just a sloppy author. If I'm honest I wouldn't even know if
> I've ever consumed a non-maven artefact, certainly none of mine! :-)
> 
> No, I am sure, I have, at least one, and it's an ant one with a hard coded
> POM that doesn't always reflect the contents of the jar. Yuck. Clearly not
> an issue with automated stuff, though.
> 
> My only argument now is ease of reading things like project descriptions,
> contributors, SCM details, etc rather than having to unpack the jar. And if
> you do, and end up with two pom.xmls laying around, that's not nice. Better
> to just start always suffixing one with pom.xml.build or some such? I think
> so, but I haven't thought deeply about it aside from reading this thread.
our consumer pom will be generated from build pom: we can automate copy of any 
information we want, and for sure, I expect to put at least description, scm 
details, issueManagement, license (of course).
In your list, there is only constributors that I was not counting on it: but 
it's a detailed decision we'll have to make

for sure, Maven consumer poms, since generated from Maven build pom, can have 
much more details (and be sure they are accurrate) than build tools that don't 
generate it from data that exists in their original build format

Regards,

Hervé

> 
> 
> 
> On Wed, Aug 24, 2016 at 6:32 PM, Hervé BOUTEMY <he...@free.fr>
> 
> wrote:
> > Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit :
> > > That should have separation between builder Pom and consumer Pom. For
> > > packaging=pom we deploy the builder Pom using classifier=build
> > > *for all other packaging a we do not deploy the builder Pom*.
> > > 
> > > I don't like the sound of this. The deployed artefacts should include
> > > the
> > > exact POM in use to build the project, as a reference, even if under a
> > > different name. Yes, they should be in SCM, however down stream it's
> > 
> > useful
> > 
> > > to see these even when the SCM is offline or gone or private or
> > > whatever.
> > > Or did I misunderstand? If so, please clarify?
> > 
> > when you consume an artifact not build with Maven, do you get the full
> > build
> > script?
> > no
> > I know that, as Maven users, we got used to have the build pom published
> > in
> > central: this is now an issue, but we like that
> > 
> > notice: the build pom can be injected in the artifact, in META-INF/maven,
> > like
> > it is currently done
> > but I don't see the point in requiring it to be pbulished separately in
> > central: no other build tool does that, and they don't have any issue with
> > that (and eventually it's a feature: don't publish internal details you
> > don't
> > really want people to see)
> > 
> > Regards,
> > 
> > Hervé
> > 
> > > On Wed, Aug 24, 2016 at 1:52 PM, Stephen Connolly <
> > > 
> > > stephen.alan.connolly@gmail.com> wrote:
> > > > On Tuesday 23 August 2016, Paul Benedict <pb...@apache.org> wrote:
> > > > > On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <cs@schulte.it
> > > > > 
> > > > > <javascript:;>> wrote:
> > > > > > Am 08/24/16 um 00:08 schrieb Paul Benedict:
> > > > > > > POM and a future major version POM? I am hinting at a strategy
> > 
> > for
> > 
> > > > > > forward
> > > > > > 
> > > > > > > compatibility.
> > > > > > 
> > > > > > Is forward compatibility really needed/required?
> > > > > 
> > > > > I honestly don't know, which is why I am asking. An answer of "no
> > > > > compatibility" is possible, too.
> > > > > 
> > > > > I can completely see the argument that says POMs must be
> > > > > all-parseable-or-nothing -- for the sake of reproducibility. I
> > 
> > actually
> > 
> > > > > prefer this answer. I think it is sensible to fail a build when
> > > > > encountering a POM version too advanced. If your client only
> > 
> > supports up
> > 
> > > > to
> > > > 
> > > > > model 4.0.0, then all artifacts must be specified by 4.0.0 models,
> > 
> > too.
> > 
> > > > > On the other hand, I wanted to give the benefit of the doubt to the
> > > > > opposite argument. At least one person spoke up and said it's
> > > > 
> > > > unacceptable
> > > > 
> > > > > to fail a build on configuration you don't understand. Well, that's
> > 
> > an
> > 
> > > > > interesting argument, too. That person doesn't want to tank the
> > > > > build
> > > > > for
> > > > > the 1% of configuration that can't be understood.... but I fail to
> > 
> > see
> > 
> > > > > an
> > > > > escape hatch here. If a client can't understand what's being
> > 
> > specified,
> > 
> > > > > then what else can be done but fail?
> > > > 
> > > > Strip the dependencies a and let the user fix up manually (ideally by
> > > > logging a warning that you are consuming a dependency using a newer
> > > > modelVersion)
> > > > 
> > > > Everyone forgets that the 4.0.0 ship has sailed already, so we have to
> > > > deploy best-effort 4.0.0 poms
> > > > 
> > > > Now I say that 3.4 should not have a new modelVersion but what it
> > 
> > could do
> > 
> > > > is be more forgiving of newer modelVersions or try and download and
> > 
> > use an
> > 
> > > > XSLT to convert newer modelVersions to 4.0.0 (while logging a warning)
> > > > with
> > > > option flags to allow failing the build if XSLT had to be applied
> > > > 
> > > > So let's bump the modelVersion in Maven 5.0.0 (there is no Maven 4.x
> > 
> > let's
> > 
> > > > align on the modelVersion)
> > > > 
> > > > That should have separation between builder Pom and consumer Pom. For
> > > > packaging=pom we deploy the builder Pom using classifier=build for all
> > > > other packaging a we do not deploy the builder Pom.
> > > > 
> > > > We deploy a *best effort* conversion of the consumer Pom to
> > 
> > modelVersion
> > 
> > > > 4.0.0 without a classifier and the consumer Pom gets deployed as
> > > > classifier
> > > > consumer.
> > > > 
> > > > The consumer Pom format allows for XSLT to transform to a parsable
> > 
> > syntax,
> > 
> > > > if transform is required we log a warning (or fail the build if the
> > > > builder
> > > > Pom indicates strict modelVersion adherence)
> > > > 
> > > > So yeah maven 5.x will be able to parse dependencies with modelVersion
> > 
> > 6.x
> > 
> > > > while logging warnings that the user may not have the correct
> > 
> > dependency
> > 
> > > > tree. That is IMHO acceptable forward compatibility
> > > > 
> > > > HTH
> > > > 
> > > > -Stephen
> > > > 
> > > > Ps I'm really hoping someone has a less crappy solution that this...
> > 
> > But I
> > 
> > > > believe this is actually *a* solution... And prior to this I have not
> > 
> > seen
> > 
> > > > any solution
> > > > 
> > > > > Cheers,
> > > > > Paul
> > > > 
> > > > --
> > > > Sent from my phone
> > 
> > ---------------------------------------------------------------------
> > 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: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Anders Hammar <an...@hammar.net>]

On Wed, Aug 24, 2016 at 11:08 AM, Martijn Dashorst <
martijn.dashorst@gmail.com> wrote:

> On Wed, Aug 24, 2016 at 8:41 AM, Fred Cooke <fr...@gmail.com> wrote:
> > Fair call re embedded pom, however it's quite convenient to just browse
> to
> > it and read.
> I'd like to vent another opinion: the build pom makes it hard to grok
> the information I need as a consumer of a library. I really don't need
> to wade through 20 pages of plugin configuration that doesn't affect
> me.
>

Something I'd like to add to this is that sometimes things in the build
section shouldn't really be exposed. In the OSS world it's probably not an
issue, but for enterprises it could be. So stripping the consumer POM would
solve that. For the parent POMs, plugin stuff needs to be available as it
could be inherited. Unfortunately as this is where this "sensitive" config
very often is handled. I don't see any solution to this though as unless we
introduce two different sorts of parents; artifact parents (think of
corporate poms) and parents available during build (think of parent in a
multi-module build). Could be too complicated though.

/Anders



>
> I would even posit that issueManagement, scm, and url should not be
> part of the consumer POM as these are external to the artifact and
> live separate lives. I'd rather see a different file that lists that
> particular information that can be updated when someone switches from
> JIRA to github issues, or from svn to git on bitbucket to git on
> github to a project specific git.project.io. Look what happened with
> codehaus or googlecode going away, or all projects moving from sf.net
> to github. Having the external information that doesn't relate to the
> particular version be external to the POM would make that much better.
>
> I really like the idea of consumer and producer POMs. Strip the
> consumer POM of everything <build> and <site> related.
>
> Martijn
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Martijn Dashorst <ma...@gmail.com>]

On Wed, Aug 24, 2016 at 8:41 AM, Fred Cooke <fr...@gmail.com> wrote:
> Fair call re embedded pom, however it's quite convenient to just browse to
> it and read.

I'd like to vent another opinion: the build pom makes it hard to grok
the information I need as a consumer of a library. I really don't need
to wade through 20 pages of plugin configuration that doesn't affect
me.

I would even posit that issueManagement, scm, and url should not be
part of the consumer POM as these are external to the artifact and
live separate lives. I'd rather see a different file that lists that
particular information that can be updated when someone switches from
JIRA to github issues, or from svn to git on bitbucket to git on
github to a project specific git.project.io. Look what happened with
codehaus or googlecode going away, or all projects moving from sf.net
to github. Having the external information that doesn't relate to the
particular version be external to the POM would make that much better.

I really like the idea of consumer and producer POMs. Strip the
consumer POM of everything <build> and <site> related.

Martijn

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Fred Cooke <fr...@gmail.com>]

Fair call re embedded pom, however it's quite convenient to just browse to
it and read.

I've occasionally gone looking for details from poms of artefacts and found
a mess and missing stuff, and been annoyed. It probably wasn't gradle's
fault, though. Just a sloppy author. If I'm honest I wouldn't even know if
I've ever consumed a non-maven artefact, certainly none of mine! :-)

No, I am sure, I have, at least one, and it's an ant one with a hard coded
POM that doesn't always reflect the contents of the jar. Yuck. Clearly not
an issue with automated stuff, though.

My only argument now is ease of reading things like project descriptions,
contributors, SCM details, etc rather than having to unpack the jar. And if
you do, and end up with two pom.xmls laying around, that's not nice. Better
to just start always suffixing one with pom.xml.build or some such? I think
so, but I haven't thought deeply about it aside from reading this thread.



On Wed, Aug 24, 2016 at 6:32 PM, Hervé BOUTEMY <he...@free.fr>
wrote:

> Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit :
> > That should have separation between builder Pom and consumer Pom. For
> > packaging=pom we deploy the builder Pom using classifier=build
> > *for all other packaging a we do not deploy the builder Pom*.
> >
> > I don't like the sound of this. The deployed artefacts should include the
> > exact POM in use to build the project, as a reference, even if under a
> > different name. Yes, they should be in SCM, however down stream it's
> useful
> > to see these even when the SCM is offline or gone or private or whatever.
> > Or did I misunderstand? If so, please clarify?
> when you consume an artifact not build with Maven, do you get the full
> build
> script?
> no
> I know that, as Maven users, we got used to have the build pom published in
> central: this is now an issue, but we like that
>
> notice: the build pom can be injected in the artifact, in META-INF/maven,
> like
> it is currently done
> but I don't see the point in requiring it to be pbulished separately in
> central: no other build tool does that, and they don't have any issue with
> that (and eventually it's a feature: don't publish internal details you
> don't
> really want people to see)
>
> Regards,
>
> Hervé
>
> >
> > On Wed, Aug 24, 2016 at 1:52 PM, Stephen Connolly <
> >
> > stephen.alan.connolly@gmail.com> wrote:
> > > On Tuesday 23 August 2016, Paul Benedict <pb...@apache.org> wrote:
> > > > On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <cs@schulte.it
> > > >
> > > > <javascript:;>> wrote:
> > > > > Am 08/24/16 um 00:08 schrieb Paul Benedict:
> > > > > > POM and a future major version POM? I am hinting at a strategy
> for
> > > > >
> > > > > forward
> > > > >
> > > > > > compatibility.
> > > > >
> > > > > Is forward compatibility really needed/required?
> > > >
> > > > I honestly don't know, which is why I am asking. An answer of "no
> > > > compatibility" is possible, too.
> > > >
> > > > I can completely see the argument that says POMs must be
> > > > all-parseable-or-nothing -- for the sake of reproducibility. I
> actually
> > > > prefer this answer. I think it is sensible to fail a build when
> > > > encountering a POM version too advanced. If your client only
> supports up
> > >
> > > to
> > >
> > > > model 4.0.0, then all artifacts must be specified by 4.0.0 models,
> too.
> > > >
> > > > On the other hand, I wanted to give the benefit of the doubt to the
> > > > opposite argument. At least one person spoke up and said it's
> > >
> > > unacceptable
> > >
> > > > to fail a build on configuration you don't understand. Well, that's
> an
> > > > interesting argument, too. That person doesn't want to tank the build
> > > > for
> > > > the 1% of configuration that can't be understood.... but I fail to
> see
> > > > an
> > > > escape hatch here. If a client can't understand what's being
> specified,
> > > > then what else can be done but fail?
> > >
> > > Strip the dependencies a and let the user fix up manually (ideally by
> > > logging a warning that you are consuming a dependency using a newer
> > > modelVersion)
> > >
> > > Everyone forgets that the 4.0.0 ship has sailed already, so we have to
> > > deploy best-effort 4.0.0 poms
> > >
> > > Now I say that 3.4 should not have a new modelVersion but what it
> could do
> > > is be more forgiving of newer modelVersions or try and download and
> use an
> > > XSLT to convert newer modelVersions to 4.0.0 (while logging a warning)
> > > with
> > > option flags to allow failing the build if XSLT had to be applied
> > >
> > > So let's bump the modelVersion in Maven 5.0.0 (there is no Maven 4.x
> let's
> > > align on the modelVersion)
> > >
> > > That should have separation between builder Pom and consumer Pom. For
> > > packaging=pom we deploy the builder Pom using classifier=build for all
> > > other packaging a we do not deploy the builder Pom.
> > >
> > > We deploy a *best effort* conversion of the consumer Pom to
> modelVersion
> > > 4.0.0 without a classifier and the consumer Pom gets deployed as
> > > classifier
> > > consumer.
> > >
> > > The consumer Pom format allows for XSLT to transform to a parsable
> syntax,
> > > if transform is required we log a warning (or fail the build if the
> > > builder
> > > Pom indicates strict modelVersion adherence)
> > >
> > > So yeah maven 5.x will be able to parse dependencies with modelVersion
> 6.x
> > > while logging warnings that the user may not have the correct
> dependency
> > > tree. That is IMHO acceptable forward compatibility
> > >
> > > HTH
> > >
> > > -Stephen
> > >
> > > Ps I'm really hoping someone has a less crappy solution that this...
> But I
> > > believe this is actually *a* solution... And prior to this I have not
> seen
> > > any solution
> > >
> > > > Cheers,
> > > > Paul
> > >
> > > --
> > > Sent from my phone
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Hervé BOUTEMY <he...@free.fr>]

Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit :
> That should have separation between builder Pom and consumer Pom. For
> packaging=pom we deploy the builder Pom using classifier=build
> *for all other packaging a we do not deploy the builder Pom*.
> 
> I don't like the sound of this. The deployed artefacts should include the
> exact POM in use to build the project, as a reference, even if under a
> different name. Yes, they should be in SCM, however down stream it's useful
> to see these even when the SCM is offline or gone or private or whatever.
> Or did I misunderstand? If so, please clarify?
when you consume an artifact not build with Maven, do you get the full build 
script?
no
I know that, as Maven users, we got used to have the build pom published in 
central: this is now an issue, but we like that

notice: the build pom can be injected in the artifact, in META-INF/maven, like 
it is currently done
but I don't see the point in requiring it to be pbulished separately in 
central: no other build tool does that, and they don't have any issue with 
that (and eventually it's a feature: don't publish internal details you don't 
really want people to see)

Regards,

Hervé

> 
> On Wed, Aug 24, 2016 at 1:52 PM, Stephen Connolly <
> 
> stephen.alan.connolly@gmail.com> wrote:
> > On Tuesday 23 August 2016, Paul Benedict <pb...@apache.org> wrote:
> > > On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <cs@schulte.it
> > > 
> > > <javascript:;>> wrote:
> > > > Am 08/24/16 um 00:08 schrieb Paul Benedict:
> > > > > POM and a future major version POM? I am hinting at a strategy for
> > > > 
> > > > forward
> > > > 
> > > > > compatibility.
> > > > 
> > > > Is forward compatibility really needed/required?
> > > 
> > > I honestly don't know, which is why I am asking. An answer of "no
> > > compatibility" is possible, too.
> > > 
> > > I can completely see the argument that says POMs must be
> > > all-parseable-or-nothing -- for the sake of reproducibility. I actually
> > > prefer this answer. I think it is sensible to fail a build when
> > > encountering a POM version too advanced. If your client only supports up
> > 
> > to
> > 
> > > model 4.0.0, then all artifacts must be specified by 4.0.0 models, too.
> > > 
> > > On the other hand, I wanted to give the benefit of the doubt to the
> > > opposite argument. At least one person spoke up and said it's
> > 
> > unacceptable
> > 
> > > to fail a build on configuration you don't understand. Well, that's an
> > > interesting argument, too. That person doesn't want to tank the build
> > > for
> > > the 1% of configuration that can't be understood.... but I fail to see
> > > an
> > > escape hatch here. If a client can't understand what's being specified,
> > > then what else can be done but fail?
> > 
> > Strip the dependencies a and let the user fix up manually (ideally by
> > logging a warning that you are consuming a dependency using a newer
> > modelVersion)
> > 
> > Everyone forgets that the 4.0.0 ship has sailed already, so we have to
> > deploy best-effort 4.0.0 poms
> > 
> > Now I say that 3.4 should not have a new modelVersion but what it could do
> > is be more forgiving of newer modelVersions or try and download and use an
> > XSLT to convert newer modelVersions to 4.0.0 (while logging a warning)
> > with
> > option flags to allow failing the build if XSLT had to be applied
> > 
> > So let's bump the modelVersion in Maven 5.0.0 (there is no Maven 4.x let's
> > align on the modelVersion)
> > 
> > That should have separation between builder Pom and consumer Pom. For
> > packaging=pom we deploy the builder Pom using classifier=build for all
> > other packaging a we do not deploy the builder Pom.
> > 
> > We deploy a *best effort* conversion of the consumer Pom to modelVersion
> > 4.0.0 without a classifier and the consumer Pom gets deployed as
> > classifier
> > consumer.
> > 
> > The consumer Pom format allows for XSLT to transform to a parsable syntax,
> > if transform is required we log a warning (or fail the build if the
> > builder
> > Pom indicates strict modelVersion adherence)
> > 
> > So yeah maven 5.x will be able to parse dependencies with modelVersion 6.x
> > while logging warnings that the user may not have the correct dependency
> > tree. That is IMHO acceptable forward compatibility
> > 
> > HTH
> > 
> > -Stephen
> > 
> > Ps I'm really hoping someone has a less crappy solution that this... But I
> > believe this is actually *a* solution... And prior to this I have not seen
> > any solution
> > 
> > > Cheers,
> > > Paul
> > 
> > --
> > Sent from my phone


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Fred Cooke <fr...@gmail.com>]

That should have separation between builder Pom and consumer Pom. For
packaging=pom we deploy the builder Pom using classifier=build
*for all other packaging a we do not deploy the builder Pom*.

I don't like the sound of this. The deployed artefacts should include the
exact POM in use to build the project, as a reference, even if under a
different name. Yes, they should be in SCM, however down stream it's useful
to see these even when the SCM is offline or gone or private or whatever.
Or did I misunderstand? If so, please clarify?

On Wed, Aug 24, 2016 at 1:52 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> On Tuesday 23 August 2016, Paul Benedict <pb...@apache.org> wrote:
>
> > On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <cs@schulte.it
> > <javascript:;>> wrote:
> >
> > > Am 08/24/16 um 00:08 schrieb Paul Benedict:
> > > > POM and a future major version POM? I am hinting at a strategy for
> > > forward
> > > > compatibility.
> > >
> > > Is forward compatibility really needed/required?
> > >
> >
> > I honestly don't know, which is why I am asking. An answer of "no
> > compatibility" is possible, too.
> >
> > I can completely see the argument that says POMs must be
> > all-parseable-or-nothing -- for the sake of reproducibility. I actually
> > prefer this answer. I think it is sensible to fail a build when
> > encountering a POM version too advanced. If your client only supports up
> to
> > model 4.0.0, then all artifacts must be specified by 4.0.0 models, too.
> >
> > On the other hand, I wanted to give the benefit of the doubt to the
> > opposite argument. At least one person spoke up and said it's
> unacceptable
> > to fail a build on configuration you don't understand. Well, that's an
> > interesting argument, too. That person doesn't want to tank the build for
> > the 1% of configuration that can't be understood.... but I fail to see an
> > escape hatch here. If a client can't understand what's being specified,
> > then what else can be done but fail?
>
>
> Strip the dependencies a and let the user fix up manually (ideally by
> logging a warning that you are consuming a dependency using a newer
> modelVersion)
>
> Everyone forgets that the 4.0.0 ship has sailed already, so we have to
> deploy best-effort 4.0.0 poms
>
> Now I say that 3.4 should not have a new modelVersion but what it could do
> is be more forgiving of newer modelVersions or try and download and use an
> XSLT to convert newer modelVersions to 4.0.0 (while logging a warning) with
> option flags to allow failing the build if XSLT had to be applied
>
> So let's bump the modelVersion in Maven 5.0.0 (there is no Maven 4.x let's
> align on the modelVersion)
>
> That should have separation between builder Pom and consumer Pom. For
> packaging=pom we deploy the builder Pom using classifier=build for all
> other packaging a we do not deploy the builder Pom.
>
> We deploy a *best effort* conversion of the consumer Pom to modelVersion
> 4.0.0 without a classifier and the consumer Pom gets deployed as classifier
> consumer.
>
> The consumer Pom format allows for XSLT to transform to a parsable syntax,
> if transform is required we log a warning (or fail the build if the builder
> Pom indicates strict modelVersion adherence)
>
> So yeah maven 5.x will be able to parse dependencies with modelVersion 6.x
> while logging warnings that the user may not have the correct dependency
> tree. That is IMHO acceptable forward compatibility
>
> HTH
>
> -Stephen
>
> Ps I'm really hoping someone has a less crappy solution that this... But I
> believe this is actually *a* solution... And prior to this I have not seen
> any solution
>
>
> > Cheers,
> > Paul
> >
>
>
> --
> Sent from my phone
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Stephen Connolly <st...@gmail.com>]

On Tuesday 23 August 2016, Paul Benedict <pb...@apache.org> wrote:

> On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <cs@schulte.it
> <javascript:;>> wrote:
>
> > Am 08/24/16 um 00:08 schrieb Paul Benedict:
> > > POM and a future major version POM? I am hinting at a strategy for
> > forward
> > > compatibility.
> >
> > Is forward compatibility really needed/required?
> >
>
> I honestly don't know, which is why I am asking. An answer of "no
> compatibility" is possible, too.
>
> I can completely see the argument that says POMs must be
> all-parseable-or-nothing -- for the sake of reproducibility. I actually
> prefer this answer. I think it is sensible to fail a build when
> encountering a POM version too advanced. If your client only supports up to
> model 4.0.0, then all artifacts must be specified by 4.0.0 models, too.
>
> On the other hand, I wanted to give the benefit of the doubt to the
> opposite argument. At least one person spoke up and said it's unacceptable
> to fail a build on configuration you don't understand. Well, that's an
> interesting argument, too. That person doesn't want to tank the build for
> the 1% of configuration that can't be understood.... but I fail to see an
> escape hatch here. If a client can't understand what's being specified,
> then what else can be done but fail?


Strip the dependencies a and let the user fix up manually (ideally by
logging a warning that you are consuming a dependency using a newer
modelVersion)

Everyone forgets that the 4.0.0 ship has sailed already, so we have to
deploy best-effort 4.0.0 poms

Now I say that 3.4 should not have a new modelVersion but what it could do
is be more forgiving of newer modelVersions or try and download and use an
XSLT to convert newer modelVersions to 4.0.0 (while logging a warning) with
option flags to allow failing the build if XSLT had to be applied

So let's bump the modelVersion in Maven 5.0.0 (there is no Maven 4.x let's
align on the modelVersion)

That should have separation between builder Pom and consumer Pom. For
packaging=pom we deploy the builder Pom using classifier=build for all
other packaging a we do not deploy the builder Pom.

We deploy a *best effort* conversion of the consumer Pom to modelVersion
4.0.0 without a classifier and the consumer Pom gets deployed as classifier
consumer.

The consumer Pom format allows for XSLT to transform to a parsable syntax,
if transform is required we log a warning (or fail the build if the builder
Pom indicates strict modelVersion adherence)

So yeah maven 5.x will be able to parse dependencies with modelVersion 6.x
while logging warnings that the user may not have the correct dependency
tree. That is IMHO acceptable forward compatibility

HTH

-Stephen

Ps I'm really hoping someone has a less crappy solution that this... But I
believe this is actually *a* solution... And prior to this I have not seen
any solution


> Cheers,
> Paul
>


-- 
Sent from my phone

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Paul Benedict <pb...@apache.org>]

On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <cs...@schulte.it> wrote:

> Am 08/24/16 um 00:08 schrieb Paul Benedict:
> > POM and a future major version POM? I am hinting at a strategy for
> forward
> > compatibility.
>
> Is forward compatibility really needed/required?
>

I honestly don't know, which is why I am asking. An answer of "no
compatibility" is possible, too.

I can completely see the argument that says POMs must be
all-parseable-or-nothing -- for the sake of reproducibility. I actually
prefer this answer. I think it is sensible to fail a build when
encountering a POM version too advanced. If your client only supports up to
model 4.0.0, then all artifacts must be specified by 4.0.0 models, too.

On the other hand, I wanted to give the benefit of the doubt to the
opposite argument. At least one person spoke up and said it's unacceptable
to fail a build on configuration you don't understand. Well, that's an
interesting argument, too. That person doesn't want to tank the build for
the 1% of configuration that can't be understood.... but I fail to see an
escape hatch here. If a client can't understand what's being specified,
then what else can be done but fail?

Cheers,
Paul

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 08/24/16 um 00:08 schrieb Paul Benedict:
> POM and a future major version POM? I am hinting at a strategy for forward
> compatibility.

Is forward compatibility really needed/required? Java developers would
not mind, if the classfiles they produce cannot be used with an older
JRE. Are we really heading for forward compatibility? Is that really a
requirement when the binaries to build do not adhere to that as well? Is
there any programming language/platform out there applying forward
compatibility? My knowledge of different programming eco systems is
limited, of course. You cannot pass more recent XYZ sourcecode to less
recent XYZ compilers in any programming language I know of, however. Can
you give an example of a programming language/system where this is
wanted/required/supported?

Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Paul Benedict <pb...@apache.org>]

If to "blow up" is unacceptable, then what is the documented way for a
Maven client to deal with a <modelVersion> it doesn't fully support?
Keyword here is *fully* support. Minus tags and values specific to the
4.1.0 POM schema, a high-percentage of the configuration should be
parseable by an older client. Perhaps this is where the discussion needs to
lead? How Maven should behave differently between a future minor version
POM and a future major version POM? I am hinting at a strategy for forward
compatibility.

Cheers,
Paul

On Tue, Aug 23, 2016 at 4:45 PM, Christian Schulte <cs...@schulte.it> wrote:

> Am 08/23/16 um 01:12 schrieb Stephen Connolly:
> > On Monday 22 August 2016, Christian Schulte <cs...@schulte.it> wrote:
> >> That won't scale. What is to note here is that the XML schema or
> >> anything syntax does not change between 4.0.0 and 4.1.0. It's just that
> >> Maven 3.4 performs the dependency management import differently when
> >> operating on a 4.1.0 POM instead of a 4.0.0 POM.
> >
> >
> > But what happens when maven [2.0-3.3.4) download that Pom?
> >
> > If the answer is "blow up" then I am -1
>
> Just to throw another one into the discussion. How to handle a change in
> behaviour like this?
>
> <https://issues.apache.org/jira/browse/MNG-5761>
>
> Committed to the maven-3.x-next branch already.
>
> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> d69dd31389b62264686e339e6c60dc5d7c26d4b1>
>
> See my last comment on that issue. This requires a bump in model version
> as well. Version ranges make it impossible to deploy the effective
> dependencies after management (classically or transitively) again.
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 08/23/16 um 01:12 schrieb Stephen Connolly:
> On Monday 22 August 2016, Christian Schulte <cs...@schulte.it> wrote:
>> That won't scale. What is to note here is that the XML schema or
>> anything syntax does not change between 4.0.0 and 4.1.0. It's just that
>> Maven 3.4 performs the dependency management import differently when
>> operating on a 4.1.0 POM instead of a 4.0.0 POM.
> 
> 
> But what happens when maven [2.0-3.3.4) download that Pom?
> 
> If the answer is "blow up" then I am -1

Just to throw another one into the discussion. How to handle a change in
behaviour like this?

<https://issues.apache.org/jira/browse/MNG-5761>

Committed to the maven-3.x-next branch already.

<https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=d69dd31389b62264686e339e6c60dc5d7c26d4b1>

See my last comment on that issue. This requires a bump in model version
as well. Version ranges make it impossible to deploy the effective
dependencies after management (classically or transitively) again.

Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 08/24/16 um 08:23 schrieb Herv BOUTEMY:
> I don't like classical dependencies version ranges, but the idea of such 
> feature for imports looks even worse: the dirty dependency tree will be really 
> huge, I imagine. And if the content of imported pom changes in the ganre, I 
> fear the result is quite un-predictible

Nothing dependency tree involved here. It's done by the model builder
and just uses the highest version found.

<https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java;h=89c989f76e345771173879477dd5c9522a988d98;hb=HEAD#l1533>

<https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultModelResolver.java;h=0832a3ada211f1a5d1170f8ac9edee7f68429e9b;hb=HEAD#l234>

Regards,
-- 
Christian



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 08/24/16 um 08:23 schrieb Herv BOUTEMY:
> version ranges: I hate version ranges... :)
> notice: what is the issue with version ranges? the generated consumer pom can 
> contain version ranges, since it is a long-standing feature

It would be really cool if the whole dependency resolution could be done
at build time and does not need to be performed when consuming an
artifact again and again. Version ranges make this impossible. Currently
we cannot change anything about dependency resolution between Maven
versions. We cannot even fix resolution bugs and stay compatible. One
way out of that would be to deploy the resolution result instead of the
recipe to resolve the dependency tree.


> notice: this is another good reason to finish Aether import first... :)

+1

When separating the build and consumer pom we also need to support
changing dependency resolution logic (enhance/fix/new feature) in a
compatible way for that consumer pom. That's another issue we are
running into frequently. Recent Maven version needs to provide the exact
same dependency tree (including all bugs) of older versions and users
need to manually opt-in to the fixes/new features/changes by some kind
of consumer pom versioning.

Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Hervé BOUTEMY <he...@free.fr>]

Le mardi 23 août 2016 22:52:18 Christian Schulte a écrit :
> Am 08/23/16 um 22:33 schrieb Hervé BOUTEMY:
> > yes, people providing libraries have this big choice to do: when to
> > upgrade
> > minimum JRE version for consumers.
> > 
> > yes, we can add them another new big decision to take: when to upgrade
> > minium Maven version to consume the library?
> > 
> > but with consumer pom vs build pom, we should be able to avoid this new
> > decision: build pom can evolve (having a prerequisite to builkd the
> > library is not an issue), consumer pom stays compatible
> > 
> > 
> > Now, I don't yet investigated the new include feature, with a simple
> > example of the difference between include and import, and see if a build
> > pom with include could be transformed into a consumer pom without it: is
> > it feasible?
> It could be transformed only when not using version ranges.
version ranges: I hate version ranges... :)
notice: what is the issue with version ranges? the generated consumer pom can 
contain version ranges, since it is a long-standing feature

> That is -
> the deployed POM just does not contain any import or include scope
> dependencies any more but the effective dependency management after
> inclusion or import.
+1

> I really like the idea of deploying only the
> information necessary to consume a project and have an option of using
> something completely different to do the build.
yes, that's the general idea: do like other build tools that publish to 
central (with a generated minimal pom, not intended for build but only 
consumption)

> There are two big issues
> all solutions presented so far do not solve. Version ranges and same
> syntax but different semantics. There is some good news to this as well.
> Currently the import scope feature does not support using version
> ranges! That got implemented on current master due to
> 
> <https://issues.apache.org/jira/browse/MNG-4463>
> 
> by me but has not been released so far. So Maven 3.4.0-SNAPSHOT
> currently supports using version ranges in import declarations. This
> will make it impossible to deploy a POM with the imported dependency
> management flattened no matter how that has been built.
I don't like classical dependencies version ranges, but the idea of such 
feature for imports looks even worse: the dirty dependency tree will be really 
huge, I imagine. And if the content of imported pom changes in the ganre, I 
fear the result is quite un-predictible

> Heading for
> future-proofness, this would need to be reverted as well. Does not solve
> the version range issue, however. This is what makes it impossible to
> deploy a pre-resolved dependency tree to the repository. So maybe that
> is the major issue we need to find a solution for first to get a
> solution solving everything else automatically.
why does it need to be pre-resolved?

notice: this is another good reason to finish Aether import first... :)

Regards,

Hervé

> 
> Regards,


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 08/30/16 um 00:51 schrieb Fred Cooke:
> Yes, presumably to be consumed in another build, right? :-)

Another build, an application launcher, etc. I fail to see the
interpolation issue here. What functionality would be lost?

Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Fred Cooke <fr...@gmail.com>]

Yes, presumably to be consumed in another build, right? :-)

On Tue, Aug 30, 2016 at 10:45 AM, Christian Schulte <cs...@schulte.it> wrote:

> Am 08/30/16 um 00:33 schrieb Fred Cooke:
> > I fail to see how any such flattening can do away with interpolation.
> Your
> > typical nonlib project has say 5-100 deps, each of which would have a
> flat
> > tree that needs to be compared with and resolved against the others.
>
> As far as I understood the proposal, this is solely happening during
> build time backed by the build pom. The consumer pom is just a
> constant/final list (tree?) of dependencies the way it got resolved
> during building.
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 08/30/16 um 00:33 schrieb Fred Cooke:
> I fail to see how any such flattening can do away with interpolation. Your
> typical nonlib project has say 5-100 deps, each of which would have a flat
> tree that needs to be compared with and resolved against the others.

As far as I understood the proposal, this is solely happening during
build time backed by the build pom. The consumer pom is just a
constant/final list (tree?) of dependencies the way it got resolved
during building.

Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Fred Cooke <fr...@gmail.com>]

I fail to see how any such flattening can do away with interpolation. Your
typical nonlib project has say 5-100 deps, each of which would have a flat
tree that needs to be compared with and resolved against the others. I can
see it speeding things up due to having all of the information for just the
declared number after that many downloads, but you can't have simple code
that just gets stuff. Not going to work.

Or am I blind?

On Tue, Aug 30, 2016 at 10:27 AM, Christian Schulte <cs...@schulte.it> wrote:

> Am 08/30/16 um 00:16 schrieb Paul Benedict:
> > I see a deployed faulty "consumer pom" to be more more harmful than
> > generating it locally on demand. At least with the local one I can
> upgrade
> > my client to fix a dependency calculation. There will be no such relief
> in
> > the case of your proposal.
>
> It's not my proposal but I agree to what is proposed. This whole
> discussion started because users have requested to revert commits due to
> compatibility issues. They want to keep such "faulty" behaviour. If they
> want to fix it, they can deploy a new version using a more recent Maven
> version. The older Maven version will then also see this new behaviour.
> If the consumer pom contains the complete resolved dependency tree, the
> code interpreting that data is not much more than downloading some files
> from some repository. Yes. Repository information needs to be part of
> that consumer pom as well. So the resolved dependency tree including
> repository information from where to get the resolved artifacts. And we
> also need to find a way to handle version ranges.
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Stephen Connolly <st...@gmail.com>]

On Thursday 1 September 2016, Christian Schulte <cs...@schulte.it> wrote:

> Am 08/31/16 um 22:51 schrieb Stephen Connolly:
> > So for the tests-jar.., that would have a declared dependency on the
> > regular .jar and provide the tree for the test-runtime scope... It may
> even
> > be that there are therefore closer overrides of the main artifact's
> > dependencies in the test jar's tree... That should all be fine.
>
> So the test jar's tree is different to the main jar's tree. The selector
> used to distinguish this in that scenario is not the scope, but the
> artifact coordinates (jar vs. test-jar), correct? Where I say "scope",
> you say "coordinates", correct? I think I got it now.


Yes that's why I said project dependency treeS ;-)


>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>

-- 
Sent from my phone

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 08/31/16 um 22:51 schrieb Stephen Connolly:
> So for the tests-jar.., that would have a declared dependency on the
> regular .jar and provide the tree for the test-runtime scope... It may even
> be that there are therefore closer overrides of the main artifact's
> dependencies in the test jar's tree... That should all be fine.

So the test jar's tree is different to the main jar's tree. The selector
used to distinguish this in that scenario is not the scope, but the
artifact coordinates (jar vs. test-jar), correct? Where I say "scope",
you say "coordinates", correct? I think I got it now.

Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Stephen Connolly <st...@gmail.com>]

On Friday 2 September 2016, Robert Scholte <rf...@apache.org> wrote:

> On Wed, 31 Aug 2016 22:51:20 +0200, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> On Wednesday 31 August 2016, Robert Scholte <rf...@apache.org> wrote:
>>
>> On Wed, 31 Aug 2016 19:35:02 +0200, Stephen Connolly <
>>> stephen.alan.connolly@gmail.com> wrote:
>>>
>>> On Wednesday 31 August 2016, Christian Schulte <cs...@schulte.it> wrote:
>>>
>>>>
>>>> Am 08/31/16 um 18:39 schrieb Christian Schulte:
>>>>
>>>>> > Am 08/31/16 um 07:52 schrieb Stephen Connolly:
>>>>> >> I've been thinking about what to call the "consumer Pom"...
>>>>> >>
>>>>> >> I think this is actually not a project object model, but the project
>>>>> >> dependency trees
>>>>> >>
>>>>> >> It should list each side artifact and their dependency trees...
>>>>> >>
>>>>> >> So for example:
>>>>> >>
>>>>> >> * the java doc artifacts should depend on the corresponding
>>>>> dependency
>>>>> java
>>>>> >> doc artifacts (in an ideal world) because we expect {@link}
>>>>> references
>>>>> >>
>>>>> >> * the source artifacts do not depend on anything else (normally) but
>>>>> for an
>>>>> >> über jar (which yes is a bad pattern) you would actually be correct
>>>>> to
>>>>> >> depend on the bundled artifacts source jars... So the concept still
>>>>> makes
>>>>> >> sense
>>>>> >>
>>>>> >> * the test jar artifact would have the full test dependency tree
>>>>> exposed as
>>>>> >> this would allow for test reuse
>>>>> >
>>>>> > +1
>>>>> >
>>>>> > Sounds like dependency trees by scope. The compile scope tree, the
>>>>> > runtime scope tree, the test scope tree, the documentation scope
>>>>> tree,
>>>>> > the source code scope tree, the invented by a 3rd party scope tree,
>>>>> etc.
>>>>> >
>>>>>
>>>>>
>>>>> public interface DependencyTreeProvider
>>>>> {
>>>>>
>>>>>   DependencyNode getDependencyTree( String logicalScopeName )
>>>>>     throws IOException;
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>
>>>> Not `String logicalScopeName` but `Artifact artifact`
>>>>
>>>> Because... Otherwise we have to pick a defined list of scope names and
>>>> their meaning... Any defined list of scope names will be different... So
>>>> better is to just publish the one tree per artifact
>>>>
>>>> Exposing the logical scope is a mistake IMHO
>>>>
>>>> There is one gotcha though... Sometimes you need a transitive dependency
>>>> to
>>>> compile but do not need it at runtime... How to handle that needs some
>>>> thought... But right now it is a problem anyway, and it is probably
>>>> safer
>>>> to just force it onto the "effective" tree and let the consumer who
>>>> *knows
>>>> they don't really need it* strip it from their tree (at the final point
>>>> of
>>>> use... Because it would also need to be on their compile path)
>>>>
>>>> I think the original view we had with maven where compile scope would
>>>> not
>>>> be transitive is no longer compatible with JavaC and basically compile
>>>> scope will always need to be transitive.
>>>>
>>>> So I am -1 on exposing details like "scope" to consumers
>>>>
>>>> We do need to expose "optional" so the consumer can resolve version
>>>> conflicts with the optional dependency
>>>>
>>>> HTH
>>>>
>>>>
>>>>
>>>> I agree that scope is something to filter on, it should not be part of
>>> the
>>> resolution result.
>>> The challenge I see is to select the proper artifact in case of multiple
>>> scopes.
>>> For example: the compiler:compile wants all dependencies with the scopes
>>> 'compile', 'provided' (and 'system'). if the same GA has different
>>> versions
>>> per scope it must be clear which one to choose.
>>> I hope we can resolve this without "nearest wins" strategy, the answer
>>> should somehow be in the .pdt;
>>>
>>
>>
>> Well I am not seeing a case for *consumers* to need different trees for
>> the
>> same artifact.
>>
>
> I had a discussion with Christian Schulte about this[1][2].
> Going for nearest doesn't always give a rational result. I think you
> should first go for the scope, next for nearest.
> Somehow such questions must be answered in the .pdt
>
>
To me, scope is a *build time* concept... As such we should not be exposing
it in the .pdt

At build time we can produce each artifacts tree (which should not resolve
version conflicts rather present the full tree)

From my PoV I see that what matters here is the artifact who's dependency
tree the consumer wants.

The consumer knows what other trees it has when it is building and what
scopes each of those trees have... The consumer knows if it should resolve
version conflicts or not.., the consumer knows how it should transform its
scoped dependency trees for publishing its own dependency trees

The .pdt cannot and should not know that IMHO

I am interested in seeing concrete examples because I worry the vision I
have in my head is too singular in origin and has some invalid bias or
cognitive oversight.

If anyone here is going to be at Jenkins World, we should meet up and
discuss (I have a promo code... Not sure how much discount remains on the
promo code though! if you want to go and haven't booked drop me a mail and
I'll forward my code)

I don't think I'll be able to make ApacheCon this year :-(

I'm working on a straw man schema for the .pdt at present which may also
help flesh out my version of a vision

- Stephen

Robert
>
> [1] http://maven.markmail.org/thread/qkudtbkiru4yynpl
> [2] https://issues.apache.org/jira/browse/MNG-4800
>
>>
>> The only case I can imagine is our *old* vision for compile scope... But I
>> think that need can be handled by optional in the worst case... My
>> preference is to let the consumer of the dependency remove the bits they
>> don't want...
>>
>> In essence each jar artifact's dependency tree would be that artifacts
>> effective runtime tree.
>>
>> So for the tests-jar.., that would have a declared dependency on the
>> regular .jar and provide the tree for the test-runtime scope... It may
>> even
>> be that there are therefore closer overrides of the main artifact's
>> dependencies in the test jar's tree... That should all be fine.
>>
>> If you are compiling against the dependency and want to use a different
>> version of the dependencies then you *as consumer* can override the tree
>> by
>> configuration... I think that is the best compromise.
>>
>>
>>
>>
>>> Robert
>>>
>>>
>>> The implementation of that method is broken down to just reading/parsing
>>>>> an XML file that way. You can implement that easily with every
>>>>> programming language of interest. There is no scope logic to implement.
>>>>> That's done at build time.
>>>>>
>>>>> When all those different trees have been fetched, the 'only' thing left
>>>>> to implement is conflict resolution / building the effective dependency
>>>>> tree. Since scopes have already been resolved, that could possibly also
>>>>> be broken down to just one very simple rule: nearest wins - no
>>>>> exceptions. Version ranges are only there to be able to check for
>>>>> conflicting ranges or hard requirements, right?
>>>>>
>>>>> Regards,
>>>>> --
>>>>> Christian
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> <javascript:;>
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>> <javascript:;>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>> 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: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Robert Scholte <rf...@apache.org>]

On Wed, 31 Aug 2016 22:51:20 +0200, Stephen Connolly  
<st...@gmail.com> wrote:

> On Wednesday 31 August 2016, Robert Scholte <rf...@apache.org> wrote:
>
>> On Wed, 31 Aug 2016 19:35:02 +0200, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>>
>> On Wednesday 31 August 2016, Christian Schulte <cs...@schulte.it> wrote:
>>>
>>> Am 08/31/16 um 18:39 schrieb Christian Schulte:
>>>> > Am 08/31/16 um 07:52 schrieb Stephen Connolly:
>>>> >> I've been thinking about what to call the "consumer Pom"...
>>>> >>
>>>> >> I think this is actually not a project object model, but the  
>>>> project
>>>> >> dependency trees
>>>> >>
>>>> >> It should list each side artifact and their dependency trees...
>>>> >>
>>>> >> So for example:
>>>> >>
>>>> >> * the java doc artifacts should depend on the corresponding  
>>>> dependency
>>>> java
>>>> >> doc artifacts (in an ideal world) because we expect {@link}  
>>>> references
>>>> >>
>>>> >> * the source artifacts do not depend on anything else (normally)  
>>>> but
>>>> for an
>>>> >> über jar (which yes is a bad pattern) you would actually be  
>>>> correct to
>>>> >> depend on the bundled artifacts source jars... So the concept still
>>>> makes
>>>> >> sense
>>>> >>
>>>> >> * the test jar artifact would have the full test dependency tree
>>>> exposed as
>>>> >> this would allow for test reuse
>>>> >
>>>> > +1
>>>> >
>>>> > Sounds like dependency trees by scope. The compile scope tree, the
>>>> > runtime scope tree, the test scope tree, the documentation scope  
>>>> tree,
>>>> > the source code scope tree, the invented by a 3rd party scope tree,
>>>> etc.
>>>> >
>>>>
>>>>
>>>> public interface DependencyTreeProvider
>>>> {
>>>>
>>>>   DependencyNode getDependencyTree( String logicalScopeName )
>>>>     throws IOException;
>>>>
>>>> }
>>>>
>>>
>>>
>>> Not `String logicalScopeName` but `Artifact artifact`
>>>
>>> Because... Otherwise we have to pick a defined list of scope names and
>>> their meaning... Any defined list of scope names will be different...  
>>> So
>>> better is to just publish the one tree per artifact
>>>
>>> Exposing the logical scope is a mistake IMHO
>>>
>>> There is one gotcha though... Sometimes you need a transitive  
>>> dependency
>>> to
>>> compile but do not need it at runtime... How to handle that needs some
>>> thought... But right now it is a problem anyway, and it is probably  
>>> safer
>>> to just force it onto the "effective" tree and let the consumer who  
>>> *knows
>>> they don't really need it* strip it from their tree (at the final  
>>> point of
>>> use... Because it would also need to be on their compile path)
>>>
>>> I think the original view we had with maven where compile scope would  
>>> not
>>> be transitive is no longer compatible with JavaC and basically compile
>>> scope will always need to be transitive.
>>>
>>> So I am -1 on exposing details like "scope" to consumers
>>>
>>> We do need to expose "optional" so the consumer can resolve version
>>> conflicts with the optional dependency
>>>
>>> HTH
>>>
>>>
>>>
>> I agree that scope is something to filter on, it should not be part of  
>> the
>> resolution result.
>> The challenge I see is to select the proper artifact in case of multiple
>> scopes.
>> For example: the compiler:compile wants all dependencies with the scopes
>> 'compile', 'provided' (and 'system'). if the same GA has different  
>> versions
>> per scope it must be clear which one to choose.
>> I hope we can resolve this without "nearest wins" strategy, the answer
>> should somehow be in the .pdt;
>
>
> Well I am not seeing a case for *consumers* to need different trees for  
> the
> same artifact.

I had a discussion with Christian Schulte about this[1][2].
Going for nearest doesn't always give a rational result. I think you  
should first go for the scope, next for nearest.
Somehow such questions must be answered in the .pdt

Robert

[1] http://maven.markmail.org/thread/qkudtbkiru4yynpl
[2] https://issues.apache.org/jira/browse/MNG-4800
>
> The only case I can imagine is our *old* vision for compile scope... But  
> I
> think that need can be handled by optional in the worst case... My
> preference is to let the consumer of the dependency remove the bits they
> don't want...
>
> In essence each jar artifact's dependency tree would be that artifacts
> effective runtime tree.
>
> So for the tests-jar.., that would have a declared dependency on the
> regular .jar and provide the tree for the test-runtime scope... It may  
> even
> be that there are therefore closer overrides of the main artifact's
> dependencies in the test jar's tree... That should all be fine.
>
> If you are compiling against the dependency and want to use a different
> version of the dependencies then you *as consumer* can override the tree  
> by
> configuration... I think that is the best compromise.
>
>
>
>>
>> Robert
>>
>>
>>>> The implementation of that method is broken down to just  
>>>> reading/parsing
>>>> an XML file that way. You can implement that easily with every
>>>> programming language of interest. There is no scope logic to  
>>>> implement.
>>>> That's done at build time.
>>>>
>>>> When all those different trees have been fetched, the 'only' thing  
>>>> left
>>>> to implement is conflict resolution / building the effective  
>>>> dependency
>>>> tree. Since scopes have already been resolved, that could possibly  
>>>> also
>>>> be broken down to just one very simple rule: nearest wins - no
>>>> exceptions. Version ranges are only there to be able to check for
>>>> conflicting ranges or hard requirements, right?
>>>>
>>>> Regards,
>>>> --
>>>> Christian
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org  
>>>> <javascript:;>
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>> <javascript:;>
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>> 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: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Stephen Connolly <st...@gmail.com>]

On Wednesday 31 August 2016, Robert Scholte <rf...@apache.org> wrote:

> On Wed, 31 Aug 2016 19:35:02 +0200, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> On Wednesday 31 August 2016, Christian Schulte <cs...@schulte.it> wrote:
>>
>> Am 08/31/16 um 18:39 schrieb Christian Schulte:
>>> > Am 08/31/16 um 07:52 schrieb Stephen Connolly:
>>> >> I've been thinking about what to call the "consumer Pom"...
>>> >>
>>> >> I think this is actually not a project object model, but the project
>>> >> dependency trees
>>> >>
>>> >> It should list each side artifact and their dependency trees...
>>> >>
>>> >> So for example:
>>> >>
>>> >> * the java doc artifacts should depend on the corresponding dependency
>>> java
>>> >> doc artifacts (in an ideal world) because we expect {@link} references
>>> >>
>>> >> * the source artifacts do not depend on anything else (normally) but
>>> for an
>>> >> über jar (which yes is a bad pattern) you would actually be correct to
>>> >> depend on the bundled artifacts source jars... So the concept still
>>> makes
>>> >> sense
>>> >>
>>> >> * the test jar artifact would have the full test dependency tree
>>> exposed as
>>> >> this would allow for test reuse
>>> >
>>> > +1
>>> >
>>> > Sounds like dependency trees by scope. The compile scope tree, the
>>> > runtime scope tree, the test scope tree, the documentation scope tree,
>>> > the source code scope tree, the invented by a 3rd party scope tree,
>>> etc.
>>> >
>>>
>>>
>>> public interface DependencyTreeProvider
>>> {
>>>
>>>   DependencyNode getDependencyTree( String logicalScopeName )
>>>     throws IOException;
>>>
>>> }
>>>
>>
>>
>> Not `String logicalScopeName` but `Artifact artifact`
>>
>> Because... Otherwise we have to pick a defined list of scope names and
>> their meaning... Any defined list of scope names will be different... So
>> better is to just publish the one tree per artifact
>>
>> Exposing the logical scope is a mistake IMHO
>>
>> There is one gotcha though... Sometimes you need a transitive dependency
>> to
>> compile but do not need it at runtime... How to handle that needs some
>> thought... But right now it is a problem anyway, and it is probably safer
>> to just force it onto the "effective" tree and let the consumer who *knows
>> they don't really need it* strip it from their tree (at the final point of
>> use... Because it would also need to be on their compile path)
>>
>> I think the original view we had with maven where compile scope would not
>> be transitive is no longer compatible with JavaC and basically compile
>> scope will always need to be transitive.
>>
>> So I am -1 on exposing details like "scope" to consumers
>>
>> We do need to expose "optional" so the consumer can resolve version
>> conflicts with the optional dependency
>>
>> HTH
>>
>>
>>
> I agree that scope is something to filter on, it should not be part of the
> resolution result.
> The challenge I see is to select the proper artifact in case of multiple
> scopes.
> For example: the compiler:compile wants all dependencies with the scopes
> 'compile', 'provided' (and 'system'). if the same GA has different versions
> per scope it must be clear which one to choose.
> I hope we can resolve this without "nearest wins" strategy, the answer
> should somehow be in the .pdt;


Well I am not seeing a case for *consumers* to need different trees for the
same artifact.

The only case I can imagine is our *old* vision for compile scope... But I
think that need can be handled by optional in the worst case... My
preference is to let the consumer of the dependency remove the bits they
don't want...

In essence each jar artifact's dependency tree would be that artifacts
effective runtime tree.

So for the tests-jar.., that would have a declared dependency on the
regular .jar and provide the tree for the test-runtime scope... It may even
be that there are therefore closer overrides of the main artifact's
dependencies in the test jar's tree... That should all be fine.

If you are compiling against the dependency and want to use a different
version of the dependencies then you *as consumer* can override the tree by
configuration... I think that is the best compromise.



>
> Robert
>
>
>>> The implementation of that method is broken down to just reading/parsing
>>> an XML file that way. You can implement that easily with every
>>> programming language of interest. There is no scope logic to implement.
>>> That's done at build time.
>>>
>>> When all those different trees have been fetched, the 'only' thing left
>>> to implement is conflict resolution / building the effective dependency
>>> tree. Since scopes have already been resolved, that could possibly also
>>> be broken down to just one very simple rule: nearest wins - no
>>> exceptions. Version ranges are only there to be able to check for
>>> conflicting ranges or hard requirements, right?
>>>
>>> Regards,
>>> --
>>> Christian
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>> <javascript:;>
>>>
>>>
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

-- 
Sent from my phone

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Robert Scholte <rf...@apache.org>]

On Wed, 31 Aug 2016 19:35:02 +0200, Stephen Connolly  
<st...@gmail.com> wrote:

> On Wednesday 31 August 2016, Christian Schulte <cs...@schulte.it> wrote:
>
>> Am 08/31/16 um 18:39 schrieb Christian Schulte:
>> > Am 08/31/16 um 07:52 schrieb Stephen Connolly:
>> >> I've been thinking about what to call the "consumer Pom"...
>> >>
>> >> I think this is actually not a project object model, but the project
>> >> dependency trees
>> >>
>> >> It should list each side artifact and their dependency trees...
>> >>
>> >> So for example:
>> >>
>> >> * the java doc artifacts should depend on the corresponding  
>> dependency
>> java
>> >> doc artifacts (in an ideal world) because we expect {@link}  
>> references
>> >>
>> >> * the source artifacts do not depend on anything else (normally) but
>> for an
>> >> über jar (which yes is a bad pattern) you would actually be correct  
>> to
>> >> depend on the bundled artifacts source jars... So the concept still
>> makes
>> >> sense
>> >>
>> >> * the test jar artifact would have the full test dependency tree
>> exposed as
>> >> this would allow for test reuse
>> >
>> > +1
>> >
>> > Sounds like dependency trees by scope. The compile scope tree, the
>> > runtime scope tree, the test scope tree, the documentation scope tree,
>> > the source code scope tree, the invented by a 3rd party scope tree,  
>> etc.
>> >
>>
>>
>> public interface DependencyTreeProvider
>> {
>>
>>   DependencyNode getDependencyTree( String logicalScopeName )
>>     throws IOException;
>>
>> }
>
>
> Not `String logicalScopeName` but `Artifact artifact`
>
> Because... Otherwise we have to pick a defined list of scope names and
> their meaning... Any defined list of scope names will be different... So
> better is to just publish the one tree per artifact
>
> Exposing the logical scope is a mistake IMHO
>
> There is one gotcha though... Sometimes you need a transitive dependency  
> to
> compile but do not need it at runtime... How to handle that needs some
> thought... But right now it is a problem anyway, and it is probably safer
> to just force it onto the "effective" tree and let the consumer who  
> *knows
> they don't really need it* strip it from their tree (at the final point  
> of
> use... Because it would also need to be on their compile path)
>
> I think the original view we had with maven where compile scope would not
> be transitive is no longer compatible with JavaC and basically compile
> scope will always need to be transitive.
>
> So I am -1 on exposing details like "scope" to consumers
>
> We do need to expose "optional" so the consumer can resolve version
> conflicts with the optional dependency
>
> HTH
>
>

I agree that scope is something to filter on, it should not be part of the  
resolution result.
The challenge I see is to select the proper artifact in case of multiple  
scopes.
For example: the compiler:compile wants all dependencies with the scopes  
'compile', 'provided' (and 'system'). if the same GA has different  
versions per scope it must be clear which one to choose.
I hope we can resolve this without "nearest wins" strategy, the answer  
should somehow be in the .pdt;

Robert

>>
>> The implementation of that method is broken down to just reading/parsing
>> an XML file that way. You can implement that easily with every
>> programming language of interest. There is no scope logic to implement.
>> That's done at build time.
>>
>> When all those different trees have been fetched, the 'only' thing left
>> to implement is conflict resolution / building the effective dependency
>> tree. Since scopes have already been resolved, that could possibly also
>> be broken down to just one very simple rule: nearest wins - no
>> exceptions. Version ranges are only there to be able to check for
>> conflicting ranges or hard requirements, right?
>>
>> Regards,
>> --
>> Christian
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
>> For additional commands, e-mail: dev-help@maven.apache.org  
>> <javascript:;>
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 08/31/16 um 19:35 schrieb Stephen Connolly:
> On Wednesday 31 August 2016, Christian Schulte <cs...@schulte.it> wrote:
>>
>>
>> public interface DependencyTreeProvider
>> {
>>
>>   DependencyNode getDependencyTree( String logicalScopeName )
>>     throws IOException;
>>
>> }
> 
> 
> Not `String logicalScopeName` but `Artifact artifact`
> 
> Because... Otherwise we have to pick a defined list of scope names and
> their meaning... Any defined list of scope names will be different... So
> better is to just publish the one tree per artifact

Are you referring to interface 'org.apache.maven.artifact.Artifact'?
Choose the tree to return based on scope? There is more than just one
tree per artifact. We need to provide many trees per artifact and then
need a way to select the tree of interest based on something. There have
been requests like "prioritize test dependencies over compile
dependencies when running tests". That's two different trees we need to
be able to read from the pdt files. Those pdt files need to support that
without the build tool having to apply any tree building logic. The pdt
files may not have been build using Maven, for example. Different tools
could apply different logic building those files. Consumer component is
not affected by this. If build tool A does not provide dependency tree
NAME of an artifact, build tool B gets no NAME tree. If build tool A
provides features like optional dependencies or dependency management
build tool B does not support, build tool B still can process the result
published by build tool A.

> 
> Exposing the logical scope is a mistake IMHO

[...]

> So I am -1 on exposing details like "scope" to consumers

Maybe scope is misleading. It's more a logical name of a dependency tree.

> 
> We do need to expose "optional" so the consumer can resolve version
> conflicts with the optional dependency

We need to keep the software processing those pdt files as dumb as
possible. Do as much as possible during building that pdt file. No need
for optional or provided in those pdt files. Optional already is a
feature of the build tool. Set it to true and the build tool will not
add that dependency to the pdt. Same with dependency management. Build
tool feature. pdt is all about pre-built final dependency trees the
consumer does not need to post-process in any way (build different
compile/test classpaths e.g.).

Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Stephen Connolly <st...@gmail.com>]

On Wednesday 31 August 2016, Christian Schulte <cs...@schulte.it> wrote:

> Am 08/31/16 um 18:39 schrieb Christian Schulte:
> > Am 08/31/16 um 07:52 schrieb Stephen Connolly:
> >> I've been thinking about what to call the "consumer Pom"...
> >>
> >> I think this is actually not a project object model, but the project
> >> dependency trees
> >>
> >> It should list each side artifact and their dependency trees...
> >>
> >> So for example:
> >>
> >> * the java doc artifacts should depend on the corresponding dependency
> java
> >> doc artifacts (in an ideal world) because we expect {@link} references
> >>
> >> * the source artifacts do not depend on anything else (normally) but
> for an
> >> über jar (which yes is a bad pattern) you would actually be correct to
> >> depend on the bundled artifacts source jars... So the concept still
> makes
> >> sense
> >>
> >> * the test jar artifact would have the full test dependency tree
> exposed as
> >> this would allow for test reuse
> >
> > +1
> >
> > Sounds like dependency trees by scope. The compile scope tree, the
> > runtime scope tree, the test scope tree, the documentation scope tree,
> > the source code scope tree, the invented by a 3rd party scope tree, etc.
> >
>
>
> public interface DependencyTreeProvider
> {
>
>   DependencyNode getDependencyTree( String logicalScopeName )
>     throws IOException;
>
> }


Not `String logicalScopeName` but `Artifact artifact`

Because... Otherwise we have to pick a defined list of scope names and
their meaning... Any defined list of scope names will be different... So
better is to just publish the one tree per artifact

Exposing the logical scope is a mistake IMHO

There is one gotcha though... Sometimes you need a transitive dependency to
compile but do not need it at runtime... How to handle that needs some
thought... But right now it is a problem anyway, and it is probably safer
to just force it onto the "effective" tree and let the consumer who *knows
they don't really need it* strip it from their tree (at the final point of
use... Because it would also need to be on their compile path)

I think the original view we had with maven where compile scope would not
be transitive is no longer compatible with JavaC and basically compile
scope will always need to be transitive.

So I am -1 on exposing details like "scope" to consumers

We do need to expose "optional" so the consumer can resolve version
conflicts with the optional dependency

HTH


>
> The implementation of that method is broken down to just reading/parsing
> an XML file that way. You can implement that easily with every
> programming language of interest. There is no scope logic to implement.
> That's done at build time.
>
> When all those different trees have been fetched, the 'only' thing left
> to implement is conflict resolution / building the effective dependency
> tree. Since scopes have already been resolved, that could possibly also
> be broken down to just one very simple rule: nearest wins - no
> exceptions. Version ranges are only there to be able to check for
> conflicting ranges or hard requirements, right?
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>

-- 
Sent from my phone

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 08/31/16 um 18:39 schrieb Christian Schulte:
> Am 08/31/16 um 07:52 schrieb Stephen Connolly:
>> I've been thinking about what to call the "consumer Pom"...
>>
>> I think this is actually not a project object model, but the project
>> dependency trees
>>
>> It should list each side artifact and their dependency trees...
>>
>> So for example:
>>
>> * the java doc artifacts should depend on the corresponding dependency java
>> doc artifacts (in an ideal world) because we expect {@link} references
>>
>> * the source artifacts do not depend on anything else (normally) but for an
>> �ber jar (which yes is a bad pattern) you would actually be correct to
>> depend on the bundled artifacts source jars... So the concept still makes
>> sense
>>
>> * the test jar artifact would have the full test dependency tree exposed as
>> this would allow for test reuse
> 
> +1
> 
> Sounds like dependency trees by scope. The compile scope tree, the
> runtime scope tree, the test scope tree, the documentation scope tree,
> the source code scope tree, the invented by a 3rd party scope tree, etc.
> 


public interface DependencyTreeProvider
{

  DependencyNode getDependencyTree( String logicalScopeName )
    throws IOException;

}

The implementation of that method is broken down to just reading/parsing
an XML file that way. You can implement that easily with every
programming language of interest. There is no scope logic to implement.
That's done at build time.

When all those different trees have been fetched, the 'only' thing left
to implement is conflict resolution / building the effective dependency
tree. Since scopes have already been resolved, that could possibly also
be broken down to just one very simple rule: nearest wins - no
exceptions. Version ranges are only there to be able to check for
conflicting ranges or hard requirements, right?

Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 08/31/16 um 07:52 schrieb Stephen Connolly:
> I've been thinking about what to call the "consumer Pom"...
> 
> I think this is actually not a project object model, but the project
> dependency trees
> 
> It should list each side artifact and their dependency trees...
> 
> So for example:
> 
> * the java doc artifacts should depend on the corresponding dependency java
> doc artifacts (in an ideal world) because we expect {@link} references
> 
> * the source artifacts do not depend on anything else (normally) but for an
> �ber jar (which yes is a bad pattern) you would actually be correct to
> depend on the bundled artifacts source jars... So the concept still makes
> sense
> 
> * the test jar artifact would have the full test dependency tree exposed as
> this would allow for test reuse

+1

Sounds like dependency trees by scope. The compile scope tree, the
runtime scope tree, the test scope tree, the documentation scope tree,
the source code scope tree, the invented by a 3rd party scope tree, etc.

> 
> Now I guess the question is if .pdt or .adt (artifact dependency trees) are
> too entrenched in some other domain that we'd want to avoid using one
> of those extensions
> 
> Next steps:
> 
> * start fleshing out a schema for the .pdt files
> * start fleshing out a spec for the repository layout (should be "parsable"
> by modelVersion 4.0.0 aware clients, but need to decide how to expose new
> features)

+1

Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Robert Scholte <rf...@apache.org>]

On Wed, 31 Aug 2016 07:52:20 +0200, Stephen Connolly  
<st...@gmail.com> wrote:

> I've been thinking about what to call the "consumer Pom"...
>
> I think this is actually not a project object model, but the project
> dependency trees
>
> It should list each side artifact and their dependency trees...
>
> So for example:
>
> * the java doc artifacts should depend on the corresponding dependency  
> java
> doc artifacts (in an ideal world) because we expect {@link} references
>
> * the source artifacts do not depend on anything else (normally) but for  
> an
> über jar (which yes is a bad pattern) you would actually be correct to
> depend on the bundled artifacts source jars... So the concept still makes
> sense
>
> * the test jar artifact would have the full test dependency tree exposed  
> as
> this would allow for test reuse
>
> Now I guess the question is if .pdt or .adt (artifact dependency trees)  
> are
> too entrenched in some other domain that we'd want to avoid using one
> of those extensions
>
> Next steps:
>
> * start fleshing out a schema for the .pdt files
> * start fleshing out a spec for the repository layout (should be  
> "parsable"
> by modelVersion 4.0.0 aware clients, but need to decide how to expose new
> features)
>

+1 for .pdt and the described next steps

Robert

> On Tuesday 30 August 2016, Stephen Connolly  
> <st...@gmail.com>
> wrote:
>
>> On 29 August 2016 at 23:27, Christian Schulte <cs@schulte.it
>> <javascript:_e(%7B%7D,'cvml','cs@schulte.it');>> wrote:
>>
>>> Am 08/30/16 um 00:16 schrieb Paul Benedict:
>>> > I see a deployed faulty "consumer pom" to be more more harmful than
>>> > generating it locally on demand. At least with the local one I can
>>> upgrade
>>> > my client to fix a dependency calculation. There will be no such  
>>> relief
>>> in
>>> > the case of your proposal.
>>>
>>> It's not my proposal but I agree to what is proposed. This whole
>>> discussion started because users have requested to revert commits due  
>>> to
>>> compatibility issues. They want to keep such "faulty" behaviour. If  
>>> they
>>> want to fix it, they can deploy a new version using a more recent Maven
>>> version. The older Maven version will then also see this new behaviour.
>>> If the consumer pom contains the complete resolved dependency tree, the
>>> code interpreting that data is not much more than downloading some  
>>> files
>>> from some repository. Yes. Repository information needs to be part of
>>> that consumer pom as well. So the resolved dependency tree including
>>> repository information from where to get the resolved artifacts. And we
>>> also need to find a way to handle version ranges.
>>>
>>
>> So the way I see this, different types of artifacts have different tree
>> requirements.
>>
>> I may have one type of artifact (i.e. jar) where it really is not
>> supported to have multiple versions of the same artifact on the same
>> classpath at the same time.
>>
>> We currently view artifact dependency resolution as building a linear  
>> path
>> from the dependency tree based on the assumption of single version of  
>> any
>> dependency.
>>
>> In the JavaScript world... and even in the OSGi world... that assumption
>> is simply not true.
>>
>> This implies - to me - that the consumer pom should contain the tree  
>> that
>> was used at build time... *as a tree*
>>
>> By all means, each node could include the version range as well as the
>> resolved version, e.g.
>>
>> <dependency groupId="..." artifactId="..." architecture="..."
>> classifier="..." type="..." version="[1.0,2.0)" resolvedVersion="1.5.0">
>>   <dependency groupId="..." artifactId="..." architecture="..."
>> classifier="..." type="..." version="..." resolvedVersion="...">
>>     ...
>>   </dependency>
>>   ...
>>   <dependency groupId="..." artifactId="..." architecture="..."
>> classifier="..." type="..." version="..." resolvedVersion="..."/>
>> </dependency>
>>
>> The child elements are the dependencies of the resolved version.
>>
>> Now the consumer of the consumer pom has all the dependency information
>> used at build time as well as the information to perform  
>> substitutions...
>>
>> This means that if I - as a consumer - am already pulling in a different
>> resolvedVersion (but valid within the advertised range) of a child
>> dependency and I am using the tree to produce a single-version  
>> classpath, I
>> can prune the tree and know I have removed the unrequired dependencies.
>>
>> If I - as a consumer - need to produce a multi-version classpath -  
>> because
>> I am producing for an OSGi container - I can build the correct tree  
>> rather
>> than being forced to look at a flattened classpath that may not be  
>> aligned
>> with the requirements of the dependency system I am using
>>
>> If I - as a consumer - decide that I want to push the ranges to newer,  
>> we
>> still have the range information to allow for range validation... but by
>> default I will be using the versions that were resolved at build time  
>> and
>> consequently tested with by the builder.
>>
>> HTH
>>
>> -Stephen
>>
>>
>>>
>>> Regards,
>>> --
>>> Christian
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> <javascript:_e(%7B%7D,'cvml','dev-unsubscribe@maven.apache.org');>
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>> <javascript:_e(%7B%7D,'cvml','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: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Stephen Connolly <st...@gmail.com>]

I've been thinking about what to call the "consumer Pom"...

I think this is actually not a project object model, but the project
dependency trees

It should list each side artifact and their dependency trees...

So for example:

* the java doc artifacts should depend on the corresponding dependency java
doc artifacts (in an ideal world) because we expect {@link} references

* the source artifacts do not depend on anything else (normally) but for an
über jar (which yes is a bad pattern) you would actually be correct to
depend on the bundled artifacts source jars... So the concept still makes
sense

* the test jar artifact would have the full test dependency tree exposed as
this would allow for test reuse

Now I guess the question is if .pdt or .adt (artifact dependency trees) are
too entrenched in some other domain that we'd want to avoid using one
of those extensions

Next steps:

* start fleshing out a schema for the .pdt files
* start fleshing out a spec for the repository layout (should be "parsable"
by modelVersion 4.0.0 aware clients, but need to decide how to expose new
features)

On Tuesday 30 August 2016, Stephen Connolly <st...@gmail.com>
wrote:

> On 29 August 2016 at 23:27, Christian Schulte <cs@schulte.it
> <javascript:_e(%7B%7D,'cvml','cs@schulte.it');>> wrote:
>
>> Am 08/30/16 um 00:16 schrieb Paul Benedict:
>> > I see a deployed faulty "consumer pom" to be more more harmful than
>> > generating it locally on demand. At least with the local one I can
>> upgrade
>> > my client to fix a dependency calculation. There will be no such relief
>> in
>> > the case of your proposal.
>>
>> It's not my proposal but I agree to what is proposed. This whole
>> discussion started because users have requested to revert commits due to
>> compatibility issues. They want to keep such "faulty" behaviour. If they
>> want to fix it, they can deploy a new version using a more recent Maven
>> version. The older Maven version will then also see this new behaviour.
>> If the consumer pom contains the complete resolved dependency tree, the
>> code interpreting that data is not much more than downloading some files
>> from some repository. Yes. Repository information needs to be part of
>> that consumer pom as well. So the resolved dependency tree including
>> repository information from where to get the resolved artifacts. And we
>> also need to find a way to handle version ranges.
>>
>
> So the way I see this, different types of artifacts have different tree
> requirements.
>
> I may have one type of artifact (i.e. jar) where it really is not
> supported to have multiple versions of the same artifact on the same
> classpath at the same time.
>
> We currently view artifact dependency resolution as building a linear path
> from the dependency tree based on the assumption of single version of any
> dependency.
>
> In the JavaScript world... and even in the OSGi world... that assumption
> is simply not true.
>
> This implies - to me - that the consumer pom should contain the tree that
> was used at build time... *as a tree*
>
> By all means, each node could include the version range as well as the
> resolved version, e.g.
>
> <dependency groupId="..." artifactId="..." architecture="..."
> classifier="..." type="..." version="[1.0,2.0)" resolvedVersion="1.5.0">
>   <dependency groupId="..." artifactId="..." architecture="..."
> classifier="..." type="..." version="..." resolvedVersion="...">
>     ...
>   </dependency>
>   ...
>   <dependency groupId="..." artifactId="..." architecture="..."
> classifier="..." type="..." version="..." resolvedVersion="..."/>
> </dependency>
>
> The child elements are the dependencies of the resolved version.
>
> Now the consumer of the consumer pom has all the dependency information
> used at build time as well as the information to perform substitutions...
>
> This means that if I - as a consumer - am already pulling in a different
> resolvedVersion (but valid within the advertised range) of a child
> dependency and I am using the tree to produce a single-version classpath, I
> can prune the tree and know I have removed the unrequired dependencies.
>
> If I - as a consumer - need to produce a multi-version classpath - because
> I am producing for an OSGi container - I can build the correct tree rather
> than being forced to look at a flattened classpath that may not be aligned
> with the requirements of the dependency system I am using
>
> If I - as a consumer - decide that I want to push the ranges to newer, we
> still have the range information to allow for range validation... but by
> default I will be using the versions that were resolved at build time and
> consequently tested with by the builder.
>
> HTH
>
> -Stephen
>
>
>>
>> Regards,
>> --
>> Christian
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> <javascript:_e(%7B%7D,'cvml','dev-unsubscribe@maven.apache.org');>
>> For additional commands, e-mail: dev-help@maven.apache.org
>> <javascript:_e(%7B%7D,'cvml','dev-help@maven.apache.org');>
>>
>>
>

-- 
Sent from my phone

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Stephen Connolly <st...@gmail.com>]

On 29 August 2016 at 23:27, Christian Schulte <cs...@schulte.it> wrote:

> Am 08/30/16 um 00:16 schrieb Paul Benedict:
> > I see a deployed faulty "consumer pom" to be more more harmful than
> > generating it locally on demand. At least with the local one I can
> upgrade
> > my client to fix a dependency calculation. There will be no such relief
> in
> > the case of your proposal.
>
> It's not my proposal but I agree to what is proposed. This whole
> discussion started because users have requested to revert commits due to
> compatibility issues. They want to keep such "faulty" behaviour. If they
> want to fix it, they can deploy a new version using a more recent Maven
> version. The older Maven version will then also see this new behaviour.
> If the consumer pom contains the complete resolved dependency tree, the
> code interpreting that data is not much more than downloading some files
> from some repository. Yes. Repository information needs to be part of
> that consumer pom as well. So the resolved dependency tree including
> repository information from where to get the resolved artifacts. And we
> also need to find a way to handle version ranges.
>

So the way I see this, different types of artifacts have different tree
requirements.

I may have one type of artifact (i.e. jar) where it really is not supported
to have multiple versions of the same artifact on the same classpath at the
same time.

We currently view artifact dependency resolution as building a linear path
from the dependency tree based on the assumption of single version of any
dependency.

In the JavaScript world... and even in the OSGi world... that assumption is
simply not true.

This implies - to me - that the consumer pom should contain the tree that
was used at build time... *as a tree*

By all means, each node could include the version range as well as the
resolved version, e.g.

<dependency groupId="..." artifactId="..." architecture="..."
classifier="..." type="..." version="[1.0,2.0)" resolvedVersion="1.5.0">
  <dependency groupId="..." artifactId="..." architecture="..."
classifier="..." type="..." version="..." resolvedVersion="...">
    ...
  </dependency>
  ...
  <dependency groupId="..." artifactId="..." architecture="..."
classifier="..." type="..." version="..." resolvedVersion="..."/>
</dependency>

The child elements are the dependencies of the resolved version.

Now the consumer of the consumer pom has all the dependency information
used at build time as well as the information to perform substitutions...

This means that if I - as a consumer - am already pulling in a different
resolvedVersion (but valid within the advertised range) of a child
dependency and I am using the tree to produce a single-version classpath, I
can prune the tree and know I have removed the unrequired dependencies.

If I - as a consumer - need to produce a multi-version classpath - because
I am producing for an OSGi container - I can build the correct tree rather
than being forced to look at a flattened classpath that may not be aligned
with the requirements of the dependency system I am using

If I - as a consumer - decide that I want to push the ranges to newer, we
still have the range information to allow for range validation... but by
default I will be using the versions that were resolved at build time and
consequently tested with by the builder.

HTH

-Stephen


>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 08/30/16 um 00:16 schrieb Paul Benedict:
> I see a deployed faulty "consumer pom" to be more more harmful than
> generating it locally on demand. At least with the local one I can upgrade
> my client to fix a dependency calculation. There will be no such relief in
> the case of your proposal.

It's not my proposal but I agree to what is proposed. This whole
discussion started because users have requested to revert commits due to
compatibility issues. They want to keep such "faulty" behaviour. If they
want to fix it, they can deploy a new version using a more recent Maven
version. The older Maven version will then also see this new behaviour.
If the consumer pom contains the complete resolved dependency tree, the
code interpreting that data is not much more than downloading some files
from some repository. Yes. Repository information needs to be part of
that consumer pom as well. So the resolved dependency tree including
repository information from where to get the resolved artifacts. And we
also need to find a way to handle version ranges.

Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Paul Benedict <pb...@apache.org>]

Christian, I could argue that's not much different than today. The
"consumer pom" -- no matter how much you distill or flatten it -- will
still require processing. Data is useless without an interpretation. A
Maven client will still have to have to process it, and there will likely
be bugs in that code, too. So please forgive me for being skeptical of
what's being proposed.

I see a deployed faulty "consumer pom" to be more more harmful than
generating it locally on demand. At least with the local one I can upgrade
my client to fix a dependency calculation. There will be no such relief in
the case of your proposal.

Cheers,
Paul

On Mon, Aug 29, 2016 at 4:56 PM, Christian Schulte <cs...@schulte.it> wrote:

> Am 08/29/16 um 23:35 schrieb Paul Benedict:
> > Robert, I am mostly in agreement here. However, the big downside to
> > deploying the calculations is that they are forever. Furthermore,
> deploying
> > the "consumer pom" takes away the ability for a newer Maven client with
> > resolution bug fixes and/or optimizations to build a leaner and more
> > efficient calculation.
>
> That's exactly what everyone is requesting. Once deployed, things are
> forever. We are asked to not change anything in Maven in a way leading
> to different build results than an older Maven version would produce
> when operating on the same pom again and again. That's the way out of
> it. The content of those consumer poms can change when using a more
> recent Maven version. Once deployed, all Maven versions always see the
> same result, even if the version in use would have generated a different
> consumer pom (containing new features/bug fixes).
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 08/29/16 um 23:35 schrieb Paul Benedict:
> Robert, I am mostly in agreement here. However, the big downside to
> deploying the calculations is that they are forever. Furthermore, deploying
> the "consumer pom" takes away the ability for a newer Maven client with
> resolution bug fixes and/or optimizations to build a leaner and more
> efficient calculation.

That's exactly what everyone is requesting. Once deployed, things are
forever. We are asked to not change anything in Maven in a way leading
to different build results than an older Maven version would produce
when operating on the same pom again and again. That's the way out of
it. The content of those consumer poms can change when using a more
recent Maven version. Once deployed, all Maven versions always see the
same result, even if the version in use would have generated a different
consumer pom (containing new features/bug fixes).

Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Paul Benedict <pb...@apache.org>]

On Mon, Aug 29, 2016 at 4:07 PM, Robert Scholte <rf...@apache.org>
wrote:

> I think that all the fields of a dependency are quite complete. Based on
> the issues I see with moving forward with Aether is that the (complex)
> dependency resolution is done inside Maven. The idea is to not calculate
> this anymore, but add all transitive dependencies to the consumer pom.
> This would hopefully remove the discussion what all the dependencies are,
> since they're already summed up.
> Stephen already started with a list of items which should be added the
> consumer-pom.
>

Robert, I am mostly in agreement here. However, the big downside to
deploying the calculations is that they are forever. Furthermore, deploying
the "consumer pom" takes away the ability for a newer Maven client with
resolution bug fixes and/or optimizations to build a leaner and more
efficient calculation.

By the time we have the first complete definitions, we should compare it
> with the experiences at Subversion.
>

The experiences at Subversion are relevant for producing the "consumer pom"
locally. I am arguing that Maven clients should automatically produce and
cache (install) the "consumer pom" as part of the download of the normal
build POM. You get the benefits you're advocating, plus the ones I am
mentioning.

Cheers,
Paul

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 08/29/16 um 23:07 schrieb Robert Scholte:
> dependency resolution is done inside Maven. The idea is to not calculate  
> this anymore, but add all transitive dependencies to the consumer pom.
> This would hopefully remove the discussion what all the dependencies are,  
> since they're already summed up.

+1

Question remains: How to handle version ranges? It's not possible to
deploy the resolution result as soon as version ranges need to be
supported. Deploying a version range with that consumer pom means the
consuming software needs to again resolve those ranges itself. Maybe
make version ranges a build time feature only? That way version ranges
would never get deployed in that consumer pom and would always get
resolved during building using the build pom.

Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Robert Scholte <rf...@apache.org>]

I think that all the fields of a dependency are quite complete. Based on  
the issues I see with moving forward with Aether is that the (complex)  
dependency resolution is done inside Maven. The idea is to not calculate  
this anymore, but add all transitive dependencies to the consumer pom.
This would hopefully remove the discussion what all the dependencies are,  
since they're already summed up.
Stephen already started with a list of items which should be added the  
consumer-pom.
By the time we have the first complete definitions, we should compare it  
with the experiences at Subversion.

But that's a completely different discussion. We're actually still  
discussing: model 4.1.0 in Maven 3.4.0 or not?

thanks,
Robert

On Mon, 29 Aug 2016 22:15:16 +0200, Paul Benedict <pb...@apache.org>  
wrote:

> Robert, I am not sure that a consumer-pom will ultimately provide any
> relief to the problem at hand. Eventually -- even if it is some point  
> very
> distant in the future -- the consumer-pom will also need to evolve so the
> same problem will rear its head: how do you read a POM of a future model
> version? The only way this ultimately gets solved is to have evolving
> formats on each end... and a policy on what is, if anything,
> forward-compatible. I called out Subversion as a solution to model. Both  
> of
> its formats (working copy and server) evolve. The most interesting  
> aspect,
> however, is the transformation of the server copy into a working copy. If
> such a model was copied, then deploying a "consumer pom" would disappear  
> as
> a notion. Instead, clients would download the build POM (like now), but
> then generate a "consumer pom" locally as their optimized "working copy"
> for dependency management.
>
> Cheers,
> Paul
>
> On Mon, Aug 29, 2016 at 1:33 PM, Robert Scholte <rf...@apache.org>
> wrote:
>
>> We're missing separations of concerns with the pom. Right now it  
>> contains
>> all the information to build the project and all the dependency
>> information. Once deployed only the latter is roughly of any interest.  
>> As
>> long as the build-pom is also the deploy-pom, we cannot change a lot  
>> since
>> this pom is also metadata for other tools, which are now very well  
>> capable
>> in parsing and processing the pom.
>> Once we split this, the build-pom will become a Maven specific file and  
>> we
>> can change it as often as we want (though we should try not to do so),  
>> as
>> long as the deploy-pom remains the same.
>>
>> The introduced changes had no effect on the schema, but it did change  
>> the
>> behavior of dependency resolution.
>> I don't know every fixed bug/changed feature, but based on the responses
>> there are projects which depend on that bug/feature. Overall I don't  
>> have a
>> very good feeling about these changes, since I can't predict the  
>> impact. Do
>> we simply push them as bugfixes after more than 5 years?
>> I have more faith in the consumer-pom/dom, but that also requires  
>> talking
>> with third parties who depend on Central. I'm talking about artifact
>> repository vendors, IDE vendors and build tool vendors. Together we have
>> enough experience and should be able to come to a new and better schema.
>>
>> cheers,
>> Robert
>>
>>
>> On Mon, 29 Aug 2016 01:32:12 +0200, Paul Benedict <pb...@apache.org>
>> wrote:
>>
>> Last week, I communicated my thoughts on why POM model 4.1.0 should not  
>> be
>>> introduced in the 3.x series. I said that I believed that forcing two
>>> separate lines of development would best be beneficial to the overall  
>>> code
>>> base (which is big!!!). The benefit, so I think, is that 3.x would  
>>> focus
>>> on
>>> graceful handling of new metadata; the 4.x line would be free to  
>>> develop
>>> new features. The two concerns are important enough that one code base
>>> shouldn't try to handle both -- especially if there is desire to  
>>> backport
>>> graceful handling into even older releases as small point releases.
>>>
>>> I am not sure there was any direct responses so I am raising the issue
>>> again. Does anyone find this appealing? And if not, why not? This is  
>>> the
>>> direction I am advocating, but unless there is any traction on it, I  
>>> don't
>>> want to beat the drum on a dead idea. Thanks everyone.
>>>
>>> Cheers,
>>> Paul
>>>
>>> On Sun, Aug 28, 2016 at 4:38 PM, Christian Schulte <cs...@schulte.it>  
>>> wrote:
>>>
>>> Am 08/24/16 um 08:15 schrieb Hervé BOUTEMY:
>>>> > Le mercredi 24 août 2016 00:45:28 Christian Schulte a écrit :
>>>> >> Am 08/24/16 um 00:40 schrieb Christian Schulte:
>>>> >>> Am 08/23/16 um 22:33 schrieb Hervé BOUTEMY:
>>>> >>>> yes, people providing libraries have this big choice to do: when  
>>>> to
>>>> >>>> upgrade
>>>> >>>> minimum JRE version for consumers.
>>>> >>>>
>>>> >>>> yes, we can add them another new big decision to take: when to
>>>> upgrade
>>>> >>>> minium Maven version to consume the library?
>>>> >>>
>>>> >>> When that upgrade lets them solve issues they cannot solve in  
>>>> another
>>>> way.
>>>> >>
>>>> >> No issue with what 4.0.0 provides -> no need to upgrade (do not
>>>> upgrade)
>>>> >> Issue you cannot solve with 4.0.0 -> upgrade to x.y.z, if that
>>>> provides
>>>> >> the solution.
>>>> >>
>>>> >> Regards,
>>>> > my point is that a library producer creates a Maven requirement for  
>>>> a
>>>> library
>>>> > consumer.
>>>> >
>>>> > I'll say it crude for us: Maven is the only tool that give library
>>>> consumers
>>>> > such issues. People using other build tools don't have this issue  
>>>> when
>>>> using
>>>> > central.
>>>>
>>>> Can you provide some links to source code of some other build tool  
>>>> which
>>>> does the whole dependency resolution including import scope processing
>>>> itself without re-using any Maven component? Have others really
>>>> implemented the dependency resolution with exactly the same behaviour
>>>> Maven has? For a build tool running on the Java VM, they would have
>>>> re-used the 'maven-model-builder' or 'maven-aether-provider', I guess.
>>>> That means they would just need to upgrade to 'maven-aether-provider'
>>>> 3.4 and be done with it.
>>>>
>>>> Regards,
>>>> --
>>>> Christian
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Tibor Digana <ti...@apache.org>]

I am sceptical about somebody would be interested in another schema
(handling new one) than the one used with POM.
I think we are too inside in ourselves.
Imaging the developers or companies using Maven nowadays, or IDEs,
easily they would say "no difference, the POM works for me so no issue
- let's keep it".

I think the biggest boost is in build-pom and not in deploy/consumer-pom.
For me deploy/consumer-pom is just a list of runtime dependencies as
the most important XML entries.

Sorry that I am not nice person to you in this thread. I don't use to
be like this.

-- 
Cheers
Tibor




--
View this message in context: http://maven.40175.n5.nabble.com/Re-POM-Model-version-4-1-0-in-3-4-0-SNAPSHOTs-tp5878254p5879339.html
Sent from the Maven Developers mailing list archive at Nabble.com.

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Paul Benedict <pb...@apache.org>]

Robert, I am not sure that a consumer-pom will ultimately provide any
relief to the problem at hand. Eventually -- even if it is some point very
distant in the future -- the consumer-pom will also need to evolve so the
same problem will rear its head: how do you read a POM of a future model
version? The only way this ultimately gets solved is to have evolving
formats on each end... and a policy on what is, if anything,
forward-compatible. I called out Subversion as a solution to model. Both of
its formats (working copy and server) evolve. The most interesting aspect,
however, is the transformation of the server copy into a working copy. If
such a model was copied, then deploying a "consumer pom" would disappear as
a notion. Instead, clients would download the build POM (like now), but
then generate a "consumer pom" locally as their optimized "working copy"
for dependency management.

Cheers,
Paul

On Mon, Aug 29, 2016 at 1:33 PM, Robert Scholte <rf...@apache.org>
wrote:

> We're missing separations of concerns with the pom. Right now it contains
> all the information to build the project and all the dependency
> information. Once deployed only the latter is roughly of any interest. As
> long as the build-pom is also the deploy-pom, we cannot change a lot since
> this pom is also metadata for other tools, which are now very well capable
> in parsing and processing the pom.
> Once we split this, the build-pom will become a Maven specific file and we
> can change it as often as we want (though we should try not to do so), as
> long as the deploy-pom remains the same.
>
> The introduced changes had no effect on the schema, but it did change the
> behavior of dependency resolution.
> I don't know every fixed bug/changed feature, but based on the responses
> there are projects which depend on that bug/feature. Overall I don't have a
> very good feeling about these changes, since I can't predict the impact. Do
> we simply push them as bugfixes after more than 5 years?
> I have more faith in the consumer-pom/dom, but that also requires talking
> with third parties who depend on Central. I'm talking about artifact
> repository vendors, IDE vendors and build tool vendors. Together we have
> enough experience and should be able to come to a new and better schema.
>
> cheers,
> Robert
>
>
> On Mon, 29 Aug 2016 01:32:12 +0200, Paul Benedict <pb...@apache.org>
> wrote:
>
> Last week, I communicated my thoughts on why POM model 4.1.0 should not be
>> introduced in the 3.x series. I said that I believed that forcing two
>> separate lines of development would best be beneficial to the overall code
>> base (which is big!!!). The benefit, so I think, is that 3.x would focus
>> on
>> graceful handling of new metadata; the 4.x line would be free to develop
>> new features. The two concerns are important enough that one code base
>> shouldn't try to handle both -- especially if there is desire to backport
>> graceful handling into even older releases as small point releases.
>>
>> I am not sure there was any direct responses so I am raising the issue
>> again. Does anyone find this appealing? And if not, why not? This is the
>> direction I am advocating, but unless there is any traction on it, I don't
>> want to beat the drum on a dead idea. Thanks everyone.
>>
>> Cheers,
>> Paul
>>
>> On Sun, Aug 28, 2016 at 4:38 PM, Christian Schulte <cs...@schulte.it> wrote:
>>
>> Am 08/24/16 um 08:15 schrieb Hervé BOUTEMY:
>>> > Le mercredi 24 août 2016 00:45:28 Christian Schulte a écrit :
>>> >> Am 08/24/16 um 00:40 schrieb Christian Schulte:
>>> >>> Am 08/23/16 um 22:33 schrieb Hervé BOUTEMY:
>>> >>>> yes, people providing libraries have this big choice to do: when to
>>> >>>> upgrade
>>> >>>> minimum JRE version for consumers.
>>> >>>>
>>> >>>> yes, we can add them another new big decision to take: when to
>>> upgrade
>>> >>>> minium Maven version to consume the library?
>>> >>>
>>> >>> When that upgrade lets them solve issues they cannot solve in another
>>> way.
>>> >>
>>> >> No issue with what 4.0.0 provides -> no need to upgrade (do not
>>> upgrade)
>>> >> Issue you cannot solve with 4.0.0 -> upgrade to x.y.z, if that
>>> provides
>>> >> the solution.
>>> >>
>>> >> Regards,
>>> > my point is that a library producer creates a Maven requirement for a
>>> library
>>> > consumer.
>>> >
>>> > I'll say it crude for us: Maven is the only tool that give library
>>> consumers
>>> > such issues. People using other build tools don't have this issue when
>>> using
>>> > central.
>>>
>>> Can you provide some links to source code of some other build tool which
>>> does the whole dependency resolution including import scope processing
>>> itself without re-using any Maven component? Have others really
>>> implemented the dependency resolution with exactly the same behaviour
>>> Maven has? For a build tool running on the Java VM, they would have
>>> re-used the 'maven-model-builder' or 'maven-aether-provider', I guess.
>>> That means they would just need to upgrade to 'maven-aether-provider'
>>> 3.4 and be done with it.
>>>
>>> Regards,
>>> --
>>> Christian
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Tibor Digana <ti...@apache.org>]

I am using flatten-maven-plugin.
What is the goal for consumer-pom?
My answer is runtime dependencies in general, but we must not forget
the facts that scm, jira is addon which let me to contact the team.
Why you want to deploy both consumer and ordinal POM?
Messy isn't it? And therefore existing tools might not be interested
which is the reason why flatten == consumer for me.
Or you want to force the Maven of next generation to lookup
consumer-pom in order to again decrease the memory footprint?
The other tools and IDEs may have another expectations like simplified
dependencies resolution. From the IDE point of view why it should
extract runtime dependencies from build-pom if it could be already
provided in Maven Central.
For instance I use IntelliJ IDEA. Every time I change a version it's a
hell for the PC, all is frozen and project files are built internally.
Why not to help the IDE to provide only relevant information in order
to create internal project files.

On 8/29/16, Robert Scholte-6 [via Maven]
<ml...@n5.nabble.com> wrote:
>
>
> On Mon, 29 Aug 2016 21:29:36 +0200, Tibor Digana <ti...@apache.org>
> wrote:
>
>> Hi Robert,
>>
>> Hm, sep.of.concern, this discussion does not have the end. We should
>> start another more concrete.
>> Let's list all first-level items of consumer POM I would need to have
>> in my case and we will see where we go:
>> parent, name, description, url, scm, issueManagement, dependencies,
>> depMgt, distributionManagement/relocation+repository.
>
> Hi Tibor,
>
> Based on these fields you're talking not talking about the
> consumer-pom/dom, but the flattened pom / reduced-deployment pom.
> And even in that case there are some fields which I doubt are interesting.
>
> I've had a lot of discussions about the flatten-maven-plugin what it must
> do and how it should work. It gave me a lot of extra insight about the
> pom, experience required to have a proper implementation of the
> reduced-deployment pom.
> Goal: minimize the content of the 4.0.0 pom to reduce memory usage.
>
> The consumer pom is a completely different beast.
> Goal: efficient dependency resolution.
>
> hopefully this makes it more clear,
> Robert
>
>>
>> Then how you want to cope with problem where a contributor want's to
>> introduce a new scope, e.g. only-compile or something else?
>>
>> Cheers
>> Tibor
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://maven.40175.n5.nabble.com/Re-POM-Model-version-4-1-0-in-3-4-0-SNAPSHOTs-tp5878254p5879296.html
>> Sent from the Maven Developers mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
>
> _______________________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/Re-POM-Model-version-4-1-0-in-3-4-0-SNAPSHOTs-tp5878254p5879346.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166h86@n5.nabble.com
> To unsubscribe from Maven Developers, visit
> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==


-- 
Cheers
Tibor




--
View this message in context: http://maven.40175.n5.nabble.com/Re-POM-Model-version-4-1-0-in-3-4-0-SNAPSHOTs-tp5878254p5879364.html
Sent from the Maven Developers mailing list archive at Nabble.com.

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 08/29/16 um 22:48 schrieb Robert Scholte:
> The consumer pom is a completely different beast.
> Goal: efficient dependency resolution.

+1

Stephen has pointed out that using XML for this is the best solution we
can offer, because XML can be handled easily with almost any programming
language and in combination with XSLT it can be transformed to anything
we want/need to. We should find a good file extension for those files so
that a repository server can easily be setup to serve these files using
some kind of compression/chunked content/transfer encoding. Using .xml
probably is a bad idea.


Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Robert Scholte <rf...@apache.org>]

On Mon, 29 Aug 2016 21:29:36 +0200, Tibor Digana <ti...@apache.org>  
wrote:

> Hi Robert,
>
> Hm, sep.of.concern, this discussion does not have the end. We should
> start another more concrete.
> Let's list all first-level items of consumer POM I would need to have
> in my case and we will see where we go:
> parent, name, description, url, scm, issueManagement, dependencies,
> depMgt, distributionManagement/relocation+repository.

Hi Tibor,

Based on these fields you're talking not talking about the  
consumer-pom/dom, but the flattened pom / reduced-deployment pom.
And even in that case there are some fields which I doubt are interesting.  
I've had a lot of discussions about the flatten-maven-plugin what it must  
do and how it should work. It gave me a lot of extra insight about the  
pom, experience required to have a proper implementation of the  
reduced-deployment pom.
Goal: minimize the content of the 4.0.0 pom to reduce memory usage.

The consumer pom is a completely different beast.
Goal: efficient dependency resolution.

hopefully this makes it more clear,
Robert

>
> Then how you want to cope with problem where a contributor want's to
> introduce a new scope, e.g. only-compile or something else?
>
> Cheers
> Tibor
>
>
>
>
> --
> View this message in context:  
> http://maven.40175.n5.nabble.com/Re-POM-Model-version-4-1-0-in-3-4-0-SNAPSHOTs-tp5878254p5879296.html
> Sent from the Maven Developers mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Tibor Digana <ti...@apache.org>]

Hi Robert,

Hm, sep.of.concern, this discussion does not have the end. We should
start another more concrete.
Let's list all first-level items of consumer POM I would need to have
in my case and we will see where we go:
parent, name, description, url, scm, issueManagement, dependencies,
depMgt, distributionManagement/relocation+repository.

Then how you want to cope with problem where a contributor want's to
introduce a new scope, e.g. only-compile or something else?

Cheers
Tibor




--
View this message in context: http://maven.40175.n5.nabble.com/Re-POM-Model-version-4-1-0-in-3-4-0-SNAPSHOTs-tp5878254p5879296.html
Sent from the Maven Developers mailing list archive at Nabble.com.

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Tibor Digana <ti...@apache.org>]

Sorry that I reply to consumer POM again, I want to fix my previous
email, the parent in consumer POM is not needed from my point of view
because I would naturally consider all POMs in Maven Central as
totally resolved with their dependencies against scope=runtime and
independent of parent and depMgt. The POM with packaging=pom may
contain depMgt.
This would lead to the situations where BOM files have depMgt but
typical POMs with binaries packaging won't have depMgt, this means two
XSD schemas.
And here we come up with BOM files.

Cheers
Tibor

On 8/29/16, Robert Scholte-6 [via Maven]
<ml...@n5.nabble.com> wrote:
>
>
> We're missing separations of concerns with the pom. Right now it contains
> all the information to build the project and all the dependency
> information. Once deployed only the latter is roughly of any interest. As
> long as the build-pom is also the deploy-pom, we cannot change a lot since
>
> this pom is also metadata for other tools, which are now very well capable
>
> in parsing and processing the pom.
> Once we split this, the build-pom will become a Maven specific file and we
>
> can change it as often as we want (though we should try not to do so), as
> long as the deploy-pom remains the same.
>
> The introduced changes had no effect on the schema, but it did change the
> behavior of dependency resolution.
> I don't know every fixed bug/changed feature, but based on the responses
> there are projects which depend on that bug/feature. Overall I don't have
> a very good feeling about these changes, since I can't predict the impact.
>
> Do we simply push them as bugfixes after more than 5 years?
> I have more faith in the consumer-pom/dom, but that also requires talking
> with third parties who depend on Central. I'm talking about artifact
> repository vendors, IDE vendors and build tool vendors. Together we have
> enough experience and should be able to come to a new and better schema.
>
> cheers,
> Robert
>
> On Mon, 29 Aug 2016 01:32:12 +0200, Paul Benedict <pb...@apache.org>
> wrote:
>
>> Last week, I communicated my thoughts on why POM model 4.1.0 should not
>> be
>> introduced in the 3.x series. I said that I believed that forcing two
>> separate lines of development would best be beneficial to the overall
>> code
>> base (which is big!!!). The benefit, so I think, is that 3.x would focus
>>
>> on
>> graceful handling of new metadata; the 4.x line would be free to develop
>> new features. The two concerns are important enough that one code base
>> shouldn't try to handle both -- especially if there is desire to backport
>> graceful handling into even older releases as small point releases.
>>
>> I am not sure there was any direct responses so I am raising the issue
>> again. Does anyone find this appealing? And if not, why not? This is the
>> direction I am advocating, but unless there is any traction on it, I
>> don't
>> want to beat the drum on a dead idea. Thanks everyone.
>>
>> Cheers,
>> Paul
>>
>> On Sun, Aug 28, 2016 at 4:38 PM, Christian Schulte <cs...@schulte.it> wrote:
>>
>>> Am 08/24/16 um 08:15 schrieb Hervé BOUTEMY:
>>> > Le mercredi 24 août 2016 00:45:28 Christian Schulte a écrit :
>>> >> Am 08/24/16 um 00:40 schrieb Christian Schulte:
>>> >>> Am 08/23/16 um 22:33 schrieb Hervé BOUTEMY:
>>> >>>> yes, people providing libraries have this big choice to do: when to
>>> >>>> upgrade
>>> >>>> minimum JRE version for consumers.
>>> >>>>
>>> >>>> yes, we can add them another new big decision to take: when to
>>> upgrade
>>> >>>> minium Maven version to consume the library?
>>> >>>
>>> >>> When that upgrade lets them solve issues they cannot solve in
>>> another
>>> way.
>>> >>
>>> >> No issue with what 4.0.0 provides -> no need to upgrade (do not
>>> upgrade)
>>> >> Issue you cannot solve with 4.0.0 -> upgrade to x.y.z, if that
>>> provides
>>> >> the solution.
>>> >>
>>> >> Regards,
>>> > my point is that a library producer creates a Maven requirement for a
>>> library
>>> > consumer.
>>> >
>>> > I'll say it crude for us: Maven is the only tool that give library
>>> consumers
>>> > such issues. People using other build tools don't have this issue when
>>> using
>>> > central.
>>>
>>> Can you provide some links to source code of some other build tool which
>>> does the whole dependency resolution including import scope processing
>>> itself without re-using any Maven component? Have others really
>>> implemented the dependency resolution with exactly the same behaviour
>>> Maven has? For a build tool running on the Java VM, they would have
>>> re-used the 'maven-model-builder' or 'maven-aether-provider', I guess.
>>> That means they would just need to upgrade to 'maven-aether-provider'
>>> 3.4 and be done with it.
>>>
>>> Regards,
>>> --
>>> Christian
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
>
>
>
> _______________________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/Re-POM-Model-version-4-1-0-in-3-4-0-SNAPSHOTs-tp5878254p5879290.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166h86@n5.nabble.com
> To unsubscribe from Maven Developers, visit
> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==


-- 
Cheers
Tibor




--
View this message in context: http://maven.40175.n5.nabble.com/Re-POM-Model-version-4-1-0-in-3-4-0-SNAPSHOTs-tp5878254p5879313.html
Sent from the Maven Developers mailing list archive at Nabble.com.

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Robert Scholte <rf...@apache.org>]

We're missing separations of concerns with the pom. Right now it contains  
all the information to build the project and all the dependency  
information. Once deployed only the latter is roughly of any interest. As  
long as the build-pom is also the deploy-pom, we cannot change a lot since  
this pom is also metadata for other tools, which are now very well capable  
in parsing and processing the pom.
Once we split this, the build-pom will become a Maven specific file and we  
can change it as often as we want (though we should try not to do so), as  
long as the deploy-pom remains the same.

The introduced changes had no effect on the schema, but it did change the  
behavior of dependency resolution.
I don't know every fixed bug/changed feature, but based on the responses  
there are projects which depend on that bug/feature. Overall I don't have  
a very good feeling about these changes, since I can't predict the impact.  
Do we simply push them as bugfixes after more than 5 years?
I have more faith in the consumer-pom/dom, but that also requires talking  
with third parties who depend on Central. I'm talking about artifact  
repository vendors, IDE vendors and build tool vendors. Together we have  
enough experience and should be able to come to a new and better schema.

cheers,
Robert

On Mon, 29 Aug 2016 01:32:12 +0200, Paul Benedict <pb...@apache.org>  
wrote:

> Last week, I communicated my thoughts on why POM model 4.1.0 should not  
> be
> introduced in the 3.x series. I said that I believed that forcing two
> separate lines of development would best be beneficial to the overall  
> code
> base (which is big!!!). The benefit, so I think, is that 3.x would focus  
> on
> graceful handling of new metadata; the 4.x line would be free to develop
> new features. The two concerns are important enough that one code base
> shouldn't try to handle both -- especially if there is desire to backport
> graceful handling into even older releases as small point releases.
>
> I am not sure there was any direct responses so I am raising the issue
> again. Does anyone find this appealing? And if not, why not? This is the
> direction I am advocating, but unless there is any traction on it, I  
> don't
> want to beat the drum on a dead idea. Thanks everyone.
>
> Cheers,
> Paul
>
> On Sun, Aug 28, 2016 at 4:38 PM, Christian Schulte <cs...@schulte.it> wrote:
>
>> Am 08/24/16 um 08:15 schrieb Hervé BOUTEMY:
>> > Le mercredi 24 août 2016 00:45:28 Christian Schulte a écrit :
>> >> Am 08/24/16 um 00:40 schrieb Christian Schulte:
>> >>> Am 08/23/16 um 22:33 schrieb Hervé BOUTEMY:
>> >>>> yes, people providing libraries have this big choice to do: when to
>> >>>> upgrade
>> >>>> minimum JRE version for consumers.
>> >>>>
>> >>>> yes, we can add them another new big decision to take: when to  
>> upgrade
>> >>>> minium Maven version to consume the library?
>> >>>
>> >>> When that upgrade lets them solve issues they cannot solve in  
>> another
>> way.
>> >>
>> >> No issue with what 4.0.0 provides -> no need to upgrade (do not  
>> upgrade)
>> >> Issue you cannot solve with 4.0.0 -> upgrade to x.y.z, if that  
>> provides
>> >> the solution.
>> >>
>> >> Regards,
>> > my point is that a library producer creates a Maven requirement for a
>> library
>> > consumer.
>> >
>> > I'll say it crude for us: Maven is the only tool that give library
>> consumers
>> > such issues. People using other build tools don't have this issue when
>> using
>> > central.
>>
>> Can you provide some links to source code of some other build tool which
>> does the whole dependency resolution including import scope processing
>> itself without re-using any Maven component? Have others really
>> implemented the dependency resolution with exactly the same behaviour
>> Maven has? For a build tool running on the Java VM, they would have
>> re-used the 'maven-model-builder' or 'maven-aether-provider', I guess.
>> That means they would just need to upgrade to 'maven-aether-provider'
>> 3.4 and be done with it.
>>
>> Regards,
>> --
>> Christian
>>
>>
>> ---------------------------------------------------------------------
>> 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: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Paul Benedict <pb...@apache.org>]

Last week, I communicated my thoughts on why POM model 4.1.0 should not be
introduced in the 3.x series. I said that I believed that forcing two
separate lines of development would best be beneficial to the overall code
base (which is big!!!). The benefit, so I think, is that 3.x would focus on
graceful handling of new metadata; the 4.x line would be free to develop
new features. The two concerns are important enough that one code base
shouldn't try to handle both -- especially if there is desire to backport
graceful handling into even older releases as small point releases.

I am not sure there was any direct responses so I am raising the issue
again. Does anyone find this appealing? And if not, why not? This is the
direction I am advocating, but unless there is any traction on it, I don't
want to beat the drum on a dead idea. Thanks everyone.

Cheers,
Paul

On Sun, Aug 28, 2016 at 4:38 PM, Christian Schulte <cs...@schulte.it> wrote:

> Am 08/24/16 um 08:15 schrieb Hervé BOUTEMY:
> > Le mercredi 24 août 2016 00:45:28 Christian Schulte a écrit :
> >> Am 08/24/16 um 00:40 schrieb Christian Schulte:
> >>> Am 08/23/16 um 22:33 schrieb Hervé BOUTEMY:
> >>>> yes, people providing libraries have this big choice to do: when to
> >>>> upgrade
> >>>> minimum JRE version for consumers.
> >>>>
> >>>> yes, we can add them another new big decision to take: when to upgrade
> >>>> minium Maven version to consume the library?
> >>>
> >>> When that upgrade lets them solve issues they cannot solve in another
> way.
> >>
> >> No issue with what 4.0.0 provides -> no need to upgrade (do not upgrade)
> >> Issue you cannot solve with 4.0.0 -> upgrade to x.y.z, if that provides
> >> the solution.
> >>
> >> Regards,
> > my point is that a library producer creates a Maven requirement for a
> library
> > consumer.
> >
> > I'll say it crude for us: Maven is the only tool that give library
> consumers
> > such issues. People using other build tools don't have this issue when
> using
> > central.
>
> Can you provide some links to source code of some other build tool which
> does the whole dependency resolution including import scope processing
> itself without re-using any Maven component? Have others really
> implemented the dependency resolution with exactly the same behaviour
> Maven has? For a build tool running on the Java VM, they would have
> re-used the 'maven-model-builder' or 'maven-aether-provider', I guess.
> That means they would just need to upgrade to 'maven-aether-provider'
> 3.4 and be done with it.
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 08/24/16 um 08:15 schrieb Herv BOUTEMY:
> Le mercredi 24 aot 2016 00:45:28 Christian Schulte a crit :
>> Am 08/24/16 um 00:40 schrieb Christian Schulte:
>>> Am 08/23/16 um 22:33 schrieb Herv BOUTEMY:
>>>> yes, people providing libraries have this big choice to do: when to
>>>> upgrade
>>>> minimum JRE version for consumers.
>>>>
>>>> yes, we can add them another new big decision to take: when to upgrade
>>>> minium Maven version to consume the library?
>>>
>>> When that upgrade lets them solve issues they cannot solve in another way.
>>
>> No issue with what 4.0.0 provides -> no need to upgrade (do not upgrade)
>> Issue you cannot solve with 4.0.0 -> upgrade to x.y.z, if that provides
>> the solution.
>>
>> Regards,
> my point is that a library producer creates a Maven requirement for a library 
> consumer.
> 
> I'll say it crude for us: Maven is the only tool that give library consumers 
> such issues. People using other build tools don't have this issue when using 
> central.

Can you provide some links to source code of some other build tool which
does the whole dependency resolution including import scope processing
itself without re-using any Maven component? Have others really
implemented the dependency resolution with exactly the same behaviour
Maven has? For a build tool running on the Java VM, they would have
re-used the 'maven-model-builder' or 'maven-aether-provider', I guess.
That means they would just need to upgrade to 'maven-aether-provider'
3.4 and be done with it.

Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Hervé BOUTEMY <he...@free.fr>]

Le mercredi 24 août 2016 00:45:28 Christian Schulte a écrit :
> Am 08/24/16 um 00:40 schrieb Christian Schulte:
> > Am 08/23/16 um 22:33 schrieb Hervé BOUTEMY:
> >> yes, people providing libraries have this big choice to do: when to
> >> upgrade
> >> minimum JRE version for consumers.
> >> 
> >> yes, we can add them another new big decision to take: when to upgrade
> >> minium Maven version to consume the library?
> > 
> > When that upgrade lets them solve issues they cannot solve in another way.
> 
> No issue with what 4.0.0 provides -> no need to upgrade (do not upgrade)
> Issue you cannot solve with 4.0.0 -> upgrade to x.y.z, if that provides
> the solution.
> 
> Regards,
my point is that a library producer creates a Maven requirement for a library 
consumer.

I'll say it crude for us: Maven is the only tool that give library consumers 
such issues. People using other build tools don't have this issue when using 
central.

Regards,

Hervé

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 08/24/16 um 00:40 schrieb Christian Schulte:
> Am 08/23/16 um 22:33 schrieb Herv BOUTEMY:
>> yes, people providing libraries have this big choice to do: when to upgrade 
>> minimum JRE version for consumers.
>>
>> yes, we can add them another new big decision to take: when to upgrade minium 
>> Maven version to consume the library?
> 
> When that upgrade lets them solve issues they cannot solve in another way.
> 

No issue with what 4.0.0 provides -> no need to upgrade (do not upgrade)
Issue you cannot solve with 4.0.0 -> upgrade to x.y.z, if that provides
the solution.

Regards,
-- 
Christian




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 08/23/16 um 22:33 schrieb Herv BOUTEMY:
> yes, people providing libraries have this big choice to do: when to upgrade 
> minimum JRE version for consumers.
> 
> yes, we can add them another new big decision to take: when to upgrade minium 
> Maven version to consume the library?

When that upgrade lets them solve issues they cannot solve in another way.

Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Hervé BOUTEMY <he...@free.fr>]

Le mardi 23 août 2016 23:25:30 Christian Schulte a écrit :
> Am 08/23/16 um 23:17 schrieb Paul Benedict:
> > Truthfully, I must say a lot of this conversation sounds much like
> > Subversion's client/server architecture:
> > 
> > *) The server has a Repository Format version = "build POM"
> > *) The clients create a Working Copy version on checkout = "consumer POM"
> > *) Two distinct schema series
> > *) A client that understands the Repository Format version converts it
> > locally to a Working Copy
> > *) A client that cannot understand a future Repository Format version
> > cannot convert it to a Working Copy
> > *) An upgraded client can "upgrade" an older Working Copy version to the
> > latest Working Copy version
> > 
> > Is this the way Maven wants to go?
1. in short, no
2. this is not yet "the way Maven wants to go" but the result of discussions 
and thought on the topic of giving back to Maven an option to be able to have 
evolution in its build format (which is currently stuck by the fact that 
central has to be usable from any Maven version and any other tool)

> 
> I cannot speak for the PMC or explain the way Maven wants to go. When
> the above comes to Maven, things are really much more simple. You never
> 'check out' the sources from a repository. The repository is only there
> to serve artifacts to be consumed by projects. You checkout the sources
> (containing everything needed to produce the binary artifacts to deploy)
> from the SCM, not the repository. There is no need to deploy any kind of
> build information to a repository. That's my understanding so far.
that' a way to explain it
a complementary explanation: Maven is the only tool which publish its detailed 
build information to central. Other build tools have their build descriptor, 
and generate a little "Maven" pom when they want to publish their artifact to 
central. I tell "Maven" pom, since this little pom is not intended to build 
the artifact, but only to consume.

Then the general idea is to do the same for Maven: treat our build pom as an 
internal build detail, that stays generally in scm but doesn't go to central.
And publish to central only a little generated consumer pom.

Parent pom would be the only exception, where the build parent pom would be 
published to central, but hey, did you see anybody not using Maven publish a 
parent pom?


> I may
> be wrong here. You could use Maven to do that checkout based on SCM
> information from the repository, of course. I think this is what has
> been discussed in that hangout you can still watch on youtube or
> somewhere else. Maybe someone post the links to that hangout?
there is no Hangout or anything: this is a long discussion, partly on this 
mailing list, partly on Hangouts, partly in conferences (ApacheCON, FOSDEM, 
...) to think think think on general strategies
And nowadays, this long running thinking starts to give a result that seems 
simple, consistent, explanable: that's the right time to try to share with 
more people and see if it is understandable and has no major issue, before 
eventually trying a POC or thiinking to decide this is the solution we all 
really want to implement

I intended to start this discussion once Aether import was over, just to avoid 
starting to much fires in parallel, but it started faster than expected :)

Regards,

Hervé

> 
> Regards,


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 08/23/16 um 23:17 schrieb Paul Benedict:
> Truthfully, I must say a lot of this conversation sounds much like
> Subversion's client/server architecture:
> 
> *) The server has a Repository Format version = "build POM"
> *) The clients create a Working Copy version on checkout = "consumer POM"
> *) Two distinct schema series
> *) A client that understands the Repository Format version converts it
> locally to a Working Copy
> *) A client that cannot understand a future Repository Format version
> cannot convert it to a Working Copy
> *) An upgraded client can "upgrade" an older Working Copy version to the
> latest Working Copy version
> 
> Is this the way Maven wants to go?

I cannot speak for the PMC or explain the way Maven wants to go. When
the above comes to Maven, things are really much more simple. You never
'check out' the sources from a repository. The repository is only there
to serve artifacts to be consumed by projects. You checkout the sources
(containing everything needed to produce the binary artifacts to deploy)
from the SCM, not the repository. There is no need to deploy any kind of
build information to a repository. That's my understanding so far. I may
be wrong here. You could use Maven to do that checkout based on SCM
information from the repository, of course. I think this is what has
been discussed in that hangout you can still watch on youtube or
somewhere else. Maybe someone post the links to that hangout?

Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Paul Benedict <pb...@apache.org>]

Truthfully, I must say a lot of this conversation sounds much like
Subversion's client/server architecture:

*) The server has a Repository Format version = "build POM"
*) The clients create a Working Copy version on checkout = "consumer POM"
*) Two distinct schema series
*) A client that understands the Repository Format version converts it
locally to a Working Copy
*) A client that cannot understand a future Repository Format version
cannot convert it to a Working Copy
*) An upgraded client can "upgrade" an older Working Copy version to the
latest Working Copy version

Is this the way Maven wants to go?

Cheers,
Paul

On Tue, Aug 23, 2016 at 4:03 PM, Christian Schulte <cs...@schulte.it> wrote:

> Am 08/23/16 um 22:52 schrieb Christian Schulte:
> > future-proofness, this would need to be reverted as well. Does not solve
> > the version range issue, however. This is what makes it impossible to
> > deploy a pre-resolved dependency tree to the repository. So maybe that
> > is the major issue we need to find a solution for first to get a
> > solution solving everything else automatically.
>
> Pragmatism would make us update the deploy plugin to deploy the
> effective model without import, include, version ranges, build, whatever
> instead of the on-disk model. This would be breaking backwards
> compatibility badly, of course but would solve the major issues so far.
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 08/23/16 um 22:52 schrieb Christian Schulte:
> future-proofness, this would need to be reverted as well. Does not solve
> the version range issue, however. This is what makes it impossible to
> deploy a pre-resolved dependency tree to the repository. So maybe that
> is the major issue we need to find a solution for first to get a
> solution solving everything else automatically.

Pragmatism would make us update the deploy plugin to deploy the
effective model without import, include, version ranges, build, whatever
instead of the on-disk model. This would be breaking backwards
compatibility badly, of course but would solve the major issues so far.

Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 08/23/16 um 22:33 schrieb Herv BOUTEMY:
> yes, people providing libraries have this big choice to do: when to upgrade 
> minimum JRE version for consumers.
> 
> yes, we can add them another new big decision to take: when to upgrade minium 
> Maven version to consume the library?
> 
> but with consumer pom vs build pom, we should be able to avoid this new 
> decision: build pom can evolve (having a prerequisite to builkd the library is 
> not an issue), consumer pom stays compatible
> 
> 
> Now, I don't yet investigated the new include feature, with a simple example 
> of the difference between include and import, and see if a build pom with 
> include could be transformed into a consumer pom without it: is it feasible?

It could be transformed only when not using version ranges. That is -
the deployed POM just does not contain any import or include scope
dependencies any more but the effective dependency management after
inclusion or import. I really like the idea of deploying only the
information necessary to consume a project and have an option of using
something completely different to do the build. There are two big issues
all solutions presented so far do not solve. Version ranges and same
syntax but different semantics. There is some good news to this as well.
Currently the import scope feature does not support using version
ranges! That got implemented on current master due to

<https://issues.apache.org/jira/browse/MNG-4463>

by me but has not been released so far. So Maven 3.4.0-SNAPSHOT
currently supports using version ranges in import declarations. This
will make it impossible to deploy a POM with the imported dependency
management flattened no matter how that has been built. Heading for
future-proofness, this would need to be reverted as well. Does not solve
the version range issue, however. This is what makes it impossible to
deploy a pre-resolved dependency tree to the repository. So maybe that
is the major issue we need to find a solution for first to get a
solution solving everything else automatically.

Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Hervé BOUTEMY <he...@free.fr>]

yes, people providing libraries have this big choice to do: when to upgrade 
minimum JRE version for consumers.

yes, we can add them another new big decision to take: when to upgrade minium 
Maven version to consume the library?

but with consumer pom vs build pom, we should be able to avoid this new 
decision: build pom can evolve (having a prerequisite to builkd the library is 
not an issue), consumer pom stays compatible


Now, I don't yet investigated the new include feature, with a simple example 
of the difference between include and import, and see if a build pom with 
include could be transformed into a consumer pom without it: is it feasible?

Regards,

Hervé

Le mardi 23 août 2016 17:39:28 Christian Schulte a écrit :
> Am 23.08.2016 um 15:53 schrieb Paul Benedict:
> > I advise to not introduce any new POM version in the 3.x series. Please do
> > that in Maven 4.0 where you can blue sky ideas and green field the
> > development. Let the 3.x series be the place to shakeout compatibility
> > concerns in gracefully handling the new POM version (like appropriate
> > warnings and errors). If you do this correctly, you should be able to be
> > forward compatible.
> 
> Maybe another example helps. Something everyone agreed upon decades ago.
> Java platform versioning. We have jars in central targetting a wide
> range of Java platforms. A mix of -target 1.2 to -target 1.8. Everyone
> knows what happens when trying to load a Java 7 class with a Java 6
> runtime environment. When incrementing the model version, we are just
> setting the target Maven version to 3.4+. There is really nothing
> uncommon about that. Just as you cannot load classes targetted at Java 7
> with a Java 6 JRE, you cannot load POMs targetted at 4.3+ with <4.3.
> That's all there is to it. We would need to do the same for Maven 4 as
> well. Call it target model version 4.1.0 or 5.0.0 or just something not
> 4.0.0 and you get Maven behaving exactly like a JRE behaves when asked
> to load a class targetted at a higher JRE (load a Java 7 class with a
> Java 6 runtime). We are not doing anything uncommon by incrementing the
> model version, in my opinion.
> 
> Regards,


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 23.08.2016 um 15:53 schrieb Paul Benedict:
> I advise to not introduce any new POM version in the 3.x series. Please do
> that in Maven 4.0 where you can blue sky ideas and green field the
> development. Let the 3.x series be the place to shakeout compatibility
> concerns in gracefully handling the new POM version (like appropriate
> warnings and errors). If you do this correctly, you should be able to be
> forward compatible.

Maybe another example helps. Something everyone agreed upon decades ago.
Java platform versioning. We have jars in central targetting a wide
range of Java platforms. A mix of -target 1.2 to -target 1.8. Everyone
knows what happens when trying to load a Java 7 class with a Java 6
runtime environment. When incrementing the model version, we are just
setting the target Maven version to 3.4+. There is really nothing
uncommon about that. Just as you cannot load classes targetted at Java 7
with a Java 6 JRE, you cannot load POMs targetted at 4.3+ with <4.3.
That's all there is to it. We would need to do the same for Maven 4 as
well. Call it target model version 4.1.0 or 5.0.0 or just something not
4.0.0 and you get Maven behaving exactly like a JRE behaves when asked
to load a class targetted at a higher JRE (load a Java 7 class with a
Java 6 runtime). We are not doing anything uncommon by incrementing the
model version, in my opinion.

Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Robert Scholte <rf...@apache.org>]

Hi Tibor,

There's no need to hurry to for Maven-4.0.0 just because of the  
modelVersion. Maven2 was already using it, we may assume that users  
already know about this.
I'd really prefer to stay on 3.x and go to 5.x once we've extended the  
model to version 5.0.0. (I don't mind skipping 4.x if that's the case)
Users may expect huge changes when going to the next major.
In case of the 3.0 it was most of all architectural, I wonder if most  
users noticed the changes. However, it still took a long long time to  
convince users to switch from 2.2.1 to 3.x

thanks,
Robert

On Sat, 27 Aug 2016 22:42:49 +0200, Tibor Digana <ti...@apache.org>  
wrote:

> I supposed to align Maven 4.x with model version 4.0, and then
> Maven 5.x with model version 5.0.
>
> I supposed to directly release Maven 4.0.0 instead of 3.4.0.
>
> Why we have to control model version and support it if the XSD
> schemaLocation is already defined:
> http://maven.apache.org/xsd/maven-4.0.0.xsd
> ?
>
> Is this double definition (xsd schema and modelVersion)?
>
> On 8/27/16, Paul Benedict [via Maven]
> <ml...@n5.nabble.com> wrote:
>>
>>
>> Christian, I argue this is a matter of perspective in regards to  
>> "solve".
>>
>> There are two things to solve:
>> 1) Introducing new functionality with POM 4.1/5.0
>> 2) Introducing acceptable responsiveness to the new POM by older tools
>>
>> Point #1 can be introduced in whatever version of Maven, that is true,  
>> but
>> it does have impact on Point #2. I've come to this conclusion based on  
>> some
>> of the push back seen in this thread. If I may emphasize what concerns  
>> me
>> most, it is the question of how older versions of Maven will be able to
>> cope with something it cannot understand? I believe the best way to
>> separate out these two concerns is to have separate lines of  
>> development --
>> Maven 4.0 for #1 and Maven 3.x for #2 -- so that the two don't constrict
>> and collide. The two concerns are admittedly related, but they don't  
>> need
>> to be developed together because they are distinct enough in their
>> behavior. I'd think you really want Maven 4.0 development to be as free  
>> as
>> possible in terms of building out new features, and then letting the 3.x
>> branch react to them in the wild. That's my formula for success which I
>> propose to the development team here. I don't think it makes any sense  
>> to
>> introduce such a grand feature in the 3.x line because it obscures the  
>> need
>> to devise acceptable responses for older tools.
>>
>> Pretending that Maven 3.4 (for sake of argument) started to gracefully
>> handle future POM versions, the problem yet remains for Maven versions
>> prior to 3.4. That's true. However, if agreement can be found in 3.4 for
>> how to gracefully handle, and if that design plan is documented well,  
>> such
>> concerns could be back-ported to even older versions, no? Clearly this
>> doesn't help people who refuse to upgrade, but my emphasis here is about
>> mitigation for those users who can tolerate a patch release. I'd rather
>> have a plan in place to help those who want to help themselves, than do
>> nothing at all.
>>
>> With that said, it is really up to how 3.4 (for sake of argument) should
>> gracefully handle the new POM versions. Many forks in the road here  
>> leading
>> to different design answers :-) However, I find that to be a secondary
>> concern, at this time. The first step is really deciding what I  
>> proposed:
>> introduce POM 4.1/50 in Maven 4.0 or 3.x? If the development team can
>> clearly answer that big picture strategy (and you know my opinion on  
>> that
>> matter), you can then begin to debate how best to be backward  
>> compatible.
>>
>> Cheers,
>> Paul
>>
>> On Tue, Aug 23, 2016 at 9:55 AM, Christian Schulte <cs...@schulte.it>  
>> wrote:
>>
>>> Am 23.08.2016 um 15:53 schrieb Paul Benedict:
>>> > I advise to not introduce any new POM version in the 3.x series.  
>>> Please
>>> do
>>> > that in Maven 4.0 where you can blue sky ideas and green field the
>>> > development.
>>>
>>> And how would we solve the issue at hand in Maven 4? We increase the
>>> model version in Maven 4 to 5.0.0 and then? We do not run into exactly
>>> the same issue we are currently trying to solve? Postponing to Maven 4
>>> is not solving anything, really.
>>>
>>> Regards,
>>> --
>>> Christian
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>>
>>
>>
>> _______________________________________________
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://maven.40175.n5.nabble.com/Re-POM-Model-version-4-1-0-in-3-4-0-SNAPSHOTs-tp5878254p5878775.html
>> To start a new topic under Maven Developers, email
>> ml-node+s40175n142166h86@n5.nabble.com
>> To unsubscribe from Maven Developers, visit
>> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Tibor Digana <ti...@apache.org>]

I supposed to align Maven 4.x with model version 4.0, and then
Maven 5.x with model version 5.0.

I supposed to directly release Maven 4.0.0 instead of 3.4.0.

Why we have to control model version and support it if the XSD
schemaLocation is already defined:
http://maven.apache.org/xsd/maven-4.0.0.xsd
?

Is this double definition (xsd schema and modelVersion)?

On 8/27/16, Paul Benedict [via Maven]
<ml...@n5.nabble.com> wrote:
>
>
> Christian, I argue this is a matter of perspective in regards to "solve".
>
> There are two things to solve:
> 1) Introducing new functionality with POM 4.1/5.0
> 2) Introducing acceptable responsiveness to the new POM by older tools
>
> Point #1 can be introduced in whatever version of Maven, that is true, but
> it does have impact on Point #2. I've come to this conclusion based on some
> of the push back seen in this thread. If I may emphasize what concerns me
> most, it is the question of how older versions of Maven will be able to
> cope with something it cannot understand? I believe the best way to
> separate out these two concerns is to have separate lines of development --
> Maven 4.0 for #1 and Maven 3.x for #2 -- so that the two don't constrict
> and collide. The two concerns are admittedly related, but they don't need
> to be developed together because they are distinct enough in their
> behavior. I'd think you really want Maven 4.0 development to be as free as
> possible in terms of building out new features, and then letting the 3.x
> branch react to them in the wild. That's my formula for success which I
> propose to the development team here. I don't think it makes any sense to
> introduce such a grand feature in the 3.x line because it obscures the need
> to devise acceptable responses for older tools.
>
> Pretending that Maven 3.4 (for sake of argument) started to gracefully
> handle future POM versions, the problem yet remains for Maven versions
> prior to 3.4. That's true. However, if agreement can be found in 3.4 for
> how to gracefully handle, and if that design plan is documented well, such
> concerns could be back-ported to even older versions, no? Clearly this
> doesn't help people who refuse to upgrade, but my emphasis here is about
> mitigation for those users who can tolerate a patch release. I'd rather
> have a plan in place to help those who want to help themselves, than do
> nothing at all.
>
> With that said, it is really up to how 3.4 (for sake of argument) should
> gracefully handle the new POM versions. Many forks in the road here leading
> to different design answers :-) However, I find that to be a secondary
> concern, at this time. The first step is really deciding what I proposed:
> introduce POM 4.1/50 in Maven 4.0 or 3.x? If the development team can
> clearly answer that big picture strategy (and you know my opinion on that
> matter), you can then begin to debate how best to be backward compatible.
>
> Cheers,
> Paul
>
> On Tue, Aug 23, 2016 at 9:55 AM, Christian Schulte <cs...@schulte.it> wrote:
>
>> Am 23.08.2016 um 15:53 schrieb Paul Benedict:
>> > I advise to not introduce any new POM version in the 3.x series. Please
>> do
>> > that in Maven 4.0 where you can blue sky ideas and green field the
>> > development.
>>
>> And how would we solve the issue at hand in Maven 4? We increase the
>> model version in Maven 4 to 5.0.0 and then? We do not run into exactly
>> the same issue we are currently trying to solve? Postponing to Maven 4
>> is not solving anything, really.
>>
>> Regards,
>> --
>> Christian
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
>
>
> _______________________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/Re-POM-Model-version-4-1-0-in-3-4-0-SNAPSHOTs-tp5878254p5878775.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166h86@n5.nabble.com
> To unsubscribe from Maven Developers, visit
> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==


-- 
Cheers
Tibor




--
View this message in context: http://maven.40175.n5.nabble.com/Re-POM-Model-version-4-1-0-in-3-4-0-SNAPSHOTs-tp5878254p5878816.html
Sent from the Maven Developers mailing list archive at Nabble.com.

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Paul Benedict <pb...@apache.org>]

Christian, I argue this is a matter of perspective in regards to "solve".

There are two things to solve:
1) Introducing new functionality with POM 4.1/5.0
2) Introducing acceptable responsiveness to the new POM by older tools

Point #1 can be introduced in whatever version of Maven, that is true, but
it does have impact on Point #2. I've come to this conclusion based on some
of the push back seen in this thread. If I may emphasize what concerns me
most, it is the question of how older versions of Maven will be able to
cope with something it cannot understand? I believe the best way to
separate out these two concerns is to have separate lines of development --
Maven 4.0 for #1 and Maven 3.x for #2 -- so that the two don't constrict
and collide. The two concerns are admittedly related, but they don't need
to be developed together because they are distinct enough in their
behavior. I'd think you really want Maven 4.0 development to be as free as
possible in terms of building out new features, and then letting the 3.x
branch react to them in the wild. That's my formula for success which I
propose to the development team here. I don't think it makes any sense to
introduce such a grand feature in the 3.x line because it obscures the need
to devise acceptable responses for older tools.

Pretending that Maven 3.4 (for sake of argument) started to gracefully
handle future POM versions, the problem yet remains for Maven versions
prior to 3.4. That's true. However, if agreement can be found in 3.4 for
how to gracefully handle, and if that design plan is documented well, such
concerns could be back-ported to even older versions, no? Clearly this
doesn't help people who refuse to upgrade, but my emphasis here is about
mitigation for those users who can tolerate a patch release. I'd rather
have a plan in place to help those who want to help themselves, than do
nothing at all.

With that said, it is really up to how 3.4 (for sake of argument) should
gracefully handle the new POM versions. Many forks in the road here leading
to different design answers :-) However, I find that to be a secondary
concern, at this time. The first step is really deciding what I proposed:
introduce POM 4.1/50 in Maven 4.0 or 3.x? If the development team can
clearly answer that big picture strategy (and you know my opinion on that
matter), you can then begin to debate how best to be backward compatible.

Cheers,
Paul

On Tue, Aug 23, 2016 at 9:55 AM, Christian Schulte <cs...@schulte.it> wrote:

> Am 23.08.2016 um 15:53 schrieb Paul Benedict:
> > I advise to not introduce any new POM version in the 3.x series. Please
> do
> > that in Maven 4.0 where you can blue sky ideas and green field the
> > development.
>
> And how would we solve the issue at hand in Maven 4? We increase the
> model version in Maven 4 to 5.0.0 and then? We do not run into exactly
> the same issue we are currently trying to solve? Postponing to Maven 4
> is not solving anything, really.
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 23.08.2016 um 15:53 schrieb Paul Benedict:
> I advise to not introduce any new POM version in the 3.x series. Please do
> that in Maven 4.0 where you can blue sky ideas and green field the
> development.

And how would we solve the issue at hand in Maven 4? We increase the
model version in Maven 4 to 5.0.0 and then? We do not run into exactly
the same issue we are currently trying to solve? Postponing to Maven 4
is not solving anything, really.

Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Paul Benedict <pb...@apache.org>]

I advise to not introduce any new POM version in the 3.x series. Please do
that in Maven 4.0 where you can blue sky ideas and green field the
development. Let the 3.x series be the place to shakeout compatibility
concerns in gracefully handling the new POM version (like appropriate
warnings and errors). If you do this correctly, you should be able to be
forward compatible.

Cheers,
Paul

On Tue, Aug 23, 2016 at 7:01 AM, Christian Schulte <cs...@schulte.it> wrote:

> Am 08/23/16 um 01:12 schrieb Stephen Connolly:
> > On Monday 22 August 2016, Christian Schulte <cs...@schulte.it> wrote:
> >> That won't scale. What is to note here is that the XML schema or
> >> anything syntax does not change between 4.0.0 and 4.1.0. It's just that
> >> Maven 3.4 performs the dependency management import differently when
> >> operating on a 4.1.0 POM instead of a 4.0.0 POM.
> >
> >
> > But what happens when maven [2.0-3.3.4) download that Pom?
> >
> > If the answer is "blow up" then I am -1
>
> Blow up. Correct. What else should it do? It cannot provide the same
> effective model 3.4+ does. So either it produces incorrect effective
> models leading to build failures later on or it just stops informing the
> user that a more recent maven version is needed. Same for the include
> scope. 3.4+ supports it. Older versions start producing incorrect
> effective models. The whole import scope feature has been introduced
> between Maven 2.0.8 and 2.0.9. No one complained about an older Maven
> version not supporting that scope. Situation today is different. I know.
> Even the IDE of my choice still bundles Maven 3.0.5. I am more in favour
> of adding that include scope right now. Projects using that scope take
> the "you need to build/consume this using 3.4+" burden. They will be the
> ones receiving huge amounts of build failure reports this way because
> older Maven versions simply do not process those dependency management
> includes which will make most of those projects blow up as well when not
> using 3.4+.
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 08/23/16 um 01:12 schrieb Stephen Connolly:
> On Monday 22 August 2016, Christian Schulte <cs...@schulte.it> wrote:
>> That won't scale. What is to note here is that the XML schema or
>> anything syntax does not change between 4.0.0 and 4.1.0. It's just that
>> Maven 3.4 performs the dependency management import differently when
>> operating on a 4.1.0 POM instead of a 4.0.0 POM.
> 
> 
> But what happens when maven [2.0-3.3.4) download that Pom?
> 
> If the answer is "blow up" then I am -1

Blow up. Correct. What else should it do? It cannot provide the same
effective model 3.4+ does. So either it produces incorrect effective
models leading to build failures later on or it just stops informing the
user that a more recent maven version is needed. Same for the include
scope. 3.4+ supports it. Older versions start producing incorrect
effective models. The whole import scope feature has been introduced
between Maven 2.0.8 and 2.0.9. No one complained about an older Maven
version not supporting that scope. Situation today is different. I know.
Even the IDE of my choice still bundles Maven 3.0.5. I am more in favour
of adding that include scope right now. Projects using that scope take
the "you need to build/consume this using 3.4+" burden. They will be the
ones receiving huge amounts of build failure reports this way because
older Maven versions simply do not process those dependency management
includes which will make most of those projects blow up as well when not
using 3.4+.

Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Stephen Connolly <st...@gmail.com>]

On Monday 22 August 2016, Karl Heinz Marbaise <kh...@gmx.de> wrote:

> Hi Stephen,
> On 23/08/16 01:12, Stephen Connolly wrote:
>
>> On Monday 22 August 2016, Christian Schulte <cs...@schulte.it> wrote:
>>
>> Am 08/22/16 um 09:08 schrieb Stephen Connolly:
>>>
>>>> This is why I said that the v5 pom (which v4.1 is... just under a
>>>>
>>> different
>>>
>>>> name) would have to be deployed separately with a *best effort*
>>>>
>>> translation
>>>
>>>> down to the 4.0.0 model deployed at the standard coordinates.
>>>>
>>>> The problem then becomes that we are deploying now two poms for
>>>>
>>> everything,
>>>
>>>> a 4.0.0 as .pom and a 4.1.0 as -v4.1.0.pom say (i.e. if the classifier
>>>> is
>>>> "v4.1.0")
>>>>
>>>> That in and of itself is not the end of the world... but then Maven 3.5
>>>> comes along and now every time we deploy a pom we will need to deploy a
>>>> 4.0.0 as foobar-1.0.pom, a 4.1.0 as foobar-1.0-v4.1.0.pom a 4.2.0 as
>>>> foobar-1.0-v4.2.0.pom...
>>>>
>>>> eventually we will end up deploying 20 or thirty poms at the same
>>>> time...
>>>> just to deploy the pom.
>>>>
>>>> So that will not scale.
>>>>
>>>
>>> That won't scale. What is to note here is that the XML schema or
>>> anything syntax does not change between 4.0.0 and 4.1.0. It's just that
>>> Maven 3.4 performs the dependency management import differently when
>>> operating on a 4.1.0 POM instead of a 4.0.0 POM.
>>>
>>
>>
>> But what happens when maven [2.0-3.3.4) download that Pom?
>>
>> If the answer is "blow up" then I am -1
>>
>
> I would really ignore Maven 2 cause it End Of Life since 2 Years ago now
> and I would also only care about Maven 3+


I'm fine if we all agree that we start from 3.0

But I'd rather the data point first.

Let's get the data point and decide from there.

I suspect that everything <= 3.3.4 will blow up if encountering a
modelVersion != 4.0.0

In which case your point about 2.x being EOL is moot

Let's get the data points, then we can make a decision


>
>
> Kind regards
> Karl Heinz
>
>
>>
>>
>>> So I am -1 on bumping a version number without an associated fix to
>>>> future-proof this.
>>>>
>>>
>>> We cannot postpone such things forever. Let's just find such a
>>> future-proof solution please. Those endless discussions have led to
>>> nowhere so far. That -1 means I need to revert the new import scope
>>> behaviour. I wouldn't mind doing that but I see the minor version
>>> increment in the model version by far not so problematic as others. I
>>> don't know what to do else when introducing new model building
>>> behaviour. I'am on that "let's just do it, it won't do any harm" road
>>> here. I better not be wrong with that, of course.
>>>
>>> I will, however, provide a *really bad solution* to this problem: XSLT
>>>>
>>>
>>> It's not that bad. It's XML only and would make things like polyglot
>>> Maven even harder but since the consumer POM is something technical -
>>> not edited manually - we could just keep it XML forever. There are XML
>>> parsers and XSLT processors available for nearly every programming
>>> language. So XML is what makes the most sense. What is not solved that
>>> way is the change in semantics because it could only be used to
>>> transform different syntaxes. The changes which made me bump the model
>>> version are not syntax related.
>>>
>>
>>
>>
>>> So then the XSLT would just change the modelVersion from 4.1.0 to 4.0.0
>>
>> Anyone using the newer artifact will have to manage their dependency graph
>> anyway so no loss there... But at least they can continue to consume the
>> newer artifacts and then upgrade maven when they are ready.
>>
>> If there is a security issue in a dependency, I need to upgrade the
>> artifact asap... Forcing me to upgrade maven with potentially far reaching
>> side effects elsewhere in the build is a bad thing... I can add the newer
>> dep, execlude all transitive a and manually pull in what I need... This is
>> currently what I have to do anyway if I am facing the issues driving the
>> change in import scope AIUI... So no loss
>>
>>
>>
>> In fact, if you diff a pom-4.0.0.xml and
>>> a pom-4.1.0.xml the only difference would be the value of the model
>>> version element. Maven would build the effective model differently based
>>> on that value. You would not need to deploy two poms for this. So to
>>> summarize, we need to find a solution for handling different syntaxes
>>> and a solution to handle different semantics for the same syntax.
>>>
>>
>>
>>
>>> It's drop to the floor or propagate the bug and let the consumer fix in
>> their Pom.
>>
>> The critical thing is that I can actually depend on the artifact using the
>> newer modelVersion
>>
>>
>> If we
>>> are going to bump model versions, it must be clear to everyone what
>>> increment means what. Same syntax, different semantics: minor version
>>> increment. Different syntax, same semantics: major version increment.
>>> Leaves the patch version for bug fixes (like changing the order of
>>> elements for the combine.children attribute). Quite XML related. So we
>>> better not think about the model in terms of XML. What we currently have
>>> on master (4.1.0) would just work. I am not sure this model version
>>> increment without any change in syntax is really such an issue, however.
>>>
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

-- 
Sent from my phone

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Karl Heinz Marbaise <kh...@gmx.de>]

Hi Stephen,
On 23/08/16 01:12, Stephen Connolly wrote:
> On Monday 22 August 2016, Christian Schulte <cs...@schulte.it> wrote:
>
>> Am 08/22/16 um 09:08 schrieb Stephen Connolly:
>>> This is why I said that the v5 pom (which v4.1 is... just under a
>> different
>>> name) would have to be deployed separately with a *best effort*
>> translation
>>> down to the 4.0.0 model deployed at the standard coordinates.
>>>
>>> The problem then becomes that we are deploying now two poms for
>> everything,
>>> a 4.0.0 as .pom and a 4.1.0 as -v4.1.0.pom say (i.e. if the classifier is
>>> "v4.1.0")
>>>
>>> That in and of itself is not the end of the world... but then Maven 3.5
>>> comes along and now every time we deploy a pom we will need to deploy a
>>> 4.0.0 as foobar-1.0.pom, a 4.1.0 as foobar-1.0-v4.1.0.pom a 4.2.0 as
>>> foobar-1.0-v4.2.0.pom...
>>>
>>> eventually we will end up deploying 20 or thirty poms at the same time...
>>> just to deploy the pom.
>>>
>>> So that will not scale.
>>
>> That won't scale. What is to note here is that the XML schema or
>> anything syntax does not change between 4.0.0 and 4.1.0. It's just that
>> Maven 3.4 performs the dependency management import differently when
>> operating on a 4.1.0 POM instead of a 4.0.0 POM.
>
>
> But what happens when maven [2.0-3.3.4) download that Pom?
>
> If the answer is "blow up" then I am -1

I would really ignore Maven 2 cause it End Of Life since 2 Years ago now 
and I would also only care about Maven 3+


Kind regards
Karl Heinz

>
>
>>
>>> So I am -1 on bumping a version number without an associated fix to
>>> future-proof this.
>>
>> We cannot postpone such things forever. Let's just find such a
>> future-proof solution please. Those endless discussions have led to
>> nowhere so far. That -1 means I need to revert the new import scope
>> behaviour. I wouldn't mind doing that but I see the minor version
>> increment in the model version by far not so problematic as others. I
>> don't know what to do else when introducing new model building
>> behaviour. I'am on that "let's just do it, it won't do any harm" road
>> here. I better not be wrong with that, of course.
>>
>>> I will, however, provide a *really bad solution* to this problem: XSLT
>>
>> It's not that bad. It's XML only and would make things like polyglot
>> Maven even harder but since the consumer POM is something technical -
>> not edited manually - we could just keep it XML forever. There are XML
>> parsers and XSLT processors available for nearly every programming
>> language. So XML is what makes the most sense. What is not solved that
>> way is the change in semantics because it could only be used to
>> transform different syntaxes. The changes which made me bump the model
>> version are not syntax related.
>
>
>>
> So then the XSLT would just change the modelVersion from 4.1.0 to 4.0.0
>
> Anyone using the newer artifact will have to manage their dependency graph
> anyway so no loss there... But at least they can continue to consume the
> newer artifacts and then upgrade maven when they are ready.
>
> If there is a security issue in a dependency, I need to upgrade the
> artifact asap... Forcing me to upgrade maven with potentially far reaching
> side effects elsewhere in the build is a bad thing... I can add the newer
> dep, execlude all transitive a and manually pull in what I need... This is
> currently what I have to do anyway if I am facing the issues driving the
> change in import scope AIUI... So no loss
>
>
>
>> In fact, if you diff a pom-4.0.0.xml and
>> a pom-4.1.0.xml the only difference would be the value of the model
>> version element. Maven would build the effective model differently based
>> on that value. You would not need to deploy two poms for this. So to
>> summarize, we need to find a solution for handling different syntaxes
>> and a solution to handle different semantics for the same syntax.
>
>
>>
> It's drop to the floor or propagate the bug and let the consumer fix in
> their Pom.
>
> The critical thing is that I can actually depend on the artifact using the
> newer modelVersion
>
>
>> If we
>> are going to bump model versions, it must be clear to everyone what
>> increment means what. Same syntax, different semantics: minor version
>> increment. Different syntax, same semantics: major version increment.
>> Leaves the patch version for bug fixes (like changing the order of
>> elements for the combine.children attribute). Quite XML related. So we
>> better not think about the model in terms of XML. What we currently have
>> on master (4.1.0) would just work. I am not sure this model version
>> increment without any change in syntax is really such an issue, however.
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Stephen Connolly <st...@gmail.com>]

On Monday 22 August 2016, Christian Schulte <cs...@schulte.it> wrote:

> Am 08/22/16 um 09:08 schrieb Stephen Connolly:
> > This is why I said that the v5 pom (which v4.1 is... just under a
> different
> > name) would have to be deployed separately with a *best effort*
> translation
> > down to the 4.0.0 model deployed at the standard coordinates.
> >
> > The problem then becomes that we are deploying now two poms for
> everything,
> > a 4.0.0 as .pom and a 4.1.0 as -v4.1.0.pom say (i.e. if the classifier is
> > "v4.1.0")
> >
> > That in and of itself is not the end of the world... but then Maven 3.5
> > comes along and now every time we deploy a pom we will need to deploy a
> > 4.0.0 as foobar-1.0.pom, a 4.1.0 as foobar-1.0-v4.1.0.pom a 4.2.0 as
> > foobar-1.0-v4.2.0.pom...
> >
> > eventually we will end up deploying 20 or thirty poms at the same time...
> > just to deploy the pom.
> >
> > So that will not scale.
>
> That won't scale. What is to note here is that the XML schema or
> anything syntax does not change between 4.0.0 and 4.1.0. It's just that
> Maven 3.4 performs the dependency management import differently when
> operating on a 4.1.0 POM instead of a 4.0.0 POM.


But what happens when maven [2.0-3.3.4) download that Pom?

If the answer is "blow up" then I am -1


>
> > So I am -1 on bumping a version number without an associated fix to
> > future-proof this.
>
> We cannot postpone such things forever. Let's just find such a
> future-proof solution please. Those endless discussions have led to
> nowhere so far. That -1 means I need to revert the new import scope
> behaviour. I wouldn't mind doing that but I see the minor version
> increment in the model version by far not so problematic as others. I
> don't know what to do else when introducing new model building
> behaviour. I'am on that "let's just do it, it won't do any harm" road
> here. I better not be wrong with that, of course.
>
> > I will, however, provide a *really bad solution* to this problem: XSLT
>
> It's not that bad. It's XML only and would make things like polyglot
> Maven even harder but since the consumer POM is something technical -
> not edited manually - we could just keep it XML forever. There are XML
> parsers and XSLT processors available for nearly every programming
> language. So XML is what makes the most sense. What is not solved that
> way is the change in semantics because it could only be used to
> transform different syntaxes. The changes which made me bump the model
> version are not syntax related.


>
So then the XSLT would just change the modelVersion from 4.1.0 to 4.0.0

Anyone using the newer artifact will have to manage their dependency graph
anyway so no loss there... But at least they can continue to consume the
newer artifacts and then upgrade maven when they are ready.

If there is a security issue in a dependency, I need to upgrade the
artifact asap... Forcing me to upgrade maven with potentially far reaching
side effects elsewhere in the build is a bad thing... I can add the newer
dep, execlude all transitive a and manually pull in what I need... This is
currently what I have to do anyway if I am facing the issues driving the
change in import scope AIUI... So no loss



> In fact, if you diff a pom-4.0.0.xml and
> a pom-4.1.0.xml the only difference would be the value of the model
> version element. Maven would build the effective model differently based
> on that value. You would not need to deploy two poms for this. So to
> summarize, we need to find a solution for handling different syntaxes
> and a solution to handle different semantics for the same syntax.


>
It's drop to the floor or propagate the bug and let the consumer fix in
their Pom.

The critical thing is that I can actually depend on the artifact using the
newer modelVersion


> If we
> are going to bump model versions, it must be clear to everyone what
> increment means what. Same syntax, different semantics: minor version
> increment. Different syntax, same semantics: major version increment.
> Leaves the patch version for bug fixes (like changing the order of
> elements for the combine.children attribute). Quite XML related. So we
> better not think about the model in terms of XML. What we currently have
> on master (4.1.0) would just work. I am not sure this model version
> increment without any change in syntax is really such an issue, however.
>
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>

-- 
Sent from my phone

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Christian Schulte <cs...@schulte.it>]

Am 08/22/16 um 09:08 schrieb Stephen Connolly:
> This is why I said that the v5 pom (which v4.1 is... just under a different
> name) would have to be deployed separately with a *best effort* translation
> down to the 4.0.0 model deployed at the standard coordinates.
> 
> The problem then becomes that we are deploying now two poms for everything,
> a 4.0.0 as .pom and a 4.1.0 as -v4.1.0.pom say (i.e. if the classifier is
> "v4.1.0")
> 
> That in and of itself is not the end of the world... but then Maven 3.5
> comes along and now every time we deploy a pom we will need to deploy a
> 4.0.0 as foobar-1.0.pom, a 4.1.0 as foobar-1.0-v4.1.0.pom a 4.2.0 as
> foobar-1.0-v4.2.0.pom...
> 
> eventually we will end up deploying 20 or thirty poms at the same time...
> just to deploy the pom.
> 
> So that will not scale.

That won't scale. What is to note here is that the XML schema or
anything syntax does not change between 4.0.0 and 4.1.0. It's just that
Maven 3.4 performs the dependency management import differently when
operating on a 4.1.0 POM instead of a 4.0.0 POM.

> So I am -1 on bumping a version number without an associated fix to
> future-proof this.

We cannot postpone such things forever. Let's just find such a
future-proof solution please. Those endless discussions have led to
nowhere so far. That -1 means I need to revert the new import scope
behaviour. I wouldn't mind doing that but I see the minor version
increment in the model version by far not so problematic as others. I
don't know what to do else when introducing new model building
behaviour. I'am on that "let's just do it, it won't do any harm" road
here. I better not be wrong with that, of course.

> I will, however, provide a *really bad solution* to this problem: XSLT

It's not that bad. It's XML only and would make things like polyglot
Maven even harder but since the consumer POM is something technical -
not edited manually - we could just keep it XML forever. There are XML
parsers and XSLT processors available for nearly every programming
language. So XML is what makes the most sense. What is not solved that
way is the change in semantics because it could only be used to
transform different syntaxes. The changes which made me bump the model
version are not syntax related. In fact, if you diff a pom-4.0.0.xml and
a pom-4.1.0.xml the only difference would be the value of the model
version element. Maven would build the effective model differently based
on that value. You would not need to deploy two poms for this. So to
summarize, we need to find a solution for handling different syntaxes
and a solution to handle different semantics for the same syntax. If we
are going to bump model versions, it must be clear to everyone what
increment means what. Same syntax, different semantics: minor version
increment. Different syntax, same semantics: major version increment.
Leaves the patch version for bug fixes (like changing the order of
elements for the combine.children attribute). Quite XML related. So we
better not think about the model in terms of XML. What we currently have
on master (4.1.0) would just work. I am not sure this model version
increment without any change in syntax is really such an issue, however.


Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Stephen Connolly <st...@gmail.com>]

This is why I said that the v5 pom (which v4.1 is... just under a different
name) would have to be deployed separately with a *best effort* translation
down to the 4.0.0 model deployed at the standard coordinates.

The problem then becomes that we are deploying now two poms for everything,
a 4.0.0 as .pom and a 4.1.0 as -v4.1.0.pom say (i.e. if the classifier is
"v4.1.0")

That in and of itself is not the end of the world... but then Maven 3.5
comes along and now every time we deploy a pom we will need to deploy a
4.0.0 as foobar-1.0.pom, a 4.1.0 as foobar-1.0-v4.1.0.pom a 4.2.0 as
foobar-1.0-v4.2.0.pom...

eventually we will end up deploying 20 or thirty poms at the same time...
just to deploy the pom.

So that will not scale.

So I am -1 on bumping a version number without an associated fix to
future-proof this.

I will, however, provide a *really bad solution* to this problem: XSLT

We can switch to deploying only two poms (at least for the next 5-10 years
say... until we have metrics showing that most consumers are modern enough)

We deploy - at known maven coordinates - an XSLT stylesheet that maps each
modelVersion to another modelVersion.

Now any Maven 3.4.0+ client that gets a modelVersion newer than it can
parse will just pull down the XSLT to transform the pom into the desired
modelVersion and parse that. It needs to be XSLT so that the transformation
can be used by non-JVM parsers of the pom format.

The "consumer" pom will not be generated by Humans... so XML is actually a
perfectly cromulent format for it... and hence XSLT is the obvious choice
to convert from newer modelVersions into older modelVersions.

Each Maven Version would already come with the *best in class* translation
models for older versions so that you would only need to download newer
ones if encountered.

The builder pom would be free to evolve into whatever format we choose...
can even switch to a non-xml DSL if that helps.

That is my *really bad solution*. I really hope somebody can come up with a
better solution to this problem as I hate this one, but it is the best I
have yet.

Critical requirements:

* Must not assume that the program parsing the pom is running on the JVM (I
have seen people parsing POMs with Ruby and JavaScript and even one or two
using Erlang). Now while you can run all of these on the JVM, you do not
need to, so we cannot assume that these tools are running on a JVM. This
immediately rejects any solution that involves downloading a .jar file that
will transform one version into another.

* Must be best effort forward compatible. Where a feature can be mapped to
the older model version, it should be mapped. Where a feature cannot be
mapped it is OK to drop it on the floor.

* We can assume the base functionality for anyone using the XSLT
transformation as being the first modelVersion *after* 4.0.0... because we
will be deploying the 4.0.0 poms anyway so only clients that understand the
first new modelVersion will be following the XSLT transformation route.

Thus the modelVersion after 4.0.0 is our one chance to get the base model
as close to perfect as we can make it... any fix-up later on will need to
happen by XSLT. So on that basis I think that shooting for a 4.1.0 is
actually the wrong thing. We should shoot for a 5.0.0 and be done with it.

The blocker from jumping to 5.0.0 has been deciding on how to handle
forward compatibility to ensure that we only deploy 2 poms.

If we get the 5.0.0 model right, we can even have an XSLT to down map that
to 4.0.0 and detect a repository manager from HTML headers on the initial
deployment and skip deploying the 4.0.0 pom. The repo managers can even use
the XSLT to generate the 4.0.0 pom on the fly and then we are in a happy
place where we only ever deploy and store one pom (though central will need
to store both as it is not an active service due to scaling requirements)

-Stephen


On 21 August 2016 at 11:19, Karl Heinz Marbaise <kh...@gmx.de> wrote:

> Hi,
>
> first changing the discussion to the dev list:
>
> On 21/08/16 14:36, Robert Scholte wrote:
>
>> Hi,
>>
>> Keep in mind that Maven is not the only tool/application using the
>> pom.xml.
>> Some of them probably never check the xsd or the modelVersion, so we
>> need to be very carefull with this.
>> If we introduce a new major modelVersion, that should probably result in
>> a new file including a backported to the current 4.0.0 so all tools will
>> keep working, including older versions of Maven.
>> In this case 4.1.0 doesn't change the xsd but the handling of
>> dependencies. I have no idea yet about the impact of such change. The
>> last thing we want is that it'll destroy the Maven repository eco system.
>>
>
> The last sentence is very important...
>
> So using a new POM Model version (4.1.0) and now I will deploy it to Maven
> Central. This means that only Maven 3.4+ can read and handle that. Older
> Maven versions will simply fail with this new version.
>
> Furthermore If I would like to use Model version 4.1.0 now in my project I
> can't change it alone. I can not change only my project (a multi module
> build) and inherit from another POM's (corporate pom) with version 4.0.0.
> This will force me to change the whole inheritance hierachie chain to use
> Model version 4.1.0...and forces me to create a new hierachie of corporate
> pom's which are using Model Version 4.1.0 and in consequence I have to
> duplicate informations/work and maintanence which I will never do
> (independent of the advantages it might have)..neither other people in
> particular in companies will do so...(I have strong doubts about that).
>
> I'm not sure about the suggestion of Christian using
> release:prepare-with-pom will that not result in a situation like this:
> Using the Model version 4.1.0 to handle some issue correct but deploying a
> pom with Model version 4.0.0 which can't handle that? All consumers would
> consume the model version 4.0.0 pom and fail in some situations ?
>
>
> I've got a very strong impression this will not work at all...and in the
> end and the longer I'm thinking about this change:
>
> -1 about this Change.
>
> We need to find a better way for those things...May be this is exactly a
> sitution to control the behaviour via a feature flag to change this. So
> anybody can decide to use the new (correct) behaviour or keep the old
> behaviour...(which could be defined as the default).
>
> As a first step we could emit warnings about those wrong pom's and give
> the user the hint that he could change that by using feature flag or better
> to fix the wrong pom files...
>
>
> Changing the pom format in general can only being done in the Future with
> Maven 4.X may be can start working on PoC's or working on Maven 4.X  to see
> how this works..and see what does not work...or may be we are getting a
> better impression what kind of path we could go for in particular for the
> compatibility path...
>
>
> Introducing an new `include` scope might be solution which might be
> discusses more in detail...
>
>
> Kind regards
> Karl Heinz
>
>
>
>> Hervé and I plan to work on the consumer-pom, but that requires a good
>> roadmap.
>> First of all we need to separate the build-pom with the
>> distribution-pom. They are now exactly the same, but this needs to be
>> separated to be able to move forward.
>>
>
> > On the the things we can finally
>
>> fix is the absence of the version in the parent in case of a multimodule
>> project.
>>
> > So the build-pom you don't have to define the version, only the
>
>> relativePath unless the default value is already okay. The
>> distribution-pom can replace relativePath with the actual version.
>>
>> Next we need to think of the consumer-pom. The idea of this file is that
>> it contains only relevant transitive information. The original idea was
>> about a new format for speed and and having a list of all resolved
>> dependencies. This way Maven doesn't have to go to a repository for
>> every artifact, since this file already has all the required
>> information.
>>
> >
>  Based on some suggested changed in Aether it seems that
>
>> distance still matters, so maybe the dependencies should keep its tree
>> structure within this consumer-pom.
>> Another advantage of this is that the file already contains the fully
>> resolved tree, so you don't depend on the implementation of any tool
>> anymore regarding resolution rules.
>>
>
>
>
>> What is important it that we must keep a pom in the repository
>> understandable for all other tools. If somehow the Maven repository
>> becomes useless by introducing changes to the current pom we shouldn't
>> do that, but think of a new file-format being extra installed/deployed.
>>
>
>
> Robert
>>
>>
>> On Sun, 21 Aug 2016 02:16:34 +0200, Christian Schulte <cs...@schulte.it>
>> wrote:
>>
>> Am 08/21/16 um 00:30 schrieb Mark Derricutt:
>>>
>>>> Christian, is there anywhere describing what changes there are/or
>>>> planned
>>>> in Model version 4.1.0 at all?
>>>>
>>>
>>> Nothing is documented yet. There have never been any plans. It's more
>>> about having to revert a bunch of useful things to stay backwards
>>> compatible or increase the model version and be able to ship without
>>> breaking backwards compatibility. Plan is to keep all information about
>>> different model versions in one central place. That currently is the
>>> following class.
>>>
>>> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;
>>> f=maven-model-builder/src/main/java/org/apache/maven/
>>> model/versioning/ModelVersions.java;h=6b527ca8666c279f550477
>>> 02b3987f37b032bbe3;hb=HEAD>
>>>
>>>
>>> If you search for the usages of the 'supportsXyz' methods, you can
>>> easily spot the differences without the need for documentation today.
>>> Not much. I think there are quite some things that have been discussed
>>> for years that should really go into 3.4 based on model version 4.1.0
>>> now. Personally I see no reason not to progress by incrementing the
>>> model version.
>>>
>>> Maven also is about developers producing software for developers working
>>> together with developers and only developers. That should really show
>>> how easy things can progress and how productive things can be and not
>>> the opposite. We should all focus more on this, in my opinion.
>>>
>>
>
>