Re: Cannot build any Maven plugins with current 3.4.0

That one should have been fixed by commit <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=286c7ffba1696053274c5da6cad4336f678fceee>. Support for exclusions was missing accidentally. Am 12/18/16 um 03:37 schrieb Christian Schulte: > Just as an example for why the plug

Re: Cannot build any Maven plugins with current 3.4.0

Just as an example for why the plugin's need to be resolved the same way as projects. The following is the resolution result of the 'maven-resources-plugin' version 2.7 when resolved as a project: org.apache.maven.plugins:maven-resources-plugin:jar:2.7:

Re: Cannot build any Maven plugins with current 3.4.0

Am 12/18/16 um 00:08 schrieb Michael Osipov: > Am 2016-12-18 um 00:01 schrieb Christian Schulte: >> Am 12/17/16 um 21:56 schrieb Guillaume Boué: >>> Yes, I confirm that the build of the Maven plugins is OK when checking >>> out cc5af1306ff91d9bef68737c96c364a371a477d7

Re: Cannot build any Maven plugins with current 3.4.0

>From what I can tell, the rat plugin can be updated to 0.12 and this should change the situation. Not sure. Still looking into it. Am 12/17/16 um 21:56 schrieb Guillaume Boué: > Yes, I confirm that the build of the Maven plugins is OK when checking > out

Re: Cannot build any Maven plugins with current 3.4.0

Am 12/17/16 um 21:56 schrieb Guillaume Boué: > Yes, I confirm that the build of the Maven plugins is OK when checking > out cc5af1306ff91d9bef68737c96c364a371a477d7. Let's just find out what is the cause for all those failures we are now seeing. MNG-6135 potentionally will uncover a massive

Re: Improving Jenkins

Am 12/17/16 um 11:52 schrieb Hervé BOUTEMY: > looks like MNG-6135 causes a lot of issues > > "Maven plugins and core extensions are not dependencies, they should be > resolved the same way as projects." > "Maven plugins and core extensions are not dependencies": why not > "they should be

Re: Commits 02795b21e753bdd4eddd7e9ebee9f50315bc0e24 and 3681fd8489cd59d0c5bc49ef38725b655d524301

We first need to decide on the version this will get released as. Updating everything to 3.4 now and to 4.0 two weeks later I can avoid the duplicate effort this time. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

Re: Maven 3.4.0 Release

Am 12/17/16 um 05:17 schrieb Christian Schulte: > Am 12/12/16 um 00:51 schrieb Igor Fedorenko: >> I'm traveling until next weekend and won't be able to review your changes >> properly until I'm back. I do want to stress that maven plugins are not >> dependencies, they are

Re: Maven 3.4.0 Release

Am 12/12/16 um 00:51 schrieb Igor Fedorenko: > I'm traveling until next weekend and won't be able to review your changes > properly until I'm back. I do want to stress that maven plugins are not > dependencies, they are resolved the same way as projects. Master does it that way now. I may need

Improving Jenkins

Hi, I renamed the 'maven-aether-provider' module to 'maven-resolver-provider'. What happens on Jenkins is this: The 'maven-aether-provider' folder will not get deleted correctly when Jenkins performs the SCM update/checkout. This may be due to the existence of the 'maven-aether-provider/target'

Re: Commits 02795b21e753bdd4eddd7e9ebee9f50315bc0e24 and 3681fd8489cd59d0c5bc49ef38725b655d524301

Am 12/16/16 um 21:36 schrieb Michael Osipov: > Am 2016-12-16 um 18:41 schrieb Christian Schulte: >> Am 12/15/16 um 22:49 schrieb Michael Osipov: >>> I would expect a VALIDATION_LEVEL_MAVEN_3_4 with VALIDATION_LEVEL_STRICT >>> = VALIDATION_LEVEL_MAVEN_3_1. All spots

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

Am 12/16/16 um 20:30 schrieb Robert Scholte: > On Fri, 16 Dec 2016 17:25:16 +0100, Christian Schulte <c...@schulte.it> > wrote: > >> Am 12/16/16 um 15:21 schrieb Robert Scholte: >>> >>> but this cover the issue we are talking about, because IIUC you

