[jira] [Commented] (MPIR-373) Upgrade from 2.9 to 3.0.0 introduces additional warning
[
https://issues.apache.org/jira/browse/MPIR-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911913#comment-16911913
]
Maxim Solodovnik commented on MPIR-373:
---
[~rfscholte] would it be possible to release this new version?
> Upgrade from 2.9 to 3.0.0 introduces additional warning
> ---
>
> Key: MPIR-373
> URL: https://issues.apache.org/jira/browse/MPIR-373
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: GWR
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.0.1
>
> Attachments: pom.xml
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> a new warning-message introduced, causing some confusion in the devteam.
> When stepping up to maven-project-info-reports-plugin:3.0.0 (from2.9) the
> stacktrace below is seen.
> mvn3.0.5, 3.3.9 and 3.5.2 all give same stacktrace.
> Seems to caused by the xml-resolver:1.2, having a pom.xml containing the
> section.
>
> {code:java}
>
> deployed
>
> {code}
> Is there some more restrictive pom validation introduced with
> maven-project-info-reports-plugin:3.0.0
> {code:java}
> $ mvn project-info-reports:dependencies
> [WARNING] Unable to create Maven project from repository for artifact
> xml-resolver:xml-resolver:jar:1.2
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs:
> [ERROR] 'distributionManagement.status' must not be specified. @ line 36,
> column 13
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:191)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:326)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository
> (RepositoryUtils.java:125)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDescriptionsAndURLs
> (DependenciesRenderer.java:890)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:847)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyTree
> (DependenciesRenderer.java:486)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionProjectDependencyGraph
> (DependenciesRenderer.java:449)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody
> (DependenciesRenderer.java:222)
> at org.apache.maven.reporting.AbstractMavenReportRenderer.render
> (AbstractMavenReportRenderer.java:80)
> at org.apache.maven.report.projectinfo.DependenciesReport.executeReport
> (DependenciesReport.java:162)
> at org.apache.maven.reporting.AbstractMavenReport.generate
> (AbstractMavenReport.java:251)
> at org.apache.maven.report.projectinfo.AbstractProjectInfoReport.execute
> (AbstractProjectInfoReport.java:220)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
> at
[GitHub] [maven-resolver] suztomo commented on a change in pull request #39: [MRESOLVER-93] - PathRecordingDependencyVisitor to handle 3 cycles
suztomo commented on a change in pull request #39: [MRESOLVER-93] -
PathRecordingDependencyVisitor to handle 3 cycles
URL: https://github.com/apache/maven-resolver/pull/39#discussion_r315974988
##
File path:
maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java
##
@@ -101,6 +96,7 @@ public boolean visitEnter( DependencyNode node )
{
boolean accept = filter == null || filter.accept( node, parents );
+boolean hasDuplicateNodeInParent = parents.contains( node );
Review comment:
Thank you for the comment. That approach of using visited “set” was the
cause of this bug.
Multiset (probably via IdentityHashMap) would solve
the problem and performance. However, the resulting code would be more complex
than current solution. Until we know there is a performance problem in this
class, I would choose simpler solution.
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
With regards,
Apache Git Services
[GitHub] [maven-resolver] belingueres commented on a change in pull request #39: [MRESOLVER-93] - PathRecordingDependencyVisitor to handle 3 cycles
belingueres commented on a change in pull request #39: [MRESOLVER-93] -
PathRecordingDependencyVisitor to handle 3 cycles
URL: https://github.com/apache/maven-resolver/pull/39#discussion_r315972295
##
File path:
maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java
##
@@ -101,6 +96,7 @@ public boolean visitEnter( DependencyNode node )
{
boolean accept = filter == null || filter.accept( node, parents );
+boolean hasDuplicateNodeInParent = parents.contains( node );
Review comment:
If parent.contains(node) performance is a problem, you could maintain both
the Stack and IdentityHasMap to store the nodes, and replace the
parent.contains(node) with visited.containsKey(node) which is an O(1) operation.
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
With regards,
Apache Git Services
[GitHub] [maven-dependency-plugin] pmoerenhout commented on issue #18: [MDEP-579] - Add mirrors, proxies and authentication for remote repos…
pmoerenhout commented on issue #18: [MDEP-579] - Add mirrors, proxies and authentication for remote repos… URL: https://github.com/apache/maven-dependency-plugin/pull/18#issuecomment-523212499 Superceded by new pull request https://github.com/apache/maven-dependency-plugin/pull/19 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 With regards, Apache Git Services
[GitHub] [maven-resolver] Tibor17 commented on issue #39: [MRESOLVER-93] - PathRecordingDependencyVisitor to handle 3 cycles
Tibor17 commented on issue #39: [MRESOLVER-93] - PathRecordingDependencyVisitor to handle 3 cycles URL: https://github.com/apache/maven-resolver/pull/39#issuecomment-523154372 I expect more developers to join , but we may add one more commit later on. So that the line `paths.add( Arrays.asList( path ) );` and use `addAll()`. 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 With regards, Apache Git Services
[jira] [Commented] (MNGSITE-372) Profile activation documentation is out of date
[ https://issues.apache.org/jira/browse/MNGSITE-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911653#comment-16911653 ] Mirko Sertic commented on MNGSITE-372: -- I created one:) > Profile activation documentation is out of date > --- > > Key: MNGSITE-372 > URL: https://issues.apache.org/jira/browse/MNGSITE-372 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Gili >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Per > https://issues.apache.org/jira/browse/MNG-4565?focusedCommentId=16844101=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16844101: > http://maven.apache.org/pom.html#Activation needs to be updated to indicate > that *all* activation conditions must be true for a profile to activate. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[GitHub] [maven-surefire] Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-523145553 The diff in Github is not enough for me, so I have to see the entire class for `toClassMethodNameWithoutPlan` and think about it. 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 With regards, Apache Git Services
[GitHub] [maven-surefire] Col-E commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Col-E commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-523144813 Ok, all suggestions have been addressed except for the usage of `toClassMethodNameWithoutPlan`, which I responded to above. How would you like this to be addressed? 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 With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 edited a comment on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Tibor17 edited a comment on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-523143928 > (JUnit 4+ providers and JUnit 5+ providers since 3.0.0-M4) > Is the remark for clarifying support as of 3.0.0-M4? yes, for both, that's ok and enough as you have mentioned. The reason is that the users sometimes are not aware that it is not the version they use in the company but the latest with a praticular feature. 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 With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-523143928 > (JUnit 4+ providers and JUnit 5+ providers since 3.0.0-M4) > Is the remark for clarifying support as of 3.0.0-M4? yes, for both, that's ok and enough as you have mentioned. The reason is that the users sometimes are not aware that it is not the version they use in the company but the latest with a praticular feature. 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 With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 edited a comment on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Tibor17 edited a comment on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-523138627 @Col-E Additionally, we have to update the chart `maven-surefire-plugin/src/site/apt/examples/featurematrix.apt.vm` and update the line `re-run count` and type `Y` with a new remark `*3`. 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 With regards, Apache Git Services
[GitHub] [maven-surefire] Col-E commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Col-E commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-523142533 > We of course have to mention JUnit 5 in JavaDoc. You can see the practice in another parameters that we say `Since version 3.0.0-M4 ...`. So `(JUnit 4+ providers and JUnit 5+ providers since 3.0.0-M4)` would be more appropriate then? > Additionally, we have to update the chart `maven-surefire-plugin/src/site/apt/examples/featurematrix.apt.vm` and update the line `re-run count` and type `Y` with a new remark `*3`. Is the remark for clarifying support as of 3.0.0-M4? 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 With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-523138627 @jon-bell Additionally, we have to update the chart `maven-surefire-plugin/src/site/apt/examples/featurematrix.apt.vm` and update the line `re-run count` and type `Y` with a new remark `*3`. 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 With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-523136911 > > > > Pls open the MOJO classes. You will see `rerunFailingTestsCount`. Extend the JavaDoc and add a new support for JUnit5 with all known limitations if any exist. > > I found docs for `rerunFailingTestsCount` in `SurefirePlugin.java` and `IntegrationTestMojo.java` where it states: `(JUnit 4+ providers)` > Would changing this to `(JUnit 4+ providers & JUnit 5+ providers)` be acceptable? We of course have to mention JUnit 5 in JavaDoc. You can see the practice in another parameters that we say `Since version 3.0.0-M4 ...`. 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 With regards, Apache Git Services
[GitHub] [maven-surefire] Col-E commented on a change in pull request #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Col-E commented on a change in pull request #245: Surefire-1584: Add option to
rerun failing tests for JUnit5
URL: https://github.com/apache/maven-surefire/pull/245#discussion_r315820300
##
File path:
surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/RunListenerAdapter.java
##
@@ -259,4 +261,50 @@ else if ( testSource.filter(
ClassSource.class::isInstance ).isPresent() )
return new String[] { source, source, display, display };
}
}
+
+public String[] toClassMethodNameWithoutPlan( TestIdentifier
testIdentifier )
Review comment:
Are you referring to `toClassMethodName`? That couldn't be used because at
the time of requesting class names for reruns the plan is set to `null`.
Perhaps adding a null check in the original method that provides the same logic
as what's implemented in this extra method would suffice? Or were you thinking
of a different approach?
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
With regards,
Apache Git Services
[GitHub] [maven-surefire] Col-E commented on a change in pull request #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Col-E commented on a change in pull request #245: Surefire-1584: Add option to
rerun failing tests for JUnit5
URL: https://github.com/apache/maven-surefire/pull/245#discussion_r315834218
##
File path:
surefire-its/src/test/java/org/apache/maven/surefire/its/JUnitPlatformRerunFailingTestsIT.java
##
@@ -0,0 +1,268 @@
+package org.apache.maven.surefire.its;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import org.apache.maven.surefire.its.fixture.OutputValidator;
+import org.apache.maven.surefire.its.fixture.SurefireJUnit4IntegrationTestCase;
+import org.apache.maven.surefire.its.fixture.SurefireLauncher;
+import org.junit.Test;
+
+/**
+ * JUnit4 RunListener Integration Test.
+ *
+ * @author mailto:qingzhou...@google.com;>Qingzhou Luo
+ * @author Matt Coley
+ */
+public class JUnitPlatformRerunFailingTestsIT extends
SurefireJUnit4IntegrationTestCase
+{
+private final static String GOAL = "-Dprovider=surefire-junit-platform";
+private final static String VERSION = "5.4.2";
Review comment:
Testing on `5.5.1` and removing the explicit provider goal yields a _BUILD
SUCCESS_ :+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
With regards,
Apache Git Services
[GitHub] [maven-surefire] Col-E commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Col-E commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-523128544 > Pls open the MOJO classes. You will see `rerunFailingTestsCount`. Extend the JavaDoc and add a new support for JUnit5 with all known limitations if any exist. I found docs for `rerunFailingTestsCount` in `SurefirePlugin.java` and `IntegrationTestMojo.java` where it states: `(JUnit 4+ providers)` Would changing this to `(JUnit 4+ providers & JUnit 5+ providers)` be acceptable? 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 With regards, Apache Git Services
[GitHub] [maven-surefire] Col-E commented on a change in pull request #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Col-E commented on a change in pull request #245: Surefire-1584: Add option to
rerun failing tests for JUnit5
URL: https://github.com/apache/maven-surefire/pull/245#discussion_r315820300
##
File path:
surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/RunListenerAdapter.java
##
@@ -259,4 +261,50 @@ else if ( testSource.filter(
ClassSource.class::isInstance ).isPresent() )
return new String[] { source, source, display, display };
}
}
+
+public String[] toClassMethodNameWithoutPlan( TestIdentifier
testIdentifier )
Review comment:
Are you referring to `toClassMethodName`? That couldn't be used because at
the time of requesting class names for reruns the plan is set to `null`.
Perhaps a null check in the original method would suffice or were you thinking
of a different approach?
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
With regards,
Apache Git Services
[jira] [Commented] (MNG-6740) Provide a way to override properties of a polyglot build
[ https://issues.apache.org/jira/browse/MNG-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911577#comment-16911577 ] Christoph Läubrich commented on MNG-6740: - migrated to https://github.com/takari/polyglot-maven/issues/193 > Provide a way to override properties of a polyglot build > > > Key: MNG-6740 > URL: https://issues.apache.org/jira/browse/MNG-6740 > Project: Maven > Issue Type: New Feature >Reporter: Christoph Läubrich >Priority: Major > > polyglot allows to generate maven models out of other metadata that pom.xml > via extensions. > This is great and offers high flexibility for advanced use-cases but comes > with the cost that it is not as easy to modify certain settings or properties > if the data is derived from other sources. > For example [Eclipse Tycho|https://www.eclipse.org/tycho/] generates models > out of OSGi/PDE metadata but can often only guess what is the right thing to > use for example as artifactId, and it can't know of any custom properties a > user might wish to set. > While it is always possible to create custom crafted poms, this contradicts > the approach which goal is to reuse as many metadata as possible, and the > user only wants do configure a really small portion of it (e.g. the > description or a single poperty). > [A proposal was made to integrate support for this inside the tycho > extension|https://bugs.eclipse.org/bugs/show_bug.cgi?id=550239], but because > it might be of wider use I'd like to evaluate (as suggestes by Mickael > Istria) if it is possible to implement/add this as a more generic feature > directly into the maven project. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MPIR-383) Error when generation site with dependency build with Java 9+
[
https://issues.apache.org/jira/browse/MPIR-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911518#comment-16911518
]
Michael Osipov commented on MPIR-383:
-
[~agaengel], update the plugin dependency inline in your POM. You say thank you
to Gary Gregory for this Java 8 update obsessiveness.
> Error when generation site with dependency build with Java 9+
> -
>
> Key: MPIR-383
> URL: https://issues.apache.org/jira/browse/MPIR-383
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 2.9, 3.0.0
>Reporter: Alexander Gängel
>Priority: Minor
>
> When building a site with a dependency to log4j-api greather than {{2.9.1}}
> the used the following error occurs.
> {code:java}
> [INFO] Generating "Dependencies" report ---
> maven-project-info-reports-plugin:2.9:dependencies
> [WARNING] Unable to process class META-INF/versions/9/module-info.class in
> JarAnalyzer File
> /Users/username/.m2/repository/org/apache/logging/log4j/log4j-api/2.11.2/log4j-api-2.11.2.jar
> org.apache.bcel.classfile.ClassFormatException: Invalid byte tag in constant
> pool: 19
> at org.apache.bcel.classfile.Constant.readConstant (Constant.java:161)
> at org.apache.bcel.classfile.ConstantPool. (ConstantPool.java:69)
> at org.apache.bcel.classfile.ClassParser.readConstantPool
> (ClassParser.java:235)
> at org.apache.bcel.classfile.ClassParser.parse (ClassParser.java:143)
> at org.apache.maven.shared.jar.classes.JarClassesAnalysis.analyze
> (JarClassesAnalysis.java:96)
> at
> org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails
> (Dependencies.java:259)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed
> (DependenciesRenderer.java:1542)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails
> (DependenciesRenderer.java:545)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody
> (DependenciesRenderer.java:240)
> at org.apache.maven.reporting.AbstractMavenReportRenderer.render
> (AbstractMavenReportRenderer.java:83)
> at org.apache.maven.report.projectinfo.DependenciesReport.executeReport
> (DependenciesReport.java:201)
> at org.apache.maven.reporting.AbstractMavenReport.generate
> (AbstractMavenReport.java:255)
> at
> org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
> (ReportDocumentRenderer.java:230)
> at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render
> (DefaultSiteRenderer.java:349)
> at org.apache.maven.plugins.site.render.SiteMojo.renderLocale
> (SiteMojo.java:198)
> at org.apache.maven.plugins.site.render.SiteMojo.execute
> (SiteMojo.java:147)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:567)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at
[jira] [Comment Edited] (MPIR-383) Error when generation site with dependency build with Java 9+
[
https://issues.apache.org/jira/browse/MPIR-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911518#comment-16911518
]
Michael Osipov edited comment on MPIR-383 at 8/20/19 4:26 PM:
--
[~agaengel], update the plugin dependency inline in your POM. You say thank you
to Gary Gregory for this Java 8 update obsession.
was (Author: michael-o):
[~agaengel], update the plugin dependency inline in your POM. You say thank you
to Gary Gregory for this Java 8 update obsessiveness.
> Error when generation site with dependency build with Java 9+
> -
>
> Key: MPIR-383
> URL: https://issues.apache.org/jira/browse/MPIR-383
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 2.9, 3.0.0
>Reporter: Alexander Gängel
>Priority: Minor
>
> When building a site with a dependency to log4j-api greather than {{2.9.1}}
> the used the following error occurs.
> {code:java}
> [INFO] Generating "Dependencies" report ---
> maven-project-info-reports-plugin:2.9:dependencies
> [WARNING] Unable to process class META-INF/versions/9/module-info.class in
> JarAnalyzer File
> /Users/username/.m2/repository/org/apache/logging/log4j/log4j-api/2.11.2/log4j-api-2.11.2.jar
> org.apache.bcel.classfile.ClassFormatException: Invalid byte tag in constant
> pool: 19
> at org.apache.bcel.classfile.Constant.readConstant (Constant.java:161)
> at org.apache.bcel.classfile.ConstantPool. (ConstantPool.java:69)
> at org.apache.bcel.classfile.ClassParser.readConstantPool
> (ClassParser.java:235)
> at org.apache.bcel.classfile.ClassParser.parse (ClassParser.java:143)
> at org.apache.maven.shared.jar.classes.JarClassesAnalysis.analyze
> (JarClassesAnalysis.java:96)
> at
> org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails
> (Dependencies.java:259)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed
> (DependenciesRenderer.java:1542)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails
> (DependenciesRenderer.java:545)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody
> (DependenciesRenderer.java:240)
> at org.apache.maven.reporting.AbstractMavenReportRenderer.render
> (AbstractMavenReportRenderer.java:83)
> at org.apache.maven.report.projectinfo.DependenciesReport.executeReport
> (DependenciesReport.java:201)
> at org.apache.maven.reporting.AbstractMavenReport.generate
> (AbstractMavenReport.java:255)
> at
> org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
> (ReportDocumentRenderer.java:230)
> at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render
> (DefaultSiteRenderer.java:349)
> at org.apache.maven.plugins.site.render.SiteMojo.renderLocale
> (SiteMojo.java:198)
> at org.apache.maven.plugins.site.render.SiteMojo.execute
> (SiteMojo.java:147)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:567)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at
[jira] [Closed] (MPIR-376) LightweightHttpsWagon is always used
[
https://issues.apache.org/jira/browse/MPIR-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPIR-376.
---
Resolution: Fixed
Fixed with
[3e3851d2f0014cec9f0593a0fa37930f30637121|https://gitbox.apache.org/repos/asf?p=maven-project-info-reports-plugin.git;a=commit;h=3e3851d2f0014cec9f0593a0fa37930f30637121].
> LightweightHttpsWagon is always used
>
>
> Key: MPIR-376
> URL: https://issues.apache.org/jira/browse/MPIR-376
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies, dependency-management, plugin-management
>Affects Versions: 3.0.0
> Environment: Apache Maven 3.5.4
> (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T20:33:14+02:00)
> Maven home: /opt/apache-maven
> Java version: 1.8.0_152, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_152.jdk/Contents/Home/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"
>Reporter: Jan Gerken
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.0.1
>
> Attachments: build.log, pom.xml
>
>
> For all dependencies, one of the plugins needs to download always the
> {{LightweightHttpsWagon}} is used. Independent of the wagon provider
> configuration in the {{settings.xml}} or via {{-Dmaven.wagon.provider.https}}
> and {{-Dmaven.wagon.provider.http}}.
> Starting with Maven 3.0.4 the {{httpclient}} is the default wagon provider
> used for http and https connections. Therefore, I added add
> {{httpConfiguration}} for all servers I access in my {{settings.xml}} to
> reduce the timeout. This works well with all other plugins but for this
> plugin in version 3.0.0 it generates the following warning for each download:
> {code:java}
> [WARNING] Could not apply configuration for central to wagon
> org.apache.maven.wagon.providers.http.LightweightHttpsWagon:Cannot find
> 'httpConfiguration' in class
> org.apache.maven.wagon.providers.http.LightweightHttpsWagon{code}
> I tried to explicitly define the wagon provider to be {{httpclient}} for each
> server in my {{settings.xml}} and I tried to force the client via the command
> line arguments. None of this changes was successful.
> Please make this plugin use the configured wagon provider for each server and
> use the same default provider as the Maven version.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MRESOLVER-93:
-
Description:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code:java}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
h1. Solutions
I came up with three solutions. I pick solution #1 for simplicity.
h2. 1. Use "parents" to check the cycle, rather than visited set
This is the simplest. Checking array element member is usually discouraged
especially for large data set. The implementation should confirm the overhead
of this solution.
h2. 2. Use AbstractMapBag/Multiset for visited set
Creating a new class that extends AbstractMapBag and leverages IdentityHashMap.
Although this solution would be theoretically more efficient than solution #1,
I felt it's overkill to create a class just for this solution.
{code:java}
AbstractMapBag(new IdentityHashMap()){code}
[https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/bag/AbstractMapBag.html]
IdentityHashMap() would work as a multiset.
h2. 3. Call visitLeave only when visitEnter is true
The cause of this bug is
[DefaultDependencyNode|https://github.com/apache/maven-resolver/blob/47edcfe69c4e52ced4cb93d65b7348b5645cdd68/maven-resolver-api/src/main/java/org/eclipse/aether/graph/DefaultDependencyNode.java#L354]
calling visitLeave regardless of visitEnter result.
I'm not sure how many other visitors rely on visitLeave being called regardless
of visitEnter result.
h1. Illustration on why existing algorithm does not catch cycle
The following illustration is the node traversal for the test case above by
current algorithm. This illustration tracks the dependency node graph and the
"visited" set maintained by the visitor.
* visited set. An internal data structure in PathRecordingDependencyVisitor to
avoid cycle
([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L45]).
* visitEnter(node): PathRecordingDependencyVisitor's function
([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L100]).
When returning true, the node's children is traversed by the algorithm. This
function adds the node to visited set.
* visitLeave(node): PathRecordingDependencyVisitor's function
([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L129]).
This function removes the node from visited set.
The initial state starts with node "a" and visited set \{a}.
!IMG_0234.jpg|width=334,height=252!
First child of a is b0. Because visited does not contain, visitEnter(b0)
returns true, meaning that the algorithm traverses this b0's children next. B0
is added to visited.
!IMG_0235.jpg|width=359,height=191!
B0's children is "a". Because visited set contains "a", visitEnter(a) returns
false. This means that the algorithm does not traverse this "a"'s children. A
is added to visited set (already it has).
!IMG_0236.jpg|width=438,height=197!
Now not traversing this "a"'s children, the algorithm calls visitLeave(a). This
removes "a" from visited set.
!IMG_0237.jpg|width=434,height=165!
B0's children are all traversed. the algorithm calls visitLeave(b0). This
removes "b0" from visited set.
!IMG_0238.jpg|width=459,height=197!
Now visited set is empty.
Next child of the root "a" is b1. B1 is not in visited set, thus visitEnter(b1)
returns true. This means the algorithm traverses the children of this b1.
!IMG_0240.jpg|width=445,height=270!
B1's only child is a. "a" is not in visited set. visitEnter(a) returns true.
This means to traverse "a"'s children.
!IMG_0241.jpg|width=418,height=262!
A's first children is b0. b0 is not in visited set. visitEnter(b0) returns
true, meaning to traverse children of this b0.
!IMG_0242.jpg|width=422,height=208!
(img 0242)
The only child of b0 is "a". Visited set contains "a", and thus not traversing
its children.
!IMG_0243.jpg|width=491,height=191!
visitLeave(a) removes "a" from visited set.
!IMG_0244.jpg|width=481,height=189!
b0's children is all traversed. VisitLeave(b0) removes b0 from visited set.
!IMG_0245.jpg|width=498,height=182!
Next child of this "a" is b1. B1 is in visited set, and thus visitEnter(b1)
returns false. This node's children is not to be traversed.
[jira] [Commented] (MNG-6716) relative testSourceDirectory on macos throw duplicate class error
[
https://issues.apache.org/jira/browse/MNG-6716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911485#comment-16911485
]
Hudson commented on MNG-6716:
-
Build succeeded in Jenkins: Maven TLP » maven » master #277
See https://builds.apache.org/job/maven-box/job/maven/job/master/277/
> relative testSourceDirectory on macos throw duplicate class error
> -
>
> Key: MNG-6716
> URL: https://issues.apache.org/jira/browse/MNG-6716
> Project: Maven
> Issue Type: Bug
> Components: core, POM
>Affects Versions: 3.6.1
> Environment: MacOS Sierra 10.12.6
> mvn 3.6.1
>Reporter: Thibaud Lepretre
>Assignee: Enrico Olivelli
>Priority: Minor
> Fix For: 3.6.2
>
> Attachments: image-2019-07-30-12-26-50-201.png,
> image-2019-07-30-12-27-38-526.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> With custom folder structure where test source folder is not sharing the same
> parent folder as source folder, for example (is just a sample structure
> itself is not the key point):
> {code:java}
> ws/bug-macos-tstsrc-relative-path-src/src/main/java
> ws/bug-macos-tstsrc-relative-path-tst/src
> {code}
> With following pom.xml customization
> {code:java}
> ../bug-macos-tstsrc-relative-path-tst/src
> {code}
> On {{<= 3.6.0}} *everything works* but until 3.6.1 MacOS (I'm not able to
> reproduce on Docker container maven:3.6.1), I have the following error:
> {code:java}
> AppTest.java:[10,8] duplicate class: dev.thibaud.AppTest{code}
> And if I check with {{-X}} I saw 2 paths added instead of 1
> {code:java}
> [DEBUG] Source roots:
> [DEBUG]
> /private/tmp/mvntest/ws/bug-macos-tstsrc-relative-path-src/../bug-macos-tstsrc-relative-path-tst/src
> [DEBUG] /private/tmp/mvntest/ws/bug-macos-tstsrc-relative-path-tst/src{code}
> h2. *How to reproduce:*
> {code:java}
> #!/usr/bin/env bash
> readonly SRC_FOLDER="bug-macos-tstsrc-relative-path-src"
> readonly TST_FOLDER="bug-macos-tstsrc-relative-path-tst"
> mkdir -p ws
> cd ws/
> mvn archetype:generate -DgroupId=dev.thibaud -DartifactId=${SRC_FOLDER}
> -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
> mkdir -p ${TST_FOLDER}/src/
> mv ${SRC_FOLDER}/src/test/java/* ${TST_FOLDER}/src/
> rm -fr ${SRC_FOLDER}/src/test
> cat < ${SRC_FOLDER}/pom.xml
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd;>
> 4.0.0
> dev.thibaud
> bug-macos-tstsrcrelative-path
> jar
> 1.0-SNAPSHOT
> bug-macos-tstsrcrelative-path
> http://maven.apache.org
>
>
> junit
> junit
> 3.8.1
> test
>
>
>
> ../${TST_FOLDER}/src
>
>
> EOT{code}
> Then simply run
> {code:java}
> mvn -f bug-macos-tstsrc-relative-path-src/pom.xml clean test -X{code}
> h2. *Workaround:*
> is not using relative path by editing
> {code:java}
> ../bug-macos-tstsrc-relative-path-tst/src{code}
> to
> {code:java}
> ${project.basedir}/../bug-macos-tstsrc-relative-path-tst/src{code}
>
> PS: maybe affect {{sourceDirectory}} but no tested
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[GitHub] [maven-dependency-plugin] pmoerenhout commented on a change in pull request #19: [MDEP-579] - Add mirrors, proxies and authentication for remote repositories.
pmoerenhout commented on a change in pull request #19: [MDEP-579] - Add mirrors, proxies and authentication for remote repositories. URL: https://github.com/apache/maven-dependency-plugin/pull/19#discussion_r315763348 ## File path: src/test/resources/unit/get-test/realm.properties ## @@ -0,0 +1,19 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. + +# username: password[,rolename ...] +foo: bar,userrole Review comment: Empty line added! 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 With regards, Apache Git Services
[GitHub] [maven-dependency-plugin] pmoerenhout commented on a change in pull request #19: [MDEP-579] - Add mirrors, proxies and authentication for remote repositories.
pmoerenhout commented on a change in pull request #19: [MDEP-579] - Add mirrors, proxies and authentication for remote repositories. URL: https://github.com/apache/maven-dependency-plugin/pull/19#discussion_r315763130 ## File path: src/test/java/org/apache/maven/plugins/dependency/TestGetMojo.java ## @@ -48,7 +62,14 @@ protected void setUp() assertNotNull( mojo ); LegacySupport legacySupport = lookup( LegacySupport.class ); -legacySupport.setSession( newMavenSession( new MavenProjectStub() ) ); +MavenSession session = newMavenSession(new MavenProjectStub()); +Settings settings = session.getSettings(); +Server server = new Server(); +server.setId( "myserver" ); +server.setUsername( "foo" ); +server.setPassword( "bar" ); +settings.addServer(server); Review comment: Done. 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 With regards, Apache Git Services
[GitHub] [maven-dependency-plugin] pmoerenhout commented on a change in pull request #19: [MDEP-579] - Add mirrors, proxies and authentication for remote repositories.
pmoerenhout commented on a change in pull request #19: [MDEP-579] - Add
mirrors, proxies and authentication for remote repositories.
URL:
https://github.com/apache/maven-dependency-plugin/pull/19#discussion_r315762920
##
File path: src/test/java/org/apache/maven/plugins/dependency/TestGetMojo.java
##
@@ -96,6 +117,27 @@ public void testRemoteRepositories()
mojo.execute();
}
+/**
+ * Test remote repositories parameter with basic authentication
+ *
+ * @throws Exception in case of errors
+ */
+public void testRemoteRepositoriesAuthentication()
+throws Exception
+{
+org.eclipse.jetty.server.Server server = createServer( 8000 );
Review comment:
I start the server now with a random port, and use server.getURI() to
generate the remoteRepositories parameter.
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
With regards,
Apache Git Services
[GitHub] [maven-dependency-plugin] pmoerenhout commented on a change in pull request #19: [MDEP-579] - Add mirrors, proxies and authentication for remote repositories.
pmoerenhout commented on a change in pull request #19: [MDEP-579] - Add mirrors, proxies and authentication for remote repositories. URL: https://github.com/apache/maven-dependency-plugin/pull/19#discussion_r315763022 ## File path: src/test/resources/unit/get-test/repository/test/test/1.0/test-1.0.pom ## @@ -0,0 +1,41 @@ + + +http://maven.apache.org/POM/4.0.0; + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; + xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd;> + 4.0.0 + + test + test + 1.0 + + + + +maven-compiler-plugin Review comment: Done. Thanks! 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 With regards, Apache Git Services
[GitHub] [maven-dependency-plugin] pmoerenhout commented on a change in pull request #19: [MDEP-579] - Add mirrors, proxies and authentication for remote repositories.
pmoerenhout commented on a change in pull request #19: [MDEP-579] - Add
mirrors, proxies and authentication for remote repositories.
URL:
https://github.com/apache/maven-dependency-plugin/pull/19#discussion_r315761851
##
File path: src/test/java/org/apache/maven/plugins/dependency/TestGetMojo.java
##
@@ -96,6 +117,27 @@ public void testRemoteRepositories()
mojo.execute();
}
+/**
+ * Test remote repositories parameter with basic authentication
+ *
+ * @throws Exception in case of errors
+ */
+public void testRemoteRepositoriesAuthentication()
+throws Exception
+{
+org.eclipse.jetty.server.Server server = createServer( 8000 );
+server.start();
+
+setVariableValueToObject( mojo, "remoteRepositories",
"myserver::default::http://localhost:8000/maven; );
+mojo.setGroupId( "test" );
+mojo.setArtifactId( "test" );
+mojo.setVersion( "1.0" );
+
+mojo.execute();
+
+server.stop();
Review comment:
I've added the server.stop() to a finally block.
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
With regards,
Apache Git Services
[GitHub] [maven-resolver] suztomo commented on issue #39: [MRESOLVER-93] - PathRecordingDependencyVisitor to handle 3 cycles
suztomo commented on issue #39: [MRESOLVER-93] - PathRecordingDependencyVisitor to handle 3 cycles URL: https://github.com/apache/maven-resolver/pull/39#issuecomment-523065669 (I picked up the highest version) I just updated to include 1.4.0 and 1.3.3 to mean the problem should be there for a while. 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 With regards, Apache Git Services
[jira] [Updated] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MRESOLVER-93:
-
Affects Version/s: 1.3.3
1.4.0
> PathRecordingDependencyVisitor to handle 3 cycles
> -
>
> Key: MRESOLVER-93
> URL: https://issues.apache.org/jira/browse/MRESOLVER-93
> Project: Maven Resolver
> Issue Type: Improvement
> Components: resolver
>Affects Versions: 1.3.3, 1.4.0, 1.4.1
>Reporter: Tomo Suzuki
>Priority: Major
> Attachments: IMG_0234.jpg, IMG_0235.jpg, IMG_0236.jpg, IMG_0237.jpg,
> IMG_0238.jpg, IMG_0240.jpg, IMG_0241.jpg, IMG_0242.jpg, IMG_0243.jpg,
> IMG_0244.jpg, IMG_0245.jpg, IMG_0255.jpg, IMG_0256.jpg, IMG_0257.jpg,
> IMG_0258.jpg, IMG_0259.jpg, IMG_0260.jpg, IMG_0261.jpg, IMG_0262.jpg,
> IMG_0263.jpg, IMG_0264.jpg, IMG_0265.jpg, IMG_0266.jpg
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
> more cycles such as below:
>
> {code:java}
> gid:a:1 (1)
> +- gid:b:0
> | \- ^1
> +- gid:b:1
> | \- ^1
> \- gid:b:2
>\- ^1
> {code}
> It fails with StackOverflowError or OutOfMemoryError. [Test
> case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
>
> h1. Solutions
> I came up with three solutions. I pick solution #1 for simplicity.
> h2. 1. Use "parents" to check the cycle, rather than visited set
> This is the simplest. Checking array element member is usually discouraged
> especially for large data set. The implementation should confirm the overhead
> of this solution.
> h2. 2. Use AbstractMapBag for visited set
> Creating a new class that extends AbstractMapBag and leverages
> IdentityHashMap. Although this solution would be theoretically more efficient
> than solution #1, I felt it's overkill to create a class just for this
> solution.
>
> {code:java}
> AbstractMapBag(new IdentityHashMap AbstractMapBag.MutableInteger>()){code}
>
> [https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/bag/AbstractMapBag.html]
> h2. 3. Call visitLeave only when visitEnter is true
> The cause of this bug is
> [DefaultDependencyNode|https://github.com/apache/maven-resolver/blob/47edcfe69c4e52ced4cb93d65b7348b5645cdd68/maven-resolver-api/src/main/java/org/eclipse/aether/graph/DefaultDependencyNode.java#L354]
> calling visitLeave regardless of visitEnter result.
> I'm not sure how many other visitors rely on visitLeave being called
> regardless of visitEnter result.
> h1. Illustration on why existing algorithm does not catch cycle
> The following illustration is the node traversal for the test case above by
> current algorithm. This illustration tracks the dependency node graph and the
> "visited" set maintained by the visitor.
> * visited set. An internal data structure in PathRecordingDependencyVisitor
> to avoid cycle
> ([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L45]).
> * visitEnter(node): PathRecordingDependencyVisitor's function
> ([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L100]).
> When returning true, the node's children is traversed by the algorithm. This
> function adds the node to visited set.
> * visitLeave(node): PathRecordingDependencyVisitor's function
> ([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L129]).
> This function removes the node from visited set.
>
> The initial state starts with node "a" and visited set \{a}.
> !IMG_0234.jpg|width=334,height=252!
> First child of a is b0. Because visited does not contain, visitEnter(b0)
> returns true, meaning that the algorithm traverses this b0's children next.
> B0 is added to visited.
> !IMG_0235.jpg|width=359,height=191!
> B0's children is "a". Because visited set contains "a", visitEnter(a) returns
> false. This means that the algorithm does not traverse this "a"'s children. A
> is added to visited set (already it has).
> !IMG_0236.jpg|width=438,height=197!
> Now not traversing this "a"'s children, the algorithm calls visitLeave(a).
> This removes "a" from visited set.
> !IMG_0237.jpg|width=434,height=165!
> B0's children are all traversed. the algorithm calls visitLeave(b0). This
> removes "b0" from visited set.
> !IMG_0238.jpg|width=459,height=197!
> Now visited set is empty.
> Next child of the
[GitHub] [maven-resolver] Tibor17 commented on issue #39: [MRESOLVER-93] - PathRecordingDependencyVisitor to handle 3 cycles
Tibor17 commented on issue #39: [MRESOLVER-93] - PathRecordingDependencyVisitor to handle 3 cycles URL: https://github.com/apache/maven-resolver/pull/39#issuecomment-523064813 @suztomo In Jira the affect version is 1.4.1. We did not change this class. Was it the same issue in previous versions? 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 With regards, Apache Git Services
[GitHub] [maven-resolver] suztomo commented on issue #39: [MRESOLVER-93] - PathRecordingDependencyVisitor to handle 3 cycles
suztomo commented on issue #39: [MRESOLVER-93] - PathRecordingDependencyVisitor to handle 3 cycles URL: https://github.com/apache/maven-resolver/pull/39#issuecomment-523063825 @Tibor17 I've added illustration on why visited set does not work as expected in [MRESOLVER-93](https://issues.apache.org/jira/browse/MRESOLVER-93) 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 With regards, Apache Git Services
[GitHub] [maven-resolver] suztomo opened a new pull request #39: [MRESOLVER-93] - PathRecordingDependencyVisitor to handle 3 cycles
suztomo opened a new pull request #39: [MRESOLVER-93] - PathRecordingDependencyVisitor to handle 3 cycles URL: https://github.com/apache/maven-resolver/pull/39 Among 3 solutions I came up with for https://issues.apache.org/jira/browse/MRESOLVER-93, I choose the simplest solution of checking parents rather than visited set. 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 With regards, Apache Git Services
[jira] [Updated] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MRESOLVER-93:
-
Description:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code:java}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
h1. Solutions
I came up with three solutions. I pick solution #1 for simplicity.
h2. 1. Use "parents" to check the cycle, rather than visited set
This is the simplest. Checking array element member is usually discouraged
especially for large data set. The implementation should confirm the overhead
of this solution.
h2. 2. Use AbstractMapBag for visited set
Creating a new class that extends AbstractMapBag and leverages IdentityHashMap.
Although this solution would be theoretically more efficient than solution #1,
I felt it's overkill to create a class just for this solution.
{code:java}
AbstractMapBag(new IdentityHashMap()){code}
[https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/bag/AbstractMapBag.html]
h2. 3. Call visitLeave only when visitEnter is true
The cause of this bug is
[DefaultDependencyNode|https://github.com/apache/maven-resolver/blob/47edcfe69c4e52ced4cb93d65b7348b5645cdd68/maven-resolver-api/src/main/java/org/eclipse/aether/graph/DefaultDependencyNode.java#L354]
calling visitLeave regardless of visitEnter result.
I'm not sure how many other visitors rely on visitLeave being called regardless
of visitEnter result.
h1. Illustration on why existing algorithm does not catch cycle
The following illustration is the node traversal for the test case above by
current algorithm. This illustration tracks the dependency node graph and the
"visited" set maintained by the visitor.
* visited set. An internal data structure in PathRecordingDependencyVisitor to
avoid cycle
([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L45]).
* visitEnter(node): PathRecordingDependencyVisitor's function
([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L100]).
When returning true, the node's children is traversed by the algorithm. This
function adds the node to visited set.
* visitLeave(node): PathRecordingDependencyVisitor's function
([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L129]).
This function removes the node from visited set.
The initial state starts with node "a" and visited set \{a}.
!IMG_0234.jpg|width=334,height=252!
First child of a is b0. Because visited does not contain, visitEnter(b0)
returns true, meaning that the algorithm traverses this b0's children next. B0
is added to visited.
!IMG_0235.jpg|width=359,height=191!
B0's children is "a". Because visited set contains "a", visitEnter(a) returns
false. This means that the algorithm does not traverse this "a"'s children. A
is added to visited set (already it has).
!IMG_0236.jpg|width=438,height=197!
Now not traversing this "a"'s children, the algorithm calls visitLeave(a). This
removes "a" from visited set.
!IMG_0237.jpg|width=434,height=165!
B0's children are all traversed. the algorithm calls visitLeave(b0). This
removes "b0" from visited set.
!IMG_0238.jpg|width=459,height=197!
Now visited set is empty.
Next child of the root "a" is b1. B1 is not in visited set, thus visitEnter(b1)
returns true. This means the algorithm traverses the children of this b1.
!IMG_0240.jpg|width=445,height=270!
B1's only child is a. "a" is not in visited set. visitEnter(a) returns true.
This means to traverse "a"'s children.
!IMG_0241.jpg|width=418,height=262!
A's first children is b0. b0 is not in visited set. visitEnter(b0) returns
true, meaning to traverse children of this b0.
!IMG_0242.jpg|width=422,height=208!
(img 0242)
The only child of b0 is "a". Visited set contains "a", and thus not traversing
its children.
!IMG_0243.jpg|width=491,height=191!
visitLeave(a) removes "a" from visited set.
!IMG_0244.jpg|width=481,height=189!
b0's children is all traversed. VisitLeave(b0) removes b0 from visited set.
!IMG_0245.jpg|width=498,height=182!
Next child of this "a" is b1. B1 is in visited set, and thus visitEnter(b1)
returns false. This node's children is not to be traversed.
!IMG_0255.jpg|width=545,height=245!
(img 0255)
visitLeave(b1)
[jira] [Updated] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MRESOLVER-93:
-
Description:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code:java}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
h1. Illustration on why existing algorithm does not catch cycle
The following illustration is the node traversal for the test case above by
current algorithm. This illustration tracks the dependency node graph and the
"visited" set maintained by the visitor.
* visited set. An internal data structure in PathRecordingDependencyVisitor to
avoid cycle
([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L45]).
* visitEnter(node): PathRecordingDependencyVisitor's function
([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L100]).
When returning true, the node's children is traversed by the algorithm. This
function adds the node to visited set.
* visitLeave(node): PathRecordingDependencyVisitor's function
([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L129]).
This function removes the node from visited set.
The initial state starts with node "a" and visited set \{a}.
!IMG_0234.jpg|width=334,height=252!
First child of a is b0. Because visited does not contain, visitEnter(b0)
returns true, meaning that the algorithm traverses this b0's children next. B0
is added to visited.
!IMG_0235.jpg|width=359,height=191!
B0's children is "a". Because visited set contains "a", visitEnter(a) returns
false. This means that the algorithm does not traverse this "a"'s children. A
is added to visited set (already it has).
!IMG_0236.jpg|width=438,height=197!
Now not traversing this "a"'s children, the algorithm calls visitLeave(a). This
removes "a" from visited set.
!IMG_0237.jpg|width=434,height=165!
B0's children are all traversed. the algorithm calls visitLeave(b0). This
removes "b0" from visited set.
!IMG_0238.jpg|width=459,height=197!
Now visited set is empty.
Next child of the root "a" is b1. B1 is not in visited set, thus visitEnter(b1)
returns true. This means the algorithm traverses the children of this b1.
!IMG_0240.jpg|width=445,height=270!
B1's only child is a. "a" is not in visited set. visitEnter(a) returns true.
This means to traverse "a"'s children.
!IMG_0241.jpg|width=418,height=262!
A's first children is b0. b0 is not in visited set. visitEnter(b0) returns
true, meaning to traverse children of this b0.
!IMG_0242.jpg|width=422,height=208!
(img 0242)
The only child of b0 is "a". Visited set contains "a", and thus not traversing
its children.
!IMG_0243.jpg|width=491,height=191!
visitLeave(a) removes "a" from visited set.
!IMG_0244.jpg|width=481,height=189!
b0's children is all traversed. VisitLeave(b0) removes b0 from visited set.
!IMG_0245.jpg|width=498,height=182!
Next child of this "a" is b1. B1 is in visited set, and thus visitEnter(b1)
returns false. This node's children is not to be traversed.
!IMG_0255.jpg|width=545,height=245!
(img 0255)
visitLeave(b1) removes b1 from visited set. Now visited is emtpy.
!IMG_0256.jpg|width=528,height=294!
The last child of "a" is b2. VisitEnter(b2) returns true. It's children is to
be traversed. B2 is in visited set.
!IMG_0257.jpg|width=502,height=309!
B2's only child is "a". "a" is not in visited set, thus visitEnter(a) returns
true. The algorithm traverses this "a"'s children.
!IMG_0258.jpg|width=485,height=299!
(img 0258)
(...omit...)
IMG_0266 shows the step where I decided to give up. The algorithm does not seem
to stop. Indeed the test shows that. The path from the root to the furthest a
includes 5 "a" nodes. I concluded the visited set is not working as expected to
avoid cycle.
!IMG_0266.jpg|width=656,height=252!
was:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code:java}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
h1. Illustration on why existing algorithm does not catch cycle
The following illustration is the
[jira] [Updated] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MRESOLVER-93:
-
Description:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code:java}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
h1. Illustration on why existing algorithm does not catch cycle
The following illustration is the node traversal for the test case above by
current algorithm. This illustration tracks the dependency node graph and the
"visited" set maintained by the visitor.
* visited set. An internal data structure in PathRecordingDependencyVisitor to
avoid cycle
([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L45]).
* visitEnter(node): PathRecordingDependencyVisitor's function
([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L100]).
When returning true, the node's children is traversed by the algorithm. This
function adds the node to visited set.
* visitLeave(node): PathRecordingDependencyVisitor's function
([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L129]).
This function removes the node from visited set.
The initial state starts with node "a" and visited set \{a}.
!IMG_0234.jpg|width=334,height=252!
First child of a is b0. Because visited does not contain, visitEnter(b0)
returns true, meaning that the algorithm traverses this b0's children next. B0
is added to visited.
!IMG_0235.jpg|width=359,height=191!
B0's children is "a". Because visited set contains "a", visitEnter(a) returns
false. This means that the algorithm does not traverse this "a"'s children. A
is added to visited set (already it has).
!IMG_0236.jpg|width=438,height=197!
Now not traversing this "a"'s children, the algorithm calls visitLeave(a). This
removes "a" from visited set.
!IMG_0237.jpg|width=434,height=165!
B0's children are all traversed. the algorithm calls visitLeave(b0). This
removes "b0" from visited set.
!IMG_0238.jpg|width=459,height=197!
Now visited set is empty.
Next child of the root "a" is b1. B1 is not in visited set, thus visitEnter(b1)
returns true. This means the algorithm traverses the children of this b1.
!IMG_0240.jpg|width=445,height=270!
B1's only child is a. "a" is not in visited set. visitEnter(a) returns true.
This means to traverse "a"'s children.
!IMG_0241.jpg|width=418,height=262!
A's first children is b0. b0 is not in visited set. visitEnter(b0) returns
true, meaning to traverse children of this b0.
!IMG_0242.jpg|width=422,height=208!
(img 0242)
The only child of b0 is "a". Visited set contains "a", and thus not traversing
its children.
!IMG_0243.jpg|width=491,height=191!
visitLeave(a) removes "a" from visited set.
!IMG_0244.jpg|width=481,height=189!
b0's children is all traversed. VisitLeave(b0) removes b0 from visited set.
!IMG_0245.jpg|width=498,height=182!
Next child of this "a" is b1. B1 is in visited set, and thus visitEnter(b1)
returns false. This node's children is not to be traversed.
!IMG_0255.jpg|width=545,height=245!
(img 0255)
visitLeave(b1) removes b1 from visited set. Now visited is emtpy.
!IMG_0256.jpg|width=528,height=294!
The last child of "a" is b2. VisitEnter(b2) returns true. It's children is to
be traversed. B2 is in visited set.
!IMG_0257.jpg|width=502,height=309!
B2's only child is "a". "a" is not in visited set, thus visitEnter(a) returns
true. The algorithm traverses this "a"'s children.
!IMG_0258.jpg|width=485,height=299!
(img 0258)
(...omit...)
IMG_0266 shows the step where I decided to give up. The algorithm does not seem
to stop. Indeed the test shows that. The path from the root to the furthest a
includes 5 "a" nodes.
!IMG_0266.jpg|width=656,height=252!
was:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code:java}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
h1. Illustration on why existing algorithm does not catch cycle
The following illustration is the node traversal for the test case above by
current algorithm. This
[jira] [Updated] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MRESOLVER-93:
-
Description:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code:java}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
h1. Illustration on why existing algorithm does not catch cycle
The following illustration is the node traversal for the test case above by
current algorithm. This illustration tracks the dependency node graph and the
"visited" set maintained by the visitor.
* visitEnter: a function
The initial state starts with node "a" and visited set \{a}.
!IMG_0234.jpg|width=334,height=252!
First child of a is b0. Because visited does not contain, visitEnter(b0)
returns true, meaning that the algorithm traverses this b0's children next. B0
is added to visited.
!IMG_0235.jpg|width=359,height=191!
B0's children is "a". Because visited set contains "a", visitEnter(a) returns
false. This means that the algorithm does not traverse this "a"'s children. A
is added to visited set (already it has).
!IMG_0236.jpg|width=438,height=197!
Now not traversing this "a"'s children, the algorithm calls visitLeave(a). This
removes "a" from visited set.
!IMG_0237.jpg|width=434,height=165!
B0's children are all traversed. the algorithm calls visitLeave(b0). This
removes "b0" from visited set.
!IMG_0238.jpg|width=459,height=197!
Now visited set is empty.
Next child of the root "a" is b1. B1 is not in visited set, thus visitEnter(b1)
returns true. This means the algorithm traverses the children of this b1.
!IMG_0240.jpg|width=445,height=270!
B1's only child is a. "a" is not in visited set. visitEnter(a) returns true.
This means to traverse "a"'s children.
!IMG_0241.jpg|width=418,height=262!
A's first children is b0. b0 is not in visited set. visitEnter(b0) returns
true, meaning to traverse children of this b0.
!IMG_0242.jpg|width=422,height=208!
(img 0242)
The only child of b0 is "a". Visited set contains "a", and thus not traversing
its children.
!IMG_0243.jpg|width=491,height=191!
visitLeave(a) removes "a" from visited set.
!IMG_0244.jpg|width=481,height=189!
b0's children is all traversed. VisitLeave(b0) removes b0 from visited set.
!IMG_0245.jpg|width=498,height=182!
Next child of this "a" is b1. B1 is in visited set, and thus visitEnter(b1)
returns false. This node's children is not to be traversed.
!IMG_0255.jpg|width=545,height=245!
(img 0255)
visitLeave(b1) removes b1 from visited set. Now visited is emtpy.
!IMG_0256.jpg|width=528,height=294!
The last child of "a" is b2. VisitEnter(b2) returns true. It's children is to
be traversed. B2 is in visited set.
!IMG_0257.jpg|width=502,height=309!
B2's only child is "a". "a" is not in visited set, thus visitEnter(a) returns
true. The algorithm traverses this "a"'s children.
!IMG_0258.jpg|width=485,height=299!
(img 0258)
(...omit...)
IMG_0266 shows the step where I decided to give up. The algorithm does not seem
to stop. Indeed the test shows that. The path from the root to the furthest a
includes 5 "a" nodes.
!IMG_0266.jpg|width=656,height=252!
was:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code:java}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
h1. Illustration on why existing algorithm does not catch cycle
The following illustration tracks the node traversal for the test case above.
The illustration tracks the dependency node graph and the "visited" set
maintained by the visitor.
The initial state starts with node "a" and visited set \{a}.
!IMG_0234.jpg|width=334,height=252!
First child of a is b0. Because visited does not contain, visitEnter(b0)
returns true, meaning that the algorithm traverses this b0's children next. B0
is added to visited.
!IMG_0235.jpg|width=359,height=191!
B0's children is "a". Because visited set contains "a", visitEnter(a) returns
false. This means that the algorithm does not traverse this "a"'s children. A
is added to visited set (already it has).
!IMG_0236.jpg|width=438,height=197!
Now not traversing this "a"'s children, the algorithm calls visitLeave(a). This
removes "a" from visited set.
!IMG_0237.jpg|width=434,height=165!
B0's children are all traversed. the algorithm calls visitLeave(b0). This
removes "b0" from visited set.
!IMG_0238.jpg|width=459,height=197!
Now visited set is empty.
Next child of the root "a" is b1. B1 is not
[jira] [Updated] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MRESOLVER-93:
-
Description:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code:java}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
h1. Illustration on why existing algorithm does not catch cycle
The following illustration tracks the node traversal for the test case above.
The illustration tracks the dependency node graph and the "visited" set
maintained by the visitor.
The initial state starts with node "a" and visited set \{a}.
!IMG_0234.jpg|width=334,height=252!
First child of a is b0. Because visited does not contain, visitEnter(b0)
returns true, meaning that the algorithm traverses this b0's children next. B0
is added to visited.
!IMG_0235.jpg|width=359,height=191!
B0's children is "a". Because visited set contains "a", visitEnter(a) returns
false. This means that the algorithm does not traverse this "a"'s children. A
is added to visited set (already it has).
!IMG_0236.jpg|width=438,height=197!
Now not traversing this "a"'s children, the algorithm calls visitLeave(a). This
removes "a" from visited set.
!IMG_0237.jpg|width=434,height=165!
B0's children are all traversed. the algorithm calls visitLeave(b0). This
removes "b0" from visited set.
!IMG_0238.jpg|width=459,height=197!
Now visited set is empty.
Next child of the root "a" is b1. B1 is not in visited set, thus visitEnter(b1)
returns true. This means the algorithm traverses the children of this b1.
!IMG_0240.jpg|width=445,height=270!
B1's only child is a. "a" is not in visited set. visitEnter(a) returns true.
This means to traverse "a"'s children.
!IMG_0241.jpg|width=418,height=262!
A's first children is b0. b0 is not in visited set. visitEnter(b0) returns
true, meaning to traverse children of this b0.
!IMG_0242.jpg|width=422,height=208!
(img 0242)
The only child of b0 is "a". Visited set contains "a", and thus not traversing
its children.
!IMG_0243.jpg|width=491,height=191!
visitLeave(a) removes "a" from visited set.
!IMG_0244.jpg|width=481,height=189!
b0's children is all traversed. VisitLeave(b0) removes b0 from visited set.
!IMG_0245.jpg|width=498,height=182!
Next child of this "a" is b1. B1 is in visited set, and thus visitEnter(b1)
returns false. This node's children is not to be traversed.
!IMG_0255.jpg|width=545,height=245!
(img 0255)
visitLeave(b1) removes b1 from visited set. Now visited is emtpy.
!IMG_0256.jpg|width=528,height=294!
The last child of "a" is b2. VisitEnter(b2) returns true. It's children is to
be traversed. B2 is in visited set.
!IMG_0257.jpg|width=502,height=309!
B2's only child is "a". "a" is not in visited set, thus visitEnter(a) returns
true. The algorithm traverses this "a"'s children.
!IMG_0258.jpg|width=485,height=299!
(img 0258)
(...omit...)
IMG_0266 shows the step where I decided to give up. The algorithm does not seem
to stop. Indeed the test shows that. The path from the root to the furthest a
includes 5 "a" nodes.
!IMG_0266.jpg|width=656,height=252!
was:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code:java}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
Diagnosis with
The following illustration tracks the node traversal for the test case above.
The illustration tracks the dependency node graph and the "visited" set
maintained by the visitor.
The initial state starts with node "a" and visited set \{a}.
!IMG_0234.jpg|width=334,height=252!
First child of a is b0. Because visited does not contain, visitEnter(b0)
returns true. B0 is added to visited.
!IMG_0235.jpg|width=359,height=191!
> PathRecordingDependencyVisitor to handle 3 cycles
> -
>
> Key: MRESOLVER-93
> URL: https://issues.apache.org/jira/browse/MRESOLVER-93
> Project: Maven Resolver
> Issue Type: Improvement
> Components: resolver
>Affects Versions: 1.4.1
>Reporter: Tomo Suzuki
>Priority: Major
> Attachments: IMG_0234.jpg, IMG_0235.jpg, IMG_0236.jpg, IMG_0237.jpg,
> IMG_0238.jpg, IMG_0240.jpg, IMG_0241.jpg, IMG_0242.jpg, IMG_0243.jpg,
> IMG_0244.jpg, IMG_0245.jpg, IMG_0255.jpg, IMG_0256.jpg, IMG_0257.jpg,
> IMG_0258.jpg, IMG_0259.jpg, IMG_0260.jpg, IMG_0261.jpg, IMG_0262.jpg,
> IMG_0263.jpg, IMG_0264.jpg,
[jira] [Updated] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MRESOLVER-93:
-
Description:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code:java}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
Diagnosis with
The following illustration tracks the node traversal for the test case above.
The illustration tracks the dependency node graph and the "visited" set
maintained by the visitor.
The initial state starts with node "a" and visited set \{a}.
!IMG_0234.jpg|width=334,height=252!
First child of a is b0. Because visited does not contain, visitEnter(b0)
returns true. B0 is added to visited.
!IMG_0235.jpg|width=359,height=191!
was:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code:java}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
Diagnosis with
The following illustration tracks the node traversal for the test case above.
The illustration tracks the dependency node graph and the "visited" set
maintained by the visitor.
The initial state starts with node "a" and visited set \{a}.
!IMG_0234.jpg|width=334,height=252!
!IMG_0235.jpg!
> PathRecordingDependencyVisitor to handle 3 cycles
> -
>
> Key: MRESOLVER-93
> URL: https://issues.apache.org/jira/browse/MRESOLVER-93
> Project: Maven Resolver
> Issue Type: Improvement
> Components: resolver
>Affects Versions: 1.4.1
>Reporter: Tomo Suzuki
>Priority: Major
> Attachments: IMG_0234.jpg, IMG_0235.jpg, IMG_0236.jpg, IMG_0237.jpg,
> IMG_0238.jpg, IMG_0240.jpg, IMG_0241.jpg, IMG_0242.jpg, IMG_0243.jpg,
> IMG_0244.jpg, IMG_0245.jpg, IMG_0255.jpg, IMG_0256.jpg, IMG_0257.jpg,
> IMG_0258.jpg, IMG_0259.jpg, IMG_0260.jpg, IMG_0261.jpg, IMG_0262.jpg,
> IMG_0263.jpg, IMG_0264.jpg, IMG_0265.jpg, IMG_0266.jpg
>
>
> PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
> more cycles such as below:
>
> {code:java}
> gid:a:1 (1)
> +- gid:b:0
> | \- ^1
> +- gid:b:1
> | \- ^1
> \- gid:b:2
>\- ^1
> {code}
> It fails with StackOverflowError or OutOfMemoryError. [Test
> case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
>
> Diagnosis with
>
> The following illustration tracks the node traversal for the test case above.
> The illustration tracks the dependency node graph and the "visited" set
> maintained by the visitor.
>
> The initial state starts with node "a" and visited set \{a}.
> !IMG_0234.jpg|width=334,height=252!
> First child of a is b0. Because visited does not contain, visitEnter(b0)
> returns true. B0 is added to visited.
> !IMG_0235.jpg|width=359,height=191!
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[GitHub] [maven] Tibor17 commented on issue #262: [MNG-6695] Improve speed in collection merging
Tibor17 commented on issue #262: [MNG-6695] Improve speed in collection merging URL: https://github.com/apache/maven/pull/262#issuecomment-523044018 We have to squash the commits and trigger the build last time before pushing to master. 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 With regards, Apache Git Services
[jira] [Updated] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MRESOLVER-93:
-
Description:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code:java}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
Diagnosis with
The following illustration tracks the node traversal for the test case above.
The illustration tracks the dependency node graph and the "visited" set
maintained by the visitor.
The initial state starts with node "a" and visited set \{a}.
!IMG_0234.jpg|width=334,height=252!
!IMG_0235.jpg!
was:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
> PathRecordingDependencyVisitor to handle 3 cycles
> -
>
> Key: MRESOLVER-93
> URL: https://issues.apache.org/jira/browse/MRESOLVER-93
> Project: Maven Resolver
> Issue Type: Improvement
> Components: resolver
>Affects Versions: 1.4.1
>Reporter: Tomo Suzuki
>Priority: Major
> Attachments: IMG_0234.jpg, IMG_0235.jpg, IMG_0236.jpg, IMG_0237.jpg,
> IMG_0238.jpg, IMG_0240.jpg, IMG_0241.jpg, IMG_0242.jpg, IMG_0243.jpg,
> IMG_0244.jpg, IMG_0245.jpg, IMG_0255.jpg, IMG_0256.jpg, IMG_0257.jpg,
> IMG_0258.jpg, IMG_0259.jpg, IMG_0260.jpg, IMG_0261.jpg, IMG_0262.jpg,
> IMG_0263.jpg, IMG_0264.jpg, IMG_0265.jpg, IMG_0266.jpg
>
>
> PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
> more cycles such as below:
>
> {code:java}
> gid:a:1 (1)
> +- gid:b:0
> | \- ^1
> +- gid:b:1
> | \- ^1
> \- gid:b:2
>\- ^1
> {code}
> It fails with StackOverflowError or OutOfMemoryError. [Test
> case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
>
> Diagnosis with
>
> The following illustration tracks the node traversal for the test case above.
> The illustration tracks the dependency node graph and the "visited" set
> maintained by the visitor.
>
> The initial state starts with node "a" and visited set \{a}.
> !IMG_0234.jpg|width=334,height=252!
> !IMG_0235.jpg!
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MRESOLVER-93:
-
Attachment: IMG_0266.jpg
IMG_0265.jpg
IMG_0264.jpg
IMG_0263.jpg
IMG_0262.jpg
IMG_0261.jpg
IMG_0260.jpg
IMG_0259.jpg
IMG_0258.jpg
IMG_0257.jpg
IMG_0256.jpg
IMG_0255.jpg
IMG_0245.jpg
IMG_0244.jpg
IMG_0243.jpg
IMG_0242.jpg
IMG_0241.jpg
IMG_0240.jpg
IMG_0238.jpg
IMG_0237.jpg
IMG_0236.jpg
IMG_0235.jpg
IMG_0234.jpg
> PathRecordingDependencyVisitor to handle 3 cycles
> -
>
> Key: MRESOLVER-93
> URL: https://issues.apache.org/jira/browse/MRESOLVER-93
> Project: Maven Resolver
> Issue Type: Improvement
> Components: resolver
>Affects Versions: 1.4.1
>Reporter: Tomo Suzuki
>Priority: Major
> Attachments: IMG_0234.jpg, IMG_0235.jpg, IMG_0236.jpg, IMG_0237.jpg,
> IMG_0238.jpg, IMG_0240.jpg, IMG_0241.jpg, IMG_0242.jpg, IMG_0243.jpg,
> IMG_0244.jpg, IMG_0245.jpg, IMG_0255.jpg, IMG_0256.jpg, IMG_0257.jpg,
> IMG_0258.jpg, IMG_0259.jpg, IMG_0260.jpg, IMG_0261.jpg, IMG_0262.jpg,
> IMG_0263.jpg, IMG_0264.jpg, IMG_0265.jpg, IMG_0266.jpg
>
>
> PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
> more cycles such as below:
>
> {code}
> gid:a:1 (1)
> +- gid:b:0
> | \- ^1
> +- gid:b:1
> | \- ^1
> \- gid:b:2
>\- ^1
> {code}
> It fails with StackOverflowError or OutOfMemoryError. [Test
> case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (SUREFIRE-1688) Junit Platform test with failing @BeforeAll does not fail the build
Guy Brand created SUREFIRE-1688:
---
Summary: Junit Platform test with failing @BeforeAll does not fail
the build
Key: SUREFIRE-1688
URL: https://issues.apache.org/jira/browse/SUREFIRE-1688
Project: Maven Surefire
Issue Type: Bug
Components: JUnit 5.x support, Maven Surefire Plugin
Reporter: Guy Brand
When using Surefire {{3.0.0-SNAPSHOT}} and JUnit Platform {{5.4.2}} the
following test does not fail the Maven build.
{code:java}
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.Assertions;
public class Tests {
@BeforeAll
public static void beforeAll() { Assertions.fail("BeforeAll fail"); }
@Test
public void test() { Assertions.fail("Test fail"); }
}
{code}
And its output:
{code}
[INFO] --- maven-surefire-plugin:3.0.0-SNAPSHOT:test (default-test) @
top-level-project ---
[INFO]
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running Tests
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 s
- in Tests
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
{code}
When removing the {{@BeforeAll}} annotation/method it fails as expected.
{{3.0.0-M3}} version of Surefire works as expected:
{code}
[INFO] --- maven-surefire-plugin:3.0.0-M3:test (default-test) @
top-level-project ---
[INFO]
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running Tests
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.008 s
<<< FAILURE! - in Tests
[ERROR] Tests Time elapsed: 0.007 s <<< FAILURE!
org.opentest4j.AssertionFailedError: BeforeAll fail
at Tests.beforeAll(Tests.java:7)
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] Tests.beforeAll:7 BeforeAll fail
[INFO]
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
[INFO]
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 2.373 s
[INFO] Finished at: 2019-08-20T16:20:16+02:00
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M3:test (default-test) on
project top-level-project: There are test failures.
{code}
For all the tests Maven 3.6.1 has been used.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6742) org.sonatype.maven.polyglot.TeslaModelProcessor.locatePom(File) ignores files ending in.xml
[
https://issues.apache.org/jira/browse/MNG-6742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911390#comment-16911390
]
Christoph Läubrich commented on MNG-6742:
-
okay, sorry for confusion, I opened
https://github.com/takari/polyglot-maven/issues/192
> org.sonatype.maven.polyglot.TeslaModelProcessor.locatePom(File) ignores files
> ending in.xml
> ---
>
> Key: MNG-6742
> URL: https://issues.apache.org/jira/browse/MNG-6742
> Project: Maven
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Assignee: Robert Scholte
>Priority: Blocker
>
> in org.sonatype.maven.polyglot.TeslaModelProcessor.locatePom(File) there is
> the following code:
> {code:java}
> File pomFile = manager.locatePom(dir);
> if (pomFile != null && !pomFile.getName().endsWith(".pom") &&
> !pomFile.getName().endsWith(".xml")) {
> ...
> }
> {code}
> This makes it impossible to return any file with xml ending as alternative to
> pom.xml, in my case data is stored in a file named category.xml and i can't
> use ist because then my Mapping is never called.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Closed] (MNG-6742) org.sonatype.maven.polyglot.TeslaModelProcessor.locatePom(File) ignores files ending in.xml
[
https://issues.apache.org/jira/browse/MNG-6742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-6742.
---
Assignee: Robert Scholte
Resolution: Invalid
As mentioned by [~mickael.istria], this is a polyglot-maven issue, which is not
maintained by the Apache Maven project.
> org.sonatype.maven.polyglot.TeslaModelProcessor.locatePom(File) ignores files
> ending in.xml
> ---
>
> Key: MNG-6742
> URL: https://issues.apache.org/jira/browse/MNG-6742
> Project: Maven
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Assignee: Robert Scholte
>Priority: Blocker
>
> in org.sonatype.maven.polyglot.TeslaModelProcessor.locatePom(File) there is
> the following code:
> {code:java}
> File pomFile = manager.locatePom(dir);
> if (pomFile != null && !pomFile.getName().endsWith(".pom") &&
> !pomFile.getName().endsWith(".xml")) {
> ...
> }
> {code}
> This makes it impossible to return any file with xml ending as alternative to
> pom.xml, in my case data is stored in a file named category.xml and i can't
> use ist because then my Mapping is never called.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[GitHub] [maven-dependency-plugin] Tibor17 commented on a change in pull request #19: [MDEP-579] - Add mirrors, proxies and authentication for remote repositories.
Tibor17 commented on a change in pull request #19: [MDEP-579] - Add mirrors,
proxies and authentication for remote repositories.
URL:
https://github.com/apache/maven-dependency-plugin/pull/19#discussion_r315697595
##
File path: src/test/java/org/apache/maven/plugins/dependency/TestGetMojo.java
##
@@ -150,4 +192,47 @@ public void testParseRepository()
// expected
}
}
+
+private ContextHandler createContextHandler() {
Review comment:
The same here (spaces).
Bracket should be on a new line:
```
private ContextHandler createContextHandler()
{
```
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
With regards,
Apache Git Services
[GitHub] [maven-dependency-plugin] Tibor17 commented on a change in pull request #19: [MDEP-579] - Add mirrors, proxies and authentication for remote repositories.
Tibor17 commented on a change in pull request #19: [MDEP-579] - Add mirrors, proxies and authentication for remote repositories. URL: https://github.com/apache/maven-dependency-plugin/pull/19#discussion_r315697889 ## File path: src/test/resources/unit/get-test/realm.properties ## @@ -0,0 +1,19 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. + +# username: password[,rolename ...] +foo: bar,userrole Review comment: add an emty line. 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 With regards, Apache Git Services
[GitHub] [maven-dependency-plugin] Tibor17 commented on a change in pull request #19: [MDEP-579] - Add mirrors, proxies and authentication for remote repositories.
Tibor17 commented on a change in pull request #19: [MDEP-579] - Add mirrors, proxies and authentication for remote repositories. URL: https://github.com/apache/maven-dependency-plugin/pull/19#discussion_r315697110 ## File path: src/test/java/org/apache/maven/plugins/dependency/TestGetMojo.java ## @@ -48,7 +62,14 @@ protected void setUp() assertNotNull( mojo ); LegacySupport legacySupport = lookup( LegacySupport.class ); -legacySupport.setSession( newMavenSession( new MavenProjectStub() ) ); +MavenSession session = newMavenSession(new MavenProjectStub()); +Settings settings = session.getSettings(); +Server server = new Server(); +server.setId( "myserver" ); +server.setUsername( "foo" ); +server.setPassword( "bar" ); +settings.addServer(server); Review comment: add spaces like his: `settings.addServer( server )` 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 With regards, Apache Git Services
[GitHub] [maven-dependency-plugin] Tibor17 commented on a change in pull request #19: [MDEP-579] - Add mirrors, proxies and authentication for remote repositories.
Tibor17 commented on a change in pull request #19: [MDEP-579] - Add mirrors, proxies and authentication for remote repositories. URL: https://github.com/apache/maven-dependency-plugin/pull/19#discussion_r315696215 ## File path: src/test/resources/unit/get-test/repository/test/test/1.0/test-1.0.pom ## @@ -0,0 +1,41 @@ + + +http://maven.apache.org/POM/4.0.0; + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; + xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd;> + 4.0.0 + + test + test + 1.0 + + + + +maven-compiler-plugin Review comment: We don't need to have a plugin for this. This is enough: ``` 1.7 1.7 ``` 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 With regards, Apache Git Services
[GitHub] [maven-dependency-plugin] Tibor17 commented on a change in pull request #19: [MDEP-579] - Add mirrors, proxies and authentication for remote repositories.
Tibor17 commented on a change in pull request #19: [MDEP-579] - Add mirrors,
proxies and authentication for remote repositories.
URL:
https://github.com/apache/maven-dependency-plugin/pull/19#discussion_r315694310
##
File path: src/test/java/org/apache/maven/plugins/dependency/TestGetMojo.java
##
@@ -96,6 +117,27 @@ public void testRemoteRepositories()
mojo.execute();
}
+/**
+ * Test remote repositories parameter with basic authentication
+ *
+ * @throws Exception in case of errors
+ */
+public void testRemoteRepositoriesAuthentication()
+throws Exception
+{
+org.eclipse.jetty.server.Server server = createServer( 8000 );
Review comment:
A concrete prort cannot be. We use the wildcard port `0.0.0.0` and the
client connects to the server's local port.
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
With regards,
Apache Git Services
[GitHub] [maven-dependency-plugin] Tibor17 commented on a change in pull request #19: [MDEP-579] - Add mirrors, proxies and authentication for remote repositories.
Tibor17 commented on a change in pull request #19: [MDEP-579] - Add mirrors,
proxies and authentication for remote repositories.
URL:
https://github.com/apache/maven-dependency-plugin/pull/19#discussion_r315693715
##
File path: src/test/java/org/apache/maven/plugins/dependency/TestGetMojo.java
##
@@ -96,6 +117,27 @@ public void testRemoteRepositories()
mojo.execute();
}
+/**
+ * Test remote repositories parameter with basic authentication
+ *
+ * @throws Exception in case of errors
+ */
+public void testRemoteRepositoriesAuthentication()
+throws Exception
+{
+org.eclipse.jetty.server.Server server = createServer( 8000 );
+server.start();
+
+setVariableValueToObject( mojo, "remoteRepositories",
"myserver::default::http://localhost:8000/maven; );
+mojo.setGroupId( "test" );
+mojo.setArtifactId( "test" );
+mojo.setVersion( "1.0" );
+
+mojo.execute();
+
+server.stop();
Review comment:
Pls call it within the `finally` block. This is a typical problem of
integration tests that they failed and the server is never stopped.
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
With regards,
Apache Git Services
[jira] [Commented] (MNG-6740) Provide a way to override properties of a polyglot build
[ https://issues.apache.org/jira/browse/MNG-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911359#comment-16911359 ] Mickael Istria commented on MNG-6740: - Actually, it also looks like something that's not in Maven Core, but instead in polyglot-maven: https://github.com/takari/polyglot-maven/issues/new > Provide a way to override properties of a polyglot build > > > Key: MNG-6740 > URL: https://issues.apache.org/jira/browse/MNG-6740 > Project: Maven > Issue Type: New Feature >Reporter: Christoph Läubrich >Priority: Major > > polyglot allows to generate maven models out of other metadata that pom.xml > via extensions. > This is great and offers high flexibility for advanced use-cases but comes > with the cost that it is not as easy to modify certain settings or properties > if the data is derived from other sources. > For example [Eclipse Tycho|https://www.eclipse.org/tycho/] generates models > out of OSGi/PDE metadata but can often only guess what is the right thing to > use for example as artifactId, and it can't know of any custom properties a > user might wish to set. > While it is always possible to create custom crafted poms, this contradicts > the approach which goal is to reuse as many metadata as possible, and the > user only wants do configure a really small portion of it (e.g. the > description or a single poperty). > [A proposal was made to integrate support for this inside the tycho > extension|https://bugs.eclipse.org/bugs/show_bug.cgi?id=550239], but because > it might be of wider use I'd like to evaluate (as suggestes by Mickael > Istria) if it is possible to implement/add this as a more generic feature > directly into the maven project. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[GitHub] [maven-dependency-plugin] pmoerenhout opened a new pull request #19: [MDEP-579] - Add mirrors, proxies and authentication for remote repositories.
pmoerenhout opened a new pull request #19: [MDEP-579] - Add mirrors, proxies and authentication for remote repositories. URL: https://github.com/apache/maven-dependency-plugin/pull/19 - [X] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [X] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). This new pull request makes pull request https://github.com/apache/maven-dependency-plugin/pull/18 redundant. It includes now a Jetty server on port 8000 to test the authentication. 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 With regards, Apache Git Services
[jira] [Updated] (MNG-6741) Modules aggregation from parent does not work
[ https://issues.apache.org/jira/browse/MNG-6741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Lehmann updated MNG-6741: Attachment: demo-maven-modules.zip > Modules aggregation from parent does not work > - > > Key: MNG-6741 > URL: https://issues.apache.org/jira/browse/MNG-6741 > Project: Maven > Issue Type: Bug >Reporter: Thomas Lehmann >Priority: Major > Attachments: demo-maven-modules.zip > > > Hi Maven Team, > for testing purpose I have a simple setup: > * three modules in parallel > ** one for the "build" with a relative path to the "parent" > ** one for the "parent" with the modules section having "../math" as one > module > (for now without any profile) > ** one for the "math" with a relative path to the "parent" > * I'm running in the root *Maven 3.6.1* with *mvn -f build clean* > My expectation: > * I would like to see "math" in the reactor build order and summary (which > is not the case) > > Of course using " ... " just in the build/pom.xml works > fine. > My intention was to split up modules definitions of a real project into > different profiles in the parent pom being surprised that no module were > suddently recognized when trying to build. > That link does describes my intention so I assumed it just work fine: > https://www.smartics.eu/confluence/display/BLOG/2013/07/22/Using+Aggregate+and+Parent+POMs > I can say that it also doesn't work with 3.3.9. > Maybe I missed a certain instruction being required ... then I'm sorry and > asking you ... please let me know. > Kind Regards, > Thomas -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6741) Modules aggregation from parent does not work
[ https://issues.apache.org/jira/browse/MNG-6741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911325#comment-16911325 ] Thomas Lehmann commented on MNG-6741: -- [^demo-maven-modules.zip] > Modules aggregation from parent does not work > - > > Key: MNG-6741 > URL: https://issues.apache.org/jira/browse/MNG-6741 > Project: Maven > Issue Type: Bug >Reporter: Thomas Lehmann >Priority: Major > Attachments: demo-maven-modules.zip > > > Hi Maven Team, > for testing purpose I have a simple setup: > * three modules in parallel > ** one for the "build" with a relative path to the "parent" > ** one for the "parent" with the modules section having "../math" as one > module > (for now without any profile) > ** one for the "math" with a relative path to the "parent" > * I'm running in the root *Maven 3.6.1* with *mvn -f build clean* > My expectation: > * I would like to see "math" in the reactor build order and summary (which > is not the case) > > Of course using " ... " just in the build/pom.xml works > fine. > My intention was to split up modules definitions of a real project into > different profiles in the parent pom being surprised that no module were > suddently recognized when trying to build. > That link does describes my intention so I assumed it just work fine: > https://www.smartics.eu/confluence/display/BLOG/2013/07/22/Using+Aggregate+and+Parent+POMs > I can say that it also doesn't work with 3.3.9. > Maybe I missed a certain instruction being required ... then I'm sorry and > asking you ... please let me know. > Kind Regards, > Thomas -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6742) org.sonatype.maven.polyglot.TeslaModelProcessor.locatePom(File) ignores files ending in.xml
[
https://issues.apache.org/jira/browse/MNG-6742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911308#comment-16911308
]
Mickael Istria commented on MNG-6742:
-
Shouldn't it be reported to https://github.com/takari/polyglot-maven/issues
instead?
> org.sonatype.maven.polyglot.TeslaModelProcessor.locatePom(File) ignores files
> ending in.xml
> ---
>
> Key: MNG-6742
> URL: https://issues.apache.org/jira/browse/MNG-6742
> Project: Maven
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Blocker
>
> in org.sonatype.maven.polyglot.TeslaModelProcessor.locatePom(File) there is
> the following code:
> {code:java}
> File pomFile = manager.locatePom(dir);
> if (pomFile != null && !pomFile.getName().endsWith(".pom") &&
> !pomFile.getName().endsWith(".xml")) {
> ...
> }
> {code}
> This makes it impossible to return any file with xml ending as alternative to
> pom.xml, in my case data is stored in a file named category.xml and i can't
> use ist because then my Mapping is never called.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MRESOLVER-93:
-
Description:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
was:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError.
> PathRecordingDependencyVisitor to handle 3 cycles
> -
>
> Key: MRESOLVER-93
> URL: https://issues.apache.org/jira/browse/MRESOLVER-93
> Project: Maven Resolver
> Issue Type: Improvement
> Components: resolver
>Affects Versions: 1.4.1
>Reporter: Tomo Suzuki
>Priority: Major
>
> PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
> more cycles such as below:
>
> {code}
> gid:a:1 (1)
> +- gid:b:0
> | \- ^1
> +- gid:b:1
> | \- ^1
> \- gid:b:2
>\- ^1
> {code}
> It fails with StackOverflowError or OutOfMemoryError. [Test
> case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6742) org.sonatype.maven.polyglot.TeslaModelProcessor.locatePom(File) ignores files ending in.xml
[
https://issues.apache.org/jira/browse/MNG-6742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911283#comment-16911283
]
Mickael Istria commented on MNG-6742:
-
This is blocking https://bugs.eclipse.org/bugs/show_bug.cgi?id=490886.
Tycho hacked this for feature.xml by assuming there is always a
build.properties file with it, but it's a hack and cannot be relied upon for
some other types.
I suggest we just fix it in Maven by refining the condition.
> org.sonatype.maven.polyglot.TeslaModelProcessor.locatePom(File) ignores files
> ending in.xml
> ---
>
> Key: MNG-6742
> URL: https://issues.apache.org/jira/browse/MNG-6742
> Project: Maven
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Blocker
>
> in org.sonatype.maven.polyglot.TeslaModelProcessor.locatePom(File) there is
> the following code:
> {code:java}
> File pomFile = manager.locatePom(dir);
> if (pomFile != null && !pomFile.getName().endsWith(".pom") &&
> !pomFile.getName().endsWith(".xml")) {
> ...
> }
> {code}
> This makes it impossible to return any file with xml ending as alternative to
> pom.xml, in my case data is stored in a file named category.xml and i can't
> use ist because then my Mapping is never called.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
Tomo Suzuki created MRESOLVER-93:
Summary: PathRecordingDependencyVisitor to handle 3 cycles
Key: MRESOLVER-93
URL: https://issues.apache.org/jira/browse/MRESOLVER-93
Project: Maven Resolver
Issue Type: Improvement
Components: resolver
Affects Versions: 1.4.1
Reporter: Tomo Suzuki
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (MNG-6742) org.sonatype.maven.polyglot.TeslaModelProcessor.locatePom(File) ignores files ending in.xml
Christoph Läubrich created MNG-6742:
---
Summary:
org.sonatype.maven.polyglot.TeslaModelProcessor.locatePom(File) ignores files
ending in.xml
Key: MNG-6742
URL: https://issues.apache.org/jira/browse/MNG-6742
Project: Maven
Issue Type: Bug
Reporter: Christoph Läubrich
in org.sonatype.maven.polyglot.TeslaModelProcessor.locatePom(File) there is the
following code:
{code:java}
File pomFile = manager.locatePom(dir);
if (pomFile != null && !pomFile.getName().endsWith(".pom") &&
!pomFile.getName().endsWith(".xml")) {
...
}
{code}
This makes it impossible to return any file with xml ending as alternative to
pom.xml, in my case data is stored in a file named category.xml and i can't use
ist because then my Mapping is never called.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6741) Modules aggregation from parent does not work
[ https://issues.apache.org/jira/browse/MNG-6741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911249#comment-16911249 ] Michael Osipov commented on MNG-6741: - Please provide a sample project for this. > Modules aggregation from parent does not work > - > > Key: MNG-6741 > URL: https://issues.apache.org/jira/browse/MNG-6741 > Project: Maven > Issue Type: Bug >Reporter: Thomas Lehmann >Priority: Major > > Hi Maven Team, > for testing purpose I have a simple setup: > * three modules in parallel > ** one for the "build" with a relative path to the "parent" > ** one for the "parent" with the modules section having "../math" as one > module > (for now without any profile) > ** one for the "math" with a relative path to the "parent" > * I'm running in the root *Maven 3.6.1* with *mvn -f build clean* > My expectation: > * I would like to see "math" in the reactor build order and summary (which > is not the case) > > Of course using " ... " just in the build/pom.xml works > fine. > My intention was to split up modules definitions of a real project into > different profiles in the parent pom being surprised that no module were > suddently recognized when trying to build. > That link does describes my intention so I assumed it just work fine: > https://www.smartics.eu/confluence/display/BLOG/2013/07/22/Using+Aggregate+and+Parent+POMs > I can say that it also doesn't work with 3.3.9. > Maybe I missed a certain instruction being required ... then I'm sorry and > asking you ... please let me know. > Kind Regards, > Thomas -- This message was sent by Atlassian Jira (v8.3.2#803003)
[GitHub] [maven] Tibor17 commented on issue #262: [MNG-6695] Improve speed in collection merging
Tibor17 commented on issue #262: [MNG-6695] Improve speed in collection merging URL: https://github.com/apache/maven/pull/262#issuecomment-522974362 @michael-o In the afternoon I will show you what I mean in another commit. Maybe I will have the answer from the author. 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 With regards, Apache Git Services
[jira] [Created] (MNG-6741) Modules aggregation from parent does not work
Thomas Lehmann created MNG-6741: Summary: Modules aggregation from parent does not work Key: MNG-6741 URL: https://issues.apache.org/jira/browse/MNG-6741 Project: Maven Issue Type: Bug Reporter: Thomas Lehmann Hi Maven Team, for testing purpose I have a simple setup: * three modules in parallel ** one for the "build" with a relative path to the "parent" ** one for the "parent" with the modules section having "../math" as one module (for now without any profile) ** one for the "math" with a relative path to the "parent" * I'm running in the root *Maven 3.6.1* with *mvn -f build clean* My expectation: * I would like to see "math" in the reactor build order and summary (which is not the case) Of course using " ... " just in the build/pom.xml works fine. My intention was to split up modules definitions of a real project into different profiles in the parent pom being surprised that no module were suddently recognized when trying to build. That link does describes my intention so I assumed it just work fine: https://www.smartics.eu/confluence/display/BLOG/2013/07/22/Using+Aggregate+and+Parent+POMs I can say that it also doesn't work with 3.3.9. Maybe I missed a certain instruction being required ... then I'm sorry and asking you ... please let me know. Kind Regards, Thomas -- This message was sent by Atlassian Jira (v8.3.2#803003)
[GitHub] [maven] eolivelli edited a comment on issue #262: [MNG-6695] Improve speed in collection merging
eolivelli edited a comment on issue #262: [MNG-6695] Improve speed in collection merging URL: https://github.com/apache/maven/pull/262#issuecomment-522973062 +1 @michael-o 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 With regards, Apache Git Services
[GitHub] [maven] eolivelli commented on issue #262: [MNG-6695] Improve speed in collection merging
eolivelli commented on issue #262: [MNG-6695] Improve speed in collection merging URL: https://github.com/apache/maven/pull/262#issuecomment-522973062 +1 @michel-o 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 With regards, Apache Git Services
[jira] [Commented] (MNG-6740) Provide a way to override properties of a polyglot build
[ https://issues.apache.org/jira/browse/MNG-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911209#comment-16911209 ] Mickael Istria commented on MNG-6740: - +1 for this feature in Maven. Most polyglot extensions will have such caveats as some missing Maven properties to infer, Maven should provide a generic way to fill the gap. In the proposal, it's about a properties file, but I imagine it could also (or maybe better) take the form of a partial pom file with only the few additional properties or elements to complete what the extension generates. > Provide a way to override properties of a polyglot build > > > Key: MNG-6740 > URL: https://issues.apache.org/jira/browse/MNG-6740 > Project: Maven > Issue Type: New Feature >Reporter: Christoph Läubrich >Priority: Major > > polyglot allows to generate maven models out of other metadata that pom.xml > via extensions. > This is great and offers high flexibility for advanced use-cases but comes > with the cost that it is not as easy to modify certain settings or properties > if the data is derived from other sources. > For example [Eclipse Tycho|https://www.eclipse.org/tycho/] generates models > out of OSGi/PDE metadata but can often only guess what is the right thing to > use for example as artifactId, and it can't know of any custom properties a > user might wish to set. > While it is always possible to create custom crafted poms, this contradicts > the approach which goal is to reuse as many metadata as possible, and the > user only wants do configure a really small portion of it (e.g. the > description or a single poperty). > [A proposal was made to integrate support for this inside the tycho > extension|https://bugs.eclipse.org/bugs/show_bug.cgi?id=550239], but because > it might be of wider use I'd like to evaluate (as suggestes by Mickael > Istria) if it is possible to implement/add this as a more generic feature > directly into the maven project. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (MNG-6740) Provide a way to override properties of a polyglot build
[ https://issues.apache.org/jira/browse/MNG-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christoph Läubrich updated MNG-6740: Description: polyglot allows to generate maven models out of other metadata that pom.xml via extensions. This is great and offers high flexibility for advanced use-cases but comes with the cost that it is not as easy to modify certain settings or properties if the data is derived from other sources. For example [Eclipse Tycho|https://www.eclipse.org/tycho/] generates models out of OSGi/PDE metadata but can often only guess what is the right thing to use for example as artifactId, and it can't know of any custom properties a user might wish to set. While it is always possible to create custom crafted poms, this contradicts the approach which goal is to reuse as many metadata as possible, and the user only wants do configure a really small portion of it (e.g. the description or a single poperty). [A proposal was made to integrate support for this inside the tycho extension|https://bugs.eclipse.org/bugs/show_bug.cgi?id=550239], but because it might be of wider use I'd like to evaluate (as suggestes by Mickael Istria) if it is possible to implement/add this as a more generic feature directly into the maven project. was: polyglot allows to generate maven models out of other metadata that pom.xml via extensions. This is great and offers high flexibility for advanced use-cases but comes with the cost that it is not as easy to modify certain settings or properties if the data is derived from other sources. For example [Eclipse Tycho|http://example.com] generates models out of OSGi/PDE metadata but can often only guess what is the right thing to use for example as artifactId, and it can't know of any custom properties a user might wish to set. While it is always possible to create custom crafted poms, this contradicts the approach which goal is to reuse as many metadata as possible, and the user only wants do configure a really small portion of it (e.g. the description or a single poperty). [A proposal was made to integrate support for this inside the tycho extension|https://bugs.eclipse.org/bugs/show_bug.cgi?id=550239], but because it might be of wider use I'd like to evaluate (as suggestes by Mickael Istria) if it is possible to implement/add this as a more generic feature directly into the maven project. > Provide a way to override properties of a polyglot build > > > Key: MNG-6740 > URL: https://issues.apache.org/jira/browse/MNG-6740 > Project: Maven > Issue Type: New Feature >Reporter: Christoph Läubrich >Priority: Major > > polyglot allows to generate maven models out of other metadata that pom.xml > via extensions. > This is great and offers high flexibility for advanced use-cases but comes > with the cost that it is not as easy to modify certain settings or properties > if the data is derived from other sources. > For example [Eclipse Tycho|https://www.eclipse.org/tycho/] generates models > out of OSGi/PDE metadata but can often only guess what is the right thing to > use for example as artifactId, and it can't know of any custom properties a > user might wish to set. > While it is always possible to create custom crafted poms, this contradicts > the approach which goal is to reuse as many metadata as possible, and the > user only wants do configure a really small portion of it (e.g. the > description or a single poperty). > [A proposal was made to integrate support for this inside the tycho > extension|https://bugs.eclipse.org/bugs/show_bug.cgi?id=550239], but because > it might be of wider use I'd like to evaluate (as suggestes by Mickael > Istria) if it is possible to implement/add this as a more generic feature > directly into the maven project. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (MNG-6740) Provide a way to override properties of a polyglot build
Christoph Läubrich created MNG-6740: --- Summary: Provide a way to override properties of a polyglot build Key: MNG-6740 URL: https://issues.apache.org/jira/browse/MNG-6740 Project: Maven Issue Type: New Feature Reporter: Christoph Läubrich polyglot allows to generate maven models out of other metadata that pom.xml via extensions. This is great and offers high flexibility for advanced use-cases but comes with the cost that it is not as easy to modify certain settings or properties if the data is derived from other sources. For example [Eclipse Tycho|http://example.com] generates models out of OSGi/PDE metadata but can often only guess what is the right thing to use for example as artifactId, and it can't know of any custom properties a user might wish to set. While it is always possible to create custom crafted poms, this contradicts the approach which goal is to reuse as many metadata as possible, and the user only wants do configure a really small portion of it (e.g. the description or a single poperty). [A proposal was made to integrate support for this inside the tycho extension|https://bugs.eclipse.org/bugs/show_bug.cgi?id=550239], but because it might be of wider use I'd like to evaluate (as suggestes by Mickael Istria) if it is possible to implement/add this as a more generic feature directly into the maven project. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MASSEMBLY-907) Dependencies are not included when run with mvn install
[ https://issues.apache.org/jira/browse/MASSEMBLY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911189#comment-16911189 ] Mark Symons commented on MASSEMBLY-907: --- Is there any progress on this? Our teams ran into exactly the same problem after upgrading from 3.1.0 to 3.1.1. Like [~lbakman], we also have bouncy castle dependencies that necesitate usage of 3.1.1 due to MASSEMBLY-873. > Dependencies are not included when run with mvn install > --- > > Key: MASSEMBLY-907 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-907 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.1.1 >Reporter: Lau Bakman >Assignee: Karl Heinz Marbaise >Priority: Major > Attachments: 310_install.log, 310_install_verbose.log, > 311_install.log, 311_install_verbose.log, 311_package_verbose.log, > assembly_deps.zip > > > We have just updated to version 3.1.1 due to MASSEMBLY-873 and have stumbled > upon a problem. > Our project is structured similar to the attached project. When we build our > project using "mvn clean package" the project is assembled correctly > including dependencies. If we on the other hand build our project using "mvn > clean install", only the top level jar files are assembled and all > dependencies are missing. > This worked in version 3.1.0. > Is this by design? And if it is, is there a way to revert to the old behavior? -- This message was sent by Atlassian Jira (v8.3.2#803003)
[GitHub] [maven-surefire] Tibor17 edited a comment on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Tibor17 edited a comment on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-522944865 @jon-bell Generally, it looks good. I have left only few comments. Pls open the MOJO classes. You will see `rerunFailingTestsCount`. Extend the JavaDoc and add a new support for JUnit5 with all known limitations if any exist. 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 With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Tibor17 commented on a change in pull request #245: Surefire-1584: Add option
to rerun failing tests for JUnit5
URL: https://github.com/apache/maven-surefire/pull/245#discussion_r315607380
##
File path:
surefire-its/src/test/java/org/apache/maven/surefire/its/JUnitPlatformRerunFailingTestsIT.java
##
@@ -0,0 +1,268 @@
+package org.apache.maven.surefire.its;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import org.apache.maven.surefire.its.fixture.OutputValidator;
+import org.apache.maven.surefire.its.fixture.SurefireJUnit4IntegrationTestCase;
+import org.apache.maven.surefire.its.fixture.SurefireLauncher;
+import org.junit.Test;
+
+/**
+ * JUnit4 RunListener Integration Test.
+ *
+ * @author mailto:qingzhou...@google.com;>Qingzhou Luo
+ * @author Matt Coley
+ */
+public class JUnitPlatformRerunFailingTestsIT extends
SurefireJUnit4IntegrationTestCase
+{
+private final static String GOAL = "-Dprovider=surefire-junit-platform";
Review comment:
Normally you should not force internal providers like this; otherwise we
have a new bug.
The MOJO should find dependencies and use the right provider automatically.
You can turn on the debug level and see the log. Alternativelly you can
assert that the provider is running if you really want to check it.
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
With regards,
Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-522944865 @jon-bell Generally, it looks good. I have left only few comments. Pls open the MOJO classes. You will see `rerunFailingTestsCount`. Extend the JavaDoc and add a new support for JUnit5 will all limitations if any exist. 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 With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Tibor17 commented on a change in pull request #245: Surefire-1584: Add option
to rerun failing tests for JUnit5
URL: https://github.com/apache/maven-surefire/pull/245#discussion_r315605236
##
File path:
surefire-its/src/test/java/org/apache/maven/surefire/its/JUnitPlatformRerunFailingTestsIT.java
##
@@ -0,0 +1,268 @@
+package org.apache.maven.surefire.its;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import org.apache.maven.surefire.its.fixture.OutputValidator;
+import org.apache.maven.surefire.its.fixture.SurefireJUnit4IntegrationTestCase;
+import org.apache.maven.surefire.its.fixture.SurefireLauncher;
+import org.junit.Test;
+
+/**
+ * JUnit4 RunListener Integration Test.
+ *
+ * @author mailto:qingzhou...@google.com;>Qingzhou Luo
+ * @author Matt Coley
+ */
+public class JUnitPlatformRerunFailingTestsIT extends
SurefireJUnit4IntegrationTestCase
+{
+private final static String GOAL = "-Dprovider=surefire-junit-platform";
+private final static String VERSION = "5.4.2";
Review comment:
Have you tried to run the tests with `5.5.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
With regards,
Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Tibor17 commented on a change in pull request #245: Surefire-1584: Add option
to rerun failing tests for JUnit5
URL: https://github.com/apache/maven-surefire/pull/245#discussion_r315603657
##
File path:
surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProvider.java
##
@@ -147,7 +149,26 @@ private TestsToRun scanClasspath()
private void invokeAllTests( TestsToRun testsToRun, RunListener
runListener )
{
LauncherDiscoveryRequest discoveryRequest =
buildLauncherDiscoveryRequest( testsToRun );
-launcher.execute( discoveryRequest, new RunListenerAdapter(
runListener ) );
+RunListenerAdapter adapter = new RunListenerAdapter( runListener );
+launcher.execute( discoveryRequest, adapter );
+// Rerun failing tests if requested
+int count = parameters.getTestRequest().getRerunFailingTestsCount();
+if ( count > 0 && adapter.hasFailingTests() )
+{
+for ( int i = 0; i < count; i++ )
+{
+// Replace the "discoveryRequest" so that it only specifies
the failing tests
+discoveryRequest =
buildLauncherDiscoveryRequestForRerunFailures( adapter );
+// Reset adapter's recorded failures and invoke the tests again
Review comment:
Added one word: `// Reset adapter's recorded failures and invoke the failed
tests again`
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
With regards,
Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Tibor17 commented on a change in pull request #245: Surefire-1584: Add option
to rerun failing tests for JUnit5
URL: https://github.com/apache/maven-surefire/pull/245#discussion_r315601476
##
File path:
surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/RunListenerAdapter.java
##
@@ -259,4 +261,50 @@ else if ( testSource.filter(
ClassSource.class::isInstance ).isPresent() )
return new String[] { source, source, display, display };
}
}
+
+public String[] toClassMethodNameWithoutPlan( TestIdentifier
testIdentifier )
Review comment:
I am not totally convinced about this method because there is already one
which returns `String[4]`. I would vote for a generic approach avoiding code
duplication in single class.
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
With regards,
Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Tibor17 commented on a change in pull request #245: Surefire-1584: Add option
to rerun failing tests for JUnit5
URL: https://github.com/apache/maven-surefire/pull/245#discussion_r315600822
##
File path:
surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/RunListenerAdapter.java
##
@@ -47,6 +47,7 @@
implements TestExecutionListener
{
private final ConcurrentMap testStartTime = new
ConcurrentHashMap<>();
+private final ConcurrentMap failures
= new ConcurrentHashMap<>();
Review comment:
`failures` should be cleaned up when the tests finished.
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
With regards,
Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Tibor17 commented on a change in pull request #245: Surefire-1584: Add option
to rerun failing tests for JUnit5
URL: https://github.com/apache/maven-surefire/pull/245#discussion_r315600822
##
File path:
surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/RunListenerAdapter.java
##
@@ -47,6 +47,7 @@
implements TestExecutionListener
{
private final ConcurrentMap testStartTime = new
ConcurrentHashMap<>();
+private final ConcurrentMap failures
= new ConcurrentHashMap<>();
Review comment:
`failures` should be cleaned up when all tests have finished.
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
With regards,
Apache Git Services
[jira] [Created] (MDEP-659) dependency:unpack / needs the option of unpacking sub-directory AND ignoring parent folders
Jasper Teng created MDEP-659:
Summary: dependency:unpack / needs the option of unpacking
sub-directory AND ignoring parent folders
Key: MDEP-659
URL: https://issues.apache.org/jira/browse/MDEP-659
Project: Maven Dependency Plugin
Issue Type: Bug
Components: unpack
Affects Versions: 3.1.1
Environment: Windows 10 / Eclipse Maven
Reporter: Jasper Teng
The current goal is able to unpack specific sub-directory of a zip type
artifact by using the "includes" parameter. However, the tree structure of the
sub-directory is maintained as well.
For example:
myartifact-version.zip
{noformat}
myartifact-version
'-folder1
'-...
'-folder2
'-...{noformat}
pom.xml
{noformat}
...
org.apache.maven.plugins
maven-dependency-plugin
unpack-igate-distribution
generate-resources
unpack
com.example
myartifact
${myartifact.version}
zip
true
${project.build.directory}/myartifact
myartifact-*/**
...{noformat}
Result
{noformat}
myproject
'-target
'-myartifact
'-myartifact-version
'-folder1
'-...
'-folder2
'-...{noformat}
However, I want to be able to change the pom.xml, to achieve the following
result:
{noformat}
myproject
'-target
'-myartifact
'-folder1
'-...
'-folder2
'-...{noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MPIR-373) Upgrade from 2.9 to 3.0.0 introduces additional warning
[
https://issues.apache.org/jira/browse/MPIR-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1691#comment-1691
]
Hudson commented on MPIR-373:
-
Build succeeded in Jenkins: Maven TLP » maven-project-info-reports-plugin »
master #60
See
https://builds.apache.org/job/maven-box/job/maven-project-info-reports-plugin/job/master/60/
> Upgrade from 2.9 to 3.0.0 introduces additional warning
> ---
>
> Key: MPIR-373
> URL: https://issues.apache.org/jira/browse/MPIR-373
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: GWR
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.0.1
>
> Attachments: pom.xml
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> a new warning-message introduced, causing some confusion in the devteam.
> When stepping up to maven-project-info-reports-plugin:3.0.0 (from2.9) the
> stacktrace below is seen.
> mvn3.0.5, 3.3.9 and 3.5.2 all give same stacktrace.
> Seems to caused by the xml-resolver:1.2, having a pom.xml containing the
> section.
>
> {code:java}
>
> deployed
>
> {code}
> Is there some more restrictive pom validation introduced with
> maven-project-info-reports-plugin:3.0.0
> {code:java}
> $ mvn project-info-reports:dependencies
> [WARNING] Unable to create Maven project from repository for artifact
> xml-resolver:xml-resolver:jar:1.2
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs:
> [ERROR] 'distributionManagement.status' must not be specified. @ line 36,
> column 13
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:191)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:326)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository
> (RepositoryUtils.java:125)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDescriptionsAndURLs
> (DependenciesRenderer.java:890)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:847)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyTree
> (DependenciesRenderer.java:486)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionProjectDependencyGraph
> (DependenciesRenderer.java:449)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody
> (DependenciesRenderer.java:222)
> at org.apache.maven.reporting.AbstractMavenReportRenderer.render
> (AbstractMavenReportRenderer.java:80)
> at org.apache.maven.report.projectinfo.DependenciesReport.executeReport
> (DependenciesReport.java:162)
> at org.apache.maven.reporting.AbstractMavenReport.generate
> (AbstractMavenReport.java:251)
> at org.apache.maven.report.projectinfo.AbstractProjectInfoReport.execute
> (AbstractProjectInfoReport.java:220)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
>
[jira] [Commented] (MPIR-376) LightweightHttpsWagon is always used
[
https://issues.apache.org/jira/browse/MPIR-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1692#comment-1692
]
Michael Osipov commented on MPIR-376:
-
[~rfscholte], all ITs pass on Jenkins. I am going to merge this today.
> LightweightHttpsWagon is always used
>
>
> Key: MPIR-376
> URL: https://issues.apache.org/jira/browse/MPIR-376
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies, dependency-management, plugin-management
>Affects Versions: 3.0.0
> Environment: Apache Maven 3.5.4
> (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T20:33:14+02:00)
> Maven home: /opt/apache-maven
> Java version: 1.8.0_152, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_152.jdk/Contents/Home/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"
>Reporter: Jan Gerken
>Priority: Major
> Fix For: 3.0.1
>
> Attachments: build.log, pom.xml
>
>
> For all dependencies, one of the plugins needs to download always the
> {{LightweightHttpsWagon}} is used. Independent of the wagon provider
> configuration in the {{settings.xml}} or via {{-Dmaven.wagon.provider.https}}
> and {{-Dmaven.wagon.provider.http}}.
> Starting with Maven 3.0.4 the {{httpclient}} is the default wagon provider
> used for http and https connections. Therefore, I added add
> {{httpConfiguration}} for all servers I access in my {{settings.xml}} to
> reduce the timeout. This works well with all other plugins but for this
> plugin in version 3.0.0 it generates the following warning for each download:
> {code:java}
> [WARNING] Could not apply configuration for central to wagon
> org.apache.maven.wagon.providers.http.LightweightHttpsWagon:Cannot find
> 'httpConfiguration' in class
> org.apache.maven.wagon.providers.http.LightweightHttpsWagon{code}
> I tried to explicitly define the wagon provider to be {{httpclient}} for each
> server in my {{settings.xml}} and I tried to force the client via the command
> line arguments. None of this changes was successful.
> Please make this plugin use the configured wagon provider for each server and
> use the same default provider as the Maven version.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Assigned] (MPIR-376) LightweightHttpsWagon is always used
[
https://issues.apache.org/jira/browse/MPIR-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MPIR-376:
---
Assignee: Michael Osipov
> LightweightHttpsWagon is always used
>
>
> Key: MPIR-376
> URL: https://issues.apache.org/jira/browse/MPIR-376
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies, dependency-management, plugin-management
>Affects Versions: 3.0.0
> Environment: Apache Maven 3.5.4
> (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T20:33:14+02:00)
> Maven home: /opt/apache-maven
> Java version: 1.8.0_152, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_152.jdk/Contents/Home/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"
>Reporter: Jan Gerken
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.0.1
>
> Attachments: build.log, pom.xml
>
>
> For all dependencies, one of the plugins needs to download always the
> {{LightweightHttpsWagon}} is used. Independent of the wagon provider
> configuration in the {{settings.xml}} or via {{-Dmaven.wagon.provider.https}}
> and {{-Dmaven.wagon.provider.http}}.
> Starting with Maven 3.0.4 the {{httpclient}} is the default wagon provider
> used for http and https connections. Therefore, I added add
> {{httpConfiguration}} for all servers I access in my {{settings.xml}} to
> reduce the timeout. This works well with all other plugins but for this
> plugin in version 3.0.0 it generates the following warning for each download:
> {code:java}
> [WARNING] Could not apply configuration for central to wagon
> org.apache.maven.wagon.providers.http.LightweightHttpsWagon:Cannot find
> 'httpConfiguration' in class
> org.apache.maven.wagon.providers.http.LightweightHttpsWagon{code}
> I tried to explicitly define the wagon provider to be {{httpclient}} for each
> server in my {{settings.xml}} and I tried to force the client via the command
> line arguments. None of this changes was successful.
> Please make this plugin use the configured wagon provider for each server and
> use the same default provider as the Maven version.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[GitHub] [maven] michael-o commented on issue #262: [MNG-6695] Improve speed in collection merging
michael-o commented on issue #262: [MNG-6695] Improve speed in collection merging URL: https://github.com/apache/maven/pull/262#issuecomment-522902969 We have all have invested a lot of time into this. Since we don't have any objections, I will rebase and merge by Thursday. 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 With regards, Apache Git Services
[GitHub] [maven-project-info-reports-plugin] michael-o closed pull request #7: [MPIR-375] add plugin excludes feature for plugin-management report
michael-o closed pull request #7: [MPIR-375] add plugin excludes feature for plugin-management report URL: https://github.com/apache/maven-project-info-reports-plugin/pull/7 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 With regards, Apache Git Services
[GitHub] [maven-project-info-reports-plugin] michael-o commented on issue #7: [MPIR-375] add plugin excludes feature for plugin-management report
michael-o commented on issue #7: [MPIR-375] add plugin excludes feature for plugin-management report URL: https://github.com/apache/maven-project-info-reports-plugin/pull/7#issuecomment-522893905 Merged with 82f4bf23b79fe87d2e414c70ab2058e8f1b4146b- 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 With regards, Apache Git Services
[GitHub] [maven-project-info-reports-plugin] michael-o edited a comment on issue #7: [MPIR-375] add plugin excludes feature for plugin-management report
michael-o edited a comment on issue #7: [MPIR-375] add plugin excludes feature for plugin-management report URL: https://github.com/apache/maven-project-info-reports-plugin/pull/7#issuecomment-522893905 Merged with 82f4bf23b79fe87d2e414c70ab2058e8f1b4146b. 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 With regards, Apache Git Services
[jira] [Closed] (MPIR-373) Upgrade from 2.9 to 3.0.0 introduces additional warning
[
https://issues.apache.org/jira/browse/MPIR-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPIR-373.
---
Resolution: Fixed
Fixed with
[e8e65f856f332ddf7f98122dd09a69d5e7907fa7|https://gitbox.apache.org/repos/asf?p=maven-project-info-reports-plugin.git;a=commit;h=e8e65f856f332ddf7f98122dd09a69d5e7907fa7].
> Upgrade from 2.9 to 3.0.0 introduces additional warning
> ---
>
> Key: MPIR-373
> URL: https://issues.apache.org/jira/browse/MPIR-373
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: GWR
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.0.1
>
> Attachments: pom.xml
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> a new warning-message introduced, causing some confusion in the devteam.
> When stepping up to maven-project-info-reports-plugin:3.0.0 (from2.9) the
> stacktrace below is seen.
> mvn3.0.5, 3.3.9 and 3.5.2 all give same stacktrace.
> Seems to caused by the xml-resolver:1.2, having a pom.xml containing the
> section.
>
> {code:java}
>
> deployed
>
> {code}
> Is there some more restrictive pom validation introduced with
> maven-project-info-reports-plugin:3.0.0
> {code:java}
> $ mvn project-info-reports:dependencies
> [WARNING] Unable to create Maven project from repository for artifact
> xml-resolver:xml-resolver:jar:1.2
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs:
> [ERROR] 'distributionManagement.status' must not be specified. @ line 36,
> column 13
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:191)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:326)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository
> (RepositoryUtils.java:125)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDescriptionsAndURLs
> (DependenciesRenderer.java:890)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:847)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyTree
> (DependenciesRenderer.java:486)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionProjectDependencyGraph
> (DependenciesRenderer.java:449)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody
> (DependenciesRenderer.java:222)
> at org.apache.maven.reporting.AbstractMavenReportRenderer.render
> (AbstractMavenReportRenderer.java:80)
> at org.apache.maven.report.projectinfo.DependenciesReport.executeReport
> (DependenciesReport.java:162)
> at org.apache.maven.reporting.AbstractMavenReport.generate
> (AbstractMavenReport.java:251)
> at org.apache.maven.report.projectinfo.AbstractProjectInfoReport.execute
> (AbstractProjectInfoReport.java:220)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
> at
[GitHub] [maven-project-info-reports-plugin] asfgit closed pull request #11: [MPIR-373][MPIR-374] Log Warning of incorrect dependency only on debug and add info otherw…
asfgit closed pull request #11: [MPIR-373][MPIR-374] Log Warning of incorrect dependency only on debug and add info otherw… URL: https://github.com/apache/maven-project-info-reports-plugin/pull/11 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 With regards, Apache Git Services
[jira] [Commented] (MPIR-373) Upgrade from 2.9 to 3.0.0 introduces additional warning
[
https://issues.apache.org/jira/browse/MPIR-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911067#comment-16911067
]
Robert Scholte commented on MPIR-373:
-
All I remember that the ModelBuilder is the preferred way to solve this, but it
is missing something to support this request. So at the moment this can only be
solved with the ProjectBuilder.
The ModelBuilder needs some redesign anyway, would be good to create an
explicit issue in MNG to solve this issue properly.
> Upgrade from 2.9 to 3.0.0 introduces additional warning
> ---
>
> Key: MPIR-373
> URL: https://issues.apache.org/jira/browse/MPIR-373
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: GWR
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.0.1
>
> Attachments: pom.xml
>
>
> a new warning-message introduced, causing some confusion in the devteam.
> When stepping up to maven-project-info-reports-plugin:3.0.0 (from2.9) the
> stacktrace below is seen.
> mvn3.0.5, 3.3.9 and 3.5.2 all give same stacktrace.
> Seems to caused by the xml-resolver:1.2, having a pom.xml containing the
> section.
>
> {code:java}
>
> deployed
>
> {code}
> Is there some more restrictive pom validation introduced with
> maven-project-info-reports-plugin:3.0.0
> {code:java}
> $ mvn project-info-reports:dependencies
> [WARNING] Unable to create Maven project from repository for artifact
> xml-resolver:xml-resolver:jar:1.2
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs:
> [ERROR] 'distributionManagement.status' must not be specified. @ line 36,
> column 13
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:191)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:326)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository
> (RepositoryUtils.java:125)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDescriptionsAndURLs
> (DependenciesRenderer.java:890)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:847)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyTree
> (DependenciesRenderer.java:486)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionProjectDependencyGraph
> (DependenciesRenderer.java:449)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody
> (DependenciesRenderer.java:222)
> at org.apache.maven.reporting.AbstractMavenReportRenderer.render
> (AbstractMavenReportRenderer.java:80)
> at org.apache.maven.report.projectinfo.DependenciesReport.executeReport
> (DependenciesReport.java:162)
> at org.apache.maven.reporting.AbstractMavenReport.generate
> (AbstractMavenReport.java:251)
> at org.apache.maven.report.projectinfo.AbstractProjectInfoReport.execute
> (AbstractProjectInfoReport.java:220)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
> at
[GitHub] [maven-indexer] eolivelli commented on issue #38: Change indexer-reader's Utils to call read() once
eolivelli commented on issue #38: Change indexer-reader's Utils to call read() once URL: https://github.com/apache/maven-indexer/pull/38#issuecomment-522878603 Let's wait for CI https://builds.apache.org/job/maven-box/job/maven-indexer/job/MNINDEXER-123/ 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 With regards, Apache Git Services
[GitHub] [maven-indexer] eolivelli commented on issue #39: Add getName() to Record.EntryKey
eolivelli commented on issue #39: Add getName() to Record.EntryKey URL: https://github.com/apache/maven-indexer/pull/39#issuecomment-522878539 Let's wait for CI https://builds.apache.org/job/maven-box/job/maven-indexer/job/MINDEXER-122/ 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 With regards, Apache Git Services
[GitHub] [maven-indexer] eolivelli commented on issue #39: Add getName() to Record.EntryKey
eolivelli commented on issue #39: Add getName() to Record.EntryKey URL: https://github.com/apache/maven-indexer/pull/39#issuecomment-522875415 No need to rename the branch. 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 With regards, Apache Git Services
[GitHub] [maven] boohoo555 commented on issue #270: [MNG-3699] - Lift JDK minimum to JDK 8
boohoo555 commented on issue #270: [MNG-3699] - Lift JDK minimum to JDK 8 URL: https://github.com/apache/maven/pull/270#issuecomment-522874039 Duplicate of # 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 With regards, Apache Git Services
[jira] [Comment Edited] (MPIR-373) Upgrade from 2.9 to 3.0.0 introduces additional warning
[
https://issues.apache.org/jira/browse/MPIR-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911029#comment-16911029
]
Hervé Boutemy edited comment on MPIR-373 at 8/20/19 6:25 AM:
-
this PR is a workaround to make the issue less visible: nice to have if we are
not able to fix really this issue shortly (I like that it does not fuly swallow
the issue, but makes it less visible, even if it may hide other types of issues
than this extra field)
the real fix I'd expect would be something about the internal Maven API used to
load dependencies POM: IIUC, it should not be ProjectBuilder, since
ProjectBuilder is intended for project's POMs that will really run the Maven
build (and that explains that there is a failure: this extra field is not
intended to be present on the pom.xml you have in scm for your projects).
I don't master precisely which API is expected to be used to just import a
dependency model: [~rfscholte] , IIRC, you worked on clarifying this, isn't it?
was (Author: hboutemy):
this PR is a workaround to make the issue less visible: nice to have if we are
not able to fix really this issue shortly
the real fix I'd expect would be something about the internal Maven API used to
load dependencies POM: IIUC, it should not be ProjectBuilder, since
ProjectBuilder is intended for project's POMs that will really run the Maven
build (and that explains that there is a failure: this extra field is not
intended to be present on the pom.xml you have in scm for your projects).
I don't master precisely which API is expected to be used to just import a
dependency model: [~rfscholte] , IIRC, you worked on clarifying this, isn't it?
> Upgrade from 2.9 to 3.0.0 introduces additional warning
> ---
>
> Key: MPIR-373
> URL: https://issues.apache.org/jira/browse/MPIR-373
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: GWR
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.0.1
>
> Attachments: pom.xml
>
>
> a new warning-message introduced, causing some confusion in the devteam.
> When stepping up to maven-project-info-reports-plugin:3.0.0 (from2.9) the
> stacktrace below is seen.
> mvn3.0.5, 3.3.9 and 3.5.2 all give same stacktrace.
> Seems to caused by the xml-resolver:1.2, having a pom.xml containing the
> section.
>
> {code:java}
>
> deployed
>
> {code}
> Is there some more restrictive pom validation introduced with
> maven-project-info-reports-plugin:3.0.0
> {code:java}
> $ mvn project-info-reports:dependencies
> [WARNING] Unable to create Maven project from repository for artifact
> xml-resolver:xml-resolver:jar:1.2
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs:
> [ERROR] 'distributionManagement.status' must not be specified. @ line 36,
> column 13
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:191)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:326)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository
> (RepositoryUtils.java:125)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDescriptionsAndURLs
> (DependenciesRenderer.java:890)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:847)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyTree
> (DependenciesRenderer.java:486)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionProjectDependencyGraph
> (DependenciesRenderer.java:449)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody
> (DependenciesRenderer.java:222)
> at org.apache.maven.reporting.AbstractMavenReportRenderer.render
> (AbstractMavenReportRenderer.java:80)
> at org.apache.maven.report.projectinfo.DependenciesReport.executeReport
> (DependenciesReport.java:162)
> at org.apache.maven.reporting.AbstractMavenReport.generate
> (AbstractMavenReport.java:251)
> at
[jira] [Commented] (MPIR-373) Upgrade from 2.9 to 3.0.0 introduces additional warning
[
https://issues.apache.org/jira/browse/MPIR-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911029#comment-16911029
]
Hervé Boutemy commented on MPIR-373:
this PR is a workaround to make the issue less visible: nice to have if we are
not able to fix really this issue shortly
the real fix I'd expect would be something about the internal Maven API used to
load dependencies POM: IIUC, it should not be ProjectBuilder, since
ProjectBuilder is intended for project's POMs that will really run the Maven
build (and that explains that there is a failure: this extra field is not
intended to be present on the pom.xml you have in scm for your projects).
I don't master precisely which API is expected to be used to just import a
dependency model: [~rfscholte] , IIRC, you worked on clarifying this, isn't it?
> Upgrade from 2.9 to 3.0.0 introduces additional warning
> ---
>
> Key: MPIR-373
> URL: https://issues.apache.org/jira/browse/MPIR-373
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: GWR
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.0.1
>
> Attachments: pom.xml
>
>
> a new warning-message introduced, causing some confusion in the devteam.
> When stepping up to maven-project-info-reports-plugin:3.0.0 (from2.9) the
> stacktrace below is seen.
> mvn3.0.5, 3.3.9 and 3.5.2 all give same stacktrace.
> Seems to caused by the xml-resolver:1.2, having a pom.xml containing the
> section.
>
> {code:java}
>
> deployed
>
> {code}
> Is there some more restrictive pom validation introduced with
> maven-project-info-reports-plugin:3.0.0
> {code:java}
> $ mvn project-info-reports:dependencies
> [WARNING] Unable to create Maven project from repository for artifact
> xml-resolver:xml-resolver:jar:1.2
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs:
> [ERROR] 'distributionManagement.status' must not be specified. @ line 36,
> column 13
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:191)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:326)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository
> (RepositoryUtils.java:125)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDescriptionsAndURLs
> (DependenciesRenderer.java:890)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:847)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyTree
> (DependenciesRenderer.java:486)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionProjectDependencyGraph
> (DependenciesRenderer.java:449)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody
> (DependenciesRenderer.java:222)
> at org.apache.maven.reporting.AbstractMavenReportRenderer.render
> (AbstractMavenReportRenderer.java:80)
> at org.apache.maven.report.projectinfo.DependenciesReport.executeReport
> (DependenciesReport.java:162)
> at org.apache.maven.reporting.AbstractMavenReport.generate
> (AbstractMavenReport.java:251)
> at org.apache.maven.report.projectinfo.AbstractProjectInfoReport.execute
> (AbstractProjectInfoReport.java:220)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:51)
> at
