Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Friday 2 September 2016, Robert Scholte wrote: > On Wed, 31 Aug 2016 22:51:20 +0200, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > On Wednesday 31 August 2016, Robert Scholte wrote: >> >> On Wed, 31 Aug 2016 19:35:02 +0200,

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Wed, 31 Aug 2016 22:51:20 +0200, Stephen Connolly wrote: On Wednesday 31 August 2016, Robert Scholte wrote: On Wed, 31 Aug 2016 19:35:02 +0200, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: On Wednesday 31 August

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Thursday 1 September 2016, Christian Schulte 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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Wednesday 31 August 2016, Robert Scholte wrote: > On Wed, 31 Aug 2016 19:35:02 +0200, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > On Wednesday 31 August 2016, Christian Schulte wrote: >> >> Am 08/31/16 um 18:39 schrieb Christian

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Wed, 31 Aug 2016 19:35:02 +0200, Stephen Connolly wrote: On Wednesday 31 August 2016, Christian Schulte 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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

Am 08/31/16 um 19:35 schrieb Stephen Connolly: > On Wednesday 31 August 2016, Christian Schulte wrote: >> >> >> public interface DependencyTreeProvider >> { >> >> DependencyNode getDependencyTree( String logicalScopeName ) >> throws IOException; >> >> } > > > Not `String

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Wednesday 31 August 2016, Christian Schulte 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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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: > > *

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Wed, 31 Aug 2016 07:52:20 +0200, Stephen Connolly 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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On 29 August 2016 at 23:27, Christian Schulte 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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

Yes, presumably to be consumed in another build, right? :-) On Tue, Aug 30, 2016 at 10:45 AM, Christian Schulte 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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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.

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Mon, Aug 29, 2016 at 4:07 PM, Robert Scholte 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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Mon, 29 Aug 2016 21:29:36 +0200, Tibor Digana 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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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 -

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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,

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

+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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

@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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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 of your project POM, then the plugin would

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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:

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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 wrote:

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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,

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Thu, 25 Aug 2016 18:30:50 +0200, Stephen Connolly wrote: On Thursday 25 August 2016, Robert Scholte wrote: On Thu, 25 Aug 2016 01:10:36 +0200, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: On 24 August 2016 at 04:50,

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Thursday 25 August 2016, Robert Scholte wrote: > On Thu, 25 Aug 2016 01:10:36 +0200, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > On 24 August 2016 at 04:50, Robert Scholte wrote: >> >> I realized last ApacheCon that I wasn't

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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 wrote: > On Thu,

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Thu, 25 Aug 2016 01:10:36 +0200, Stephen Connolly wrote: On 24 August 2016 at 04:50, Robert Scholte 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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Thu, 25 Aug 2016 08:00:14 +0200, Hervé BOUTEMY 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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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.

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On 24 August 2016 at 04:50, Robert Scholte 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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Wed, Aug 24, 2016 at 11:08 AM, Martijn Dashorst < martijn.dasho...@gmail.com> wrote: > On Wed, Aug 24, 2016 at 8:41 AM, Fred Cooke 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:

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Wed, Aug 24, 2016 at 8:41 AM, Fred Cooke 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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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).

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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" > > *)

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Tuesday 23 August 2016, Paul Benedict wrote: > On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte > 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 > >

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte 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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

If to "blow up" is unacceptable, then what is the documented way for a Maven client to deal with a 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.

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

Am 08/23/16 um 01:12 schrieb Stephen Connolly: > On Monday 22 August 2016, Christian Schulte 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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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,

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

Am 08/23/16 um 01:12 schrieb Stephen Connolly: > On Monday 22 August 2016, Christian Schulte 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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Monday 22 August 2016, Karl Heinz Marbaise wrote: > Hi Stephen, > On 23/08/16 01:12, Stephen Connolly wrote: > >> On Monday 22 August 2016, Christian Schulte wrote: >> >> Am 08/22/16 um 09:08 schrieb Stephen Connolly: >>> This is why I said that the

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

Hi Stephen, On 23/08/16 01:12, Stephen Connolly wrote: On Monday 22 August 2016, Christian Schulte 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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Monday 22 August 2016, Christian Schulte 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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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