Re: Commits 02795b21e753bdd4eddd7e9ebee9f50315bc0e24 and 3681fd8489cd59d0c5bc49ef38725b655d524301

First commit is not relevant to the increase of the validation level, BTW. Just the second one. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org

Re: Commits 02795b21e753bdd4eddd7e9ebee9f50315bc0e24 and 3681fd8489cd59d0c5bc49ef38725b655d524301

Am 12/15/16 um 22:49 schrieb Michael Osipov: > I would expect a VALIDATION_LEVEL_MAVEN_3_4 with VALIDATION_LEVEL_STRICT > = VALIDATION_LEVEL_MAVEN_3_1. All spots which say Severity errOn31 = > getSeverity( request, ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_3_1 ); > must be turned into

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

Am 12/16/16 um 17:25 schrieb Christian Schulte: > Am 12/16/16 um 15:21 schrieb Robert Scholte: >> >> but this cover the issue we are talking about, because IIUC you are saying >> that IF both junit and hamcrest get the test-scope AND hamcrest would have >> a depe

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

Am 12/16/16 um 15:21 schrieb Robert Scholte: > > but this cover the issue we are talking about, because IIUC you are saying > that IF both junit and hamcrest get the test-scope AND hamcrest would have > a dependency THEN that dependency is not added to the classpath. That is > still

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

Am 12/15/16 um 23:28 schrieb Christian Schulte: > different thing. Think about the dependency management as a global > override of everything. That's how the resolver works. That's my Maven does it that way since 2.0.something. Take a look at this pom: <http://repo.maven.apache.org/mav

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

Am 12/15/16 um 22:31 schrieb Robert Scholte: > On Thu, 15 Dec 2016 09:40:46 +0100, Christian Schulte <c...@schulte.it> > wrote: > >> Am 12/15/16 um 09:28 schrieb Robert Scholte: >>> I think I understand where the confusion is coming from. We must be &g

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

Am 12/15/16 um 09:28 schrieb Robert Scholte: > I think I understand where the confusion is coming from. We must be very > clear about definitions. > Transitive means adding all indirect dependencies with the compile and > runtime dependencies. > So the transitive *scope* itself is not

Re: Dependency resolution broken on Wagon master with Maven 3.4.0-SNAPSHOT

Am 12/15/16 um 09:16 schrieb Christian Schulte: > Am 12/15/16 um 07:53 schrieb Stephen Connolly: >> That may be at odds with the code and docs but it is the only think that >> makes sense to me, depMgmt is about managing dependencies... the bit you >> want to manage is ve

Re: Dependency resolution broken on Wagon master with Maven 3.4.0-SNAPSHOT

Am 12/15/16 um 07:53 schrieb Stephen Connolly: > That may be at odds with the code and docs but it is the only think that > makes sense to me, depMgmt is about managing dependencies... the bit you > want to manage is versions and exclusions, everything else is just the > matching as I see it

Re: Question regarding repository overriding.

Am 12/15/16 um 01:09 schrieb Christian Schulte: > I would have expected the nearest wins strategy as well, BTW. Seems to > not make sense for the resolver to just ignore repository declarations > matching an ID already discovered at another level. Well. Makes perfect sense for the resol

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

Am 12/15/16 um 01:15 schrieb Christian Schulte: > Am 12/14/16 um 23:29 schrieb Michael Osipov: >> I just hit the same issue with the Maven Clean Plugin: >> plexus-container-default is missing on the classpath. >> >> I think that Christian does the right t

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

Am 12/14/16 um 23:29 schrieb Michael Osipov: > I just hit the same issue with the Maven Clean Plugin: > plexus-container-default is missing on the classpath. > > I think that Christian does the right thing, either adjusting code to > documentation or the other way around. We just need to agree

Re: Question regarding repository overriding.

I would have expected the nearest wins strategy as well, BTW. Seems to not make sense for the resolver to just ignore repository declarations matching an ID already discovered at another level. - To unsubscribe, e-mail:

