[jira] [Created] (MSHARED-911) Replace AntClassLoader by RootLoader
Slawomir Jaranowski created MSHARED-911:
---
Summary: Replace AntClassLoader by RootLoader
Key: MSHARED-911
URL: https://issues.apache.org/jira/browse/MSHARED-911
Project: Maven Shared Components
Issue Type: Improvement
Components: maven-script-interpreter
Reporter: Slawomir Jaranowski
I hope we can replace {{org.apache.tools.ant.AntClassLoader}} by
{{org.codehaus.groovy.tools.RootLoader}}.
After it we cen remove dependency to ant - unless ant is required in runtime by
something else, but this probably will be detected in tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MSHARED-910) Redundant option failOnException
Slawomir Jaranowski created MSHARED-910:
---
Summary: Redundant option failOnException
Key: MSHARED-910
URL: https://issues.apache.org/jira/browse/MSHARED-910
Project: Maven Shared Components
Issue Type: Improvement
Components: maven-script-interpreter
Reporter: Slawomir Jaranowski
In code of {{ScriptRunner}} we have:
{code:java}
if ( failOnException )
{
throw new RunFailureException( "The " + scriptDescription + " did not
succeed. " + msg, stage );
}
else
{
throw new RunErrorException( "The " + scriptDescription + " did not
succeed. " + msg, stage, t );
}
{code}
This cause to only throw different exception, but in client code we should
catch exception regardless of this option.
I think that this complicate code of this class and code on client with process
many exceptions.
My proposition:
- remove option {{failOnException}}
- remove exceptions: {{RunFailureException}} and {{RunErrorException}}
- throw by methods run, executeRun - {{ScriptEvaluationException}}
I can do it - after your approval.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOLVER-114) ArtifactNotFoundExceptions when building in parallel
[
https://issues.apache.org/jira/browse/MRESOLVER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120646#comment-17120646
]
Michael Osipov commented on MRESOLVER-114:
--
[~rreich], you analysis sounds reasonable. Can you tell which of these is
fauly:
https://github.com/apache/maven-resolver/blob/8d2c3752af1b724ea224bd7006ca9ab911db3a87/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java#L412-L416
or
https://github.com/apache/maven-resolver/blob/8d2c3752af1b724ea224bd7006ca9ab911db3a87/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java#L263-L267.
I don't fully understand the transition fron 4 to 5. If the nothing has to be
downloaded and the idem is availabe via {{LOCAL_PATH}} how can it fail then?
Why does the artifact not contain a file?
> ArtifactNotFoundExceptions when building in parallel
>
>
> Key: MRESOLVER-114
> URL: https://issues.apache.org/jira/browse/MRESOLVER-114
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.4.2
>Reporter: Rainer Reich
>Priority: Major
> Attachments: maven-debug-log.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have a multi-module project with quite many modules and many dependencies
> and observe pretty random {{ArtifactNotFoundExceptions}} when building in
> parallel with an empty local repository.
> The "funny" thing is that Maven did in fact download the jar that it
> complained about not finding.
> In this example Maven said it could not find
> {{edu.tum.cs:cup-runtime:jar:11a}} (see stacktrace below)
> But it also said: {{Downloaded from central-mirror:
> [https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar]}}.
> When looking into the local repository after the failed build we found the
> cup-runtime.jar in the correct place with the correct checksum.
> We tried the following to "fix" the problem:
> * build with and without the takari extensions ({{takari-local-repository}}
> & {{takari-smart-builder}}) using {{--builder smart}}
> * also build with {{io.takari.aether:aether-connector-okhttp}} extension
> * only execute goal package instead of install
> * build with these properties: {{-Daether.connector.basic.threads=1
> -Daether.connector.resumeDownloads=false}}
> But nothing helped.
> Unfortunately it seems to be a race condition and we cannot reproduce it
> consistently but it happens in about 1 out of 5 builds.
> {code:java}
> ...
> [2019-11-18T16:46:29.370Z] [INFO] Downloaded from central-mirror:
> https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar
> (13 kB at 738 kB/s)
> ...
> [2019-11-18T16:46:30.894Z] [ERROR] Failed to execute goal on project xy:
> Could not resolve dependencies for project xy: The following artifacts could
> not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> -> [Help 1]
> [2019-11-18T16:46:30.894Z]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project xy: Could not resolve dependencies for project xy: The
> following artifacts could not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl.buildProject
> (SmartBuilderImpl.java:205)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run
>
[jira] [Updated] (MRESOLVER-96) Dependency Injection fails after upgrading to Maven 3.6.2
[
https://issues.apache.org/jira/browse/MRESOLVER-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MRESOLVER-96:
Fix Version/s: (was: waiting-for-feedback)
> Dependency Injection fails after upgrading to Maven 3.6.2
> -
>
> Key: MRESOLVER-96
> URL: https://issues.apache.org/jira/browse/MRESOLVER-96
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.4.1
>Reporter: Marek Neumann
>Priority: Minor
>
> When using Maven Resolver 1.4.1 in combination with Maven 3.6.2 (also 3.6.3)
> we face the following errors when we bootstrap our application:
> {code:java}
> Exception in thread "main" com.google.inject.CreationException: Unable to
> create injector, see the following errors:1) No implementation for
> org.apache.maven.model.composition.DependencyManagementImporter was bound.
> while locating
> org.apache.maven.model.composition.DependencyManagementImporter
> for field at
> org.apache.maven.model.building.DefaultModelBuilder.dependencyManagementImporter(DefaultModelBuilder.java:207)
> at
> org.apache.maven.repository.internal.MavenResolverModule.configure(MavenResolverModule.java:58)
> (via modules: build.development.boot.Bootstrap$ResolverModule ->
> org.apache.maven.repository.internal.MavenResolverModule)2) No implementation
> for org.apache.maven.model.management.DependencyManagementInjector was bound.
> while locating
> org.apache.maven.model.management.DependencyManagementInjector
> for field at
> org.apache.maven.model.building.DefaultModelBuilder.dependencyManagementInjector(DefaultModelBuilder.java:213)
> at
> org.apache.maven.repository.internal.MavenResolverModule.configure(MavenResolverModule.java:58)
> (via modules: build.development.boot.Bootstrap$ResolverModule ->
> org.apache.maven.repository.internal.MavenResolverModule)
> ...
> 17 errors
> at
> com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:470)
> at
> com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:155)
> at
> com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107)
> at com.google.inject.Guice.createInjector(Guice.java:99)
> at com.google.inject.Guice.createInjector(Guice.java:73)
> at com.google.inject.Guice.createInjector(Guice.java:62){code}
> The relevant code part is:
> {code:java}
> Guice.createInjector(new
> ResolverModule()).getInstance(RepositorySystem.class);
> static class ResolverModule extends AbstractModule {
> @Override
> protected void configure() {
> install(new MavenResolverModule());
>
> bind(RepositoryConnectorFactory.class).annotatedWith(Names.named("basic")).to(BasicRepositoryConnectorFactory.class);
>
> bind(TransporterFactory.class).annotatedWith(Names.named("file")).to(FileTransporterFactory.class);
>
> bind(TransporterFactory.class).annotatedWith(Names.named("http")).to(HttpTransporterFactory.class);
> }
> @Provides
> @Singleton
> Set
> provideRepositoryConnectorFactories(@Named("basic")
> RepositoryConnectorFactory basic) {
> Set factories = new HashSet<>();
> factories.add(basic);
> return Collections.unmodifiableSet(factories);
> }
> @Provides
> @Singleton
> Set provideTransporterFactories(@Named("file")
> TransporterFactory file, @Named("http") TransporterFactory http) {
> Set factories = new HashSet<>();
> factories.add(file);
> factories.add(http);
> return Collections.unmodifiableSet(factories);
> }
> } {code}
> This works with either maven-resolver-provider 3.6.0 or downgrading all
> org.apache.maven.resolver artifacts to 1.3.1.
> It seems as if a similar problem occurred in Idea when setting used Maven
> version to 3.6.2:
> [https://youtrack.jetbrains.com/issue/IDEA-221882]
> Is this a regression introduced in one of the recent maven-resolver versions?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOLVER-96) Dependency Injection fails after upgrading to Maven 3.6.2
[
https://issues.apache.org/jira/browse/MRESOLVER-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120641#comment-17120641
]
Michael Osipov commented on MRESOLVER-96:
-
[~slachiewicz], thanks see the error now. I have no idea how this can be fixed.
Never used Guice directly.
> Dependency Injection fails after upgrading to Maven 3.6.2
> -
>
> Key: MRESOLVER-96
> URL: https://issues.apache.org/jira/browse/MRESOLVER-96
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.4.1
>Reporter: Marek Neumann
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> When using Maven Resolver 1.4.1 in combination with Maven 3.6.2 (also 3.6.3)
> we face the following errors when we bootstrap our application:
> {code:java}
> Exception in thread "main" com.google.inject.CreationException: Unable to
> create injector, see the following errors:1) No implementation for
> org.apache.maven.model.composition.DependencyManagementImporter was bound.
> while locating
> org.apache.maven.model.composition.DependencyManagementImporter
> for field at
> org.apache.maven.model.building.DefaultModelBuilder.dependencyManagementImporter(DefaultModelBuilder.java:207)
> at
> org.apache.maven.repository.internal.MavenResolverModule.configure(MavenResolverModule.java:58)
> (via modules: build.development.boot.Bootstrap$ResolverModule ->
> org.apache.maven.repository.internal.MavenResolverModule)2) No implementation
> for org.apache.maven.model.management.DependencyManagementInjector was bound.
> while locating
> org.apache.maven.model.management.DependencyManagementInjector
> for field at
> org.apache.maven.model.building.DefaultModelBuilder.dependencyManagementInjector(DefaultModelBuilder.java:213)
> at
> org.apache.maven.repository.internal.MavenResolverModule.configure(MavenResolverModule.java:58)
> (via modules: build.development.boot.Bootstrap$ResolverModule ->
> org.apache.maven.repository.internal.MavenResolverModule)
> ...
> 17 errors
> at
> com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:470)
> at
> com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:155)
> at
> com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107)
> at com.google.inject.Guice.createInjector(Guice.java:99)
> at com.google.inject.Guice.createInjector(Guice.java:73)
> at com.google.inject.Guice.createInjector(Guice.java:62){code}
> The relevant code part is:
> {code:java}
> Guice.createInjector(new
> ResolverModule()).getInstance(RepositorySystem.class);
> static class ResolverModule extends AbstractModule {
> @Override
> protected void configure() {
> install(new MavenResolverModule());
>
> bind(RepositoryConnectorFactory.class).annotatedWith(Names.named("basic")).to(BasicRepositoryConnectorFactory.class);
>
> bind(TransporterFactory.class).annotatedWith(Names.named("file")).to(FileTransporterFactory.class);
>
> bind(TransporterFactory.class).annotatedWith(Names.named("http")).to(HttpTransporterFactory.class);
> }
> @Provides
> @Singleton
> Set
> provideRepositoryConnectorFactories(@Named("basic")
> RepositoryConnectorFactory basic) {
> Set factories = new HashSet<>();
> factories.add(basic);
> return Collections.unmodifiableSet(factories);
> }
> @Provides
> @Singleton
> Set provideTransporterFactories(@Named("file")
> TransporterFactory file, @Named("http") TransporterFactory http) {
> Set factories = new HashSet<>();
> factories.add(file);
> factories.add(http);
> return Collections.unmodifiableSet(factories);
> }
> } {code}
> This works with either maven-resolver-provider 3.6.0 or downgrading all
> org.apache.maven.resolver artifacts to 1.3.1.
> It seems as if a similar problem occurred in Idea when setting used Maven
> version to 3.6.2:
> [https://youtrack.jetbrains.com/issue/IDEA-221882]
> Is this a regression introduced in one of the recent maven-resolver versions?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-resolver] michael-o opened a new pull request #52: [MRESOLVER-56] Support SHA-256 and SHA-512 as checksums
michael-o opened a new pull request #52: URL: https://github.com/apache/maven-resolver/pull/52 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-96) Dependency Injection fails after upgrading to Maven 3.6.2
[
https://issues.apache.org/jira/browse/MRESOLVER-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120638#comment-17120638
]
Sylwester Lachiewicz commented on MRESOLVER-96:
---
In org.apache.maven.resolver.examples.util.Booter#newRepositorySystem please
uncomment _GuiceRepositorySystemFactory_ and run one of examples from
_maven-resolver-demo-snippets_
> Dependency Injection fails after upgrading to Maven 3.6.2
> -
>
> Key: MRESOLVER-96
> URL: https://issues.apache.org/jira/browse/MRESOLVER-96
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.4.1
>Reporter: Marek Neumann
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> When using Maven Resolver 1.4.1 in combination with Maven 3.6.2 (also 3.6.3)
> we face the following errors when we bootstrap our application:
> {code:java}
> Exception in thread "main" com.google.inject.CreationException: Unable to
> create injector, see the following errors:1) No implementation for
> org.apache.maven.model.composition.DependencyManagementImporter was bound.
> while locating
> org.apache.maven.model.composition.DependencyManagementImporter
> for field at
> org.apache.maven.model.building.DefaultModelBuilder.dependencyManagementImporter(DefaultModelBuilder.java:207)
> at
> org.apache.maven.repository.internal.MavenResolverModule.configure(MavenResolverModule.java:58)
> (via modules: build.development.boot.Bootstrap$ResolverModule ->
> org.apache.maven.repository.internal.MavenResolverModule)2) No implementation
> for org.apache.maven.model.management.DependencyManagementInjector was bound.
> while locating
> org.apache.maven.model.management.DependencyManagementInjector
> for field at
> org.apache.maven.model.building.DefaultModelBuilder.dependencyManagementInjector(DefaultModelBuilder.java:213)
> at
> org.apache.maven.repository.internal.MavenResolverModule.configure(MavenResolverModule.java:58)
> (via modules: build.development.boot.Bootstrap$ResolverModule ->
> org.apache.maven.repository.internal.MavenResolverModule)
> ...
> 17 errors
> at
> com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:470)
> at
> com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:155)
> at
> com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107)
> at com.google.inject.Guice.createInjector(Guice.java:99)
> at com.google.inject.Guice.createInjector(Guice.java:73)
> at com.google.inject.Guice.createInjector(Guice.java:62){code}
> The relevant code part is:
> {code:java}
> Guice.createInjector(new
> ResolverModule()).getInstance(RepositorySystem.class);
> static class ResolverModule extends AbstractModule {
> @Override
> protected void configure() {
> install(new MavenResolverModule());
>
> bind(RepositoryConnectorFactory.class).annotatedWith(Names.named("basic")).to(BasicRepositoryConnectorFactory.class);
>
> bind(TransporterFactory.class).annotatedWith(Names.named("file")).to(FileTransporterFactory.class);
>
> bind(TransporterFactory.class).annotatedWith(Names.named("http")).to(HttpTransporterFactory.class);
> }
> @Provides
> @Singleton
> Set
> provideRepositoryConnectorFactories(@Named("basic")
> RepositoryConnectorFactory basic) {
> Set factories = new HashSet<>();
> factories.add(basic);
> return Collections.unmodifiableSet(factories);
> }
> @Provides
> @Singleton
> Set provideTransporterFactories(@Named("file")
> TransporterFactory file, @Named("http") TransporterFactory http) {
> Set factories = new HashSet<>();
> factories.add(file);
> factories.add(http);
> return Collections.unmodifiableSet(factories);
> }
> } {code}
> This works with either maven-resolver-provider 3.6.0 or downgrading all
> org.apache.maven.resolver artifacts to 1.3.1.
> It seems as if a similar problem occurred in Idea when setting used Maven
> version to 3.6.2:
> [https://youtrack.jetbrains.com/issue/IDEA-221882]
> Is this a regression introduced in one of the recent maven-resolver versions?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MNG-6930) Cannot use lambda as argument in a method in Mojo
Abel Salgado Romero created MNG-6930:
Summary: Cannot use lambda as argument in a method in Mojo
Key: MNG-6930
URL: https://issues.apache.org/jira/browse/MNG-6930
Project: Maven
Issue Type: Bug
Components: Plugin API
Affects Versions: 3.6.0
Reporter: Abel Salgado Romero
I have a plugin with uses a component that receives a lambda as argument.
When passing any lamba, for example the following empty one
{code:java}
Optional sourceDir = new SourceDirectoryLocator(sourceDirectory,
project.getBasedir(), file -> {})
.find();
{code}
`maven-plugin-plugin` fails with the error:
{code:java}
[ERROR] Failed to execute goal
org.codehaus.plexus:plexus-component-metadata:1.5.5:generate-metadata (default)
on project asciidoctor-maven-plugin: Error generating metadata: : Failed to
extract descriptors: Index 9578 out of bounds for length 999 -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.codehaus.plexus:plexus-component-metadata:1.5.5:generate-metadata (default)
on project asciidoctor-maven-plugin: Error generating metadata:
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:215)
{code}
Passing `null` or an anonymous class like shown below works however.
{code:java}
Optional sourceDir = new SourceDirectoryLocator(sourceDirectory,
project.getBasedir(),
new Consumer() {
@Override
public void accept(File file) {
getLog().info("sourceDirectory " + file + " does not exist");
}
})
.find();
{code}
Also tested with the current SNAPSHOT and the issue still happens
Here is the code to reprodude:
[https://github.com/abelsromero/asciidoctor-maven-plugin/tree/maven-plugin-plugin-lambda-issue]
. Just run `mvn clean test-compile` to see the error.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOLVER-96) Dependency Injection fails after upgrading to Maven 3.6.2
[
https://issues.apache.org/jira/browse/MRESOLVER-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120623#comment-17120623
]
Michael Osipov commented on MRESOLVER-96:
-
[~slachiewicz], I have updated {{mavenVersion}} in the mentioned POM and cannot
reproduce this case. Can someone tell me how to reproduce properly?
> Dependency Injection fails after upgrading to Maven 3.6.2
> -
>
> Key: MRESOLVER-96
> URL: https://issues.apache.org/jira/browse/MRESOLVER-96
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.4.1
>Reporter: Marek Neumann
>Priority: Minor
>
> When using Maven Resolver 1.4.1 in combination with Maven 3.6.2 (also 3.6.3)
> we face the following errors when we bootstrap our application:
> {code:java}
> Exception in thread "main" com.google.inject.CreationException: Unable to
> create injector, see the following errors:1) No implementation for
> org.apache.maven.model.composition.DependencyManagementImporter was bound.
> while locating
> org.apache.maven.model.composition.DependencyManagementImporter
> for field at
> org.apache.maven.model.building.DefaultModelBuilder.dependencyManagementImporter(DefaultModelBuilder.java:207)
> at
> org.apache.maven.repository.internal.MavenResolverModule.configure(MavenResolverModule.java:58)
> (via modules: build.development.boot.Bootstrap$ResolverModule ->
> org.apache.maven.repository.internal.MavenResolverModule)2) No implementation
> for org.apache.maven.model.management.DependencyManagementInjector was bound.
> while locating
> org.apache.maven.model.management.DependencyManagementInjector
> for field at
> org.apache.maven.model.building.DefaultModelBuilder.dependencyManagementInjector(DefaultModelBuilder.java:213)
> at
> org.apache.maven.repository.internal.MavenResolverModule.configure(MavenResolverModule.java:58)
> (via modules: build.development.boot.Bootstrap$ResolverModule ->
> org.apache.maven.repository.internal.MavenResolverModule)
> ...
> 17 errors
> at
> com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:470)
> at
> com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:155)
> at
> com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107)
> at com.google.inject.Guice.createInjector(Guice.java:99)
> at com.google.inject.Guice.createInjector(Guice.java:73)
> at com.google.inject.Guice.createInjector(Guice.java:62){code}
> The relevant code part is:
> {code:java}
> Guice.createInjector(new
> ResolverModule()).getInstance(RepositorySystem.class);
> static class ResolverModule extends AbstractModule {
> @Override
> protected void configure() {
> install(new MavenResolverModule());
>
> bind(RepositoryConnectorFactory.class).annotatedWith(Names.named("basic")).to(BasicRepositoryConnectorFactory.class);
>
> bind(TransporterFactory.class).annotatedWith(Names.named("file")).to(FileTransporterFactory.class);
>
> bind(TransporterFactory.class).annotatedWith(Names.named("http")).to(HttpTransporterFactory.class);
> }
> @Provides
> @Singleton
> Set
> provideRepositoryConnectorFactories(@Named("basic")
> RepositoryConnectorFactory basic) {
> Set factories = new HashSet<>();
> factories.add(basic);
> return Collections.unmodifiableSet(factories);
> }
> @Provides
> @Singleton
> Set provideTransporterFactories(@Named("file")
> TransporterFactory file, @Named("http") TransporterFactory http) {
> Set factories = new HashSet<>();
> factories.add(file);
> factories.add(http);
> return Collections.unmodifiableSet(factories);
> }
> } {code}
> This works with either maven-resolver-provider 3.6.0 or downgrading all
> org.apache.maven.resolver artifacts to 1.3.1.
> It seems as if a similar problem occurred in Idea when setting used Maven
> version to 3.6.2:
> [https://youtrack.jetbrains.com/issue/IDEA-221882]
> Is this a regression introduced in one of the recent maven-resolver versions?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MRESOLVER-96) Dependency Injection fails after upgrading to Maven 3.6.2
[
https://issues.apache.org/jira/browse/MRESOLVER-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MRESOLVER-96:
Fix Version/s: waiting-for-feedback
> Dependency Injection fails after upgrading to Maven 3.6.2
> -
>
> Key: MRESOLVER-96
> URL: https://issues.apache.org/jira/browse/MRESOLVER-96
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.4.1
>Reporter: Marek Neumann
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> When using Maven Resolver 1.4.1 in combination with Maven 3.6.2 (also 3.6.3)
> we face the following errors when we bootstrap our application:
> {code:java}
> Exception in thread "main" com.google.inject.CreationException: Unable to
> create injector, see the following errors:1) No implementation for
> org.apache.maven.model.composition.DependencyManagementImporter was bound.
> while locating
> org.apache.maven.model.composition.DependencyManagementImporter
> for field at
> org.apache.maven.model.building.DefaultModelBuilder.dependencyManagementImporter(DefaultModelBuilder.java:207)
> at
> org.apache.maven.repository.internal.MavenResolverModule.configure(MavenResolverModule.java:58)
> (via modules: build.development.boot.Bootstrap$ResolverModule ->
> org.apache.maven.repository.internal.MavenResolverModule)2) No implementation
> for org.apache.maven.model.management.DependencyManagementInjector was bound.
> while locating
> org.apache.maven.model.management.DependencyManagementInjector
> for field at
> org.apache.maven.model.building.DefaultModelBuilder.dependencyManagementInjector(DefaultModelBuilder.java:213)
> at
> org.apache.maven.repository.internal.MavenResolverModule.configure(MavenResolverModule.java:58)
> (via modules: build.development.boot.Bootstrap$ResolverModule ->
> org.apache.maven.repository.internal.MavenResolverModule)
> ...
> 17 errors
> at
> com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:470)
> at
> com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:155)
> at
> com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107)
> at com.google.inject.Guice.createInjector(Guice.java:99)
> at com.google.inject.Guice.createInjector(Guice.java:73)
> at com.google.inject.Guice.createInjector(Guice.java:62){code}
> The relevant code part is:
> {code:java}
> Guice.createInjector(new
> ResolverModule()).getInstance(RepositorySystem.class);
> static class ResolverModule extends AbstractModule {
> @Override
> protected void configure() {
> install(new MavenResolverModule());
>
> bind(RepositoryConnectorFactory.class).annotatedWith(Names.named("basic")).to(BasicRepositoryConnectorFactory.class);
>
> bind(TransporterFactory.class).annotatedWith(Names.named("file")).to(FileTransporterFactory.class);
>
> bind(TransporterFactory.class).annotatedWith(Names.named("http")).to(HttpTransporterFactory.class);
> }
> @Provides
> @Singleton
> Set
> provideRepositoryConnectorFactories(@Named("basic")
> RepositoryConnectorFactory basic) {
> Set factories = new HashSet<>();
> factories.add(basic);
> return Collections.unmodifiableSet(factories);
> }
> @Provides
> @Singleton
> Set provideTransporterFactories(@Named("file")
> TransporterFactory file, @Named("http") TransporterFactory http) {
> Set factories = new HashSet<>();
> factories.add(file);
> factories.add(http);
> return Collections.unmodifiableSet(factories);
> }
> } {code}
> This works with either maven-resolver-provider 3.6.0 or downgrading all
> org.apache.maven.resolver artifacts to 1.3.1.
> It seems as if a similar problem occurred in Idea when setting used Maven
> version to 3.6.2:
> [https://youtrack.jetbrains.com/issue/IDEA-221882]
> Is this a regression introduced in one of the recent maven-resolver versions?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-enforcer] belingueres commented on a change in pull request #38: [MENFORCER-313] - Added [] to the conflicting artifacts in the output. Highlight those with compile scope.
belingueres commented on a change in pull request #38: URL: https://github.com/apache/maven-enforcer/pull/38#discussion_r432971928 ## File path: maven-enforcer-plugin/src/it/projects/require-upper-bound-dependencies-managed_failure/verify.groovy ## @@ -21,9 +21,9 @@ File buildLog = new File( basedir, 'build.log' ) assert buildLog.text.contains( 'Rule 0: org.apache.maven.plugins.enforcer.RequireUpperBoundDeps failed with message:' ) def message = 'Failed while enforcing RequireUpperBoundDeps. The error(s) are [' + LS+ -'Require upper bound dependencies error for org.apache.maven.plugins.enforcer.its:menforcer146-x:1.1 paths to dependency are:' + LS+ +'Require upper bound dependencies error for org.apache.maven.plugins.enforcer.its:menforcer146-x:1.1 [compile] paths to dependency are:' + LS+ Review comment: modified, rebased and squashed. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MSHARED-886) Require Java 8
[ https://issues.apache.org/jira/browse/MSHARED-886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MSHARED-886: - Fix Version/s: (was: maven-shared-jar-3.0.0) > Require Java 8 > -- > > Key: MSHARED-886 > URL: https://issues.apache.org/jira/browse/MSHARED-886 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-shared-jar >Reporter: Sylwester Lachiewicz >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MSHARED-886) Require Java 8
[ https://issues.apache.org/jira/browse/MSHARED-886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MSHARED-886: Assignee: (was: Elliotte Rusty Harold) > Require Java 8 > -- > > Key: MSHARED-886 > URL: https://issues.apache.org/jira/browse/MSHARED-886 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-shared-jar >Reporter: Sylwester Lachiewicz >Priority: Major > Fix For: maven-shared-jar-3.0.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MSHARED-887) Require Maven 3.1
[ https://issues.apache.org/jira/browse/MSHARED-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MSHARED-887: Assignee: Elliotte Rusty Harold > Require Maven 3.1 > - > > Key: MSHARED-887 > URL: https://issues.apache.org/jira/browse/MSHARED-887 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-shared-jar >Reporter: Sylwester Lachiewicz >Assignee: Elliotte Rusty Harold >Priority: Major > Fix For: maven-shared-jar-3.0.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MSHARED-886) Require Java 8
[ https://issues.apache.org/jira/browse/MSHARED-886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MSHARED-886: Assignee: Elliotte Rusty Harold > Require Java 8 > -- > > Key: MSHARED-886 > URL: https://issues.apache.org/jira/browse/MSHARED-886 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-shared-jar >Reporter: Sylwester Lachiewicz >Assignee: Elliotte Rusty Harold >Priority: Major > Fix For: maven-shared-jar-3.0.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MRESOLVER-9) DefaultDependencyCollector does not correctly handle dependency management
[
https://issues.apache.org/jira/browse/MRESOLVER-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MRESOLVER-9:
---
Component/s: resolver
> DefaultDependencyCollector does not correctly handle dependency management
> --
>
> Key: MRESOLVER-9
> URL: https://issues.apache.org/jira/browse/MRESOLVER-9
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Reporter: Christian Schulte
>Priority: Critical
> Fix For: Maven Artifact Resolver 1.2.0 pre-reset
>
>
> During dependency processing the {{DependencySelector}} is called to decide
> if a dependency is to be selected. The call to
> {{DependencySelector.selectDependency()}} is performed with the unmanaged
> dependency, but needs to be performed with the managed dependency. With the
> fix applied, the result no longer contains dependencies whose scope or
> optionality has been managed to not be part of the result (correct
> behaviour). Without the fix applied, the result contains dependencies with a
> managed scope or optionality not filtered out by the {{DependencySelector}}
> in use (incorrect behaviour).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MRESOLVER-114) ArtifactNotFoundExceptions when building in parallel
[
https://issues.apache.org/jira/browse/MRESOLVER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MRESOLVER-114:
-
Component/s: resolver
> ArtifactNotFoundExceptions when building in parallel
>
>
> Key: MRESOLVER-114
> URL: https://issues.apache.org/jira/browse/MRESOLVER-114
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.4.2
>Reporter: Rainer Reich
>Priority: Major
> Attachments: maven-debug-log.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have a multi-module project with quite many modules and many dependencies
> and observe pretty random {{ArtifactNotFoundExceptions}} when building in
> parallel with an empty local repository.
> The "funny" thing is that Maven did in fact download the jar that it
> complained about not finding.
> In this example Maven said it could not find
> {{edu.tum.cs:cup-runtime:jar:11a}} (see stacktrace below)
> But it also said: {{Downloaded from central-mirror:
> [https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar]}}.
> When looking into the local repository after the failed build we found the
> cup-runtime.jar in the correct place with the correct checksum.
> We tried the following to "fix" the problem:
> * build with and without the takari extensions ({{takari-local-repository}}
> & {{takari-smart-builder}}) using {{--builder smart}}
> * also build with {{io.takari.aether:aether-connector-okhttp}} extension
> * only execute goal package instead of install
> * build with these properties: {{-Daether.connector.basic.threads=1
> -Daether.connector.resumeDownloads=false}}
> But nothing helped.
> Unfortunately it seems to be a race condition and we cannot reproduce it
> consistently but it happens in about 1 out of 5 builds.
> {code:java}
> ...
> [2019-11-18T16:46:29.370Z] [INFO] Downloaded from central-mirror:
> https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar
> (13 kB at 738 kB/s)
> ...
> [2019-11-18T16:46:30.894Z] [ERROR] Failed to execute goal on project xy:
> Could not resolve dependencies for project xy: The following artifacts could
> not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> -> [Help 1]
> [2019-11-18T16:46:30.894Z]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project xy: Could not resolve dependencies for project xy: The
> following artifacts could not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl.buildProject
> (SmartBuilderImpl.java:205)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run
> (SmartBuilderImpl.java:77)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
> [2019-11-18T16:46:30.894Z] at java.util.concurrent.FutureTask.run
> (FutureTask.java:264)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1128)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:628)
> [2019-11-18T16:46:30.894Z] at java.lang.Thread.run (Thread.java:834)
> [2019-11-18T16:46:30.894Z] Caused by:
> org.apache.maven.project.DependencyResolutionException: Could not resolve
> dependencies for project xy: The
[jira] [Updated] (MRESOLVER-8) ScopeDependencySelector incorrectly de-selects direct dependencies
[
https://issues.apache.org/jira/browse/MRESOLVER-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MRESOLVER-8:
---
Component/s: resolver
> ScopeDependencySelector incorrectly de-selects direct dependencies
> --
>
> Key: MRESOLVER-8
> URL: https://issues.apache.org/jira/browse/MRESOLVER-8
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Reporter: Christian Schulte
>Priority: Critical
> Fix For: Maven Artifact Resolver 1.2.0 pre-reset
>
>
> The {{ScopeDependencySelector}} decides if a node is a direct dependency or
> transitive dependency differently based on the request performed. For the
> {{CollectRequest.setRootArtifact(Artifact)}} case, the class is working
> correctly. For the {{CollectRequest.setRoot(Dependency)}} case, the class is
> de-selecting direct dependencies instead of transitive dependencies.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MRESOLVER-56) Support SHA-256 and SHA-512 as checksums
[
https://issues.apache.org/jira/browse/MRESOLVER-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MRESOLVER-56:
Fix Version/s: 1.4.3
> Support SHA-256 and SHA-512 as checksums
>
>
> Key: MRESOLVER-56
> URL: https://issues.apache.org/jira/browse/MRESOLVER-56
> Project: Maven Resolver
> Issue Type: Improvement
> Components: resolver
>Affects Versions: Maven Artifact Resolver 1.1.1
>Reporter: Konrad Windszus
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.4.3
>
>
> As both supported checksums on remote repositories (namely MD5 and SHA1) have
> known flaws it would be nice if the Maven Resolver could also leverage other
> hashes like SHA256 and SHA512.
> Although those hashes aren't part of the official Maven 2 repository layout
> (https://cwiki.apache.org/confluence/display/MAVENOLD/Repository+Layout+-+Final,
> couldn't find any newer/other spec) I don't see how an additional
> {{.sha256}} or {{.sha512}} file could introduce backwards compatibility
> issues with older clients.
> I think this namely would mean you would also return SHA512 and SHA256 if
> they exist and leverage if they are supported by the JRE. The longer the hash
> the better it is, therefore the hashes should be checked in the following
> order
> # SHA512
> # SHA256
> # SHA1
> # MD5
> This would need to be considered in the API within
> https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/layout/RepositoryLayout.java#L165
> and
> https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/layout/RepositoryLayout.java#L178.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (WAGON-597) AbstractHttpClientWagon.setPersistentPool has no effect due to parameter assigned to itself
[ https://issues.apache.org/jira/browse/WAGON-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned WAGON-597: Assignee: Michael Osipov > AbstractHttpClientWagon.setPersistentPool has no effect due to parameter > assigned to itself > --- > > Key: WAGON-597 > URL: https://issues.apache.org/jira/browse/WAGON-597 > Project: Maven Wagon > Issue Type: Bug >Affects Versions: 3.4.1 >Reporter: Piotr Zygielo >Assignee: Michael Osipov >Priority: Trivial > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (WAGON-597) AbstractHttpClientWagon.setPersistentPool has no effect due to parameter assigned to itself
[ https://issues.apache.org/jira/browse/WAGON-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated WAGON-597: - Fix Version/s: 3.4.2 > AbstractHttpClientWagon.setPersistentPool has no effect due to parameter > assigned to itself > --- > > Key: WAGON-597 > URL: https://issues.apache.org/jira/browse/WAGON-597 > Project: Maven Wagon > Issue Type: Bug >Affects Versions: 3.4.1 >Reporter: Piotr Zygielo >Assignee: Michael Osipov >Priority: Trivial > Fix For: 3.4.2 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Moved] (MRESOLVER-114) ArtifactNotFoundExceptions when building in parallel
[
https://issues.apache.org/jira/browse/MRESOLVER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov moved MNG-6803 to MRESOLVER-114:
---
Key: MRESOLVER-114 (was: MNG-6803)
Affects Version/s: (was: 3.6.2)
1.4.2
Project: Maven Resolver (was: Maven)
> ArtifactNotFoundExceptions when building in parallel
>
>
> Key: MRESOLVER-114
> URL: https://issues.apache.org/jira/browse/MRESOLVER-114
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.4.2
>Reporter: Rainer Reich
>Priority: Major
> Attachments: maven-debug-log.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have a multi-module project with quite many modules and many dependencies
> and observe pretty random {{ArtifactNotFoundExceptions}} when building in
> parallel with an empty local repository.
> The "funny" thing is that Maven did in fact download the jar that it
> complained about not finding.
> In this example Maven said it could not find
> {{edu.tum.cs:cup-runtime:jar:11a}} (see stacktrace below)
> But it also said: {{Downloaded from central-mirror:
> [https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar]}}.
> When looking into the local repository after the failed build we found the
> cup-runtime.jar in the correct place with the correct checksum.
> We tried the following to "fix" the problem:
> * build with and without the takari extensions ({{takari-local-repository}}
> & {{takari-smart-builder}}) using {{--builder smart}}
> * also build with {{io.takari.aether:aether-connector-okhttp}} extension
> * only execute goal package instead of install
> * build with these properties: {{-Daether.connector.basic.threads=1
> -Daether.connector.resumeDownloads=false}}
> But nothing helped.
> Unfortunately it seems to be a race condition and we cannot reproduce it
> consistently but it happens in about 1 out of 5 builds.
> {code:java}
> ...
> [2019-11-18T16:46:29.370Z] [INFO] Downloaded from central-mirror:
> https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar
> (13 kB at 738 kB/s)
> ...
> [2019-11-18T16:46:30.894Z] [ERROR] Failed to execute goal on project xy:
> Could not resolve dependencies for project xy: The following artifacts could
> not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> -> [Help 1]
> [2019-11-18T16:46:30.894Z]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project xy: Could not resolve dependencies for project xy: The
> following artifacts could not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl.buildProject
> (SmartBuilderImpl.java:205)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run
> (SmartBuilderImpl.java:77)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
> [2019-11-18T16:46:30.894Z] at java.util.concurrent.FutureTask.run
> (FutureTask.java:264)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1128)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:628)
> [2019-11-18T16:46:30.894Z] at java.lang.Thread.run (Thread.java:834)
>
[GitHub] [maven-resolver] michael-o commented on pull request #48: [MRESOLVER-103] replace some deprecated classes
michael-o commented on pull request #48: URL: https://github.com/apache/maven-resolver/pull/48#issuecomment-636487976 Before we do this we need to verify that everything will still work outside of Maven. E.g., custom, standalone code and out Maven Resolver Ant Tasks. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] elharo commented on pull request #48: [MRESOLVER-103] replace some deprecated classes
elharo commented on pull request #48: URL: https://github.com/apache/maven-resolver/pull/48#issuecomment-636487627 I'm all in favor of removing duplicate code. There's a lot of random, reimplemented cruft throughout the plugins. Perhaps start by deprecating these packages and adding instructions for porting to wagon http? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MSHARED-906) Add GitHub Action to confirm build PR
[ https://issues.apache.org/jira/browse/MSHARED-906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MSHARED-906: -- Priority: Critical (was: Major) > Add GitHub Action to confirm build PR > - > > Key: MSHARED-906 > URL: https://issues.apache.org/jira/browse/MSHARED-906 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-script-interpreter >Reporter: Slawomir Jaranowski >Priority: Critical > > GitHub Action can confirm build PR -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MSHARED-908) Update JUnit to 4.13
[ https://issues.apache.org/jira/browse/MSHARED-908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MSHARED-908: -- Priority: Minor (was: Major) > Update JUnit to 4.13 > > > Key: MSHARED-908 > URL: https://issues.apache.org/jira/browse/MSHARED-908 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-script-interpreter >Reporter: Slawomir Jaranowski >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MSHARED-905) Set minimum Maven version to 3.1.0
[ https://issues.apache.org/jira/browse/MSHARED-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MSHARED-905. --- Resolution: Duplicate > Set minimum Maven version to 3.1.0 > -- > > Key: MSHARED-905 > URL: https://issues.apache.org/jira/browse/MSHARED-905 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-shared-jar >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-resolver] michael-o commented on pull request #48: [MRESOLVER-103] replace some deprecated classes
michael-o commented on pull request #48: URL: https://github.com/apache/maven-resolver/pull/48#issuecomment-636483786 I have been recently reviewing Resolver. To be frank the HTTP transport is basically duplicate of Wagon HTTP Provider. If it is possible to properly use Resolver with Wagon and its providers outside of Maven space and especially with Resolver Ant Tasks, I'd be included to remove this module from the next major version. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (WAGON-597) AbstractHttpClientWagon.setPersistentPool has no effect due to parameter assigned to itself
Piotr Zygielo created WAGON-597: --- Summary: AbstractHttpClientWagon.setPersistentPool has no effect due to parameter assigned to itself Key: WAGON-597 URL: https://issues.apache.org/jira/browse/WAGON-597 Project: Maven Wagon Issue Type: Bug Affects Versions: 3.4.1 Reporter: Piotr Zygielo -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-script-interpreter] michael-o edited a comment on pull request #3: [MSHARED-909] update maven-shared-utils 0.3 -> 3.2.1
michael-o edited a comment on pull request #3: URL: https://github.com/apache/maven-script-interpreter/pull/3#issuecomment-636476774 I did not even know that this one exist. I wonder where this is used at in Maven space. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-script-interpreter] michael-o commented on pull request #3: [MSHARED-909] update maven-shared-utils 0.3 -> 3.2.1
michael-o commented on pull request #3: URL: https://github.com/apache/maven-script-interpreter/pull/3#issuecomment-636476774 I did not even know that this one exist. I wonder where this is used at in Maven spacce. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-wagon] michael-o commented on pull request #68: Fix self-assignment and set class field
michael-o commented on pull request #68: URL: https://github.com/apache/maven-wagon/pull/68#issuecomment-636476370 Please create a JIRA issue. This is a long standing one I know about and always forget to fix. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MSHARED-909) Update maven-shared-utils 0.3 -> 3.2.1
Slawomir Jaranowski created MSHARED-909: --- Summary: Update maven-shared-utils 0.3 -> 3.2.1 Key: MSHARED-909 URL: https://issues.apache.org/jira/browse/MSHARED-909 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-script-interpreter Reporter: Slawomir Jaranowski -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-script-interpreter] slawekjaranowski opened a new pull request #2: [MSHARED-908] Update JUnit to 4.13
slawekjaranowski opened a new pull request #2: URL: https://github.com/apache/maven-script-interpreter/pull/2 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MSHARED-908) Update JUnit to 4.13
Slawomir Jaranowski created MSHARED-908: --- Summary: Update JUnit to 4.13 Key: MSHARED-908 URL: https://issues.apache.org/jira/browse/MSHARED-908 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-script-interpreter Reporter: Slawomir Jaranowski -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-2478) add "resources-filtered" filtered resource directories to super POM
[
https://issues.apache.org/jira/browse/MNG-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120539#comment-17120539
]
Hudson commented on MNG-2478:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #57
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/57/
> add "resources-filtered" filtered resource directories to super POM
> ---
>
> Key: MNG-2478
> URL: https://issues.apache.org/jira/browse/MNG-2478
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Affects Versions: 2.0.4
> Environment: any
>Reporter: Jörg Hohwiller
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0
>
>
> The super POM contains default folders for resources that are NOT filtered
> (src/main/resources and src/test/resources). If one (additionally) needs a
> filtered resources folder, it needs to override the default and therefore has
> to add all default folders if he does NOT want to "loose" the defaults.
> To make this easier my suggestion is to add filtered resource folders to the
> super POM. This should also fit to the philosophy of maven that aims to have
> defaults and only declare as little custom configuration as needed.
> My personal favorite for the foldernames would be "templates" but to make
> things more obvious to the user maybe "resources-filtered" would be better.
> Actually I do not care to much about the name...
> So the resources in the super POM should look like this:
> {code:xml}
>
> src/main/resources
>
>
>
> src/main/resources-filtered
> true
>
>
>
>
>
> src/test/resources
>
>
>
> src/test/resources-filtered
> true
>
>
> {code}
> Update: The folder name has been changed to "resources-filtered".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6919) maven-wrapper on windows
[ https://issues.apache.org/jira/browse/MNG-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120540#comment-17120540 ] Hudson commented on MNG-6919: - Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #57 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/57/ > maven-wrapper on windows > > > Key: MNG-6919 > URL: https://issues.apache.org/jira/browse/MNG-6919 > Project: Maven > Issue Type: Bug > Components: Bootstrap Build >Affects Versions: 3.7.0-candidate >Reporter: James Z.M. Gao >Assignee: Robert Scholte >Priority: Minor > Fix For: 3.7.0 > > > new maven-wrapper inherit 2 bugs for windows batch scripts: > # cannot read the config ".mvn\wrapper\maven-wrapper.properties" correctly > when the full path has space. > # -eof style of cmd scripts are not CRLF- (This is fixed by assembly-plugin > `lineEnding` settings) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5640) AbstractMavenLifecycleParticipant#afterSessionEnd is not invoked in some cases
[
https://issues.apache.org/jira/browse/MNG-5640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120536#comment-17120536
]
Hudson commented on MNG-5640:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #57
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/57/
> AbstractMavenLifecycleParticipant#afterSessionEnd is not invoked in some cases
> --
>
> Key: MNG-5640
> URL: https://issues.apache.org/jira/browse/MNG-5640
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.2.1
>Reporter: Tamás Cservenák
>Assignee: Jason van Zyl
>Priority: Major
> Fix For: 3.2.2
>
> Attachments: aftersessionend.zip
>
>
> It seems that {{AbstractMavenLifecycleParticipant#afterSessionEnd}} is not
> invoked in some cases, at least one case for sure: when the build fails.
> Reproduce case:
> 1. unzip the attached project
> 2. build it but skip tests {{mvn clean install -Dtest=void
> -DfailIfNoTests=false}}
> 3. install the resulting jar in /lib/ext of your Maven 3.2.1
> 4. with JAR installed in Maven, build it again with skipped tests
> 5. verify console output (both {{afterProjectsRead OK}} and {{afterSessionEnd
> OK}} are printed on console)
> 6. with JAR installed in Maven, build it again with tests (there is one UT
> that always fails).
> 6. console output contains only {{afterProjectsRead OK}}, but afterSessionEnd
> method is NOT invoked.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-2741) [regression] Meaningless error message: "Error transferring file"
[ https://issues.apache.org/jira/browse/MNG-2741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120538#comment-17120538 ] Hudson commented on MNG-2741: - Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #57 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/57/ > [regression] Meaningless error message: "Error transferring file" > - > > Key: MNG-2741 > URL: https://issues.apache.org/jira/browse/MNG-2741 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories, Errors >Affects Versions: 2.0.4 >Reporter: Graham Leggett >Assignee: Benjamin Bentmann >Priority: Major > Fix For: 3.0-beta-1 > > > When an attempt is made to resolve dependencies, the following error is > encountered: > [INFO] artifact org.apache.maven.plugins:maven-resources-plugin: checking for > updates from codehaus-mojo-snapshot-plugins > [WARNING] repository metadata for: 'artifact > org.apache.maven.plugins:maven-resources-plugin' could not be retrieved from > repository: codehaus-mojo-snapshot-plugins due to an error: Error > transferring file > [INFO] Repository 'codehaus-mojo-snapshot-plugins' will be blacklisted > Without further information, debugging this problem is impractical. > Information needed in the error message: > - Whether or not a proxy is being used, and if so, which one. (Symptoms in > this case indicate no proxy is being used, yet a proxy is configured - no way > to tell whether its a config problem or a proxy problem) > - Whether the server and/or proxy server gave an error code (4xx, 5xx), or > whether there was no response at all. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6613) Mirror matching ignores closest/nearest definition
[
https://issues.apache.org/jira/browse/MNG-6613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120535#comment-17120535
]
Hudson commented on MNG-6613:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #57
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/57/
> Mirror matching ignores closest/nearest definition
> --
>
> Key: MNG-6613
> URL: https://issues.apache.org/jira/browse/MNG-6613
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, Integration Tests
>Affects Versions: 3.5.4, 3.6.1
> Environment: Java 8u202, Java11u2
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Critical
> Attachments: log.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Ran our IT suite in a locked down environment at work, w/o direct internet
> access. IT {{mng3461MirrorMatching(itNonGreedyWildcard)}} blocks forever
> because the mirror exclude does not work: {{*,!maven-core-it}}.
> It still tries to download via mirror instead of ignoring it. See attached
> log file. Even switching {{!maven-core-it,*}} makes no difference.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-4660) Use of --resume-from in multi-module project fails with missing inter-module dependencies
[ https://issues.apache.org/jira/browse/MNG-4660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120537#comment-17120537 ] Hudson commented on MNG-4660: - Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #57 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/57/ > Use of --resume-from in multi-module project fails with missing inter-module > dependencies > - > > Key: MNG-4660 > URL: https://issues.apache.org/jira/browse/MNG-4660 > Project: Maven > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 2.2.1, 3.0-beta-1 > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700) > Java version: 1.6.0_17 > Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x" version: "10.6.3" arch: "x86_64" Family: "mac" >Reporter: Brian Ferris >Assignee: Robert Scholte >Priority: Major > Fix For: 3.7.0 > > Attachments: modules-parent.tar.gz > > Time Spent: 1h 20m > Remaining Estimate: 0h > > In a simple multi-module project with a parent pom "modules-parent", two sub > modules "module-a" and "module-b", where B depends on A, I've not been able > to get the Maven "--resume-from" feature to work. > Specifically, I expect: > > mvn --resume-from module-b test > would resume execution of the "test" goal in "module-b". Instead it fails > with a missing artifact error: > > [INFO] Failed to resolve artifact. > > > > Missing: > > -- > > 1) org.test:module-a:jar:0.0.1-SNAPSHOT > Why isn't Maven resolving the within-multi-module dependency? I've attached > a simple project that reproduces the problem with Maven 2.2.1 and Maven > 3.0-beta-1. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MINVOKER-260) Option 'streamLogs' does not work properly for logs from intepreter
[
https://issues.apache.org/jira/browse/MINVOKER-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120533#comment-17120533
]
Slawomir Jaranowski commented on MINVOKER-260:
--
This issue should be fixed in {{maven-script-interpreter}} MSHARED-907
> Option 'streamLogs' does not work properly for logs from intepreter
> ---
>
> Key: MINVOKER-260
> URL: https://issues.apache.org/jira/browse/MINVOKER-260
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.1.0, 3.2.0, 3.2.1
>Reporter: Leonid Gorshkov
>Priority: Major
> Attachments: problem.png
>
>
> Logs from script interpreter should be shown not only in build.log file.
> !problem.png!
> See [org/apache/maven/plugins/invoker/AbstractInvokerMojo#runPostBuildHook |
> https://github.com/apache/maven-invoker-plugin/blob/master/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L2176]
> and nested calls
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MSHARED-907) Output build log from script to maven mojo log
Slawomir Jaranowski created MSHARED-907:
---
Summary: Output build log from script to maven mojo log
Key: MSHARED-907
URL: https://issues.apache.org/jira/browse/MSHARED-907
Project: Maven Shared Components
Issue Type: Improvement
Components: maven-script-interpreter
Reporter: Slawomir Jaranowski
Currently only PrintStream from ExecutionLogger is propagated to interpreter.
Even we have mojo log in ExecutionLogger it is not used for logging.
In {{ScriptRunner}} we have:
{code:java}
PrintStream out = ( logger != null ) ? logger.getPrintStream() : null;
result = interpreter.evaluateScript( script, classPath, globalVariables, out );
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-script-interpreter] slawekjaranowski opened a new pull request #1: [MSHARED-906] Add GitHub Action
slawekjaranowski opened a new pull request #1: URL: https://github.com/apache/maven-script-interpreter/pull/1 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MSHARED-906) Add GitHub Action to confirm build PR
Slawomir Jaranowski created MSHARED-906: --- Summary: Add GitHub Action to confirm build PR Key: MSHARED-906 URL: https://issues.apache.org/jira/browse/MSHARED-906 Project: Maven Shared Components Issue Type: Improvement Components: maven-script-interpreter Reporter: Slawomir Jaranowski GitHub Action can confirm build PR -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MSHARED-905) Set minimum Maven version to 3.1.0
Elliotte Rusty Harold created MSHARED-905: - Summary: Set minimum Maven version to 3.1.0 Key: MSHARED-905 URL: https://issues.apache.org/jira/browse/MSHARED-905 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-shared-jar Reporter: Elliotte Rusty Harold Assignee: Elliotte Rusty Harold -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1733.
--
Resolution: Fixed
https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=ed70a5683398f5de55b958e5c8579db89dc7f594
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 3.0.0-M5
>
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:656)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1183)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1011)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:857)
> [ERROR] at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> [ERROR] at
>
[jira] [Closed] (SUREFIRE-1793) Change the Java packge of surefire-api to the distinct package org.apache.maven.surefire.api
[ https://issues.apache.org/jira/browse/SUREFIRE-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1793. -- Resolution: Fixed https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=e77054f3c7be2ba204e6d03f168463b87756be69 > Change the Java packge of surefire-api to the distinct package > org.apache.maven.surefire.api > > > Key: SUREFIRE-1793 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1793 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M5 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 merged pull request #293: [SUREFIRE-1733] Surefire and Failsafe JPMS additions for JUnit 5.x execution
Tibor17 merged pull request #293: URL: https://github.com/apache/maven-surefire/pull/293 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6882) Change the URL's in tests etc. from http to https
[ https://issues.apache.org/jira/browse/MNG-6882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120487#comment-17120487 ] Hudson commented on MNG-6882: - Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #56 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/56/ > Change the URL's in tests etc. from http to https > - > > Key: MNG-6882 > URL: https://issues.apache.org/jira/browse/MNG-6882 > Project: Maven > Issue Type: Improvement > Components: core >Affects Versions: 3.7.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.7.0 > > > Based on the given PR https://github.com/apache/maven/pull/323 it's not > enough to change the URL's in the pom files it is also necessary to change > the URL's in the tests cause they are using in assertions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6891) Improve support --fail-on-severity
[
https://issues.apache.org/jira/browse/MNG-6891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120497#comment-17120497
]
Hudson commented on MNG-6891:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #56
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/56/
> Improve support --fail-on-severity
> --
>
> Key: MNG-6891
> URL: https://issues.apache.org/jira/browse/MNG-6891
> Project: Maven
> Issue Type: Improvement
>Reporter: Robert Scholte
>Priority: Major
> Fix For: 3.7.0-candidate
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> MNG-6065 was a first implementation, but it is not user friendly enough.
> 1. When saying {{-fos}} the message is: No enum constant
> org.slf4j.event.Level.warn
> We should show at least all available values here
> 2. The prefix for warnings in Maven is [WARNING], due to
> {{org.slf4j.simpleLogger.warnLevelString}} in
> {{apache-maven/conf/logging/simplelogger.properties}}. It makes sense support
> this custom value as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6866) PluginDescriptorBuilder build method very long
[ https://issues.apache.org/jira/browse/MNG-6866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120486#comment-17120486 ] Hudson commented on MNG-6866: - Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #56 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/56/ > PluginDescriptorBuilder build method very long > -- > > Key: MNG-6866 > URL: https://issues.apache.org/jira/browse/MNG-6866 > Project: Maven > Issue Type: Improvement > Components: core >Reporter: Arne Lewinski >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > The build method of the class ""PluginDescriptorBuilder" is very long. > I suggest to extract several methods and harmonize the methodolgy to set all > values. It can follows the strict concept: extracting the necessary element > from the PlexusConfiguration and setting it on the PluginDescriptor. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-4660) Use of --resume-from in multi-module project fails with missing inter-module dependencies
[ https://issues.apache.org/jira/browse/MNG-4660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120492#comment-17120492 ] Hudson commented on MNG-4660: - Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #56 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/56/ > Use of --resume-from in multi-module project fails with missing inter-module > dependencies > - > > Key: MNG-4660 > URL: https://issues.apache.org/jira/browse/MNG-4660 > Project: Maven > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 2.2.1, 3.0-beta-1 > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700) > Java version: 1.6.0_17 > Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x" version: "10.6.3" arch: "x86_64" Family: "mac" >Reporter: Brian Ferris >Assignee: Robert Scholte >Priority: Major > Fix For: 3.7.0 > > Attachments: modules-parent.tar.gz > > Time Spent: 1h 20m > Remaining Estimate: 0h > > In a simple multi-module project with a parent pom "modules-parent", two sub > modules "module-a" and "module-b", where B depends on A, I've not been able > to get the Maven "--resume-from" feature to work. > Specifically, I expect: > > mvn --resume-from module-b test > would resume execution of the "test" goal in "module-b". Instead it fails > with a missing artifact error: > > [INFO] Failed to resolve artifact. > > > > Missing: > > -- > > 1) org.test:module-a:jar:0.0.1-SNAPSHOT > Why isn't Maven resolving the within-multi-module dependency? I've attached > a simple project that reproduces the problem with Maven 2.2.1 and Maven > 3.0-beta-1. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-2478) add "resources-filtered" filtered resource directories to super POM
[
https://issues.apache.org/jira/browse/MNG-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120496#comment-17120496
]
Hudson commented on MNG-2478:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #56
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/56/
> add "resources-filtered" filtered resource directories to super POM
> ---
>
> Key: MNG-2478
> URL: https://issues.apache.org/jira/browse/MNG-2478
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Affects Versions: 2.0.4
> Environment: any
>Reporter: Jörg Hohwiller
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0
>
>
> The super POM contains default folders for resources that are NOT filtered
> (src/main/resources and src/test/resources). If one (additionally) needs a
> filtered resources folder, it needs to override the default and therefore has
> to add all default folders if he does NOT want to "loose" the defaults.
> To make this easier my suggestion is to add filtered resource folders to the
> super POM. This should also fit to the philosophy of maven that aims to have
> defaults and only declare as little custom configuration as needed.
> My personal favorite for the foldernames would be "templates" but to make
> things more obvious to the user maybe "resources-filtered" would be better.
> Actually I do not care to much about the name...
> So the resources in the super POM should look like this:
> {code:xml}
>
> src/main/resources
>
>
>
> src/main/resources-filtered
> true
>
>
>
>
>
> src/test/resources
>
>
>
> src/test/resources-filtered
> true
>
>
> {code}
> Update: The folder name has been changed to "resources-filtered".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6863) --also-make is being ignored when calling --resume-from
[
https://issues.apache.org/jira/browse/MNG-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120493#comment-17120493
]
Hudson commented on MNG-6863:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #56
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/56/
> --also-make is being ignored when calling --resume-from
> ---
>
> Key: MNG-6863
> URL: https://issues.apache.org/jira/browse/MNG-6863
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.7.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The --resume-from is a bit broken since Maven 3. For Maven 2 it worked fine,
> because dependencies needed to exist in the local repository, hence you could
> only do this by calling {{mvn install}}.
> With Maven 3 the need for {{install}} is gone, however if you call
> --resume-from, its dependencies might be part of the multimodule project, but
> not from the reactor (these are the maven modules that are being built).
> With -am/--also-make it should include all required modules as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6873) Inconsistent library versions notice.
[ https://issues.apache.org/jira/browse/MNG-6873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120500#comment-17120500 ] Hudson commented on MNG-6873: - Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #56 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/56/ > Inconsistent library versions notice. > - > > Key: MNG-6873 > URL: https://issues.apache.org/jira/browse/MNG-6873 > Project: Maven > Issue Type: Improvement >Reporter: Kaifeng Huang >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.7.0 > > Attachments: apache maven.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > > Hi. I have implemented a tool to detect library version inconsistencies. Your > project have 1 inconsistent library and 12 false consistent libraries. > > Take junit:junit for example, this library is declared as version 3.8.1 in > maven-core/src/test/resources-project-builder/dependency-inheritance, 4.4 in > maven-core/src/test/resources-project-builder/dependency-inheritance/sub and > etc... Such version inconsistencies may cause unnecessary maintenance effort > in the long run. For example, if two modules become inter-dependent, library > version conflict may happen. It has already become a common issue and hinders > development progress. Thus a version harmonization is necessary. > > Provided we applied a version harmonization, I calculated the cost it may > have to harmonize to all upper versions including an up-to-date one. The cost > refers to POM config changes and API invocation changes. Take junit:junit for > example, if we harmonize all the library versions into 4.4. The concern is, > how much should the project code adapt to the newer library version. We list > an effort table to quantify the harmonization cost. > > The effort table shows the overall harmonization cost on APIs. It seems your > project have no API invokes on this library, which could be safely upgrade to > 4.4 > ||Index||Module||NA(NAC)||NDA(NDAC)||NMA(NMAC)|| > |1|maven-core/src/test/resources-project-builder/dependency-inheritance|0(0)|0(0)|0(0)| > |2|maven-core/src/test/resources-project-builder/dependency-inheritance/sub|0(0)|0(0)|0(0)| > > Also we provided another table to show the potential files that may be > affected due to library API change, which could help to spot the concerned > API usage and rerun the test cases. > As for false consistency, take junit junit jar for example. The library is > declared in version 4.13 in all modules. However they are declared > differently. As components are developed in parallel, if one single library > version is updated, which could become inconsistent as mentioned above, may > cause above-mentioned inconsistency issues > If you are interested, you can have a more complete and detailed report in > the attached PDF file. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6867) extract methods, apply SLA DefaultMavenPluginManager
[ https://issues.apache.org/jira/browse/MNG-6867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120489#comment-17120489 ] Hudson commented on MNG-6867: - Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #56 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/56/ > extract methods, apply SLA DefaultMavenPluginManager > > > Key: MNG-6867 > URL: https://issues.apache.org/jira/browse/MNG-6867 > Project: Maven > Issue Type: Improvement > Components: core >Reporter: Arne Lewinski >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Apply "extract method" refactoring to make methods smaller. Considering > principle "single level of abstraction". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6856) Remove dependency to Powermock
[ https://issues.apache.org/jira/browse/MNG-6856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120498#comment-17120498 ] Hudson commented on MNG-6856: - Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #56 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/56/ > Remove dependency to Powermock > -- > > Key: MNG-6856 > URL: https://issues.apache.org/jira/browse/MNG-6856 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Trivial > Fix For: 3.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > > We use Powermock only in one set of tests, in a class > `StringSearchModelInterpolator` that is no longer used in Maven Core -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6672) Upgrade Maven Resolver to 1.4.2
[ https://issues.apache.org/jira/browse/MNG-6672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120495#comment-17120495 ] Hudson commented on MNG-6672: - Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #56 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/56/ > Upgrade Maven Resolver to 1.4.2 > --- > > Key: MNG-6672 > URL: https://issues.apache.org/jira/browse/MNG-6672 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Affects Versions: 3.6.1 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.7.0 > > > Release Notes - Maven Resolver - Version 1.4.0 > * Bug > [MRESOLVER-86] - ResolveArtifactMojo from resolver example uses plugin > repositories to resolve dependencies > * New Feature > [MRESOLVER-10] - New 'TransitiveDependencyManager' supporting transitive > dependency management > [MRESOLVER-33] - New 'DefaultDependencyManager' managing dependencies on all > levels supporting transitive dependency management > * Improvement > [MRESOLVER-7] - Download dependency POMs in parallel > [MRESOLVER-84] - Add support for "release" qualifier > [MRESOLVER-87] - Refresh examples to use maven-resolver artifacts for demo > [MRESOLVER-88] - Code style cleanup to use Java 7 features > Release Notes - Maven Resolver - Version 1.4.1 > * Task > [MRESOLVER-92] - Revert MRESOLVER-7 > Release Notes - Maven Resolver - Version 1.4.2 > * Improvement > [MRESOLVER-93] - PathRecordingDependencyVisitor to handle 3 cycles > [MRESOLVER-102] - make build Reproducible -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6819) NullPointerException for DefaultArtifactDescriptorReader.loadPom
[
https://issues.apache.org/jira/browse/MNG-6819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120503#comment-17120503
]
Hudson commented on MNG-6819:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #56
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/56/
> NullPointerException for DefaultArtifactDescriptorReader.loadPom
>
>
> Key: MNG-6819
> URL: https://issues.apache.org/jira/browse/MNG-6819
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.6.2, 3.6.3
>Reporter: Darcy Shen
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.7.0
>
>
> Here is a clue to reproduce the NPE.
> {code:xml}
>
> maven-antrun-plugin
>
>
> package
>
>
>
> src="${project.build.directory}/${project.build.finalName}.${project.packaging}"
> dest="${project.build.directory}/xxx" />
>
>
>
> run
>
>
>
>
> {code}
> project.build.finalName is the previous value, and the interpolated value is
> null.
> {noformat}
> $ mvn clean compile -e # on a private project
> [ERROR] NullPointerException
> java.lang.NullPointerException
> at java.util.Hashtable$Entry.setValue (Hashtable.java:1286)
> at
> org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit
> (StringVisitorModelInterpolator.java:1429)
> at
> org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit
> (StringVisitorModelInterpolator.java:1027)
> at
> org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit
> (StringVisitorModelInterpolator.java:170)
> at
> org.apache.maven.model.interpolation.StringVisitorModelInterpolator.interpolateModel
> (StringVisitorModelInterpolator.java:107)
> at org.apache.maven.model.building.DefaultModelBuilder.interpolateModel
> (DefaultModelBuilder.java:789)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:393)
> at
> org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom
> (DefaultArtifactDescriptorReader.java:292)
> at
> org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor
> (DefaultArtifactDescriptorReader.java:171)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.resolveCachedArtifactDescriptor
> (DefaultDependencyCollector.java:541)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.getArtifactDescriptorResult
> (DefaultDependencyCollector.java:524)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:412)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:365)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
> (DefaultDependencyCollector.java:352)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse
> (DefaultDependencyCollector.java:509)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:461)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:365)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
> (DefaultDependencyCollector.java:352)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse
> (DefaultDependencyCollector.java:509)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:461)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:365)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
> (DefaultDependencyCollector.java:352)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse
> (DefaultDependencyCollector.java:509)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:461)
> at
>
[jira] [Commented] (MNG-6900) Upgrade Jansi to 1.18
[ https://issues.apache.org/jira/browse/MNG-6900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120504#comment-17120504 ] Hudson commented on MNG-6900: - Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #56 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/56/ > Upgrade Jansi to 1.18 > - > > Key: MNG-6900 > URL: https://issues.apache.org/jira/browse/MNG-6900 > Project: Maven > Issue Type: Dependency upgrade >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.7.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5577) Convert the core to use JSR 330 and remove the use of Plexus
[ https://issues.apache.org/jira/browse/MNG-5577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120488#comment-17120488 ] Hudson commented on MNG-5577: - Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #56 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/56/ > Convert the core to use JSR 330 and remove the use of Plexus > > > Key: MNG-5577 > URL: https://issues.apache.org/jira/browse/MNG-5577 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Jason van Zyl >Priority: Major > Fix For: 3.7.x-candidate > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Remove the use of Plexus annotations and use JSR330 annotations throughout > the core. > *NOTE:* The descriptor must still be generated, since Maven doesn't do > annotation scanning for performance reason. It simply reads the descriptor > file(s). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6914) Align mvn and mvnw scripts
[ https://issues.apache.org/jira/browse/MNG-6914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120502#comment-17120502 ] Hudson commented on MNG-6914: - Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #56 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/56/ > Align mvn and mvnw scripts > -- > > Key: MNG-6914 > URL: https://issues.apache.org/jira/browse/MNG-6914 > Project: Maven > Issue Type: Improvement >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Major > Fix For: 3.7.0 > > > With MNG-5937 the wrapper code becomes part of core. > The scripts are like 80% the same, 10% is wrapper specific and 10% are > differences due to improvements on one or the other side. > By aligning the scripts they both benefit from the improvements. > Some important changes that might but should not effect the build: > - CLASSWORLDS_LAUNCHER / WRAPPER_LAUNCHER will be renamed to MAVEN_LAUNCHER > - CLASSWORLDS_JAR / WRAPPER_JAR will be renamed to LAUNCHER_JAR > - Introduce MAVENHOME_CONFIG. For the wrapper it will be empty (as the > wrapper must download the Maven first), maven will use it to set > classworlds.conf, maven.home and library.jansi.path -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6919) maven-wrapper on windows
[ https://issues.apache.org/jira/browse/MNG-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120505#comment-17120505 ] Hudson commented on MNG-6919: - Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #56 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/56/ > maven-wrapper on windows > > > Key: MNG-6919 > URL: https://issues.apache.org/jira/browse/MNG-6919 > Project: Maven > Issue Type: Bug > Components: Bootstrap Build >Affects Versions: 3.7.0-candidate >Reporter: James Z.M. Gao >Assignee: Robert Scholte >Priority: Minor > Fix For: 3.7.0 > > > new maven-wrapper inherit 2 bugs for windows batch scripts: > # cannot read the config ".mvn\wrapper\maven-wrapper.properties" correctly > when the full path has space. > # -eof style of cmd scripts are not CRLF- (This is fixed by assembly-plugin > `lineEnding` settings) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6884) Cleanup POM File after version upgrade
[ https://issues.apache.org/jira/browse/MNG-6884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120490#comment-17120490 ] Hudson commented on MNG-6884: - Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #56 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/56/ > Cleanup POM File after version upgrade > -- > > Key: MNG-6884 > URL: https://issues.apache.org/jira/browse/MNG-6884 > Project: Maven > Issue Type: Task >Affects Versions: 3.7.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.7.0 > > > Remove the entries in pom file which are mentioned by the TODO: > * maven-source-plugin > * maven-jar-plugin > * maven-assembly-plugin > they are handled by the parent. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5937) Maven-Wrapper for unified project environments (analog the Gradle wrapper)
[ https://issues.apache.org/jira/browse/MNG-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120501#comment-17120501 ] Hudson commented on MNG-5937: - Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #56 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/56/ > Maven-Wrapper for unified project environments (analog the Gradle wrapper) > -- > > Key: MNG-5937 > URL: https://issues.apache.org/jira/browse/MNG-5937 > Project: Maven > Issue Type: Improvement > Components: Command Line >Reporter: Robert Weiser >Assignee: Robert Scholte >Priority: Major > Fix For: 3.7.0 > > > It would be nice to provide a wrapper for maven which behaves similarily to > the wrapper Gradle has. This would allow projects to share Maven in a certain > version along with some project-specific Maven options like for example the > location of the user or the global settings files or the maximum java heap > size to use. > There already are projects on github (e.g.: > https://github.com/takari/maven-wrapper) providing said feature, however it > would be nice to have it developed and maintained by the very people > providing us with the offical Maven release. > Cheers, Robert -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6897) Upgrade Maven Wagon to 3.4.0
[ https://issues.apache.org/jira/browse/MNG-6897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120494#comment-17120494 ] Hudson commented on MNG-6897: - Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #56 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/56/ > Upgrade Maven Wagon to 3.4.0 > > > Key: MNG-6897 > URL: https://issues.apache.org/jira/browse/MNG-6897 > Project: Maven > Issue Type: Dependency upgrade > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.7.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6886) Upgrade plexus-cipher 1.8
[ https://issues.apache.org/jira/browse/MNG-6886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120491#comment-17120491 ] Hudson commented on MNG-6886: - Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #56 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/56/ > Upgrade plexus-cipher 1.8 > - > > Key: MNG-6886 > URL: https://issues.apache.org/jira/browse/MNG-6886 > Project: Maven > Issue Type: Bug > Components: Dependencies >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6893) Update plugin versions in super POM (api 3.0)
[ https://issues.apache.org/jira/browse/MNG-6893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120499#comment-17120499 ] Hudson commented on MNG-6893: - Build unstable in Jenkins: Maven TLP » maven » MNG-6656 #56 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/56/ > Update plugin versions in super POM (api 3.0) > - > > Key: MNG-6893 > URL: https://issues.apache.org/jira/browse/MNG-6893 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Priority: Major > Fix For: 3.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Update plugins in maven-model-builder pom-4.0.0.xml > * maven-ant-run from 1.3 to 3.0.0 (/) > * maven-assembly-plugin from 2.2-beta-5 to XXX > * maven-dependency-plugin from 2.8 to XXX > * maven-dependency-plugin from 2.5.3 to XXX -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSITE-788) Remove menu items link in the side bar to sub module that do not generate any site in the same build.
[ https://issues.apache.org/jira/browse/MSITE-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120483#comment-17120483 ] Elliotte Rusty Harold commented on MSITE-788: - Nikolas, I agree with you. Sorry if that wasn't clear. I was objecting to the addition of a configuration option to control this behavior. There should be no need to configure anything. This should just work. > Remove menu items link in the side bar to sub module that do not generate any > site in the same build. > - > > Key: MSITE-788 > URL: https://issues.apache.org/jira/browse/MSITE-788 > Project: Maven Site Plugin > Issue Type: Bug > Components: site:run >Affects Versions: 3.6 > Environment: Windows7, Maven 3.3.9 >Reporter: Nikolas Falco >Priority: Major > > We have some multi-module projects where a few modules are only for scope > distribution or for integration test. > These modules are marked with maven.site.skip=true and the site is not > generated, but in the maven site of parent project they appear in the sidebar > menu, clearly if you click on those links are broken. > Debugging the code, the mojo loop on each project in the reactor build and > add as menu item. > Is possible add a configuration element of maven-site-plugin to exclude some > modules from the modules report menu? or implement a check if a site for that > project exists? > org.example > |- module1 > |- module2 > |- module.test (skip generation) > |- distribution (skip generation) > the maven site of org.example have in the menu bar links to no available site > of distribution and module.test -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSITE-788) Remove menu items link in the side bar to sub module that do not generate any site in the same build.
[ https://issues.apache.org/jira/browse/MSITE-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120481#comment-17120481 ] Nikolas Falco commented on MSITE-788: - > Just don't include the 404 links. This mean customize the index menu file every time I add or remove a module. I was asking to do not create a link for skipped modules > Remove menu items link in the side bar to sub module that do not generate any > site in the same build. > - > > Key: MSITE-788 > URL: https://issues.apache.org/jira/browse/MSITE-788 > Project: Maven Site Plugin > Issue Type: Bug > Components: site:run >Affects Versions: 3.6 > Environment: Windows7, Maven 3.3.9 >Reporter: Nikolas Falco >Priority: Major > > We have some multi-module projects where a few modules are only for scope > distribution or for integration test. > These modules are marked with maven.site.skip=true and the site is not > generated, but in the maven site of parent project they appear in the sidebar > menu, clearly if you click on those links are broken. > Debugging the code, the mojo loop on each project in the reactor build and > add as menu item. > Is possible add a configuration element of maven-site-plugin to exclude some > modules from the modules report menu? or implement a check if a site for that > project exists? > org.example > |- module1 > |- module2 > |- module.test (skip generation) > |- distribution (skip generation) > the maven site of org.example have in the menu bar links to no available site > of distribution and module.test -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNGSITE-412) Add Reposilite to the list of available repository managers
[ https://issues.apache.org/jira/browse/MNGSITE-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120467#comment-17120467 ] Hudson commented on MNGSITE-412: Build succeeded in Jenkins: Maven TLP » maven-site » master #305 See https://builds.apache.org/job/maven-box/job/maven-site/job/master/305/ > Add Reposilite to the list of available repository managers > --- > > Key: MNGSITE-412 > URL: https://issues.apache.org/jira/browse/MNGSITE-412 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: dzikoysk >Assignee: Michael Osipov >Priority: Minor > > Reposilite repository: https://github.com/dzikoysk/reposilite > Motivation: Project is active for 3 years now and it is a good solution for > developers hosting their projects at low cost. > At this moment, people are forced to use huge ecosystems like Nexus or > Artifactory. I think it might be a good idea to show an alternative. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-wagon] pzygielo opened a new pull request #68: Fix self-assignment and set class field
pzygielo opened a new pull request #68: URL: https://github.com/apache/maven-wagon/pull/68 @olamy - may I ask for review, please? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MCOMPILER-418) NPE when --patch-module is used in non-modular Project
[
https://issues.apache.org/jira/browse/MCOMPILER-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120459#comment-17120459
]
Robert Scholte commented on MCOMPILER-418:
--
The first question that comes to my mind: should we allow passing
{{--patch-module}} as a separate argument? My first response would be 'no', as
it looks more like a workaround than fixing the root cause.
> NPE when --patch-module is used in non-modular Project
> --
>
> Key: MCOMPILER-418
> URL: https://issues.apache.org/jira/browse/MCOMPILER-418
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Stanislav Spiridonov
>Priority: Major
>
> When "--patch-module" argument with reference to jar is added to the
> compiler, the plugin always throws NullPointerException.
>
> {noformat}
> Caused by: java.lang.NullPointerException
> at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute
> (AbstractCompilerMojo.java:1051)
> at org.apache.maven.plugin.compiler.CompilerMojo.execute
> (CompilerMojo.java:187)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137) {noformat}
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
