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

[CANCELED] [VOTE] Release Apache Maven WAR Plugin version 3.0.0

Hi, based on different request I cancel the VOTE... Kind regards Karl Heinz Marbaise On 22/08/16 22:01, Karl Heinz Marbaise wrote: Hi, We solved 32 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318121=12331760 There are still a couple of issues left in JIRA:

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: Maven war plugin 3.x: can it finally include MWAR-262?

Le 23 août 2016 22:08, "Karl Heinz Marbaise" a écrit : > > Hi Romains, > > > On 23/08/16 09:56, Romain Manni-Bucau wrote: >> >> Hi guys, >> >> just saw m-w-p 3.0.0 vote was on the list without >> https://issues.apache.org/jira/browse/MWAR-262 > > > Yes... > > >> >> When I asked

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: [VOTE] Release Apache Maven WAR Plugin version 3.0.0

Le 23 août 2016 22:10, "Karl Heinz Marbaise" a écrit : > > Hi Romain, > > > On 23/08/16 10:22, Romain Manni-Bucau wrote: >> >> +1, created another thread about this one (title: "Maven war plugin 3.x: >> can it finally include MWAR-262?", but not yet moderated I think). > > >

Re: [VOTE] Release Apache Maven WAR Plugin version 3.0.0

Hi Romain, On 23/08/16 10:22, Romain Manni-Bucau wrote: +1, created another thread about this one (title: "Maven war plugin 3.x: can it finally include MWAR-262?", but not yet moderated I think). The DEV list is only moderated in that way for first time posters... not every post... Kind

Re: Maven war plugin 3.x: can it finally include MWAR-262?

Hi Romains, On 23/08/16 09:56, Romain Manni-Bucau wrote: Hi guys, just saw m-w-p 3.0.0 vote was on the list without https://issues.apache.org/jira/browse/MWAR-262 Yes... When I asked about that some months ago the feedback was "not for a minor" but for 3.0.0 I don't see why it couldn't

Re: Building Maven from scratch

Hi Björn, On 23/08/16 08:25, Björn Höfling wrote: I want to build maven without haven _ANY_ maven/plugin binary. How can I do that? First you can do that only till Maven 3.3.9 starting with Maven 3.4.0 you need Maven 3.3.9 to build Maven 3.4.0...Details [1]. The question is why do you want

[GitHub] maven-surefire issue #110: SUREFIRE-1216: TEST-*.xml files generated by Sure...

Github user justinharringa commented on the issue: https://github.com/apache/maven-surefire/pull/110 Cool. Thanks for the update @Tibor17! :) --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have

Re: [VOTE] Release Apache Maven WAR Plugin version 3.0.0

+1: here is mine; tested in my project @ MVN 3.2.1 Java 1.8 +1: to MWAR-262 in 3.0.0. Yes it toggles behavior of the config parameter thus it's a chance to have it in 3.0. Agree that setting failOnMissingWebXml or permanently creating web.xml must be really annoying. On Mon, Aug 22, 2016 at 10:01

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

[GitHub] maven-surefire pull request #113: SUREFIRE-1250: add exceptions to describe ...

Github user kgyrtkirk closed the pull request at: https://github.com/apache/maven-surefire/pull/113 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the

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: [VOTE] Release Apache Maven WAR Plugin version 3.0.0

Personally I think a change of default value should go in into 3.0.0 rather than 3.0.1. We have a great oportunity here with v3.0.0 to fix these types of changes. /Anders On Tue, Aug 23, 2016 at 10:22 AM, Romain Manni-Bucau wrote: > +1, created another thread about this

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: obtain java spec version from Forked VM

All other cases check the Java runtime instead the forked instance, that's much easier. The -Xpatch is only interesting if target/classes/module-info.class exists. So I'd go for that strategy. In fact, that's what the maven-compiler-plugin will do too to decide if it should use classpath or

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

obtain java spec version from Forked VM

I want to obtain java.specification.version from forked JVM started from Toolchain. I need to know if the JDK is Jigsaw 9 or lower. Robert gave me advise to run "java -version" and parse the string but the problem is that it is VM version and not the specification version of Java language, and

obtain java spec version from Forked VM

I want to obtain java.specification.version from forked JVM started from Toolchain. I need to know if the JDK is Jigsaw 9 or lower. Robert gave me advise to run "java -version" and parse the string but the problem is that it is VM version and not the specification version of Java language, and