Re: Question regarding repository overriding.

Am 12/14/16 um 20:41 schrieb Stephen Connolly: > definition nearest to the project should win is the principle that has been > in force... That's what Maven core developers had in mind. Maven resolver developers did the opposite. See this class:

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

Just an additional information. Maven core and the resolver are not behaving consistently in that area and also not in the "repository overriding" area. As you may have noticed, I am just heading for consistency. I am having a hard time figuring out why the core has not been updated to reflect

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

Am 12/15/16 um 00:19 schrieb Christian Schulte: > -ldm,--legacy-dependency-management > Use Maven 2 dependency management behaviour. Can also be activated by > using -Dmaven.legacyDependencyManagement=true. > > There are a bunch of issues in JIRA affecting dependency management

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

Am 12/14/16 um 22:57 schrieb Robert Scholte: > Digging into this case before the change: > > The 4 related modules ignoring the versions: > > org.apache.maven.wagon:wagon:pom > { > dependencyManagement { > dependencies { >

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

Am 12/14/16 um 17:57 schrieb Robert Scholte: > Hi, > > I read the comment but I'm not sure I follow. The original setup is a > widely used pattern: give dependencies which should always have the > test-scope this scope in the dependencyManagement of the parent. > Considering the case below it

Re: Documenting Maven 3.4.0

Am 12/14/16 um 01:41 schrieb Manfred Moser: > I would suggest latest publically available version (so 3.3.9). > Ok. Thanks. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail:

Documenting Maven 3.4.0

When providing examples, which Maven version should be used to demonstrate differences. Maven 3.0.5, 3.1.1, 3.2.5 or 3.3.9? Regards, -- Christian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional

Re: Maven 3.4.0 Release

Am 12/14/16 um 01:05 schrieb Christian Schulte: > That a direct optional dependency That should read: That a transitive optional dependency... - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional comma

Re: Maven 3.4.0 Release

Am 12/12/16 um 00:51 schrieb Igor Fedorenko: > I'm traveling until next weekend and won't be able to review your changes > properly until I'm back. I do want to stress that maven plugins are not > dependencies, they are resolved the same way as projects. Coming back to this. Currently plugins

Re: Dependency resolution broken on Wagon master with Maven 3.4.0-SNAPSHOT

That's MRESOLVER-9. Fixed the POMs with this commit. This is what is lacking documentation the most. Does the commit message clarify what is going on? Am 12/13/16 um 20:32 schrieb

Re: Dependency resolution broken on Wagon master with Maven 3.4.0-SNAPSHOT

Am 12/13/16 um 20:32 schrieb Michael Osipov: > Hi folks, > > current Wagon master cannot be built with > > Apache Maven 3.4.0-SNAPSHOT (33c79c6e4662abb836df95a5d70c236f2e5cda3d; > 2016-12-13T20:22:49+01:00) > Maven home: D:\Entwicklung\Programme\apache-maven-3.4.0-SNAPSHOT\bin\.. > Java

Re: Parent Version maybe not needed in child POM

Am 12/13/16 um 07:33 schrieb Igor Fedorenko: > But reactor dependencies make perfect sense in m2e! Also, keep in mind that > we are talking about new maven concept, it does not currently exist and > can't be supported by m2e, netbeans or any other existing tool. > Last time I worked on a Maven

Re: Parent Version maybe not needed in child POM

Am 12/13/16 um 06:04 schrieb Tibor Digana: >>> Something like an J2EE >>> You can take a long walk >>> until it finishes downloading sources, javadoc, dependencies >>> I really only open the module(s) I need > This is not Maven problem then. > You architect must give you a freedom to move some

Jenkins: Modules changed, recalculating dependency graph

Would it be possible to assign me role in Jenkins allowing me to fix things myself? I renamed 'maven-aether-provider' to 'maven-resolver-provider' and all hell breaks loose on Jenkins. I have a strong need on a reliable CI system :-). I'd like to stop this one from failing, for example, but cannot

2nd question regarding repository overriding.

Am 12/13/16 um 02:32 schrieb Christian Schulte: > Consider these projects: > > P1 declares a repository with id 'central' and a dependency on D1 > available in that repository. > > D1 declares a repository with id 'central' with a different URL and has > a depende

Question regarding repository overriding.

Consider these projects: P1 declares a repository with id 'central' and a dependency on D1 available in that repository. D1 declares a repository with id 'central' with a different URL and has a dependency management import declaration on D2. When importing D2 into the effective model of D1,

Re: Parent Version maybe not needed in child POM

Am 12/13/16 um 01:33 schrieb Igor Fedorenko: > This suggests inefficiency in existing implementation. We use this model > internally with some custom optimizations for a very large codebase. Maybe. Netbeans is using the Maven API for all of this. It's like building the full reactor on the

Re: Maven 3.4.0 Release

Am 12/12/16 um 22:55 schrieb Michael Osipov: > Am 2016-12-12 um 02:48 schrieb Christian Schulte: >> Am 12/11/16 um 22:56 schrieb Michael Osipov: >>> I just ran ITs with current master, only one IT fails: >> >> Should be fixed now. > > Are you

Re: Parent Version maybe not needed in child POM

Am 12/13/16 um 01:07 schrieb Manfred Moser: > All of these task should only happen when you open a new project. Otherwise > all of it should be cached in the local repo. > > When all of it is local it should NOT take so long. At least it doesnt in > M2e. If you resort to a hack like opening

Re: Parent Version maybe not needed in child POM

Am 12/12/16 um 23:23 schrieb Igor Fedorenko: > Disagree. I think in most if not all cases we build entire project, not > just random part of a project. Try opening a big multi-module project in Netbeans, for example. Something like an J2EE application server. You can take a long walk until it

Re: Maven 3.4.0 Release

Am 12/12/16 um 22:55 schrieb Michael Osipov: > Am 2016-12-12 um 02:48 schrieb Christian Schulte: >> Am 12/11/16 um 22:56 schrieb Michael Osipov: >>> I just ran ITs with current master, only one IT fails: >> >> Should be fixed now. > > Are you

Re: Parent Version maybe not needed in child POM

Am 12.12.2016 um 21:32 schrieb Tibor Digana: > The IDEs like Eclipse, IDEA etc must adapt to versionless parent. > > @Christian > Execution of large projects and parent version depends on development team. > Nowadays they are going to be Microservices very small and isolated in > build time and

Re: Parent Version maybe not needed in child POM

Am 12/12/16 um 10:16 schrieb Tibor Digana: > Is it really necessary to specify version of parent artifact in ? It must be possible to checkout a single module and build that in isolation. A parent without a version cannot be resolved from a repository. Supporting that means you need to checkout

Re: Maven 3.4.0 Release

Am 12/11/16 um 22:56 schrieb Michael Osipov: > I just ran ITs with current master, only one IT fails: Should be fixed now. Regards, -- Christian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional

Re: Maven 3.4.0 Release

Am 12/12/16 um 00:51 schrieb Igor Fedorenko: > I'm traveling until next weekend and won't be able to review your changes > properly until I'm back. I do want to stress that maven plugins are not > dependencies, they are resolved the same way as projects. Yes. I agree to that. It's not

maven-3.3-release-status-build build job.

Can someone please take a look at that build job. It is failing with Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "main" for quite some time now. Regards, -- Christian - To

maven-aether-provider renamed to maven-resolver-provider.

Do we want to deploy a 'maven-aether-provider' relocating to 'maven-resolver-provider'? Regards, -- Christian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org

extensions.xml (Re: [4/7] maven git commit: [MNG-6110] Upgrade Aether to Maven Resolver 1.2)

Can someone please take a look at this and verify the changes are correct? I am not sure the former artifacts also need to be exported. For the sonatype ones the package names are different. For the eclipse ones the package names are identical. Not sure, though. org.eclipse.aether:aether-api

Re: Maven 3.4.0 Release

Thanks. Noticed this myself yesterday. Wanted to wait for Jenkins to finish all pending jobs. Haven't expected any IT to fail. Will have a look. Am 12/11/16 um 22:56 schrieb Michael Osipov: > Am 2016-12-10 um 16:06 schrieb Christian Schulte: >> If it's happening just due to th

Re: Maven 3.4.0 Release

Am 12/11/16 um 03:29 schrieb Igor Fedorenko: > Why do you say Dependency A is transitive? Maven plugin directly depends > on Dependency A, so I expect it to be present on the plugin classpath. > This is consistent with how project direct optional dependencies are > always present on classpath.

Re: Maven 3.4.0 Release

Corrected IT in this commit. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For

Re: Maven 3.4.0 Release

Am 12/10/16 um 13:39 schrieb Hervé BOUTEMY: > I just tested the patch associated to MNG-6110 - Upgrade Aether to Maven > Resolver 1.2, and it caused one failure in ITs > testit(org.apache.maven.it.MavenITmng4721OptionalPluginDependencyTest) Time > elapsed: 0.185 sec <<< FAILURE! >

Include scope (Re: [4/4] maven git commit: [MNG-5971] Imported dependencies should be available to inheritance processing)

.org/repos/asf/maven/commit/5785d6f1 > Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/5785d6f1 > Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/5785d6f1 > > Branch: refs/heads/master > Commit: 5785d6f1dc7c494445eedc49a537c5537ede8865 > Parents: ef4e4b4 > Author: C

Re: [ANN] Apache Maven Resources Plugin 3.0.2 Released

7. Celebrate :o) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org

[ANN] Apache Maven Resources Plugin 3.0.2 Released

The Maven team is pleased to announce the release of the Apache Maven Resources Plugin, version 3.0.2 The Resources Plugin handles the copying of project resources to the output directory. There are two different kinds of resources: main resources and test resources. The difference is

Re: [RESULT] [VOTE] Release Apache Maven Resources Plugin version 3.0.2

Am 12/10/16 um 18:54 schrieb Robert Scholte: > Done as well Thanks. Does that mean I need to re-generate the website or does this just affect the announcement mail? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For

Re: [RESULT] [VOTE] Release Apache Maven Resources Plugin version 3.0.2

Am 12/10/16 um 18:28 schrieb Robert Scholte: > Done One more step I cannot perform myself: 3. Update the version tracking in JIRA In the relevant project, go to Administration, then Versions. Mark the Y.Z version as 'released'. Create version Y.Z+1, if that hasn't already been done. You may

Re: [RESULT] [VOTE] Release Apache Maven Resources Plugin version 3.0.2

Am 12/10/16 um 18:28 schrieb Robert Scholte: > Done Thanks! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 3.4.0 Release

Am 12/10/16 um 17:48 schrieb Michael Osipov: > Can you create a proper branch with fixed ITs? I'd like to run those. > From my point of view, we can release Resolver 1.2 and roll an RC for > Maven 3.4. Let's just switch maven master to the resolver snapshot and continue from there on. That

Re: [RESULT] [VOTE] Release Apache Maven Resources Plugin version 3.0.2

Am 12/10/16 um 16:48 schrieb Robert Scholte: > Hi Christian, > > See > http://maven.apache.org/developers/release/maven-project-release-procedure.html#Copy_the_source_release_to_the_Apache_Distribution_Area > > the last sense of the first paragraph: > Currently this requires to be in

Re: Maven 3.4.0 Release

Wait. That maybe a different story. MRESOLVER-8. The changes to 'OptionalDependencySelector' made it behave the same way the 'ScopeDependencySelector' and other selectors are

Re: Maven 3.4.0 Release

It would be cool if someone could answer the questions I raised in this thread. I would still need to remove those system properties from the 'DefaultModelBuilder', for example.

Re: Maven 3.4.0 Release

If it's happening just due to the upgrade of the resolver, then it's a resolver bugfix the IT hasn't been updated to reflect. I discussed this issue with Jason in december last year when upgrading the resolver to 1.1 needed to be reverted.

Re: [RESULT] [VOTE] Release Apache Maven Resources Plugin version 3.0.2

Seems I do not have permission to add the source release to the dist area. Can someone else add the files for me, please? I would like to follow the release process document step by step. This is the next step I would not want to skip for later. svn: E195023: Commit failed (details follow): svn:

[RESULT] [VOTE] Release Apache Maven Resources Plugin version 3.0.2

Hi, The vote has passed with the following result: +1: Robert Scholte, Anders Hammar, Olivier Lamy, Karl Heinz Marbaise, Hervé Boutemy PMC quorum: reached. I will promote the artifacts to the central repo. - To unsubscribe,

Re: POM 5: The problems with mixins

Am 05.12.2016 um 16:03 schrieb Christian Schulte: > checkout the project for you automatically. You only need the "master" > POM and the first invocation of "mvn" will checkout the aggregator > automatically in some way. Just thoughts, though.) With this I am refer

