Re: Maven 3.4.0 Release

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

Regards,
-- 
Christian


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

Yes. I agree to that. It's not implemented that way in the core.
Currently they are resolved the same way as dependencies :-o . So the
core needs updating to resolve plugins the same way as projects (POMs).
If we agree to this, I'll change it.

Regards,
-- 
Christian


-
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

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


--
Regards,
Igor



On December 11, 2016 1:59:39 PM Christian Schulte  wrote:


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.


Yes. That's the POM resolution case. The plugin resolution is performed
exactly the same way dependency resolution is performed. See below. If
what you say is the intented behaviour (plugins need to be resolved the
same way as POMs) then the core needs to be updated to actually perform
the resolution that way. I am glad you are coming up with this.



Note that the project does not *depend* on the plugin. From dependency
resolution point of view, the plugin is standalone "top-level" entity at
the same level as the project.



That means plugins need to be resolved the same way as POMs. And that
means direct 'test', 'provided' and 'optional' dependencies need to be
resolved as well. Last time I updated the core to do exactly that, it
lead to issues like:




Currently only 'optional' direct dependencies are resolved. And that is
due to a bug.



Easy to spot. I'll revert the changes to 'ScopeDependencySelector' and
'OptionalDependencySelector' in a few hours locally and the tests in
'DefaultDependencyCollectorTest' need to still pass. If one of the tests
starts failing, the fix to MRESOLVER-8 is correct. There is no reason
for the two classes to behave differently. The 'ScopeDependencySelector'
handles the POM resolution vs. dependency resolution case correctly but
differently to the 'OptionalDependencySelector'. That can't be correct.
There is no way to handle plugin resolution differently than dependency
resolution. So either 'OptionalDependencySelector' behaves incorrectly
for dependency resolution of incorrectly for plugin resolution.

Maybe we'll need to update classes 'ScopeDependencySelector' and
'OptionalDependencySelector' to make the mode of operation (transitive
vs. direct) a property we can set from the core to make plugin
resolution behave the same way it did before the fix (filtering out
direct 'test' and 'provided' dependencies but not direct 'optional'
dependencies to make that IT lacking any kind of meaningful - why? -
description pass). Let's see.

Regards,
--
Christian


-
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

Review Request: Download Dependencies in parallel (MRESOLVER-7)

[Harald Wellmann]

There's a pull request waiting for review by resolver experts:

https://github.com/apache/maven-resolver/pull/2
https://issues.apache.org/jira/browse/MRESOLVER-7

This is a recap of a PR I originally submitted last year, which has been 
pending while Aether move from Eclipse to ASF was in progress.


I adapted it to the current version in November. In the meantime, some 
more conflicting changes have occurred on master.


It would be great if someone who knows Resolver inside out could comment 
on the PR in this stage, before starting another rework.


Thanks,
Harald

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

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

[Christian Schulte]

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

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

[Christian Schulte]

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)

[Christian Schulte]

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
org.eclipse.aether:aether-spi
org.eclipse.aether:aether-impl


Am 12/11/16 um 23:37 schrieb schu...@apache.org:
> http://git-wip-us.apache.org/repos/asf/maven/blob/58554032/maven-core/src/main/resources/META-INF/maven/extension.xml
> --
> diff --git a/maven-core/src/main/resources/META-INF/maven/extension.xml 
> b/maven-core/src/main/resources/META-INF/maven/extension.xml
> index eaa807b..55e0096 100644
> --- a/maven-core/src/main/resources/META-INF/maven/extension.xml
> +++ b/maven-core/src/main/resources/META-INF/maven/extension.xml
> @@ -54,7 +54,7 @@ under the License.
>  org.apache.maven.wagon.repository
>  org.apache.maven.wagon.resource
>  
> -
> +
>  org.eclipse.aether.*
>  org.eclipse.aether.artifact
>  org.eclipse.aether.collection
> @@ -134,7 +134,7 @@ under the License.
>  org.sonatype.sisu:sisu-inject-plexus
>  
> org.eclipse.sisu:org.eclipse.sisu.plexus
>  org.apache.maven:maven-artifact
> -
> org.apache.maven:maven-aether-provider
> +
> org.apache.maven:maven-resolver-provider
>  
> org.apache.maven:maven-artifact-manager
>  org.apache.maven:maven-compat
>  org.apache.maven:maven-core
> @@ -154,9 +154,9 @@ under the License.
>  
> org.apache.maven:maven-settings-builder
>  org.apache.maven:maven-toolchain
>  
> org.apache.maven.wagon:wagon-provider-api
> -org.eclipse.aether:aether-api
> -org.eclipse.aether:aether-spi
> -org.eclipse.aether:aether-impl
> +
> org.apache.maven.resolver:maven-resolver-api
> +
> org.apache.maven.resolver:maven-resolver-spi
> +
> org.apache.maven.resolver:maven-resolver-impl
>  
>  javax.inject:javax.inject
>  javax.annotation:jsr250-api
> @@ -169,6 +169,9 @@ under the License.
>  org.sonatype.aether:aether-api
>  org.sonatype.aether:aether-spi
>  org.sonatype.aether:aether-impl
> +org.eclipse.aether:aether-api
> +org.eclipse.aether:aether-spi
> +org.eclipse.aether:aether-impl
>  
>  