[GitHub] maven-surefire pull request #81: Create better report for AssumptionFailure

Github user jimma closed the pull request at: https://github.com/apache/maven-surefire/pull/81 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature

[GitHub] maven-surefire issue #81: Create better report for AssumptionFailure

Github user jimma commented on the issue: https://github.com/apache/maven-surefire/pull/81 @Tibor17 Thank you. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and

[GitHub] maven-surefire issue #81: Create better report for AssumptionFailure

Github user Tibor17 commented on the issue: https://github.com/apache/maven-surefire/pull/81 @jimma Thank you for contributing! The pull request was merged with master branch. You can close PR. --- If your project is set up for it, you can reply to this email and have your reply

[GitHub] maven-surefire issue #81: Create better report for AssumptionFailure

Github user Tibor17 commented on the issue: https://github.com/apache/maven-surefire/pull/81 @jimma yes, it's very good work. Thx. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this

Re: [VOTE] Release Apache Maven WAR Plugin version 3.0.0

+1, created another thread about this one (title: "Maven war plugin 3.x: can it finally include MWAR-262?", but not yet moderated I think). Not seeing an issue to do it in 3.0.1 and not prevent 3.0.0 but it is quite important to do it since the default is needed since > 16 years and it is very

[GitHub] maven-surefire issue #81: Create better report for AssumptionFailure

Github user jimma commented on the issue: https://github.com/apache/maven-surefire/pull/81 @Tibor17 Test is added. Is it surefire-integration-tests a good place to add ? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well.

Re: [VOTE] Release Apache Maven WAR Plugin version 3.0.0

Sorry to be a party pooper but is there any way we could include MWAR-262 still? Thanks, S. On Mon, Aug 22, 2016 at 10:01 PM, Karl Heinz Marbaise wrote: > Hi, > > We solved 32 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje > ctId=12318121=12331760 > >

Maven war plugin 3.x: can it finally include MWAR-262?

Hi guys, just saw m-w-p 3.0.0 vote was on the list without https://issues.apache.org/jira/browse/MWAR-262 When I asked about that some months ago the feedback was "not for a minor" but for 3.0.0 I don't see why it couldn't have been done. Here is how I see it: - changing it now will not break

[GitHub] maven-surefire pull request #81: Create better report for AssumptionFailure

GitHub user jimma reopened a pull request: https://github.com/apache/maven-surefire/pull/81 Create better report for AssumptionFailure You can merge this pull request into a Git repository by running: $ git pull https://github.com/jimma/maven-surefire master Alternatively

[GitHub] maven-surefire pull request #115: [SUREFIRE-1272]:Create better report for A...

Github user jimma closed the pull request at: https://github.com/apache/maven-surefire/pull/115 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature

Re: [VOTE] Release Apache Maven WAR Plugin version 3.0.0

+1 non-binding /Anders On Mon, Aug 22, 2016 at 10:01 PM, Karl Heinz Marbaise wrote: > Hi, > > We solved 32 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje > ctId=12318121=12331760 > > There are still a couple of issues left in JIRA: >

[GitHub] maven-surefire pull request #115: [SUREFIRE-1272]:Create better report for A...

GitHub user jimma opened a pull request: https://github.com/apache/maven-surefire/pull/115 [SUREFIRE-1272]:Create better report for AssumptionFailure You can merge this pull request into a Git repository by running: $ git pull https://github.com/jimma/maven-surefire master

[GitHub] maven-surefire pull request #81: Create better report for AssumptionFailure

Github user jimma closed the pull request at: https://github.com/apache/maven-surefire/pull/81 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature

Re: Building Maven from scratch

I doubt this is possible. We used to support building Maven core with Ant, but IIRC a fairly recent discussion resulted in a decision to stop supporting that. So you need Maven installed to build Maven core. More info here: http://maven.apache.org/guides/development/guide-building-maven.html

Re: Building Maven from scratch

Out of curiosity, what is your usecase? -- Regards, Igor On Tue, Aug 23, 2016, at 02:25 AM, Björn Höfling wrote: > I want to build maven without haven _ANY_ maven/plugin binary. How can > I do that? > > I found out that there is a build.xml and it start building a first > version of Maven.

Building Maven from scratch

I want to build maven without haven _ANY_ maven/plugin binary. How can I do that? I found out that there is a build.xml and it start building a first version of Maven. But then it needs plugins to go further. I found the plugins source here: https://maven.apache.org/plugins/ But these have only