Re: POM 5: The problems with mixins

Am 05.12.2016 um 15:31 schrieb Chas Honton: > What problems are you trying to solve with mixins? What is missing from the > current inheritance scheme? > > It appears to me that you are putting the "how before the "what". > > My personal experience is that mixins lead to jar hell rather fast.

Re: POM 5: The problems with mixins

Not having read all of this for now, but that's what I was referring to with "relaxing a constraint is easier than enforcing a new one". When in doubt how to process conflicting elements or something like that, just error out and fail the build with a descriptive error message. If we later find

[VOTE] Release Apache Maven Resources Plugin version 3.0.2

Hi, We solved 3 issues: There are still a couple of issues left in JIRA:

svn: E170013: Unable to connect to a repository

I cannot access the subversion repository since a few hours any more. Anyone else experiencing this? C:\Users\schulte>svn checkout https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-resources-plugin svn: E170013: Unable to connect to a repository at URL

Re: maven-gpg-plugin updates

Am 04.12.2016 um 16:11 schrieb Chas Honton: > Already there. Seems I looked at the wrong patch file. Regarding the 'checksum-files' goal, I think this does not belong to the 'maven-gpg-plugin' because it is not related to GPG in any way. Looking at , I am

Re: maven-gpg-plugin updates

Am 12/04/16 um 06:27 schrieb Charles Honton: > Who can work with me to get maven-gpg-plugin updated? In particular, I’d > like to add goals to sign and checksum files that are not artifacts. See > MGPG-43 . > Could you add ITs to that patch as

