Re: [MNG-5761] Dependency management is not transitive.

Am 11/17/16 um 06:00 schrieb Igor Fedorenko: > FWIW, I ran maven integration tests (commit 73a2b7) against current ^^ Running this commit against 3.4.0-SNAPSHOT now locally. I expect some ITs to fail. There have been updates to a few tests adding

Re: [MNG-5761] Dependency management is not transitive.

Am 11/17/16 um 06:00 schrieb Igor Fedorenko: > FWIW, I ran maven integration tests (commit 73a2b7) against current > maven master and got this > >> Tests run: 771, Failures: 3, Errors: 21, Skipped: 0 > > Running the same test checkout with Maven 3.3.9 > >> Tests run: 771, Failures: 0, Errors:

Re: [MNG-5761] Dependency management is not transitive.

Am 11/17/16 um 23:56 schrieb Christian Schulte: > Am 11/15/16 um 23:41 schrieb Jason van Zyl: >> Almost none of the changes are well documented, there’s no release notes, >> we’ve told you to roll back or stop making behavioral changes. Put another way. Please take a look a

Re: [MNG-5761] Dependency management is not transitive.

Am 11/15/16 um 23:41 schrieb Jason van Zyl: > Almost none of the changes are well documented, there’s no release notes, > we’ve told you to roll back or stop making behavioral changes. Do you notice how many times I reverted things, changed things, re-reverted things, tried it in a backwards

Re: [MNG-5761] Dependency management is not transitive.

Am 11/17/16 um 21:43 schrieb Christian Schulte: > Am 11/17/16 um 06:00 schrieb Igor Fedorenko: >> FWIW, I ran maven integration tests (commit 73a2b7) against current >> maven master and got this >> >>> Tests run: 771, Failures: 3, Errors: 21, Skipped: 0 >&g

Re: [MNG-5761] Dependency management is not transitive.

Am 11/17/16 um 06:00 schrieb Igor Fedorenko: > FWIW, I ran maven integration tests (commit 73a2b7) against current > maven master and got this > >> Tests run: 771, Failures: 3, Errors: 21, Skipped: 0 > > Running the same test checkout with Maven 3.3.9 > >> Tests run: 771, Failures: 0, Errors:

Re: [MNG-5761] Dependency management is not transitive.

To sum it up. I've asked the very same question a few weeks ago. That has lead to creating that maven-3.x-next branch. A few weeks later I get a different answer and that branch becomes obsolete and all JIRA issues for version 3.5.0 need updating and the branch can be deleted, because it became

Re: [MNG-5761] Dependency management is not transitive.

Am 11/16/16 um 00:42 schrieb Christian Schulte: > tracked with. Can we please line up all of this with everyone and with > whatever changes others have in mind. By this I mean the following. If the import scope behaviour cannot be changed to what was done for MNG-5971 in any Maven 3.x v

Re: [MNG-5761] Dependency management is not transitive.

Am 11/15/16 um 23:41 schrieb Jason van Zyl: > > You obviously don’t work with anyone who has a system with any number of > users. No one has said the system cannot change, but you repeatedly keep > changing stuff that potentially has huge impacts on users and it doesn’t > bother you at all. I

Re: [MNG-5761] Dependency management is not transitive.

Am 11/15/16 um 17:17 schrieb Jason van Zyl: > -1 > > No one has likely to have read the information The reporter of the issue clearly has ;-) > and you’re reasoning is illogical. Making Maven behave as advertised and as requested isn't that illogical, IMHO. > Repeatedly you seem not to care

[MNG-5761] Dependency management is not transitive.

Hi, starting to write up some documentation for 3.4.0 has lead to (re-) reading various parts of the existing documentation. Regarding the issue in the subject. Would it be ok to include the corresponding fix in 3.4.0? It makes Maven 3.4.0 dependency management behave exactly as it is documented.

[VOTE] Release Apache Maven Resources Plugin version 3.0.2