Re: Maven 3.4.0 Release

[Christian Schulte]

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 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.
>>
>> 
>>
>> Also part of:
>>
>> 
>>
>> This was lacking test cases badly. I am the author of the corresponding
>> test cases in the resolver. A few months later I had to correct those
>> tests to match the 1.0.x behaviour exactly.
>>
>> 
>>
>> That IT would need to be updated to no longer run with Maven 3.4+ and a
>> new one needs to be created in parallel running with 3.4+, IMHO. The
>> bugfix also has an impact on how 'test' scope dependencies are resolved.
>> In short: If the scope of a transitive dependency is managed to 'test'
>> that dependency will no longer be resolved as the test scope is not
>> transitive.
> 
> I just ran ITs with current master, only one IT fails:
> 
> ---
> Tests run: 797, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 
> 1,306.697 sec <<< FAILURE! - in org.apache.maven.it.IntegrationTestSuite
> testit(org.apache.maven.it.MavenITmng4347ImportScopeWithSettingsProfilesTest) 
>   Time elapsed: 1.174 sec  <<< ERROR!
> org.apache.maven.it.VerificationException: Exit code was non-zero: 1; 
> command line and log =
> D:\Entwicklung\Programme\apache-maven-3.4.0-SNAPSHOT\bin\..\bin\mvn 
> --global-settings 
> D:\Entwicklung\Projekte\maven-integration-testing\core-it-suite\target\test-classes\settings.xml
>  
> -s settings.xml -e --batch-mode 
> -Dmaven.repo.local=C:\Users\mosipov\.m2\repository validate
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building consumer 1
> [INFO] 
> 
> [INFO] Downloading: 
> file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-4347/remote-repository/org/apache/maven/it/mng4347/dep-with-import/1/dep-with-import-1.pom
> [INFO] Downloaded: 
> file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-4347/remote-repository/org/apache/maven/it/mng4347/dep-with-import/1/dep-with-import-1.pom
>  
> (1.7 kB at 109 kB/s)
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 0.181 s
> [INFO] Finished at: 2016-12-11T22:37:08+01:00
> [INFO] Final Memory: 8M/241M
> [INFO] 
> 
> [ERROR] Failed to execute goal on project consumer: Could not resolve 
> dependencies for project org.apache.maven.it.mng4347:consumer:jar:1: 
> Failed to collect dependencies at 
> org.apache.maven.it.mng4347:dep-with-import:jar:1: Failed to read 
> artifact descriptor for 
> org.apache.maven.it.mng4347:dep-with-import:jar:1: Could not find 
> artifact org.apache.maven.it.mng4347:import-dep:pom:1-SNAPSHOT -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to 
> execute goal on project consumer: Could not resolve dependencies for 
> project org.apache.maven.it.mng4347:consumer:jar:1: Failed to collect 
> dependencies at org.apache.maven.it.mng4347:dep-with-import:jar:1
>   at 
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:249)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:145)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:247)
> ...
> Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Could 
> not find artifact org.apache.maven.it.mng4347:import-dep:pom:1-SNAPSHOT
>   at 
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:412)
>   ... 42 more
> 
> Michael
> 
> 
> -
> 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

[Michael Osipov]

Am 2016-12-10 um 16:06 schrieb Christian Schulte:

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.



Also part of:



This was lacking test cases badly. I am the author of the corresponding
test cases in the resolver. A few months later I had to correct those
tests to match the 1.0.x behaviour exactly.



That IT would need to be updated to no longer run with Maven 3.4+ and a
new one needs to be created in parallel running with 3.4+, IMHO. The
bugfix also has an impact on how 'test' scope dependencies are resolved.
In short: If the scope of a transitive dependency is managed to 'test'
that dependency will no longer be resolved as the test scope is not
transitive.


I just ran ITs with current master, only one IT fails:

---
Tests run: 797, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 
1,306.697 sec <<< FAILURE! - in org.apache.maven.it.IntegrationTestSuite
testit(org.apache.maven.it.MavenITmng4347ImportScopeWithSettingsProfilesTest) 
 Time elapsed: 1.174 sec  <<< ERROR!
org.apache.maven.it.VerificationException: Exit code was non-zero: 1; 
command line and log =
D:\Entwicklung\Programme\apache-maven-3.4.0-SNAPSHOT\bin\..\bin\mvn 
--global-settings 
D:\Entwicklung\Projekte\maven-integration-testing\core-it-suite\target\test-classes\settings.xml 
-s settings.xml -e --batch-mode 
-Dmaven.repo.local=C:\Users\mosipov\.m2\repository validate

[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO]
[INFO] 


[INFO] Building consumer 1
[INFO] 