Re: Restore default escaping in maven-resources-plugin?

Am 11/29/16 um 20:01 schrieb Robert Scholte: > How about no escape character? This also implies that escaping is off by > default. +1 That's what was the default prior 3.0.0. Just revert that and be done with it. - To

Re: Restore default escaping in maven-resources-plugin?

Am 11/27/16 um 22:04 schrieb Robert Scholte: > Hi, > > it all depends if the introduced escape character is really a good default > and/or if we should have 2 parameters regarding escaping. > I prefer having only 1 parameter and I think that the chosen escape > character is not default enough

Restore default escaping in maven-resources-plugin?

Hi, the maven-resources-plugin has enabled escaping by default in version 3.0.0 - see MRESOURCES-223 [1]. Prior to version 3.0.0, users wanting to make use of any escaping needed to set the 'escapeString' parameter to some value. This parameter starts to default to the backslash as of version

Re: MRESOURCES-231

Am 11/24/16 um 02:40 schrieb Dan Tran: > ? That is working indeed! Thanks. Is this something official - the way to go - I can tell the reporter of the issue? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For

MRESOURCES-231

If there is @Parameter( defaultValue = "\\" ) protected String escapeString; in a plugin, how can I set the field to null or an empty string? I tried '' and '' but that still leads to the field being set to the default value. I am sure this has been possible in the past. Regards, --