Hi, We solved 3 issues: * [MRESOURCES-230] - Can't escape the escape string * [MRESOURCES-233] - Upgrade of plexus-interpolation 1.24 to correct escaping issue. * [MRESOURCES-234] - Upgrade of commons-io to 2.5 and correction of invalid scope. There are still a couple of issues left

Re: Releasing maven-resources-plugin 3.0.2

I also have huge problems when downloading snapshots from that repository. That also is *very* slow here. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org

Re: Releasing maven-resources-plugin 3.0.2

[INFO] [WARNING] Could not transfer metadata org.apache.maven.artifact.repository.metadata.MetadataBridge@31da0344 from/to apache.releases.https (https://repository.apache.org/service/local/staging/deploy/maven2): Connect to repository.apache.org:443 [repository.apache.org/207.244.88.143] failed:

Re: Releasing maven-resources-plugin 3.0.2

Am 11/13/16 um 19:56 schrieb Christian Schulte: > Am 11/13/16 um 19:42 schrieb Christian Schulte: >> Am 11/13/16 um 18:53 schrieb herve.bout...@free.fr: >>> seems you missed >>> https://www.apache.org/dev/publishing-maven-artifacts.html#de

Re: Releasing maven-resources-plugin 3.0.2

Am 11/13/16 um 19:42 schrieb Christian Schulte: > Am 11/13/16 um 18:53 schrieb herve.bout...@free.fr: >> seems you missed >> https://www.apache.org/dev/publishing-maven-artifacts.html#dev-env >> Wait. I have -Djava.net.useSystemProxies=true -

Re: Releasing maven-resources-plugin 3.0.2

t; Regards, > > Hervé > > - Mail original - > De: "Christian Schulte" <c...@schulte.it> > À: "Maven Developers List" <dev@maven.apache.org> > Envoyé: Dimanche 13 Novembre 2016 17:56:30 > Objet: Releasing maven-resources-plugin

Releasing maven-resources-plugin 3.0.2

Hi, this is the first time I am releasing a plugin. I've read the release process documentation and am currently at the 'release:perform' step. It's not possible for me to deploy to the repository. I tried it several times now. It always fails with: [INFO] [WARNING] Could not transfer metadata

Re: Build failed in Jenkins: maven-plugins-ITs-m3-windows #1762

Am 11/13/16 um 13:26 schrieb Guillaume Boué: > Hi, > > About the OS name printed, it's a bug in Java 7, that is fixed for 9 and > was backported down to 8u60, see > https://bugs.openjdk.java.net/browse/JDK-8066504. This is what I have on > my machine with Java 8u102: > > Apache Maven

Re: Build failed in Jenkins: maven-plugins-ITs-m3-windows #1762

Is there something special about OS name: "windows server 2012 r2", version: "6.3", arch: "amd64", family: "windows" ? I verified the ITs do pass using Apache Maven 3.4.0-SNAPSHOT (a6f8bd1712a5ae30068424651bac35d2909dc4c1; 2016-11-12T22:15:03+01:00) Maven home:

Re: [VOTE] Maven Assembly Plugin 3.0.0

The plugin is affected by . Would it be possible to release the plugin with downgraded 'plexus-interpolation' 1.21? Am 11/05/16 um 02:07 schrieb Olivier Lamy: > Hi, > > We solved 34 issues: >

Re: [VOTE] Release Apache Maven PMD Plugin version 3.7

Am 10/18/16 um 00:04 schrieb Hervé BOUTEMY: > FYI, I found the cause of the issue: this could be useful to share... > > I defined a ~/.mavenrc file which defined MAVEN_OPTS env variable > > since maven-invoker-plugin passed configuration from invoker.properties as > MAVEN_OPTS env variable

Re: Some thoughts on Maven 5

Am 10/15/16 um 15:20 schrieb Stephen Connolly: > * Pom doesn't need to be XML any more... (maybe we want to keep XML though... > just a less verbose form) Maybe XML really isn't the way to go. Whenever I look at an XML file, it appears to be a mixture of meta-data, data and behaviour/logic. Last

Re: Some thoughts on Maven 5

Am 10/15/16 um 19:32 schrieb Stephen Connolly: > I'm thinking that we still want a dependency management section I think dependency management is a must have. That's a build tool feature to allow overriding dependency details from the consumed PDT. What is different here is that instead of having

Re: Some thoughts on Maven 5

Am 10/15/16 um 16:26 schrieb Stephen Connolly: > Thinking out loud... perhaps something like > > [version="..."] packaging="..."> > [ [relativePath="...']/> > > [] > [] > ... > [] Looking at this from a syntax point of view only, we will run into those "XML element declaration order

Re: [jira] [Created] (MRESOLVER-4) Use Commons Lang's Validate to intercept invalid input

Am 10/16/16 um 23:51 schrieb Stephen Connolly: > Let's just go for Java 7... this is linked to core... if you are stuck on > an older Java likely you can't upgrade Maven anyway +1 - To unsubscribe, e-mail:

Re: [jira] [Created] (MRESOLVER-4) Use Commons Lang's Validate to intercept invalid input

Am 10/16/16 um 22:51 schrieb Michael Osipov: > Am 2016-10-16 um 22:48 schrieb Christian Schulte: >> Will the resolver be upgraded to Java 7? I would use 'java.util.Objects' >> then. > > I have the very same idea. I wouldn't mind using j.u.Objects instead of > o.a.c.l4.Val

Re: [jira] [Created] (MRESOLVER-4) Use Commons Lang's Validate to intercept invalid input

Will the resolver be upgraded to Java 7? I would use 'java.util.Objects' then. Am 10/16/16 um 22:30 schrieb Michael Osipov (JIRA): > Michael Osipov created MRESOLVER-4: > -- > > Summary: Use Commons Lang's Validate to intercept invalid input >

Re: Maven Resolver 1.2 with Maven 3.4?

Am 10/16/16 um 21:43 schrieb Michael Osipov: > Hi folks, > > are we going to incorporate v 1.2 of Resolver into Maven 3.4? I've seen > that Christian done some fixing required by some MNGs as well as our > rebranding of the project. Some dependencies need to be updated to match > Maven's but

Re: maven git commit: [MNG-6105] properties.internal.SystemProperties.addSystemProperties() is not really thread-safe

Btw: Do you know why and where system properties are being removed? Am 10/16/16 um 01:40 schrieb gb...@apache.org: > Repository: maven > Updated Branches: > refs/heads/master f7c1359cf -> ace448158 > > > [MNG-6105] properties.internal.SystemProperties.addSystemProperties() is > not really

Re: Some thoughts on Maven 5

Am 10/16/16 um 02:03 schrieb Stephen Connolly: >> On 16 Oct 2016, at 00:07, Christian Schulte <c...@schulte.it> wrote: >> Any thoughts about how to name that new build pom? > > project.mvn or pom.mvn > > But only if we move to a non-xml DSL > > If we are sti

Re: Some thoughts on Maven 5

Am 10/16/16 um 00:57 schrieb Stephen Connolly: > We only have to generate a "consumer pom" in modelVersion 4.0.0... and that > need only be best effort, and will be generated off the PDT ... the new Pom > schema is what drives generating the PDT If a scope is used not known to POM 4.0.0, just

Re: Some thoughts on Maven 5

Am 10/15/16 um 15:20 schrieb Stephen Connolly: > * does Maven 5 build Maven 2/3 projects? No need for this, IMHO. Maven 2 could not build Maven 1 projects. Maven 3 could build Maven 2 projects but added warnings for various things and some internal model transformations like for the 'reporting'

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

Am 10/13/16 um 21:52 schrieb Robert Scholte: > On Thu, 13 Oct 2016 02:53:54 +0200, Christian Schulte <c...@schulte.it> >> Should I change the order of the effective settings so that things from >> the global settings always come before the user settings? Will that blow >

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

Am 10/13/16 um 21:52 schrieb Robert Scholte: > I'd say revert these changes. We see that this "hack" doesn't always work. > Better look for a more solid solution with another release in the future. The better solution would be to completely remove repositories from the poms and from all

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

Am 10/12/16 um 23:17 schrieb Robert Scholte: > It is a bit different: the *effective* settings are the global settings > where parts can be overridden with the user settings. This means that all > profiles will be there, during build the content of profiles will keep > overriding each other.

Re: Cannot build current master.

Am 10/11/16 um 21:50 schrieb Karl Heinz Marbaise: > Hi Guillaue, > > On 11/10/16 21:21, Guillaume Boué wrote: >> Regarding this failure, I think it is caused by a capitalization >> issue... The test is looking for >> "missing-artifactid-pluginManagement.xml" (lowercase "i" at artifactid) >> while

Cannot build current master.

Just updated current master and am getting test failures. Just my local checkout? $ env LC_ALL=C git branch * master maven-3.x-next $ env LC_ALL=C git status On branch master Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

Am 10/10/16 um 20:49 schrieb Igor Fedorenko: > Are repositories and other configuration defined in user settings.xml > take precedence over global settings.xml? Don't know for sure but would assume so. The current master 4.0.0 super pom has already been reverted to not change in any way in 3.4.0.

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

Am 10.10.2016 um 15:35 schrieb Igor Fedorenko: > It is common to use repository with id=central in settings.xml to > override central location. This functionality should continue to work, > regardless how it is implemented in Maven internally. > Do you have a wildcard mirror in the settings as

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

Am 10.10.2016 um 16:16 schrieb Christian Schulte: > Am 10.10.2016 um 15:35 schrieb Igor Fedorenko: >> It is common to use repository with id=central in settings.xml to >> override central location. This functionality should continue to work, >> regardless how it is implemente

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

Am 10.10.2016 um 15:35 schrieb Igor Fedorenko: > It is common to use repository with id=central in settings.xml to > override central location. This functionality should continue to work, > regardless how it is implemented in Maven internally. >

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

Am 10.10.2016 um 15:35 schrieb Igor Fedorenko: > It is common to use repository with id=central in settings.xml to > override central location. This functionality should continue to work, > regardless how it is implemented in Maven internally. > That is what has become the default. Did you look

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

Am 10/10/16 um 14:45 schrieb Mirko Friedenhagen: > Hello, > > I just tried to run "mvn help:effective-pom -Doutput=MVNVERSION.xml" > on one of our inhouse projects once with 3.3.9 and once with > 3.4.0-SNAPSHOT (4ad0fb217c93d36cf3365b83baec48470196f5fa; > 2016-10-09T21:16:52+02:00) > > 3.4.0

Re: Maven 3.4.0 Release

Am 10/09/16 um 14:10 schrieb Jason van Zyl: > The preparation of detailed released notes to be reviewed. The last release > was almost a year ago, and an enormous number of behavioral changes have been > made in that time-frame. There’s zero documentation outlining these changes > thus far in

Re: Maven 3.4.0 Release

Am 10/09/16 um 21:44 schrieb Stephen Connolly: > Open issues bound to 3.4.0 > > * Introduction of model version 4.1.0. > https://issues.apache.org/jira/browse/MNG-6082 > <https://issues.apache.org/jira/browse/MNG-6082> > assignee: Christian Schu

Re: Project Dependency Trees schema...

Am 09/29/16 um 19:34 schrieb Christian Schulte: > Am 09/29/16 um 19:13 schrieb Christian Schulte: >> >> I fail to come up with anything more appropriate than DNS TXT records to >> map coordinates/group ids to download locations in combination with >> DNSSEC. It's exact

Re: Project Dependency Trees schema...

Am 09/29/16 um 19:13 schrieb Christian Schulte: > > I fail to come up with anything more appropriate than DNS TXT records to > map coordinates/group ids to download locations in combination with > DNSSEC. It's exactly the model we are heading after. This would make > signing/hash

Re: Project Dependency Trees schema...

Am 09/28/16 um 23:23 schrieb Stephen Connolly: > So I am seeing conflicting requirements and I am unsure how we should > approach resolving them: > > 1. Seems perfectly reasonable to add some form of integrity details about > the *project's artifacts* into the PDT. Probably a SHA512 hash... Adds

Re: Project Dependency Trees schema...

Am 09/28/16 um 19:27 schrieb Stephen Connolly: > On Wednesday 28 September 2016, Christian Schulte <c...@schulte.it> wrote: > >> Am 09/28/16 um 08:25 schrieb Stephen Connolly: >>> So if we provide a way to decentralise. >> >> We do already. >> &

Re: Project Dependency Trees schema...

Am 09/28/16 um 08:25 schrieb Stephen Connolly: > So if we provide a way to decentralise. We do already. > > So now junit hosts their own artifacts, not central Or some company hosts it at the same coordinates and I happen to need to add that repository to a project of mine. > Now the absolute

Re: Project Dependency Trees schema...

Am 09/28/16 um 04:48 schrieb Christian Schulte: > Am 09/28/16 um 04:16 schrieb Christian Schulte: >> Am 09/27/16 um 15:24 schrieb Stephen Connolly: >>> I think that may be problematic... but probably not the worst thing to add >>> to the schema (would just be an extra

Re: Project Dependency Trees schema...

Am 09/28/16 um 04:16 schrieb Christian Schulte: > Am 09/27/16 um 15:24 schrieb Stephen Connolly: >> I think that may be problematic... but probably not the worst thing to add >> to the schema (would just be an extra attribute) > > Something you can use to identify the e

Re: Project Dependency Trees schema...

Am 09/27/16 um 15:24 schrieb Stephen Connolly: > I think that may be problematic... but probably not the worst thing to add > to the schema (would just be an extra attribute) Something you can use to identify the entity having produced an artifact and useable to verify an artifact has not been

Re: Project Dependency Trees schema...

Just thinking about how different repositories can be handled. I think we should at least track the "origin" repository ids an artifact has been resolved from to have something to match against the effective repositories of a project. So that an artifact resolved from a repository not part of a

Re: Project Dependency Trees schema...

Am 09/26/16 um 15:29 schrieb Stephen Connolly: >

Re: Project Dependency Trees schema...

Am 26.09.2016 um 15:29 schrieb Stephen Connolly: > Here's an approximation of my current thinking: > > > > > [...] > [...] > ... > > > groupId, artifactId and version are the ones specified at level, correct? > >

Re: DefaultArtifactVersion / VersonComparison

Am 09/24/16 um 17:33 schrieb Karl Heinz Marbaise: > Hi Hervé, > So I have marked the class as deprecated... > > But it implements an interface: > > public interface ArtifactVersion > extends Comparable > > which should be marked as deprecated as well in consequence of the > previous step

Re: DefaultArtifactVersion / VersonComparison

Am 09/24/16 um 13:46 schrieb Hervé BOUTEMY: > DefaultArtifactVersion with its broken API. But I never went ahead and > removed > this class from core, to avoid incompatibility: perhaps just deprecating this > class would be the most simple thing to do. > +1

Re: New warnings with Maven 3.4-SNAP

Am 09/14/16 um 13:50 schrieb Stephane Nicoll: > Dependency 'org.springframework.cloud:spring-cloud-commons:jar' has > conflicting dependency management from ' > org.springframework.cloud:spring-cloud-consul-dependencies:1.0.2.RELEASE' and >

Re: New warnings with Maven 3.4-SNAP

Am 09/14/16 um 14:17 schrieb Christian Schulte: > Am 09/14/16 um 13:50 schrieb Stephane Nicoll: >> Well, first of all I have no idea what the following means: >> >> rearrange the causing imports in the inheritance hierarchy to apply >> standard override logic ba

Re: New warnings with Maven 3.4-SNAP

Am 09/14/16 um 13:50 schrieb Stephane Nicoll: > Well, first of all I have no idea what the following means: > > rearrange the causing imports in the inheritance hierarchy to apply > standard override logic based on artifact coordinates. Apply inheritance override logic to resolve the conflict.

Re: New warnings with Maven 3.4-SNAP

Am 09/14/16 um 08:42 schrieb Stephane Nicoll: > First of all, I'd like the error message to change. I still don't know to > this day what it means. Second, if Maven is able to find out that two boms > provide dependency management for foo with conflicting versions, It would > be nice to say in

Re: Apache OpenMeetings build fails on Maven 3.4-SNAPSHOT

Am 09/05/16 um 17:46 schrieb Behrooz Nobakht: > Thanks, Christian. Is there a Maven ticket for this? Looks like . Regards, -- Christian - To unsubscribe, e-mail:

Re: Apache OpenMeetings build fails on Maven 3.4-SNAPSHOT

Am 09/05/16 um 16:48 schrieb Maxim Solodovnik: > I have merged your PR, Thanks! :)) I cannot tell in what version this has stopped working. It will be working again in 3.4+. Maybe that PR isn't correct and the old behaviour really was intended years ago. Regards, -- Christian

Re: Apache OpenMeetings build fails on Maven 3.4-SNAPSHOT

Am 09/05/16 um 14:39 schrieb Behrooz Nobakht: > Hi there, > > Trying to build Apache OpenMeetings with Apache Maven 3.4-SNAPSHOT[1] fails > with "Compilation failure" all with "package org.red5.x does not exist". > > The build is run on the

Re: Building jar targeting multiple Java versions, including 9

Am 09/03/16 um 11:48 schrieb Robert Scholte: > Simple? We have several options. Most user friendly might be to have the > "magic" in the maven-compiler-plugin, which implies you need to be able to > set the javac executable for both, set the source/target/release for both. > And how about

Re: Building jar targeting multiple Java versions, including 9

Am 09/02/16 um 19:06 schrieb Robert Scholte: > I'll rephrase the question: What to do which projects who want to have > their code compatible with a version lower than Java 9 AND want to provide > a module-info file as well? The main sources are compiled with, for example, -target 1.6 and

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

Am 08/31/16 um 19:35 schrieb Stephen Connolly: > On Wednesday 31 August 2016, Christian Schulte <c...@schulte.it> wrote: >> >> >> public interface DependencyTreeProvider >> { >> >> DependencyNode getDependencyTree( String logicalScopeName ) >>

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

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

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

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

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

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

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

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

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

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 choi

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

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

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 decisi

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

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

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

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 i

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

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

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

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

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: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

Am 08/19/16 um 21:10 schrieb jieryn: > I am seeing a huge amount of additional warnings at the start of the > build now, that is intentional I believe? Do we have a wiki or any > documentation about resolving these issues? For example, I'm seeing > this because I use Arquillian and their standard

Re: Discussion: Resource-only artifacts

Am 08/17/16 um 21:57 schrieb Paul Benedict: > to me... but it does raise the bigger issue regarding Maven and > resource-only artifacts. Except for the "pom" packaging type, every other > type relates to code, no? The current core packaging values are: pom, jar, > maven-plugin, ejb, war, ear, rar,

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

Am 08/16/16 um 23:14 schrieb Curtis Rueden: > properly with Maven 3.4.0. But I am very concerned about the precedent > here: at any point in the future, complex builds which used to work might > stop doing so, even without a major version increment, due to future > changes in the logic of core

Re: slf4j runtime dependency for plugin

Am 08/15/16 um 22:21 schrieb Fred Cooke: > Something doesn't have to be in Java to be universal (as SLF4J really is), > and conversely, something being in Java doesn't make the world instantly > catch up (eg YodaTime vs J8+). Or java.util.logging. Almost not used anywhere.

<    1   2   3   4   5   6   7   >