Re: Commits 02795b21e753bdd4eddd7e9ebee9f50315bc0e24 and 3681fd8489cd59d0c5bc49ef38725b655d524301

[Christian Schulte]

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
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 3.4.0 Release

[Christian Schulte]

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 resolved the same way as  projects.
> 
> Master does it that way now. I may need to revert an update to an IT
> tomorrow. Let's see. Please note that direct 'test' and 'provided'
> dependencies of a plugin are now resolved and can lead to different
> resolution results as before where they have not been resolved. So the
> conflict resolver sees them now and may decide differently. The issues I
> ran into this were all bugs in plugin POMs. Someone added 'commons-lang'
> as a 'test' dependency to a plugin although that dependency was a
> transitive dependency in 'compile' scope already, for example. That
> 'commons-lang' will now disappear completely from the plugin's classpath
> because it will be resolved (nearest wins) and then later get filtered
> out. You may need to tun Maven with -X and diff the resolution trees
> from the debug messages when running into problems.
> 

I solved things like this like: Remove all 'test' and 'provided'
dependencies from a plugin's POM so they do not override any transitive
dependency from another scope and then verify no transitive dependency
gets resolved which was in the POM before.



-
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

[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 resolved the same way as  projects.

Master does it that way now. I may need to revert an update to an IT
tomorrow. Let's see. Please note that direct 'test' and 'provided'
dependencies of a plugin are now resolved and can lead to different
resolution results as before where they have not been resolved. So the
conflict resolver sees them now and may decide differently. The issues I
ran into this were all bugs in plugin POMs. Someone added 'commons-lang'
as a 'test' dependency to a plugin although that dependency was a
transitive dependency in 'compile' scope already, for example. That
'commons-lang' will now disappear completely from the plugin's classpath
because it will be resolved (nearest wins) and then later get filtered
out. You may need to tun Maven with -X and diff the resolution trees
from the debug messages when running into problems.

Regards,
-- 
Christian


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

Improving Jenkins

[Christian Schulte]

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' folder. We cannot run a
post-build 'clean' execution. This would throw away the build result
after a successfull build so that no-one could download anything of that
build result. Does someone know how to make Jenkins correctly handle
module renames? Issue is the old module folder is lying around on every
build node and the workspace needs to be deleted manually on every build
node. That's one of the reasons Jenkins is sending out failure notices
for the 'maven-3.x' and related build jobs since a few days. Can we do
something about it? If not, just delete the workspace whenever such a
build failure gets reported until all build nodes caught up.

Regards,
-- 
Christian

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

Re: Commits 02795b21e753bdd4eddd7e9ebee9f50315bc0e24 and 3681fd8489cd59d0c5bc49ef38725b655d524301

[Christian Schulte]

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 which say Severity errOn31 =
>>> getSeverity( request, ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_3_1 );
>>> must be turned into Severity errOn34 = getSeverity( request,
>>> ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_3_4 ); because 3_1 has never
>>> been enforced starting with 3.1.
>>>
>>> Christian, can you have a look and cleanup accordingly?
>>
>> Seems this had been planned to be done in Maven 3.1 during development
>> of Maven 3.0 but then has never been done. I just kept the constants
>> that way. We could update all of that to 3.4 so you never see any
>> reference to 3.1 anymore. Is it that what you find confusion or is it
>> the error you would like to be kept a warning?
> 
> The former, the warning to error tranformation is fine though.
> Leave 31 as is and introduce 34 and update all referencing code 
> accordingly. This will avoid confusion if someone searches through the 
> source code.
> 

Ok. Will do that.


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

Re: Commits 02795b21e753bdd4eddd7e9ebee9f50315bc0e24 and 3681fd8489cd59d0c5bc49ef38725b655d524301

[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 which say Severity errOn31 =
getSeverity( request, ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_3_1 );
must be turned into Severity errOn34 = getSeverity( request,
ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_3_4 ); because 3_1 has never
been enforced starting with 3.1.

Christian, can you have a look and cleanup accordingly?


Seems this had been planned to be done in Maven 3.1 during development
of Maven 3.0 but then has never been done. I just kept the constants
that way. We could update all of that to 3.4 so you never see any
reference to 3.1 anymore. Is it that what you find confusion or is it
the error you would like to be kept a warning?


The former, the warning to error tranformation is fine though.
Leave 31 as is and introduce 34 and update all referencing code 
accordingly. This will avoid confusion if someone searches through the 
source code.


Michael


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

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

[Christian Schulte]

Am 12/16/16 um 20:30 schrieb Robert Scholte:
> On Fri, 16 Dec 2016 17:25:16 +0100, Christian Schulte   
> wrote:
> 
>> 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 unexpected behavior.
>>
>> Just add 'test' scope to the hamcrest dependency in that pom. It will
>> disappear from the classpath. I would expect that to happen. Why should
>> it manage the version but not the scope?
>>
> 
> Because Junit refers to hamcrest classes, so they are required to be able  
> to compile.
> There is an issue about this, that Maven should never reduce the scope. 

It's not Maven reducing any scope, it's the user telling Maven to do
that. The user is the dependency manager, not Maven.

> Suppose the user wasn't aware that hamcrest is a runtime requirement of  
> JUnit and simply adds it for his own test there as test-scoped dependency  
> you will have a surprising effect.
> I am of course aware that (currently) a dependency can only have one  
> version and one scope. However, I would love to go for a different  
> approach: choose one or more scopes and select all their matching  
> dependencies + transitive dependencies. Reflecting this to your example  
> hamcrest would always be selected as transitive dependency of junit and  
> its scope will be ignored.
> This matches much better the real world expected behavior no matter what  
> the Maven documentation says.

The following is status quo:

The core (model builder) uses the dependency management as a source of
default values it will copy to all dependencies lacking the
corresponding elements. The resolver uses the dependency management
passed to it as a source of effective values it will apply just like a
global override.

Prior 3.4, the dependency collection process looked like:

1. Request to resolve a dependency.
2. Query the repository system session's 'DependencySelector' to see if
the dependency should be selected.
3. Override everything of that dependency with any requested management.
4. Do everything else (transformations and conflict resolution) with
that managed state.

In 3.4, the dependency collection process now looks like:

1. Request to resolve a dependency.
2. Override everything of that dependency with any requested management.
3. Query the repository system session's 'DependencySelector' to see if
the dependency should be selected.
4. Do everything else (transformations and conflict resolution) with
that managed state.

It just calls the 'DependencySelector' with the managed state the same
way it performs everything else with the managed state. The dependency
selector in use happens to be setup to exclude "test", "provided" and
"optional" transitive dependencies. Why is that correct? If the
"DependencySelector" decides a "runtime" scoped dependency is to be
selected and the very next step makes it a "test" scoped dependency,
that dependency influences everything else in an unexpected way. The
conflict resolver may decide to keep that managed "test" scope
dependency over another node although that other node is what users
would have expected to be collected. So what we now have on master is
just behaving consistently with itself. The pom and the description from
that mail is the example for the release notes, BTW.

> Btw, this looks very close to
> https://issues.apache.org/jira/browse/MNG-6058

MNG-6058 cannot be solved with model version 4.0.0.

Regards,
-- 
Christian


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

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

[Robert Scholte]

On Fri, 16 Dec 2016 17:25:16 +0100, Christian Schulte   
wrote:



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


Just add 'test' scope to the hamcrest dependency in that pom. It will
disappear from the classpath. I would expect that to happen. Why should
it manage the version but not the scope?



Because Junit refers to hamcrest classes, so they are required to be able  
to compile.
There is an issue about this, that Maven should never reduce the scope.  
Suppose the user wasn't aware that hamcrest is a runtime requirement of  
JUnit and simply adds it for his own test there as test-scoped dependency  
you will have a surprising effect.
I am of course aware that (currently) a dependency can only have one  
version and one scope. However, I would love to go for a different  
approach: choose one or more scopes and select all their matching  
dependencies + transitive dependencies. Reflecting this to your example  
hamcrest would always be selected as transitive dependency of junit and  
its scope will be ignored.
This matches much better the real world expected behavior no matter what  
the Maven documentation says.


Btw, this looks very close to  
https://issues.apache.org/jira/browse/MNG-6058


Robert



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


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

Re: Commits 02795b21e753bdd4eddd7e9ebee9f50315bc0e24 and 3681fd8489cd59d0c5bc49ef38725b655d524301

[Christian Schulte]

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

[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 which say Severity errOn31 = 
> getSeverity( request, ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_3_1 ); 
> must be turned into Severity errOn34 = getSeverity( request, 
> ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_3_4 ); because 3_1 has never 
> been enforced starting with 3.1.
> 
> Christian, can you have a look and cleanup accordingly?

Seems this had been planned to be done in Maven 3.1 during development
of Maven 3.0 but then has never been done. I just kept the constants
that way. We could update all of that to 3.4 so you never see any
reference to 3.1 anymore. Is it that what you find confusion or is it
the error you would like to be kept a warning?


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

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

[Christian Schulte]

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 dependency THEN that dependency is not added to the classpath. That is  
>> still unexpected behavior.
> 
> Just add 'test' scope to the hamcrest dependency in that pom. 

I am referring to the pom of my email. Just test with 'compile',
'runtime', 'test' and 'provided' scope in the management and repeat that
with the 'optional' flag set to 'true' (mvn -X dependency:tree). For the
'test' and 'provided' scopes it is correct the dependency disappears.
For 'compile' and 'runtime' scopes it is correct the dependency is
resolved in 'runtime' and 'compile' scope. With 'optional' set to 'true'
it is correct the dependency disappears. That's exactly the behaviour
you could observe if all of this would have been declared directly with
the dependency (without using any management). Dependency management in
3.4 makes the managed dependencies resolved the same way they would get
resolved with all of what is done via the management would have been
done directly on the dependencies without any management in use. Compare
that to < 3.4.



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

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

[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 dependency THEN that dependency is not added to the classpath. That is  
> still unexpected behavior.

Just add 'test' scope to the hamcrest dependency in that pom. It will
disappear from the classpath. I would expect that to happen. Why should
it manage the version but not the scope?


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

[ANN] Apache Maven Dependency Plugin 3.0.0 Released

[Robert Scholte]

The Apache Maven team is pleased to announce the release of the Apache
Maven Dependency Plugin, version 3.0.0

The dependency plugin provides the capability to manipulate artifacts. It
can copy and/or unpack artifacts from local or remote repositories to a
specified location.

https://maven.apache.org/plugins/maven-dependency-plugin/

You should specify the version in your project's plugin configuration:


org.apache.maven.plugins
maven-dependency-plugin
3.0.0


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-dependency-plugin/download.cgi


Release Notes - Maven Dependency Plugin - Version 3.0.0

** Bug
  * [MDEP-410] - Add dependency:collect goal which prints the  
dependency

list by resolving the POMs only
  * [MDEP-436] - German umlauts in outputDirectory and destFileName
getting garbled
  * [MDEP-478] - dependency:copy-dependencies always overwrites if
 is true
  * [MDEP-483] - NullPointerException when using classifier and markers
  * [MDEP-486] - Upgrade plexus-utils to 3.0.22
  * [MDEP-506] - NPE in AnalyzeDepMgt.getMismatch
  * [MDEP-531] - MDP 2.10 depends on a known insecure library
commons-collections:3.2.1
  * [MDEP-543] - Remove link to non-existing Codehaus wiki

** Documentation
  * [MDEP-546] - Update project information on plugin site

** Improvement
  * [MDEP-487] - Documentation cleanup
  * [MDEP-493] - Change Maven prerequisite and JDK requirement
  * [MDEP-494] - Remove/replace Maven2 specific code
  * [MDEP-495] - Remove deprecated parameters
  * [MDEP-511] - Upgrade maven-common-artifact-filters to 3.0.0
  * [MDEP-512] - Removed unused dependency to maven-invoker component.
  * [MDEP-517] - Upgrade plexus-archiver from 2.9 to 3.0.3
  * [MDEP-527] - Upgrade of 'plexus-archiver' to version 3.3.
  * [MDEP-530] - Upgrade mrm to 1.0.0
  * [MDEP-537] - Goal purge-local-repository requires a Maven project,
even with manualIncludes
  * [MDEP-538] - Display moduleName
  * [MDEP-539] - Upgrade maven-shared-components parent to version 30

** New Feature
  * [MDEP-509] - dependency:tree and :list should reveal 'optional'
  * [MDEP-514] - Add support for tar.snappy compression

** Task
  * [MDEP-529] - Upgrade of plexus-archiver to 3.4.
  * [MDEP-544] - Upgrade of plexus-interpolation to 1.24.

Enjoy,

-The Apache Maven team

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

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

[Robert Scholte]

On Thu, 15 Dec 2016 23:39:50 +0100, Christian Schulte   
wrote:



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:
.
You'll see it declares a dependency on hamcrest-core in version 1.3.
Here is a pom managing that version to 1.1.


http://maven.apache.org/POM/4.0.0;
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
  4.0.0
  localhost
  test
  1.0-SNAPSHOT
  jar
  

  
org.hamcrest
hamcrest-core
1.1
  

  
  

  junit
  junit
  4.12

  


Run mvn -X dependency:tree on that pom. You'll see that the version of
the transitive dependency of junit will have been managed to what I put
into that pom. That's exactly what I would expect to happen.

[INFO] localhost:test:jar:1.0-SNAPSHOT
[INFO] \- junit:junit:jar:4.12:compile
[INFO]\- org.hamcrest:hamcrest-core:jar:1.1:compile (version managed
from 1.3)




this is indeed expected behaviour: You are using classes from junit, not  
from hamcrest-core; you want a different version from hamcrest-core, so  
dependencyManagement is the place to specify it.


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


Robert



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


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

[RESULT] [VOTE] Release Apache Maven Dependency Plugin version 3.0.0

[Robert Scholte]

Hi,

The vote has passed with the following result:

+1 : Anders Hammar, Hervé BOUTEMY, Olivier Lamy, Robert Scholte

PMC quorum: reached

I will promote the artifacts to the central repo.

On Mon, 12 Dec 2016 23:20:56 +0100, Robert Scholte   
wrote:



Hi,

We solved 25 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317227=12330458=Text

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317227%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1312
https://repository.apache.org/content/repositories/maven-1312/org/apache/maven/plugins/maven-dependency-plugin/3.0.0/maven-dependency-plugin-3.0.0-source-release.zip

Source release checksum(s):
maven-dependency-plugin-3.0.0-source-release.zip sha1:  
094af75c62c7d36fc7de5dcac5d4589312495362


Staging site:
https://maven.apache.org/plugins-archives/maven-dependency-plugin-LATEST/

Notes:
- from now on this plugin will require Maven3 to run
- When running the list-goal with Java9 a new feature is exposed: the  
artifact coordinate is extended with the module name, marked with (auto)  
if it is an automatic module.


Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1

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


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

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

[Robert Scholte]

+1

On Mon, 12 Dec 2016 23:20:56 +0100, Robert Scholte   
wrote:



Hi,

We solved 25 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317227=12330458=Text

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317227%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1312
https://repository.apache.org/content/repositories/maven-1312/org/apache/maven/plugins/maven-dependency-plugin/3.0.0/maven-dependency-plugin-3.0.0-source-release.zip

Source release checksum(s):
maven-dependency-plugin-3.0.0-source-release.zip sha1:  
094af75c62c7d36fc7de5dcac5d4589312495362


Staging site:
https://maven.apache.org/plugins-archives/maven-dependency-plugin-LATEST/

Notes:
- from now on this plugin will require Maven3 to run
- When running the list-goal with Java9 a new feature is exposed: the  
artifact coordinate is extended with the module name, marked with (auto)  
if it is an automatic module.


Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1

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


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