Re: Need to change a test case in 'maven-filtering'.

Am 11/22/16 um 20:40 schrieb Guillaume Boué: > Hi Christian, > > This test looks normal to me. When loading the properties, through load > https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.Reader-, > > the backslash indicates the line terminator, so it needs to

Need to change a test case in 'maven-filtering'.

Hi, I am currently working on and am running into an issue. With the fix in place an existing test case will start failing. Here is the issue: Please take a look at the following line edge.escape.hanging=\\ from

maven-filtering and plexus-interpolation

Hi, what is the reason for having the same logic in two different components? May I delegate to 'plexus-interpolation' or should the same issue really be fixed in 'maven-filtering' as well? Is 'plexus-interpolation' going away? I mean: InterpolatorFilterReaderLineEnding: This implementation is

Re: Need a new version in MSHARED.

Am 11/21/16 um 22:33 schrieb Robert Scholte: > Either somebody was faster or it was already there Could be it got filtered out in the list I was looking at. It's there in the list of 'fix version'. Thanks. - To unsubscribe,

Need a new version in MSHARED.

Hi, could someone please create the next version for 'maven-filtering' in MSHARED? Should be 'maven-filtering-3.1.2'. Thanks. Regards, -- Christian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional

[CANCELLED] Re: [VOTE] Release Apache Maven Resources Plugin version 3.0.2

