[jira] [Commented] (MNG-6502) More performant AbstractZipArchiver when maven module contains lots of big resources
[ https://issues.apache.org/jira/browse/MNG-6502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701493#comment-16701493 ] Karl Heinz Marbaise commented on MNG-6502: -- Take your time..no problem.. > More performant AbstractZipArchiver when maven module contains lots of big > resources > > > Key: MNG-6502 > URL: https://issues.apache.org/jira/browse/MNG-6502 > Project: Maven > Issue Type: Improvement >Reporter: Hoa Phan >Priority: Major > Fix For: waiting-for-feedback > > Attachments: Screen Shot 2018-11-01 at 2.22.42 am.png, Screen Shot > 2018-11-01 at 2.25.22 am.png > > > *Consider process resources in parallel > * > > !Screen Shot 2018-11-01 at 2.22.42 am.png! > *Consider flexible/adjustable buffer size for IOUtil.copy > *!Screen Shot 2018-11-01 at 2.25.22 am.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6502) More performant AbstractZipArchiver when maven module contains lots of big resources
[ https://issues.apache.org/jira/browse/MNG-6502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MNG-6502: - Fix Version/s: waiting-for-feedback > More performant AbstractZipArchiver when maven module contains lots of big > resources > > > Key: MNG-6502 > URL: https://issues.apache.org/jira/browse/MNG-6502 > Project: Maven > Issue Type: Improvement >Reporter: Hoa Phan >Priority: Major > Fix For: waiting-for-feedback > > Attachments: Screen Shot 2018-11-01 at 2.22.42 am.png, Screen Shot > 2018-11-01 at 2.25.22 am.png > > > *Consider process resources in parallel > * > > !Screen Shot 2018-11-01 at 2.22.42 am.png! > *Consider flexible/adjustable buffer size for IOUtil.copy > *!Screen Shot 2018-11-01 at 2.25.22 am.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6502) More performant AbstractZipArchiver when maven module contains lots of big resources
[ https://issues.apache.org/jira/browse/MNG-6502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701385#comment-16701385 ] Hoa Phan commented on MNG-6502: --- sorry [~khmarbaise] I'm in the period of leaving my job so quite a few things I need to finish(and job hunting). I'll try to set up a sample project for you when I can, basically, it's a maven project with a massive number of resources. The build is just mainly copying the resources over to the target. > More performant AbstractZipArchiver when maven module contains lots of big > resources > > > Key: MNG-6502 > URL: https://issues.apache.org/jira/browse/MNG-6502 > Project: Maven > Issue Type: Improvement >Reporter: Hoa Phan >Priority: Major > Attachments: Screen Shot 2018-11-01 at 2.22.42 am.png, Screen Shot > 2018-11-01 at 2.25.22 am.png > > > *Consider process resources in parallel > * > > !Screen Shot 2018-11-01 at 2.22.42 am.png! > *Consider flexible/adjustable buffer size for IOUtil.copy > *!Screen Shot 2018-11-01 at 2.25.22 am.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MPIR-377) Profiles in POMs do not appear to be evaluated
[
https://issues.apache.org/jira/browse/MPIR-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701292#comment-16701292
]
Gabriel Belingueres commented on MPIR-377:
--
Hi Jason.
I could reproduce the stacktrace with Maven 3.5.4, but running with Maven 3.6.0
there is no exception.
Can you confirm this in your own environment?
> Profiles in POMs do not appear to be evaluated
> --
>
> Key: MPIR-377
> URL: https://issues.apache.org/jira/browse/MPIR-377
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 3.0.0
> Environment: Maven 3.5.4, Win 32_64, Java 10
>Reporter: Jason Faust
>Priority: Minor
> Attachments: log.txt, pom.xml
>
>
> First of, I do not know if this is a bug, or if it's a result of OpenJFX
> being silly with how they setup their parent pom (
> [http://repo.maven.apache.org/maven2/org/openjfx/javafx/11.0.1/javafx-11.0.1.pom]
> and
> [http://repo.maven.apache.org/maven2/org/openjfx/javafx-base/11.0.1/javafx-base-11.0.1.pom]
> ), and the bug should be filed there, but:
> The dependencies report reports warnings of the OpenJFX poms (for example)
> referring to themselves, as they depend on {{${javafx.profile}}} having a
> value, which is derived from the parent POM. Net result is it appears that
> the dependencies report is unable to see the full tree, whereas Maven
> normally is able to include all of the jars required for a build.
> Error triggered by running 'site' against the attached [^pom.xml].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6529) ProjectBuilder.build(List projects, boolean, ProjectBuildingRequest) doesn't honor ProjectBuildingRequest.isResolveDependencies()
[ https://issues.apache.org/jira/browse/MNG-6529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701259#comment-16701259 ] ASF GitHub Bot commented on MNG-6529: - slachiewicz commented on issue #193: MNG-6529 - ProjectBuild.build(projectsList, ...) ignores request.isResolveDependency() URL: https://github.com/apache/maven/pull/193#issuecomment-442283024 Build ok https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/MNG-6529/ This is an automated message from the Apache Git Service. To respond to the message, please log on 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 > ProjectBuilder.build(List projects, boolean, ProjectBuildingRequest) > doesn't honor ProjectBuildingRequest.isResolveDependencies() > --- > > Key: MNG-6529 > URL: https://issues.apache.org/jira/browse/MNG-6529 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.3 >Reporter: Mickael Istria >Priority: Critical > > I'm willing to upfate Eclipse m2e to take advantage of the > `ProjectBuilder.build(List project, boolean, ProjectBuildingRequest)` > in Eclipse m2e to avoid duplication of MavenProject in the IDE in place of > `ProjectBuilder.build(File singleFile, ProjectBuildingRequest)`. It's already > measured to have drastically good impact on the IDE, as explained in > [https://bugs.eclipse.org/bugs/show_bug.cgi?id=515668#c20] and > [https://bugs.eclipse.org/bugs/show_bug.cgi?id=515668#c38]. > However, using this cause regressions because the multi-projects entry-point > method seems to totally ignore the > `ProjectBuildRequest.isResolveDependencies()` flag and never returns a valid > list of `MavenProject.getArtifacts()`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] slachiewicz commented on issue #193: MNG-6529 - ProjectBuild.build(projectsList, ...) ignores request.isResolveDependency()
slachiewicz commented on issue #193: MNG-6529 - ProjectBuild.build(projectsList, ...) ignores request.isResolveDependency() URL: https://github.com/apache/maven/pull/193#issuecomment-442283024 Build ok https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/MNG-6529/ This is an automated message from the Apache Git Service. To respond to the message, please log on 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-6261) Relative parent POM resolution failing in 3.5.0 with complex multimodule builds
[
https://issues.apache.org/jira/browse/MNG-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701256#comment-16701256
]
ASF GitHub Bot commented on MNG-6261:
-
slachiewicz commented on issue #192: [MNG-6261] - using java File api to compare
URL: https://github.com/apache/maven/pull/192#issuecomment-442282452
+1
And one more small testcase - should pass before/after patch
`org.apache.maven.model.building.FileModelSource#getRelatedSource` - one use
of normalize
```
@Test
public void testDiffrentPaths () throws IOException {
Path tempDirParent = Files.createTempDirectory( "FileModelSource-" );
Path subdir = Files.createDirectory( tempDirParent.resolve( "test" )
);
Path pomFile = Files.createTempFile(subdir, "myCustomPom-", ".xml" );
Path relativeFile = subdir.resolve( "../test/" +
pomFile.getFileName() );
assertNotEquals( pomFile, relativeFile );
assertEquals( pomFile.normalize(), relativeFile.normalize());
assertNotEquals( pomFile.toFile(), relativeFile.toFile() );
assertNotEquals( pomFile.toFile().toURI(),
relativeFile.toFile().toURI() );
assertEquals( pomFile.toFile().getCanonicalFile(),
relativeFile.toFile().getCanonicalFile() );
assertEquals( pomFile.toFile().toURI().normalize(),
relativeFile.toFile().toURI().normalize() );
FileModelSource instance = new FileModelSource( pomFile.toFile() );
assertNotEquals(instance, new FileModelSource( relativeFile.toFile()
) );
}
}
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on 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
> Relative parent POM resolution failing in 3.5.0 with complex multimodule
> builds
> ---
>
> Key: MNG-6261
> URL: https://issues.apache.org/jira/browse/MNG-6261
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Dawid Weiss
>Priority: Minor
> Labels: up-for-grabs
> Fix For: 3.6.x-candidate
>
> Attachments: capture-6.png, repro.zip
>
>
> In my effort to upgrade an existing (fairly complex) Maven build to Java
> 1.9.0 I updated Maven to 3.5.0 (from 3.3.9). Unfortunately I get errors when
> the project's modules are resolved:
> {noformat}
> > mvn validate
> [FATAL] Non-resolvable parent POM for
> com.carrotsearch.lingo4g:lingo4g-public-bom:[unknown-version]: Could not find
> artifact com.carrotsearch.lingo4g:lingo4g-public:pom:1.6.0-SNAPSHOT and
> 'parent.relativePath' points at wrong local POM @ line 5, column 11
> ...
> (and many follow).
> {noformat}
> This build has a correct pom parent-structure (a tree), but is fairly complex
> -- the submodule hierarchy is not aligned with parent-child pom hierarchy
> (it's best to look at the repro code to understand how it's structured).
> However, it's been working correctly with all prior Maven versions and I
> wonder if it's a regression bug or maybe underspecified Maven requirement
> (that should be enforced with a warning and not lead to this odd runtime
> message).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] slachiewicz commented on issue #192: [MNG-6261] - using java File api to compare
slachiewicz commented on issue #192: [MNG-6261] - using java File api to compare
URL: https://github.com/apache/maven/pull/192#issuecomment-442282452
+1
And one more small testcase - should pass before/after patch
`org.apache.maven.model.building.FileModelSource#getRelatedSource` - one use
of normalize
```
@Test
public void testDiffrentPaths () throws IOException {
Path tempDirParent = Files.createTempDirectory( "FileModelSource-" );
Path subdir = Files.createDirectory( tempDirParent.resolve( "test" )
);
Path pomFile = Files.createTempFile(subdir, "myCustomPom-", ".xml" );
Path relativeFile = subdir.resolve( "../test/" +
pomFile.getFileName() );
assertNotEquals( pomFile, relativeFile );
assertEquals( pomFile.normalize(), relativeFile.normalize());
assertNotEquals( pomFile.toFile(), relativeFile.toFile() );
assertNotEquals( pomFile.toFile().toURI(),
relativeFile.toFile().toURI() );
assertEquals( pomFile.toFile().getCanonicalFile(),
relativeFile.toFile().getCanonicalFile() );
assertEquals( pomFile.toFile().toURI().normalize(),
relativeFile.toFile().toURI().normalize() );
FileModelSource instance = new FileModelSource( pomFile.toFile() );
assertNotEquals(instance, new FileModelSource( relativeFile.toFile()
) );
}
}
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on 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-6311) Maven intolerably slow when import scope used heavily in large project
[ https://issues.apache.org/jira/browse/MNG-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701138#comment-16701138 ] Mickael Istria commented on MNG-6311: - I'm also quite surprised that despite the concerns raised by [~fbricon] in October, no further verification nor investigation has happened on this patch and it was released 13 days later in 3.6.0, basically ignoring adopter's concerns. It seems to me that this is a major failure in term of QE. The fact that the issue was missed can happen, but ignoring feedback from an adopter project that is delivered to 6 million users obviously leads to bad results, such as 3.6.0 containing a regression over 3.5.3 and not being usable for downstream projects. > Maven intolerably slow when import scope used heavily in large project > -- > > Key: MNG-6311 > URL: https://issues.apache.org/jira/browse/MNG-6311 > Project: Maven > Issue Type: Bug > Components: core, Performance >Affects Versions: 3.5.0, 3.5.2 >Reporter: David Churcher >Assignee: Sylwester Lachiewicz >Priority: Major > Labels: performance > Fix For: 3.6.0 > > Attachments: Call-tree-–-All-threads-together.html, > anon-hierarchy-maven-output.zip, modelcachefix.diff > > > I have a build performance problem that is identical to MNG-5312, and has > appeared since MNG-6030 in Maven v3.5.0 reversed the patch for MNG-5312, > removing the ModelCache from some of the overloads for > DefaultProjectBuilder.build. > As in MNG-5312 the problem is in a large proprietary project. It uses up to 8 > levels of parent POMs, many of which use the import scope and have large > dependency-management sections, and has hundreds of dependencies that also > use the same parent POM hierarchy. Adding some logging shows that Maven does > over 800,000 uncached reads of parent POM files, which takes about half an > hour. With model caching this goes down to a few seconds. > I've attached a patch that fixes this by using a class-level ModelCache in > DefaultProjectBuilder. This does not suffer from the memory usage problems > reported in MNG-6030. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6529) ProjectBuilder.build(List projects, boolean, ProjectBuildingRequest) doesn't honor ProjectBuildingRequest.isResolveDependencies()
[ https://issues.apache.org/jira/browse/MNG-6529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701127#comment-16701127 ] Mickael Istria commented on MNG-6529: - Pull request https://github.com/apache/maven/pull/193 now contains something that looks like a fix. > ProjectBuilder.build(List projects, boolean, ProjectBuildingRequest) > doesn't honor ProjectBuildingRequest.isResolveDependencies() > --- > > Key: MNG-6529 > URL: https://issues.apache.org/jira/browse/MNG-6529 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.3 >Reporter: Mickael Istria >Priority: Critical > > I'm willing to upfate Eclipse m2e to take advantage of the > `ProjectBuilder.build(List project, boolean, ProjectBuildingRequest)` > in Eclipse m2e to avoid duplication of MavenProject in the IDE in place of > `ProjectBuilder.build(File singleFile, ProjectBuildingRequest)`. It's already > measured to have drastically good impact on the IDE, as explained in > [https://bugs.eclipse.org/bugs/show_bug.cgi?id=515668#c20] and > [https://bugs.eclipse.org/bugs/show_bug.cgi?id=515668#c38]. > However, using this cause regressions because the multi-projects entry-point > method seems to totally ignore the > `ProjectBuildRequest.isResolveDependencies()` flag and never returns a valid > list of `MavenProject.getArtifacts()`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6311) Maven intolerably slow when import scope used heavily in large project
[ https://issues.apache.org/jira/browse/MNG-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701106#comment-16701106 ] Mickael Istria commented on MNG-6311: - Please have a look at this test case: https://github.com/apache/maven/pull/194 . It fails with current master. If you `git revert 8bc3c207d0aa7cef72171af23d9c4667b2d46c5d`, it succeeds, as expected. In the current form, the contract of `ProjectBuilder.build(...)` is broken as it doesn't resolve the MavenProject correctly. This is a severe regression, and I think it should really be avoided in Maven before it cascade to m2e or other projects that use the ProjectBuilder API to do some validation or any other form of analysis. I suggest this gets reverted, we merge my unit-test that guarantees a good functioning state for `ProjectBuilder.build(...)` and the patch gets reworked to not introduce a regression. This is the only safe path. Note that while I may seem very opposed to this change, I am actually not at all. I just want to make the API still work as expected. I think there are way to rework the suggested patch so it doesn't introduce that regression. > Maven intolerably slow when import scope used heavily in large project > -- > > Key: MNG-6311 > URL: https://issues.apache.org/jira/browse/MNG-6311 > Project: Maven > Issue Type: Bug > Components: core, Performance >Affects Versions: 3.5.0, 3.5.2 >Reporter: David Churcher >Assignee: Sylwester Lachiewicz >Priority: Major > Labels: performance > Fix For: 3.6.0 > > Attachments: Call-tree-–-All-threads-together.html, > anon-hierarchy-maven-output.zip, modelcachefix.diff > > > I have a build performance problem that is identical to MNG-5312, and has > appeared since MNG-6030 in Maven v3.5.0 reversed the patch for MNG-5312, > removing the ModelCache from some of the overloads for > DefaultProjectBuilder.build. > As in MNG-5312 the problem is in a large proprietary project. It uses up to 8 > levels of parent POMs, many of which use the import scope and have large > dependency-management sections, and has hundreds of dependencies that also > use the same parent POM hierarchy. Adding some logging shows that Maven does > over 800,000 uncached reads of parent POM files, which takes about half an > hour. With model caching this goes down to a few seconds. > I've attached a patch that fixes this by using a class-level ModelCache in > DefaultProjectBuilder. This does not suffer from the memory usage problems > reported in MNG-6030. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1602) Surefire fails loading class ForkedBooter when using a sub-directory pom file and a local maven repo
[
https://issues.apache.org/jira/browse/SUREFIRE-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701080#comment-16701080
]
Tibor Digana commented on SUREFIRE-1602:
[~daniel.kurzynski]
Create a project on GitHub because this has to be reproduced.
Where is your module {{integration-tests}}. It's not seen in the command with
{{archetype}} s I need to check it out with GitHub project.
> Surefire fails loading class ForkedBooter when using a sub-directory pom file
> and a local maven repo
>
>
> Key: SUREFIRE-1602
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1602
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M1
> Environment: maven 3.6.0 open-jdk-8 (docker image
> maven:3.6.0-open-jdk-8)
>Reporter: Daniel Kurzynski
>Priority: Major
>
> Steps to reproduce:
> Use a docker image for maven:3.6 (docker run -it maven:3.6.0-jdk-8 bash)
> Inside generate a new project:
> {code:java}
> mvn archetype:generate \
> -DinteractiveMode=false \
> -DarchetypeGroupId=com.sap.cloud.s4hana.archetypes \
> -DarchetypeArtifactId=scp-cf-tomee \
> -DarchetypeVersion=2.7.0 \
> -DgroupId=com.sap.cloud.sdk.tutorial \
> -DartifactId=testapp\
> -Dversion=1.0-SNAPSHOT \
> -Dpackage=com.sap.cloud.s4hana.examples{code}
> In the folder testapp set surefire version to 3.0.0-M1 in unit-tests/pom.xml
> and integration-tests/pom.xml
> Build the project
> {code:java}
> mvn -Dmaven.repo.local=maven_local_repo -Dmaven.test.skip clean install{code}
> Running the tests afterwards will fail
> {code:java}
> mvn test -Dmaven.repo.local=maven_local_repo --file
> ./integration-tests/pom.xml{code}
> The error message in the logs is:
> Error: Could not find or load main class
> org.apache.maven.surefire.booter.ForkedBooter
> However, it only fails when using ./ in the beginning of the file parameter
> in combination with having a local maven repo.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6311) Maven intolerably slow when import scope used heavily in large project
[ https://issues.apache.org/jira/browse/MNG-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701098#comment-16701098 ] ASF GitHub Bot commented on MNG-6311: - mickaelistria opened a new pull request #194: MNG-6311 - Show regression with Model cache URL: https://github.com/apache/maven/pull/194 Using a model cache that doesn't check for last file change leads to resolving against out of date models, generating erroneous MavenProjects. Signed-off-by: Mickael Istria This is an automated message from the Apache Git Service. To respond to the message, please log on 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 > Maven intolerably slow when import scope used heavily in large project > -- > > Key: MNG-6311 > URL: https://issues.apache.org/jira/browse/MNG-6311 > Project: Maven > Issue Type: Bug > Components: core, Performance >Affects Versions: 3.5.0, 3.5.2 >Reporter: David Churcher >Assignee: Sylwester Lachiewicz >Priority: Major > Labels: performance > Fix For: 3.6.0 > > Attachments: Call-tree-–-All-threads-together.html, > anon-hierarchy-maven-output.zip, modelcachefix.diff > > > I have a build performance problem that is identical to MNG-5312, and has > appeared since MNG-6030 in Maven v3.5.0 reversed the patch for MNG-5312, > removing the ModelCache from some of the overloads for > DefaultProjectBuilder.build. > As in MNG-5312 the problem is in a large proprietary project. It uses up to 8 > levels of parent POMs, many of which use the import scope and have large > dependency-management sections, and has hundreds of dependencies that also > use the same parent POM hierarchy. Adding some logging shows that Maven does > over 800,000 uncached reads of parent POM files, which takes about half an > hour. With model caching this goes down to a few seconds. > I've attached a patch that fixes this by using a class-level ModelCache in > DefaultProjectBuilder. This does not suffer from the memory usage problems > reported in MNG-6030. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] mickaelistria opened a new pull request #194: MNG-6311 - Show regression with Model cache
mickaelistria opened a new pull request #194: MNG-6311 - Show regression with Model cache URL: https://github.com/apache/maven/pull/194 Using a model cache that doesn't check for last file change leads to resolving against out of date models, generating erroneous MavenProjects. Signed-off-by: Mickael Istria This is an automated message from the Apache Git Service. To respond to the message, please log on 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] (SUREFIRE-1603) Output captured under wrong test in JUnit 5 parallel mode
[
https://issues.apache.org/jira/browse/SUREFIRE-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701070#comment-16701070
]
Tibor Digana commented on SUREFIRE-1603:
[~johnsus]
Parallel execution is not supported yet.
See the docu
https://maven.apache.org/surefire/maven-surefire-plugin/featurematrix.html
[~sormu...@gmx.de] Can you comment on this? What's the plan with parallel
execution in Surefire?
> Output captured under wrong test in JUnit 5 parallel mode
> -
>
> Key: SUREFIRE-1603
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1603
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M1, 2.22.1
>Reporter: John Knight
>Priority: Major
>
> Using JUnit 5.31 with the following configuration:
> {noformat}
>
> junit.jupiter.execution.parallel.enabled = true
> junit.jupiter.execution.parallel.config.dynamic.factor = 8
> junit.jupiter.extensions.autodetection.enabled = true
> {noformat}
> and the following tests (for demonstration purposes)
> {noformat}
> public class AppTest
> {
> @Test
> public void mogbyTrue()
> {
> for (int i = 0; i < 5; i++) {
> System.out.println("mogby " + Thread.currentThread().getName());
> }
> assertTrue( false );
> }
> @Test
> public void kermitTrue()
> {
> for (int i = 0; i < 5; i++) {
> System.out.println("kermit " + Thread.currentThread().getName());
> }
> assertTrue( false );
> }{noformat}
> When the tests are executed via mvn test, the messages from both tests appear
> under the output for the first test:
> {noformat}
>
> https://junit.org/junit5/docs/snapshot/user-guide/#running-tests-capturing-output]
> - The output for both tests is still captured within the field
> of the first test, but in a different order:
> {noformat}
> {noformat}
> The original use case for this, is that we have a whole suite of tests
> running via Jenkins, so when tests fail, it's really difficult to see what
> the actual problem is, as the logging is out of sync.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (SUREFIRE-1590) Deploy multiple versions of Report XSD
[ https://issues.apache.org/jira/browse/SUREFIRE-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1590. -- Resolution: Fixed https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=edb3b71b95db98eef6a8e4fa98d376fd3512b05a > Deploy multiple versions of Report XSD > -- > > Key: SUREFIRE-1590 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1590 > Project: Maven Surefire > Issue Type: Improvement > Components: xml generation >Affects Versions: 2.22.1 >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (SUREFIRE-1568) Versions 2.21 and higher doesn't work with junit-platform for Java 9 module
[
https://issues.apache.org/jira/browse/SUREFIRE-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1568.
--
Resolution: Fixed
https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=9b36828cc2ba65d17d3256c4f0c738a1ae7fe89d
> Versions 2.21 and higher doesn't work with junit-platform for Java 9 module
> ---
>
> Key: SUREFIRE-1568
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1568
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Surefire Plugin, process forking
>Affects Versions: 2.21.0
> Environment: Ubuntu
>Reporter: Pavel_K
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M2
>
> Attachments: 2018-09-15T18-54-48_266.dumpstream, debug1.txt,
> debug2.txt, mavenproject19.zip, mavenproject19_target_and_debug.zip
>
>
> I have a simple JPMS module. When I use the maven-surefire-plugin 2.20.1
> everything is ok - my tests are executed:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.20.1
>
>
> org.junit.platform
>
> junit-platform-surefire-provider
> 1.3.0
>
>
> {code}
> However, when I want to use newer versions of surefire (2.21.0 or 2.22.0) I
> get the following:
> {code:java}
> Please refer to dump files (if any exist) [date]-jvmRun[N].dump,
> [date].dumpstream and [date]-jvmRun[N].dumpstream.
> The forked VM terminated without properly saying goodbye. VM crash or
> System.exit called?
> Command was /bin/sh -c cd "/home/project" && /opt/jdk-9/bin/java
> '@/home/project/target/surefire/surefireargs4438382394951202560'
> '/home/project/target/surefire' 2018-09-13T13-42-05_435-jvmRun1
> surefire4870497011802680670tmp surefire_015850140770716473411tmp
> Error occurred in starting fork, check output in log
> Process Exit Code: 1
> org.apache.maven.surefire.booter.SurefireBooterForkException: The forked
> VM terminated without properly saying goodbye. VM crash or System.exit called?
> Command was /bin/sh -c cd "/home/project" && /opt/jdk-9/bin/java
> '@/home/project/target/surefire/surefireargs4438382394951202560'
> '/home/project/target/surefire' 2018-09-13T13-42-05_435-jvmRun1
> surefire4870497011802680670tmp surefire_015850140770716473411tmp
> Error occurred in starting fork, check output in log
> Process Exit Code: 1
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:671)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:278)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:244)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1194)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1022)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:868)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> 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:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
>
[jira] [Issue Comment Deleted] (MJAVADOC-546) Allow to generate report in Spanish locale
[ https://issues.apache.org/jira/browse/MJAVADOC-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MJAVADOC-546: Comment: was deleted (was: Build failed in Jenkins: Maven TLP » maven-javadoc-plugin » master #78 See https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/master/78/) > Allow to generate report in Spanish locale > -- > > Key: MJAVADOC-546 > URL: https://issues.apache.org/jira/browse/MJAVADOC-546 > Project: Maven Javadoc Plugin > Issue Type: Improvement > Components: javadoc >Reporter: Gabriel Belingueres >Assignee: Robert Scholte >Priority: Trivial > Fix For: 3.0.2 > > > Add locale files to generate javadoc reports in Spanish. > (I'll provide a PR these files) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MJAVADOC-537) warning when javadoc is invoked for dependency
[
https://issues.apache.org/jira/browse/MJAVADOC-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MJAVADOC-537:
Description:
When the javadoc goal is to be called for a dependency a warning from the maven
invocation is emitted:
{{[WARN] Maven will be executed in interactive mode, but no input stream has
been configured for this MavenInvoker instance.}}
was:
When the javadoc goal is to be called for a dependency a warning from the maven
invocation is emitted:
```
[WARN] Maven will be executed in interactive mode, but no input stream has been
configured for this MavenInvoker instance.
```
> warning when javadoc is invoked for dependency
> --
>
> Key: MJAVADOC-537
> URL: https://issues.apache.org/jira/browse/MJAVADOC-537
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.0.1
>Reporter: Johannes Edmeier
>Priority: Minor
>
> When the javadoc goal is to be called for a dependency a warning from the
> maven invocation is emitted:
> {{[WARN] Maven will be executed in interactive mode, but no input stream has
> been configured for this MavenInvoker instance.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-537) warning when javadoc is invoked for dependency
[ https://issues.apache.org/jira/browse/MJAVADOC-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701040#comment-16701040 ] Robert Scholte commented on MJAVADOC-537: - Fixed in [3dcf135299950db9541f7da671bec1a84c5cef49|https://gitbox.apache.org/repos/asf?p=maven-javadoc-plugin.git;a=commit;h=3dcf135299950db9541f7da671bec1a84c5cef49] Thanks for the patch! > warning when javadoc is invoked for dependency > -- > > Key: MJAVADOC-537 > URL: https://issues.apache.org/jira/browse/MJAVADOC-537 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.0.1 >Reporter: Johannes Edmeier >Priority: Minor > > When the javadoc goal is to be called for a dependency a warning from the > maven invocation is emitted: > ``` > [WARN] Maven will be executed in interactive mode, but no input stream has > been configured for this MavenInvoker instance. > ``` -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAVADOC-537) warning when javadoc is invoked for dependency
[
https://issues.apache.org/jira/browse/MJAVADOC-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701038#comment-16701038
]
ASF GitHub Bot commented on MJAVADOC-537:
-
rfscholte closed pull request #7: [MJAVADOC-537] Explicitly the batchMode to
true
URL: https://github.com/apache/maven-javadoc-plugin/pull/7
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java
b/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java
index da72cac..ea7e6fb 100644
--- a/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java
+++ b/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java
@@ -920,6 +920,7 @@ protected static void invokeMaven( Log log, File
localRepositoryDir, File projec
InvocationRequest request = new DefaultInvocationRequest();
request.setBaseDirectory( projectFile.getParentFile() );
request.setPomFile( projectFile );
+request.setBatchMode( true );
if ( log != null )
{
request.setDebug( log.isDebugEnabled() );
This is an automated message from the Apache Git Service.
To respond to the message, please log on 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
> warning when javadoc is invoked for dependency
> --
>
> Key: MJAVADOC-537
> URL: https://issues.apache.org/jira/browse/MJAVADOC-537
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.0.1
>Reporter: Johannes Edmeier
>Priority: Minor
>
> When the javadoc goal is to be called for a dependency a warning from the
> maven invocation is emitted:
> ```
> [WARN] Maven will be executed in interactive mode, but no input stream has
> been configured for this MavenInvoker instance.
> ```
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] rfscholte closed pull request #7: [MJAVADOC-537] Explicitly the batchMode to true
rfscholte closed pull request #7: [MJAVADOC-537] Explicitly the batchMode to
true
URL: https://github.com/apache/maven-javadoc-plugin/pull/7
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java
b/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java
index da72cac..ea7e6fb 100644
--- a/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java
+++ b/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java
@@ -920,6 +920,7 @@ protected static void invokeMaven( Log log, File
localRepositoryDir, File projec
InvocationRequest request = new DefaultInvocationRequest();
request.setBaseDirectory( projectFile.getParentFile() );
request.setPomFile( projectFile );
+request.setBatchMode( true );
if ( log != null )
{
request.setDebug( log.isDebugEnabled() );
This is an automated message from the Apache Git Service.
To respond to the message, please log on 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] (MJAVADOC-546) Allow to generate report in Spanish locale
[ https://issues.apache.org/jira/browse/MJAVADOC-546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16700977#comment-16700977 ] Hudson commented on MJAVADOC-546: - Build failed in Jenkins: Maven TLP » maven-javadoc-plugin » master #78 See https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/master/78/ > Allow to generate report in Spanish locale > -- > > Key: MJAVADOC-546 > URL: https://issues.apache.org/jira/browse/MJAVADOC-546 > Project: Maven Javadoc Plugin > Issue Type: Improvement > Components: javadoc >Reporter: Gabriel Belingueres >Assignee: Robert Scholte >Priority: Trivial > Fix For: 3.0.2 > > > Add locale files to generate javadoc reports in Spanish. > (I'll provide a PR these files) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MJAVADOC-506) Javadoc plugin broken on Java 8 when module-info.java present
[ https://issues.apache.org/jira/browse/MJAVADOC-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MJAVADOC-506. --- Resolution: Fixed Fix Version/s: 3.0.2 Fixed as part of MJAVADOC-542, added an IT to confirm in [2138b0532caee02d7dc33d06e8414af791257438|https://gitbox.apache.org/repos/asf?p=maven-javadoc-plugin.git;a=commit;h=2138b0532caee02d7dc33d06e8414af791257438] > Javadoc plugin broken on Java 8 when module-info.java present > - > > Key: MJAVADOC-506 > URL: https://issues.apache.org/jira/browse/MJAVADOC-506 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.0.0 >Reporter: Stephen Colebourne >Assignee: Robert Scholte >Priority: Major > Fix For: 3.0.2 > > > The fix to MJAVADOC-498 causes the command line flag `--class-path` to be > used on Java 8, a flag that is not recognised. This happens when the project > contains `module-info.java`, but the module-info file is excluded by the > configuration of the plugin. > The problem is here: > http://svn.apache.org/viewvc/maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java?r1=1802722=1813672=1813672 > where the code checks whether `src/main/java/module-info.java` exists without > considering whether the file has been excluded by configuration. (I am simply > trying to setup a build that uses Java 9 tooling on Java 9 and Java 8 tooling > when running on Java 8) > There is no workaround to this in v3.0.0 that I can see, so I have to > rollback to v3.0.0-M1. The solution is to check the includes/excludes when > trying to obtain the module-info file. Or to check what version of the > Javadoc tool is being used (as per MJAVADOC-499). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MJAVADOC-546) Allow to generate report in Spanish locale
[ https://issues.apache.org/jira/browse/MJAVADOC-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MJAVADOC-546. --- Resolution: Fixed Assignee: Robert Scholte Fix Version/s: 3.0.2 Fixed in [ffa997370be99ff0093275ce78517fe256afadcd|https://gitbox.apache.org/repos/asf?p=maven-javadoc-plugin.git;a=commit;h=ffa997370be99ff0093275ce78517fe256afadcd] Thanks for the patch! > Allow to generate report in Spanish locale > -- > > Key: MJAVADOC-546 > URL: https://issues.apache.org/jira/browse/MJAVADOC-546 > Project: Maven Javadoc Plugin > Issue Type: Improvement > Components: javadoc >Reporter: Gabriel Belingueres >Assignee: Robert Scholte >Priority: Trivial > Fix For: 3.0.2 > > > Add locale files to generate javadoc reports in Spanish. > (I'll provide a PR these files) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAVADOC-546) Allow to generate report in Spanish locale
[ https://issues.apache.org/jira/browse/MJAVADOC-546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16700957#comment-16700957 ] ASF GitHub Bot commented on MJAVADOC-546: - rfscholte closed pull request #12: [MJAVADOC-546] Allow to generate report in Spanish locale URL: https://github.com/apache/maven-javadoc-plugin/pull/12 This is a PR merged from a forked repository. As GitHub hides the original diff on merge, it is displayed below for the sake of provenance: As this is a foreign pull request (from a fork), the diff is supplied below (as it won't show otherwise due to GitHub magic): diff --git a/src/main/resources/javadoc-report_es.properties b/src/main/resources/javadoc-report_es.properties new file mode 100644 index 000..75b402f --- /dev/null +++ b/src/main/resources/javadoc-report_es.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. + +report.javadoc.name=Javadoc +report.javadoc.description=Documentaci\u00F3n de API Javadoc. diff --git a/src/main/resources/test-javadoc-report_es.properties b/src/main/resources/test-javadoc-report_es.properties new file mode 100644 index 000..a726495 --- /dev/null +++ b/src/main/resources/test-javadoc-report_es.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. + +report.test-javadoc.name=Javadoc de Pruebas +report.test-javadoc.description=Documentaci\u00F3n de API Javadoc para Pruebas. This is an automated message from the Apache Git Service. To respond to the message, please log on 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 > Allow to generate report in Spanish locale > -- > > Key: MJAVADOC-546 > URL: https://issues.apache.org/jira/browse/MJAVADOC-546 > Project: Maven Javadoc Plugin > Issue Type: Improvement > Components: javadoc >Reporter: Gabriel Belingueres >Priority: Trivial > > Add locale files to generate javadoc reports in Spanish. > (I'll provide a PR these files) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] rfscholte closed pull request #12: [MJAVADOC-546] Allow to generate report in Spanish locale
rfscholte closed pull request #12: [MJAVADOC-546] Allow to generate report in Spanish locale URL: https://github.com/apache/maven-javadoc-plugin/pull/12 This is a PR merged from a forked repository. As GitHub hides the original diff on merge, it is displayed below for the sake of provenance: As this is a foreign pull request (from a fork), the diff is supplied below (as it won't show otherwise due to GitHub magic): diff --git a/src/main/resources/javadoc-report_es.properties b/src/main/resources/javadoc-report_es.properties new file mode 100644 index 000..75b402f --- /dev/null +++ b/src/main/resources/javadoc-report_es.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. + +report.javadoc.name=Javadoc +report.javadoc.description=Documentaci\u00F3n de API Javadoc. diff --git a/src/main/resources/test-javadoc-report_es.properties b/src/main/resources/test-javadoc-report_es.properties new file mode 100644 index 000..a726495 --- /dev/null +++ b/src/main/resources/test-javadoc-report_es.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. + +report.test-javadoc.name=Javadoc de Pruebas +report.test-javadoc.description=Documentaci\u00F3n de API Javadoc para Pruebas. This is an automated message from the Apache Git Service. To respond to the message, please log on 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] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts
[ https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1585: --- Fix Version/s: (was: 3.0.0-M2) Backlog > Auto-resolve "missing" JUnit 5 artifacts > > > Key: SUREFIRE-1585 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1585 > Project: Maven Surefire > Issue Type: Improvement > Components: JUnit 5.x support >Affects Versions: 2.22.1 >Reporter: Christian Stein >Assignee: Christian Stein >Priority: Minor > Labels: features > Fix For: Backlog > > > Providers should be able to enhance the test runtime by injecting "missing" > artifacts before executing tests. > > For example, the JUnit Platform Provider should add "missing" Test Engine > artifacts for when users only depend on the API of a test framework. > * User test depends on *`junit-jupiter-api`* only? Provide > *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps. > * User test depends on *`junit-jupiter-params`* only? That pulls in > *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test > runtime -- automatically or via plugin deps. > * User test depends on *`junit:junit:4.12`* only *AND* the JUnit Platform > Provider is forced? Provide *`junit-vintage-engine`* at test runtime -- > automatically or via plugin deps. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-4777) Match property for profile activation against a regex
[
https://issues.apache.org/jira/browse/MNG-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16700901#comment-16700901
]
ASF GitHub Bot commented on MNG-4777:
-
rfscholte commented on issue #80: [MNG-4777] Match property for profile
activation against a regex
URL: https://github.com/apache/maven/pull/80#issuecomment-442186378
Not anymore possible to merge. Also, changing the specification will have a
negative effect on all consumers of the pom. Allowing regex as property comes
with extra requirements and such profile must be removed when distributing the
pom.
I'll close this PR, MNG-4777is still open.
This is an automated message from the Apache Git Service.
To respond to the message, please log on 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
> Match property for profile activation against a regex
> -
>
> Key: MNG-4777
> URL: https://issues.apache.org/jira/browse/MNG-4777
> Project: Maven
> Issue Type: Improvement
> Components: Profiles
>Affects Versions: 2.0.11
>Reporter: Andreas Ebbert-Karroum
>Priority: Major
> Attachments: regex-project-property-profile-activator.patch
>
>
> For activating a profile it would be nice, in addition or as a seperate
> feature to MNG-3328, to match a property not against a specific value but
> against a regex. In our case, we need to set some properties for some hudson
> builds. Not only is that setup fragile against job name changes, but also
> doesn't scale for multiple jobs. IMHO adding a regex matcher would be a nice
> feature for multiple purposes.
> Old:
> {code:xml}
>
>
> env.JOB_NAME
>
> xyz-abc-foo/label=robotframework,maven.browser-profile=firefox,maven.env-profile=dev
>
>
> {code}
> New:
> {code:xml}
>
>
> env.JOB_NAME
> xyz-abc-foo/.*
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] rfscholte commented on issue #80: [MNG-4777] Match property for profile activation against a regex
rfscholte commented on issue #80: [MNG-4777] Match property for profile activation against a regex URL: https://github.com/apache/maven/pull/80#issuecomment-442186378 Not anymore possible to merge. Also, changing the specification will have a negative effect on all consumers of the pom. Allowing regex as property comes with extra requirements and such profile must be removed when distributing the pom. I'll close this PR, MNG-4777is still open. This is an automated message from the Apache Git Service. To respond to the message, please log on 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] rfscholte commented on issue #107: Fixes to various JIRA issues.
rfscholte commented on issue #107: Fixes to various JIRA issues. URL: https://github.com/apache/maven/pull/107#issuecomment-442183835 We might need to cherry-pick some commits, but we won't merge this PR. This is an automated message from the Apache Git Service. To respond to the message, please log on 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-6311) Maven intolerably slow when import scope used heavily in large project
[ https://issues.apache.org/jira/browse/MNG-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16700887#comment-16700887 ] Robert Scholte commented on MNG-6311: - [~mickael.istria] based on the comments this commit seems to improve the performance a lot, so I don't think that reverting is the right solution. Instad I would suggest to create a new issue to improve the cache even more, keeping IDEs in mind. > Maven intolerably slow when import scope used heavily in large project > -- > > Key: MNG-6311 > URL: https://issues.apache.org/jira/browse/MNG-6311 > Project: Maven > Issue Type: Bug > Components: core, Performance >Affects Versions: 3.5.0, 3.5.2 >Reporter: David Churcher >Assignee: Sylwester Lachiewicz >Priority: Major > Labels: performance > Fix For: 3.6.0 > > Attachments: Call-tree-–-All-threads-together.html, > anon-hierarchy-maven-output.zip, modelcachefix.diff > > > I have a build performance problem that is identical to MNG-5312, and has > appeared since MNG-6030 in Maven v3.5.0 reversed the patch for MNG-5312, > removing the ModelCache from some of the overloads for > DefaultProjectBuilder.build. > As in MNG-5312 the problem is in a large proprietary project. It uses up to 8 > levels of parent POMs, many of which use the import scope and have large > dependency-management sections, and has hundreds of dependencies that also > use the same parent POM hierarchy. Adding some logging shows that Maven does > over 800,000 uncached reads of parent POM files, which takes about half an > hour. With model caching this goes down to a few seconds. > I've attached a patch that fixes this by using a class-level ModelCache in > DefaultProjectBuilder. This does not suffer from the memory usage problems > reported in MNG-6030. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MNG-6311) Maven intolerably slow when import scope used heavily in large project
[ https://issues.apache.org/jira/browse/MNG-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-6311: Comment: was deleted (was: Build succeeded in Jenkins: Maven TLP » maven » MNG-5666 #6 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-5666/6/) > Maven intolerably slow when import scope used heavily in large project > -- > > Key: MNG-6311 > URL: https://issues.apache.org/jira/browse/MNG-6311 > Project: Maven > Issue Type: Bug > Components: core, Performance >Affects Versions: 3.5.0, 3.5.2 >Reporter: David Churcher >Assignee: Sylwester Lachiewicz >Priority: Major > Labels: performance > Fix For: 3.6.0 > > Attachments: Call-tree-–-All-threads-together.html, > anon-hierarchy-maven-output.zip, modelcachefix.diff > > > I have a build performance problem that is identical to MNG-5312, and has > appeared since MNG-6030 in Maven v3.5.0 reversed the patch for MNG-5312, > removing the ModelCache from some of the overloads for > DefaultProjectBuilder.build. > As in MNG-5312 the problem is in a large proprietary project. It uses up to 8 > levels of parent POMs, many of which use the import scope and have large > dependency-management sections, and has hundreds of dependencies that also > use the same parent POM hierarchy. Adding some logging shows that Maven does > over 800,000 uncached reads of parent POM files, which takes about half an > hour. With model caching this goes down to a few seconds. > I've attached a patch that fixes this by using a class-level ModelCache in > DefaultProjectBuilder. This does not suffer from the memory usage problems > reported in MNG-6030. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MNG-6311) Maven intolerably slow when import scope used heavily in large project
[ https://issues.apache.org/jira/browse/MNG-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-6311: Comment: was deleted (was: Build failed in Jenkins: Maven TLP » maven » master #71 See https://builds.apache.org/job/maven-box/job/maven/job/master/71/) > Maven intolerably slow when import scope used heavily in large project > -- > > Key: MNG-6311 > URL: https://issues.apache.org/jira/browse/MNG-6311 > Project: Maven > Issue Type: Bug > Components: core, Performance >Affects Versions: 3.5.0, 3.5.2 >Reporter: David Churcher >Assignee: Sylwester Lachiewicz >Priority: Major > Labels: performance > Fix For: 3.6.0 > > Attachments: Call-tree-–-All-threads-together.html, > anon-hierarchy-maven-output.zip, modelcachefix.diff > > > I have a build performance problem that is identical to MNG-5312, and has > appeared since MNG-6030 in Maven v3.5.0 reversed the patch for MNG-5312, > removing the ModelCache from some of the overloads for > DefaultProjectBuilder.build. > As in MNG-5312 the problem is in a large proprietary project. It uses up to 8 > levels of parent POMs, many of which use the import scope and have large > dependency-management sections, and has hundreds of dependencies that also > use the same parent POM hierarchy. Adding some logging shows that Maven does > over 800,000 uncached reads of parent POM files, which takes about half an > hour. With model caching this goes down to a few seconds. > I've attached a patch that fixes this by using a class-level ModelCache in > DefaultProjectBuilder. This does not suffer from the memory usage problems > reported in MNG-6030. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MNG-6311) Maven intolerably slow when import scope used heavily in large project
[ https://issues.apache.org/jira/browse/MNG-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-6311: Comment: was deleted (was: Build failed in Jenkins: Maven TLP » maven » MNG-6012-Missing-Profile-At-End #16 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/16/) > Maven intolerably slow when import scope used heavily in large project > -- > > Key: MNG-6311 > URL: https://issues.apache.org/jira/browse/MNG-6311 > Project: Maven > Issue Type: Bug > Components: core, Performance >Affects Versions: 3.5.0, 3.5.2 >Reporter: David Churcher >Assignee: Sylwester Lachiewicz >Priority: Major > Labels: performance > Fix For: 3.6.0 > > Attachments: Call-tree-–-All-threads-together.html, > anon-hierarchy-maven-output.zip, modelcachefix.diff > > > I have a build performance problem that is identical to MNG-5312, and has > appeared since MNG-6030 in Maven v3.5.0 reversed the patch for MNG-5312, > removing the ModelCache from some of the overloads for > DefaultProjectBuilder.build. > As in MNG-5312 the problem is in a large proprietary project. It uses up to 8 > levels of parent POMs, many of which use the import scope and have large > dependency-management sections, and has hundreds of dependencies that also > use the same parent POM hierarchy. Adding some logging shows that Maven does > over 800,000 uncached reads of parent POM files, which takes about half an > hour. With model caching this goes down to a few seconds. > I've attached a patch that fixes this by using a class-level ModelCache in > DefaultProjectBuilder. This does not suffer from the memory usage problems > reported in MNG-6030. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MNG-6311) Maven intolerably slow when import scope used heavily in large project
[ https://issues.apache.org/jira/browse/MNG-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-6311: Comment: was deleted (was: Build succeeded in Jenkins: Maven TLP » maven » MNG-6414-apache-license #2 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6414-apache-license/2/) > Maven intolerably slow when import scope used heavily in large project > -- > > Key: MNG-6311 > URL: https://issues.apache.org/jira/browse/MNG-6311 > Project: Maven > Issue Type: Bug > Components: core, Performance >Affects Versions: 3.5.0, 3.5.2 >Reporter: David Churcher >Assignee: Sylwester Lachiewicz >Priority: Major > Labels: performance > Fix For: 3.6.0 > > Attachments: Call-tree-–-All-threads-together.html, > anon-hierarchy-maven-output.zip, modelcachefix.diff > > > I have a build performance problem that is identical to MNG-5312, and has > appeared since MNG-6030 in Maven v3.5.0 reversed the patch for MNG-5312, > removing the ModelCache from some of the overloads for > DefaultProjectBuilder.build. > As in MNG-5312 the problem is in a large proprietary project. It uses up to 8 > levels of parent POMs, many of which use the import scope and have large > dependency-management sections, and has hundreds of dependencies that also > use the same parent POM hierarchy. Adding some logging shows that Maven does > over 800,000 uncached reads of parent POM files, which takes about half an > hour. With model caching this goes down to a few seconds. > I've attached a patch that fixes this by using a class-level ModelCache in > DefaultProjectBuilder. This does not suffer from the memory usage problems > reported in MNG-6030. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MNG-6311) Maven intolerably slow when import scope used heavily in large project
[ https://issues.apache.org/jira/browse/MNG-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-6311: Comment: was deleted (was: Build unstable in Jenkins: Maven TLP » maven » MNG-6391 #21 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6391/21/) > Maven intolerably slow when import scope used heavily in large project > -- > > Key: MNG-6311 > URL: https://issues.apache.org/jira/browse/MNG-6311 > Project: Maven > Issue Type: Bug > Components: core, Performance >Affects Versions: 3.5.0, 3.5.2 >Reporter: David Churcher >Assignee: Sylwester Lachiewicz >Priority: Major > Labels: performance > Fix For: 3.6.0 > > Attachments: Call-tree-–-All-threads-together.html, > anon-hierarchy-maven-output.zip, modelcachefix.diff > > > I have a build performance problem that is identical to MNG-5312, and has > appeared since MNG-6030 in Maven v3.5.0 reversed the patch for MNG-5312, > removing the ModelCache from some of the overloads for > DefaultProjectBuilder.build. > As in MNG-5312 the problem is in a large proprietary project. It uses up to 8 > levels of parent POMs, many of which use the import scope and have large > dependency-management sections, and has hundreds of dependencies that also > use the same parent POM hierarchy. Adding some logging shows that Maven does > over 800,000 uncached reads of parent POM files, which takes about half an > hour. With model caching this goes down to a few seconds. > I've attached a patch that fixes this by using a class-level ModelCache in > DefaultProjectBuilder. This does not suffer from the memory usage problems > reported in MNG-6030. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MNG-6311) Maven intolerably slow when import scope used heavily in large project
[ https://issues.apache.org/jira/browse/MNG-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-6311: Comment: was deleted (was: Build succeeded in Jenkins: Maven TLP » maven » jenkins-relativize-problem #4 See https://builds.apache.org/job/maven-box/job/maven/job/jenkins-relativize-problem/4/) > Maven intolerably slow when import scope used heavily in large project > -- > > Key: MNG-6311 > URL: https://issues.apache.org/jira/browse/MNG-6311 > Project: Maven > Issue Type: Bug > Components: core, Performance >Affects Versions: 3.5.0, 3.5.2 >Reporter: David Churcher >Assignee: Sylwester Lachiewicz >Priority: Major > Labels: performance > Fix For: 3.6.0 > > Attachments: Call-tree-–-All-threads-together.html, > anon-hierarchy-maven-output.zip, modelcachefix.diff > > > I have a build performance problem that is identical to MNG-5312, and has > appeared since MNG-6030 in Maven v3.5.0 reversed the patch for MNG-5312, > removing the ModelCache from some of the overloads for > DefaultProjectBuilder.build. > As in MNG-5312 the problem is in a large proprietary project. It uses up to 8 > levels of parent POMs, many of which use the import scope and have large > dependency-management sections, and has hundreds of dependencies that also > use the same parent POM hierarchy. Adding some logging shows that Maven does > over 800,000 uncached reads of parent POM files, which takes about half an > hour. With model caching this goes down to a few seconds. > I've attached a patch that fixes this by using a class-level ModelCache in > DefaultProjectBuilder. This does not suffer from the memory usage problems > reported in MNG-6030. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEP-628) Unpacking File Mappers
[
https://issues.apache.org/jira/browse/MDEP-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16700883#comment-16700883
]
ASF GitHub Bot commented on MDEP-628:
-
rfscholte commented on issue #5: [MDEP-628] Parameter `fileMappers` for unpack
path rewriting
URL:
https://github.com/apache/maven-dependency-plugin/pull/5#issuecomment-442179583
A ping like this helps. I've had a look at the patch, but I am missing a
test to confirm this feature. Probably easiest solved by providing an
Integration Test under `src/it/projects`, executed with `mvn verify -Prun-its`
This is an automated message from the Apache Git Service.
To respond to the message, please log on 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
> Unpacking File Mappers
> --
>
> Key: MDEP-628
> URL: https://issues.apache.org/jira/browse/MDEP-628
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: unpack, unpack-dependencies
>Affects Versions: 3.1.1
>Reporter: Markus Karg
>Priority: Major
> Labels: FileMapper, Mapping, Path
>
> The new parameter {{fileMappers}} (default: {{null}}) can be set to an
> implementation of the
> {{org.codehaus.plexus.components.io.filemappers.FileMapper}} interface to
> rewrite the target path of each unpacked file.
> This is useful in case prefixes of target files names within the target
> directory shall be added (using {{PrefixFileMapper}}), changed or omitted
> (using {{RegExpFileMapper}}).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] rfscholte commented on issue #5: [MDEP-628] Parameter `fileMappers` for unpack path rewriting
rfscholte commented on issue #5: [MDEP-628] Parameter `fileMappers` for unpack path rewriting URL: https://github.com/apache/maven-dependency-plugin/pull/5#issuecomment-442179583 A ping like this helps. I've had a look at the patch, but I am missing a test to confirm this feature. Probably easiest solved by providing an Integration Test under `src/it/projects`, executed with `mvn verify -Prun-its` This is an automated message from the Apache Git Service. To respond to the message, please log on 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-6311) Maven intolerably slow when import scope used heavily in large project
[ https://issues.apache.org/jira/browse/MNG-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16700807#comment-16700807 ] Mickael Istria commented on MNG-6311: - I think this change should be reverted as it's not backward compatible. Unless I'm mistaken, this caching makes that 2 distinct calls to ProjectBuilder.build(pomFile) would always return the same result even if the content of pomFile did change. It's almost certain that m2e will face a bug and other clients of ProjectBuilder may face bugs too. This case of changing pom content being modified and ProjectBuilder.build(...) returning the same result should be covered by a unit test (I may try write one). Caching is a good idea, but it also need to take into account the modification date to not cause bug in dynamic world. > Maven intolerably slow when import scope used heavily in large project > -- > > Key: MNG-6311 > URL: https://issues.apache.org/jira/browse/MNG-6311 > Project: Maven > Issue Type: Bug > Components: core, Performance >Affects Versions: 3.5.0, 3.5.2 >Reporter: David Churcher >Assignee: Sylwester Lachiewicz >Priority: Major > Labels: performance > Fix For: 3.6.0 > > Attachments: Call-tree-–-All-threads-together.html, > anon-hierarchy-maven-output.zip, modelcachefix.diff > > > I have a build performance problem that is identical to MNG-5312, and has > appeared since MNG-6030 in Maven v3.5.0 reversed the patch for MNG-5312, > removing the ModelCache from some of the overloads for > DefaultProjectBuilder.build. > As in MNG-5312 the problem is in a large proprietary project. It uses up to 8 > levels of parent POMs, many of which use the import scope and have large > dependency-management sections, and has hundreds of dependencies that also > use the same parent POM hierarchy. Adding some logging shows that Maven does > over 800,000 uncached reads of parent POM files, which takes about half an > hour. With model caching this goes down to a few seconds. > I've attached a patch that fixes this by using a class-level ModelCache in > DefaultProjectBuilder. This does not suffer from the memory usage problems > reported in MNG-6030. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAVADOC-523) Exclude non-Java JARs from Maven Javadoc plugin processing
[
https://issues.apache.org/jira/browse/MJAVADOC-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16700745#comment-16700745
]
Thorsten Glaser commented on MJAVADOC-523:
--
Thanks for the workaround, it at least gets rid of several yellow and red lines
in my Jenkins output, making it more manageable. I’d still prefer a proper fix
of course, and I don’t know how this can negatively affect documentation.
Perhaps an invocation to build a dummy javadoc could be added to the non-Java
modules, if the plugin supports such… it’s easy enough to run it after all.
Even better would be if it could do that automatically, if invoked in a project
without Java files, *and* skip attaching the dummy javadoc, use it only to
satisfy resolution.
> Exclude non-Java JARs from Maven Javadoc plugin processing
> --
>
> Key: MJAVADOC-523
> URL: https://issues.apache.org/jira/browse/MJAVADOC-523
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.8
>Reporter: Thorsten Glaser
>Priority: Minor
>
> I have a multi-module project which builds a couple of JARs and then
> distributed them into two WARs.
> However, one of the JARs does not contain any Java code at all, merely
> (maven-filtered) resources. This leads to warnings during the build like
> these:
> {{[…]
> [INFO] --- maven-javadoc-plugin:2.8:jar (attach-javadocs) @ foo-services ---
> [INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:2.8:javadoc'
> has not been previously called for the module:
> 'de.tarent.foo:foo-rsrcs:jar:1.3.900-SNAPSHOT'. Trying to invoke it...
> [WARNING] Creating fake javadoc directory to prevent repeated invocations:
> /var/lib/jenkins/jobs/FooTool/workspace/foo-backend/foo-rsrcs/target/apidocs
> [ERROR] Error fetching link:
> /var/lib/jenkins/jobs/FooTool/workspace/foo-backend/foo-rsrcs/target/apidocs/package-list.
> Ignored it.
> [INFO]
> Loading source files for package de.tarent.foo.rest.transformation...
> […]}}
> I found how I can exclude javadoc stuff by package, but not by artifact.
> The plugin is currently included ONLY in the parent POM, like this:
> {{org.apache.maven.pluginsmaven-javadoc-plugin2.8attach-javadocsjar}}
> While it _is_ run during “compilation” of the resources-only JAR, it
> (obviously) produces no result, thus the warning (as it’s not excluded
> either).
> How can I either make it produce something (i.e. the ability to create a
> valid-looking yet contentless FOO-javadoc.jar that satisfies references by
> reverse dependencies, in a JAR not containing any Java™ code) or, probably
> preferably, exclude the {{foo-rsrcs}} module from being accessed by mjavadoc
> on modules depending on it?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-527) detectLinks may pass invalid urls to javadoc
[ https://issues.apache.org/jira/browse/MJAVADOC-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16700594#comment-16700594 ] ASF GitHub Bot commented on MJAVADOC-527: - dedabob commented on issue #4: [MJAVADOC-527] - detectLinks may pass invalid urls to javadoc URL: https://github.com/apache/maven-javadoc-plugin/pull/4#issuecomment-442102471 Verify we were redirected to a location ending with `/package-list`. This is faster then using `validateLinks`, which can be used anyway to verify the content of the resource. This is an automated message from the Apache Git Service. To respond to the message, please log on 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 > detectLinks may pass invalid urls to javadoc > > > Key: MJAVADOC-527 > URL: https://issues.apache.org/jira/browse/MJAVADOC-527 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.0.1 > Environment: Windows 10 > JDK 8 > Maven 3.5.2 >Reporter: Roberto Benedetti >Priority: Major > Labels: detectLinks > > The url of artifact com.sun.mail:mailapi:1.5.5 is > [http://javamail.java.net/mailapi], so the plugin tests if > [http://javamail.java.net/mailapi/apidocs/package-list] is valid. > That url redirects to [https://javaee.github.io/javamail/] which is JavaMail > home page, so the plugin thinks the url is valid and passes it to javadoc. > javadoc warns about invalid link. > Maybe checking if the effective url is still "package-list" would be safer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAVADOC-527) detectLinks may pass invalid urls to javadoc
[ https://issues.apache.org/jira/browse/MJAVADOC-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16700601#comment-16700601 ] Roberto Benedetti commented on MJAVADOC-527: I'm sorry I'm not experienced at using GitHub. I merged with upstream, which accidentally changed the format of some files. I comment the PR too. > detectLinks may pass invalid urls to javadoc > > > Key: MJAVADOC-527 > URL: https://issues.apache.org/jira/browse/MJAVADOC-527 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.0.1 > Environment: Windows 10 > JDK 8 > Maven 3.5.2 >Reporter: Roberto Benedetti >Priority: Major > Labels: detectLinks > > The url of artifact com.sun.mail:mailapi:1.5.5 is > [http://javamail.java.net/mailapi], so the plugin tests if > [http://javamail.java.net/mailapi/apidocs/package-list] is valid. > That url redirects to [https://javaee.github.io/javamail/] which is JavaMail > home page, so the plugin thinks the url is valid and passes it to javadoc. > javadoc warns about invalid link. > Maybe checking if the effective url is still "package-list" would be safer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] dedabob commented on issue #4: [MJAVADOC-527] - detectLinks may pass invalid urls to javadoc
dedabob commented on issue #4: [MJAVADOC-527] - detectLinks may pass invalid urls to javadoc URL: https://github.com/apache/maven-javadoc-plugin/pull/4#issuecomment-442102471 Verify we were redirected to a location ending with `/package-list`. This is faster then using `validateLinks`, which can be used anyway to verify the content of the resource. This is an automated message from the Apache Git Service. To respond to the message, please log on 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-6529) ProjectBuilder.build(List projects, boolean, ProjectBuildingRequest) doesn't honor ProjectBuildingRequest.isResolveDependencies()
[ https://issues.apache.org/jira/browse/MNG-6529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16700542#comment-16700542 ] Mickael Istria commented on MNG-6529: - https://github.com/apache/maven/pull/193 showcases the bug in a JUnit Test > ProjectBuilder.build(List projects, boolean, ProjectBuildingRequest) > doesn't honor ProjectBuildingRequest.isResolveDependencies() > --- > > Key: MNG-6529 > URL: https://issues.apache.org/jira/browse/MNG-6529 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.3 >Reporter: Mickael Istria >Priority: Critical > > I'm willing to upfate Eclipse m2e to take advantage of the > `ProjectBuilder.build(List project, boolean, ProjectBuildingRequest)` > in Eclipse m2e to avoid duplication of MavenProject in the IDE in place of > `ProjectBuilder.build(File singleFile, ProjectBuildingRequest)`. It's already > measured to have drastically good impact on the IDE, as explained in > [https://bugs.eclipse.org/bugs/show_bug.cgi?id=515668#c20] and > [https://bugs.eclipse.org/bugs/show_bug.cgi?id=515668#c38]. > However, using this cause regressions because the multi-projects entry-point > method seems to totally ignore the > `ProjectBuildRequest.isResolveDependencies()` flag and never returns a valid > list of `MavenProject.getArtifacts()`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6529) ProjectBuilder.build(List projects, boolean, ProjectBuildingRequest) doesn't honor ProjectBuildingRequest.isResolveDependencies()
[ https://issues.apache.org/jira/browse/MNG-6529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16700541#comment-16700541 ] ASF GitHub Bot commented on MNG-6529: - mickaelistria opened a new pull request #193: MNG-6529 - JUnit Test showcasing the bug URL: https://github.com/apache/maven/pull/193 This adds a (failing) unit test showcasing that ProjectBuilder.build(List projects, boolean, ProjectBuildingRequest) doesn't honor ProjectBuildingRequest.isResolveDependencies() Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MNG-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MNG-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [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) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ This is an automated message from the Apache Git Service. To respond to the message, please log on 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 > ProjectBuilder.build(List projects, boolean, ProjectBuildingRequest) > doesn't honor ProjectBuildingRequest.isResolveDependencies() > --- > > Key: MNG-6529 > URL: https://issues.apache.org/jira/browse/MNG-6529 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.3 >Reporter: Mickael Istria >Priority: Critical > > I'm willing to upfate Eclipse m2e to take advantage of the > `ProjectBuilder.build(List project, boolean, ProjectBuildingRequest)` > in Eclipse m2e to avoid duplication of MavenProject in the IDE in place of > `ProjectBuilder.build(File singleFile, ProjectBuildingRequest)`. It's already > measured to have drastically good impact on the IDE, as explained in > [https://bugs.eclipse.org/bugs/show_bug.cgi?id=515668#c20] and > [https://bugs.eclipse.org/bugs/show_bug.cgi?id=515668#c38]. > However, using this cause regressions because the multi-projects entry-point > method seems to totally ignore the > `ProjectBuildRequest.isResolveDependencies()` flag and never returns a valid > list of `MavenProject.getArtifacts()`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] mickaelistria opened a new pull request #193: MNG-6529 - JUnit Test showcasing the bug
mickaelistria opened a new pull request #193: MNG-6529 - JUnit Test showcasing the bug URL: https://github.com/apache/maven/pull/193 This adds a (failing) unit test showcasing that ProjectBuilder.build(List projects, boolean, ProjectBuildingRequest) doesn't honor ProjectBuildingRequest.isResolveDependencies() Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MNG-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MNG-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [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) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ This is an automated message from the Apache Git Service. To respond to the message, please log on 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-6529) ProjectBuilder.build(List projects, boolean, ProjectBuildingRequest) doesn't honor ProjectBuildingRequest.isResolveDependencies()
Mickael Istria created MNG-6529: --- Summary: ProjectBuilder.build(List projects, boolean, ProjectBuildingRequest) doesn't honor ProjectBuildingRequest.isResolveDependencies() Key: MNG-6529 URL: https://issues.apache.org/jira/browse/MNG-6529 Project: Maven Issue Type: Bug Components: core Affects Versions: 3.5.3 Reporter: Mickael Istria I'm willing to upfate Eclipse m2e to take advantage of the `ProjectBuilder.build(List project, boolean, ProjectBuildingRequest)` in Eclipse m2e to avoid duplication of MavenProject in the IDE in place of `ProjectBuilder.build(File singleFile, ProjectBuildingRequest)`. It's already measured to have drastically good impact on the IDE, as explained in [https://bugs.eclipse.org/bugs/show_bug.cgi?id=515668#c20] and [https://bugs.eclipse.org/bugs/show_bug.cgi?id=515668#c38]. However, using this cause regressions because the multi-projects entry-point method seems to totally ignore the `ProjectBuildRequest.isResolveDependencies()` flag and never returns a valid list of `MavenProject.getArtifacts()`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6528) Add unit tests for org.apache.maven.plugin.CacheUtils
[
https://issues.apache.org/jira/browse/MNG-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Louis Mills updated MNG-6528:
-
Description: These tests were written by Diffblue Cover. (was: {{These
tests were written by Diffblue Cover.}})
> Add unit tests for org.apache.maven.plugin.CacheUtils
> -
>
> Key: MNG-6528
> URL: https://issues.apache.org/jira/browse/MNG-6528
> Project: Maven
> Issue Type: Test
>Reporter: Louis Mills
>Priority: Major
> Labels: pull-request-available
>
> These tests were written by Diffblue Cover.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-523) Exclude non-Java JARs from Maven Javadoc plugin processing
[
https://issues.apache.org/jira/browse/MJAVADOC-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16700452#comment-16700452
]
Rune Flobakk commented on MJAVADOC-523:
---
I can make the warn go away using
{{false}}
(Found here: https://issues.jboss.org/browse/ISPN-8629)
I guess this works ok in my case because I have _only_ two modules, where one
is not producing any javadocs.
> Exclude non-Java JARs from Maven Javadoc plugin processing
> --
>
> Key: MJAVADOC-523
> URL: https://issues.apache.org/jira/browse/MJAVADOC-523
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.8
>Reporter: Thorsten Glaser
>Priority: Minor
>
> I have a multi-module project which builds a couple of JARs and then
> distributed them into two WARs.
> However, one of the JARs does not contain any Java code at all, merely
> (maven-filtered) resources. This leads to warnings during the build like
> these:
> {{[…]
> [INFO] --- maven-javadoc-plugin:2.8:jar (attach-javadocs) @ foo-services ---
> [INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:2.8:javadoc'
> has not been previously called for the module:
> 'de.tarent.foo:foo-rsrcs:jar:1.3.900-SNAPSHOT'. Trying to invoke it...
> [WARNING] Creating fake javadoc directory to prevent repeated invocations:
> /var/lib/jenkins/jobs/FooTool/workspace/foo-backend/foo-rsrcs/target/apidocs
> [ERROR] Error fetching link:
> /var/lib/jenkins/jobs/FooTool/workspace/foo-backend/foo-rsrcs/target/apidocs/package-list.
> Ignored it.
> [INFO]
> Loading source files for package de.tarent.foo.rest.transformation...
> […]}}
> I found how I can exclude javadoc stuff by package, but not by artifact.
> The plugin is currently included ONLY in the parent POM, like this:
> {{org.apache.maven.pluginsmaven-javadoc-plugin2.8attach-javadocsjar}}
> While it _is_ run during “compilation” of the resources-only JAR, it
> (obviously) produces no result, thus the warning (as it’s not excluded
> either).
> How can I either make it produce something (i.e. the ability to create a
> valid-looking yet contentless FOO-javadoc.jar that satisfies references by
> reverse dependencies, in a JAR not containing any Java™ code) or, probably
> preferably, exclude the {{foo-rsrcs}} module from being accessed by mjavadoc
> on modules depending on it?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MENFORCER-304) Improve dependency resolving in multiple modules project
[ https://issues.apache.org/jira/browse/MENFORCER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16700279#comment-16700279 ] ASF GitHub Bot commented on MENFORCER-304: -- gmshake commented on issue #35: [MENFORCER-304] Improve dependency resolving in multiple modules project URL: https://github.com/apache/maven-enforcer/pull/35#issuecomment-442025953 Hi @khmarbaise Any progress yet? This is an automated message from the Apache Git Service. To respond to the message, please log on 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 > Improve dependency resolving in multiple modules project > > > Key: MENFORCER-304 > URL: https://issues.apache.org/jira/browse/MENFORCER-304 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Affects Versions: 3.0.0-M1 >Reporter: Zhenlei Huang >Priority: Minor > > In a multiple modules project, some enforcer rule can not get sufficient > dependency info with default phase validate, causing issues like > [https://issues.apache.org/jira/browse/MENFORCER-168|https://issues.apache.org/jira/browse/MENFORCER-168], > and probable > [https://issues.apache.org/jira/browse/MNG-3283|https://issues.apache.org/jira/browse/MNG-3283] > Proposal: Include dependencies of reactor projects (not yet compiled) during > rule dependency resolving. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] gmshake commented on issue #35: [MENFORCER-304] Improve dependency resolving in multiple modules project
gmshake commented on issue #35: [MENFORCER-304] Improve dependency resolving in multiple modules project URL: https://github.com/apache/maven-enforcer/pull/35#issuecomment-442025953 Hi @khmarbaise Any progress yet? This is an automated message from the Apache Git Service. To respond to the message, please log on 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-6528) Add unit tests for org.apache.maven.plugin.CacheUtils
Louis Mills created MNG-6528:
Summary: Add unit tests for org.apache.maven.plugin.CacheUtils
Key: MNG-6528
URL: https://issues.apache.org/jira/browse/MNG-6528
Project: Maven
Issue Type: Test
Reporter: Louis Mills
{{These tests were written by Diffblue Cover.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6527) Add unit tests for org.apache.maven.repository.MavenArtifactMetadata
Louis Mills created MNG-6527: Summary: Add unit tests for org.apache.maven.repository.MavenArtifactMetadata Key: MNG-6527 URL: https://issues.apache.org/jira/browse/MNG-6527 Project: Maven Issue Type: Test Reporter: Louis Mills These tests were written by Diffblue Cover. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6526) Upgrade to Wagon 3.3.0
Olaf Otto created MNG-6526: -- Summary: Upgrade to Wagon 3.3.0 Key: MNG-6526 URL: https://issues.apache.org/jira/browse/MNG-6526 Project: Maven Issue Type: Dependency upgrade Components: Dependencies Affects Versions: 3.6.0 Reporter: Olaf Otto Wagon 3.3.0 contains an important improvement for the transfer speed of large artifacts (see WAGON-537). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