[INFO] Downloading: 
file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-4347/remote-repository/org/apache/maven/it/mng4347/dep-with-import/1/dep-with-import-1.pom
[INFO] Downloaded: 
file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-4347/remote-repository/org/apache/maven/it/mng4347/dep-with-import/1/dep-with-import-1.pom 
(1.7 kB at 109 kB/s)
[INFO] 


[INFO] BUILD FAILURE
[INFO] 


[INFO] Total time: 0.181 s
[INFO] Finished at: 2016-12-11T22:37:08+01:00
[INFO] Final Memory: 8M/241M
[INFO] 

[ERROR] Failed to execute goal on project consumer: Could not resolve 
dependencies for project org.apache.maven.it.mng4347:consumer:jar:1: 
Failed to collect dependencies at 
org.apache.maven.it.mng4347:dep-with-import:jar:1: Failed to read 
artifact descriptor for 
org.apache.maven.it.mng4347:dep-with-import:jar:1: Could not find 
artifact org.apache.maven.it.mng4347:import-dep:pom:1-SNAPSHOT -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to 
execute goal on project consumer: Could not resolve dependencies for 
project org.apache.maven.it.mng4347:consumer:jar:1: Failed to collect 
dependencies at org.apache.maven.it.mng4347:dep-with-import:jar:1
	at 
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:249)
	at 
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:145)
	at 
org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:247)

...
Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Could 
not find artifact org.apache.maven.it.mng4347:import-dep:pom:1-SNAPSHOT
	at 
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:412)

... 42 more

Michael


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

[HEADS UP] Releasing maven-wagon-2.11

[Dan Tran]

Hi

I am planning to stage maven-wagon-2.11  tomorrow night US Pacific time.
Let me know if you need me to wait

Thanks

-Dan

Re: Maven 3.4.0 Release

[Christian Schulte]

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.

Yes. That's the POM resolution case. The plugin resolution is performed
exactly the same way dependency resolution is performed. See below. If
what you say is the intented behaviour (plugins need to be resolved the
same way as POMs) then the core needs to be updated to actually perform
the resolution that way. I am glad you are coming up with this.

> 
> Note that the project does not *depend* on the plugin. From dependency
> resolution point of view, the plugin is standalone "top-level" entity at
> the same level as the project.
> 

That means plugins need to be resolved the same way as POMs. And that
means direct 'test', 'provided' and 'optional' dependencies need to be
resolved as well. Last time I updated the core to do exactly that, it
lead to issues like:




Currently only 'optional' direct dependencies are resolved. And that is
due to a bug.



Easy to spot. I'll revert the changes to 'ScopeDependencySelector' and
'OptionalDependencySelector' in a few hours locally and the tests in
'DefaultDependencyCollectorTest' need to still pass. If one of the tests
starts failing, the fix to MRESOLVER-8 is correct. There is no reason
for the two classes to behave differently. The 'ScopeDependencySelector'
handles the POM resolution vs. dependency resolution case correctly but
differently to the 'OptionalDependencySelector'. That can't be correct.
There is no way to handle plugin resolution differently than dependency
resolution. So either 'OptionalDependencySelector' behaves incorrectly
for dependency resolution of incorrectly for plugin resolution.

Maybe we'll need to update classes 'ScopeDependencySelector' and
'OptionalDependencySelector' to make the mode of operation (transitive
vs. direct) a property we can set from the core to make plugin
resolution behave the same way it did before the fix (filtering out
direct 'test' and 'provided' dependencies but not direct 'optional'
dependencies to make that IT lacking any kind of meaningful - why? -
description pass). Let's see.

Regards,
-- 
Christian


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

[GitHub] maven-surefire issue #114: Parallel runner should not drop away runners that...

[Tibor17]

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/114
  
@Fuud 
You mean this PR does not pass on Win or the master origin?
Please see our Jenkins on Windows. It passed 
https://builds.apache.org/job/maven-surefire-windows


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: [SUREFIRE] Bring more order in the integration tests project?

[Tibor Digana]

I agree since it helps improving the code clarity but currently I cannot do
it because I am preparing a new release and several commits are pending.

On Sat, Dec 10, 2016 at 8:08 PM, Benedikt Ritter [via Maven] <
ml-node+s40175n5888093...@n5.nabble.com> wrote:

> Hello,
>
> at the moment the integration test project has a directory containing
> almost all integration tests. The Jira issue related tests are located in
> a
> sub package. The test/resources directory contains all the test projects
> with no further ordering. This makes it hard to navigate through the
> project.
> I propose to bring more order to the integration test project, by grouping
> tests into sub packages (e.g. junit, testng, concurrent, ...). Further
> more
> the structure should be reflected in the src/test/resources directory so
> it
> becomes easier to find related test projects.
>
> Thoughts?
> Benedikt
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/SUREFIRE-Bring-more-order-
> in-the-integration-tests-project-tp5888093.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166...@n5.nabble.com
> To unsubscribe from Maven Developers, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://maven.40175.n5.nabble.com/Re-SUREFIRE-Bring-more-order-in-the-integration-tests-project-tp5888173.html
Sent from the Maven Developers mailing list archive at Nabble.com.