Am 11/19/16 um 20:58 schrieb Robert Scholte: > I noticed a comment on MRESOURCES-230[1] that the issue is actually not > fixed. > Based on this comment I think there should be a test for it, even though > the root cause is in a different project. Thanks for noticing. First release from me.

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

Am 11/20/16 um 03:28 schrieb Igor Fedorenko: > I am sorry, Christian, I must be missing something obvious. When I try > building the IT project you suggested as an expect of correct parent > version usage [1] I get the error below when using current 3.4 master. > Are you able to build the project

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

Am 11/20/16 um 02:56 schrieb Christian Schulte: > Am 11/20/16 um 00:12 schrieb Igor Fedorenko: >> Let me rephrase my question. What IT shows how to use parent version >> ranges with Maven 3.4? > > MNG-2199 > > <https://git-wip-us.apache.org/repos/asf?p=maven-integra

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

When implementing parent version ranges, I also noticed MNG-5840. I did not know what to do about it because there has been comments around stating that the version is ingored intentionally somehow. I thought it is intentional the local parent resolution is ignoring the version element and did not

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

Am 11/20/16 um 00:12 schrieb Igor Fedorenko: > Let me rephrase my question. What IT shows how to use parent version > ranges with Maven 3.4? MNG-2199

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

Am 11/19/16 um 23:57 schrieb Christian Schulte: > Am 11/19/16 um 13:35 schrieb Igor Fedorenko: >> What is parent version range syntax that works with 3.4? Or you are >> saying parent version ranges are not supported at all now? To not confuse anyone. The parent version range featu

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

Am 11/19/16 um 13:35 schrieb Igor Fedorenko: > What is parent version range syntax that works with 3.4? Or you are > saying parent version ranges are not supported at all now? They got introduced in 3.2.2. This commit

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

Am 11/19/16 um 03:58 schrieb Igor Fedorenko: > Thank you for the analysis of the IT failures, Christian. I have a few > questions/observations, if you don't mind > > MavenITmng2199ParentVersionRangeTest.testValidLocalParentVersionRange > From what I can tell, module uses parent version=[1.0,2)

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

Am 11/19/16 um 03:58 schrieb Igor Fedorenko: > Thank you for the analysis of the IT failures, Christian. I have a few > questions/observations, if you don't mind > > MavenITmng2199ParentVersionRangeTest.testValidLocalParentVersionRange > From what I can tell, module uses parent version=[1.0,2)

Re: How to disable colours?

Am 11/18/16 um 08:04 schrieb herve.bout...@free.fr: > wow, removing jansi jar file is expeditive, but for sure gives guaranteed > result :) > > Currently, there are 2 ways to disable color: > - -B option: batch mode > - -l option: log file > > (if you search for "setColorEnabled" in MavenCli,

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

How to disable colours?

Is this the only safe way to disable all kind of ANSI output? $ rm apache-maven-3.4.0-SNAPSHOT/lib/jansi-1.13.jar - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail:

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:

<    1   2   3   4   5   6   7   >