[jira] [Created] (MINVOKER-309) In-process execution without forking
Michael Boyles created MINVOKER-309:
---
Summary: In-process execution without forking
Key: MINVOKER-309
URL: https://issues.apache.org/jira/browse/MINVOKER-309
Project: Maven Invoker Plugin
Issue Type: New Feature
Reporter: Michael Boyles
The FAQ has a statement from a long time ago (15 years), but there appears to
be no related ticket:
_"it is hoped that soon we will integrate the Maven Embedder into the mix to
allow you run your projects in process for great speed."_
Is this still the hope? Perhaps gains from not forking are expected to be
minimal and it's no longer worth pursuing. Functionally, it was suggested as a
workaround for MINVOKER-222
If this is desirable, is Maven Embedder still the way to go? According to a
comment on MINVOKER-222 "{_}I'm not sure maven-embedder can be used in a plugin
context{_}".
Any other thoughts welcome
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MASSEMBLY-852) permissions are lost if is present
[
https://issues.apache.org/jira/browse/MASSEMBLY-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17388299#comment-17388299
]
Michael Boyles commented on MASSEMBLY-852:
--
[~slachiewicz] I notice you've committed a few changes recently. Could you
possibly review this PR if you have time?
> permissions are lost if is present
>
>
> Key: MASSEMBLY-852
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-852
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: component descriptor, permissions
>Affects Versions: 3.0.0
> Environment: Java HotSpot(TM) 64-Bit Server VM warning: ignoring
> option MaxPermSize=256m; support was removed in 8.0
> Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4;
> 2014-08-12T00:58:10+03:00)
> Java version: 1.8.0_51, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_51/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-573.8.1.el6.x86_64", arch: "amd64",
> family: "unix"
>Reporter: Anton
>Priority: Minor
> Attachments: test.rar
>
>
> Used next descriptor:
> {code:xml}
>
> test
>
> zip
>
> false
>
>
> bin
> bin-include
>
> *
>
> 700
> 700
>
>
> bin
> bin-no-include
> 700
> 700
>
>
>
> {code}
> For both ** same *directoryMode* is set, but for case where
> ** pattern is present directory permissions are broken.
> Listing:
> {noformat}
> $ zipinfo target/testpom-1.0.0.zip
> Archive: target/testpom-1.0.0.zip
> Zip file size: 502 bytes, number of entries: 4
> drwxr-xr-x 2.0 unx0 b- stor 17-Apr-19 17:48 bin-include/
> drwx-- 2.0 unx0 b- stor 17-Apr-19 15:48 bin-no-include/
> -rwx-- 2.0 unx0 bl defN 17-Apr-19 15:48 bin-include/testfile
> -rwx-- 2.0 unx0 bl defN 17-Apr-19 15:48 bin-no-include/testfile
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1860) extend ReportEntry interface and SimpleReportEntry with mandatory properties runMode:String, id:long, forkId:int
[
https://issues.apache.org/jira/browse/SUREFIRE-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17234898#comment-17234898
]
Michael Boyles commented on SUREFIRE-1860:
--
[~tibordigana] How do you imagine testId will be derived? I had a look at the
existing code and it seems this concept does not exist yet.
If we are deriving the integer ID from the test (say, I could take the hashcode
of the class+method), then we need to consider what happens if there's a
collision, even though it might be unlikely. If we have some registry in-memory
(let's say something as basic as each fork maintains some counter which gets
incremented for each test which requests an ID) then ID becomes dependent on
the run order and will not be consistent for the same test on each run.
You mentioned in the other ticket that "this string would slow down the
performance", but to me String seems like the most unambiguous way to represent
the test.
Also, it seems we already have a RunMode enum, so should it use that or String
like you suggested? If string, then why?
Thanks!
> extend ReportEntry interface and SimpleReportEntry with mandatory properties
> runMode:String, id:long, forkId:int
>
>
> Key: SUREFIRE-1860
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1860
> Project: Maven Surefire
> Issue Type: New Feature
> Components: JUnit 3.x support, Junit 4.7+ (parallel) support, Junit
> 4.x support, JUnit 5.x support, Maven Failsafe Plugin, Maven Surefire Plugin,
> TestNG support
>Reporter: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> We are missing two properties in the {{ReportEntry}} interface
> * *runMode:String*, which "informs" the reporters that the statistics data
> is for normal tests or re-run tests
> * *id:long*, which identifies the test run instead of the current ID
> represented by the combination of class+method.
> * *forkId:int*, which identifies the {{id}} of the sub-process (forked JVM)
> Currently the XML reporter is stateful and the run mode is determined by the
> timing and the order of normal tests and rerun tests. The problem is when we
> run the tests in parallel. After we would employ the {{id:long}} we would not
> have these problems and we would solve much more like JUnit5's Dynamic tests
> and the ability to run Cucumber scripts.
> The reporters should identify the test run by the combination of *forkId* +
> test *id*. The forks have no notion about the other forks, and it's even more
> difficult to make the test ids coherent (without duplicates) across the forks
> because they are very dynamically created and finished during the lifetime of
> the plugin execution. Therefore the reporter implementation should respect
> the *forkId* too.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1844) Trademarks / privacy policy footer displays broken
[ https://issues.apache.org/jira/browse/SUREFIRE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17234496#comment-17234496 ] Michael Boyles commented on SUREFIRE-1844: -- [~tibordigana] I'd be happy to. Is there a separate ticket for that work? If not, should there be? > Trademarks / privacy policy footer displays broken > -- > > Key: SUREFIRE-1844 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1844 > Project: Maven Surefire > Issue Type: Bug > Components: documentation >Reporter: Philippe Cloutier >Assignee: Enrico Olivelli >Priority: Trivial > Fix For: 3.0.0-M6 > > Attachments: image-2020-09-22-17-29-40-357.png > > Original Estimate: 1h > Remaining Estimate: 1h > > The footer which is at the end of Surefire's documentation pages, such as > [this > one|https://maven.apache.org/surefire/maven-surefire-plugin/index.html], have > a broken display (at least in Firefox 81 and Google Chrome 85). The > horizontal alignment is incorrect, causing the sentence to start outside the > visible area and its end to overlap with the "Privacy policy" link, as can be > seen in the screenshot below: > !image-2020-09-22-17-29-40-357.png|thumbnail! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1844) Trademarks / privacy policy footer displays broken
[ https://issues.apache.org/jira/browse/SUREFIRE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233141#comment-17233141 ] Michael Boyles commented on SUREFIRE-1844: -- I suppose it will happen automatically as part of the next release. The roadmap is here [https://maven.apache.org/surefire/maven-surefire-plugin/index.html] So I'd guess: whenever those features are finished > Trademarks / privacy policy footer displays broken > -- > > Key: SUREFIRE-1844 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1844 > Project: Maven Surefire > Issue Type: Bug > Components: documentation >Reporter: Philippe Cloutier >Assignee: Enrico Olivelli >Priority: Trivial > Fix For: 3.0.0-M6 > > Attachments: image-2020-09-22-17-29-40-357.png > > Original Estimate: 1h > Remaining Estimate: 1h > > The footer which is at the end of Surefire's documentation pages, such as > [this > one|https://maven.apache.org/surefire/maven-surefire-plugin/index.html], have > a broken display (at least in Firefox 81 and Google Chrome 85). The > horizontal alignment is incorrect, causing the sentence to start outside the > visible area and its end to overlap with the "Privacy policy" link, as can be > seen in the screenshot below: > !image-2020-09-22-17-29-40-357.png|thumbnail! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCOMPILER-288) Annotation Processors are not automatically detected and executed
[ https://issues.apache.org/jira/browse/MCOMPILER-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17224082#comment-17224082 ] Michael Boyles commented on MCOMPILER-288: -- Cannot reproduce. Requires sample project or should be closed > Annotation Processors are not automatically detected and executed > - > > Key: MCOMPILER-288 > URL: https://issues.apache.org/jira/browse/MCOMPILER-288 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.6.1 > Environment: Window, Java8 >Reporter: David Nouls >Priority: Major > > I created a small annotation processor and I am trying to use it in another > maven project. > The APT is properly bundled with the > META-INF/services/java.annotation.processing.Processor pointing to the right > classname. > And I am including it as a scope provided dependency in the second module > that tries to use it. The docs of maven-compiler-plugin states that it should > auto detect and execute the APT but it does not. > If I add a configuration forceJavaCompilerUse then the annotation processor > is properly executed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6345) Support profile activation via script
[
https://issues.apache.org/jira/browse/MNG-6345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215926#comment-17215926
]
Michael Boyles commented on MNG-6345:
-
IMO this is not worth the effort to implement and maintain. For this to be
reproducible, maven would need to bundle an interpreter for all supported
scripting languages presumably.
You can just write a custom build script, something like
{code:java}
node ./my-script.js
if [ $? -eq 0 ]; then profile="abc"; else profile="def"; fi
mvn verify -P${profile}
{code}
> Support profile activation via script
> -
>
> Key: MNG-6345
> URL: https://issues.apache.org/jira/browse/MNG-6345
> Project: Maven
> Issue Type: New Feature
> Components: Bootstrap & Build
>Affects Versions: 3.5.2
>Reporter: Andrei Pozolotin
>Priority: Major
>
> Please consider introduction of new profile activation method: "script".
> Here is working prototype which adds required functionality via
> PropertyActivator:
> [https://github.com/random-maven/profile-activator-extension]
> in the final form, this feature usage will look like:
>
>
>
> javascript
> print("hello-maven"); return true;
>
>
>
> Suggested minimal supported script types:
> * Groovy
> * JavaScript
> * MVEL Script
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DOXIA-615) Can you provide an updated version in order to fix CVE-2020-13956
[ https://issues.apache.org/jira/browse/DOXIA-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17211897#comment-17211897 ] Michael Boyles commented on DOXIA-615: -- It is already done [https://github.com/apache/maven-doxia/commit/74c3e876b5c7a044f5a6b7ad7be6ea3ac10a6f49] > Can you provide an updated version in order to fix CVE-2020-13956 > - > > Key: DOXIA-615 > URL: https://issues.apache.org/jira/browse/DOXIA-615 > Project: Maven Doxia > Issue Type: Bug > Components: Core >Affects Versions: 1.6, 1.9.1 >Reporter: Philipp Ottlinger >Priority: Major > > [https://snyk.io/vuln/SNYK-JAVA-ORGAPACHEHTTPCOMPONENTS-1016906] > [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13956] > Over at RAT we do use doxia-core and just got a security report (RAT-275) > that doxia uses a problematic version of httpclient. > Can you update to a more recent version and provide a new release? > Thanks -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSTAGE-26) Fix and un-ignore RepositoryCopierTest
[ https://issues.apache.org/jira/browse/MSTAGE-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208799#comment-17208799 ] Michael Boyles commented on MSTAGE-26: -- Works on my machine™. Had to introduce an FTP server to the test. You can't rely on file:// working consistently cross-platform to "upload" files, much less exec scripts. Discovered undocumented behaviour that this plugin relies on publishing to a unix system, so had to fake some stuff to get this to run on a Windows machine. Luckily, sshd makes it easy. Line coverage of the copier is 86%. If you want more in-depth, here: [^jacoco.zip] > Fix and un-ignore RepositoryCopierTest > -- > > Key: MSTAGE-26 > URL: https://issues.apache.org/jira/browse/MSTAGE-26 > Project: Maven Stage Plugin > Issue Type: Task >Affects Versions: 1.0 >Reporter: Michael Boyles >Priority: Major > Attachments: jacoco.zip > > > Stage plugin only has 1 test and it's ignored. The comment next to it says > "This test fails in various ways on different platforms - from hanging > permanently to erroring out. Temporarily exclude it." > We should fix this test so that it's cross-platform and remove it from the > list of ignored tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MSTAGE-26) Fix and un-ignore RepositoryCopierTest
[ https://issues.apache.org/jira/browse/MSTAGE-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Boyles updated MSTAGE-26: - Attachment: jacoco.zip > Fix and un-ignore RepositoryCopierTest > -- > > Key: MSTAGE-26 > URL: https://issues.apache.org/jira/browse/MSTAGE-26 > Project: Maven Stage Plugin > Issue Type: Task >Affects Versions: 1.0 >Reporter: Michael Boyles >Priority: Major > Attachments: jacoco.zip > > > Stage plugin only has 1 test and it's ignored. The comment next to it says > "This test fails in various ways on different platforms - from hanging > permanently to erroring out. Temporarily exclude it." > We should fix this test so that it's cross-platform and remove it from the > list of ignored tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MSTAGE-26) Fix and un-ignore RepositoryCopierTest
Michael Boyles created MSTAGE-26: Summary: Fix and un-ignore RepositoryCopierTest Key: MSTAGE-26 URL: https://issues.apache.org/jira/browse/MSTAGE-26 Project: Maven Stage Plugin Issue Type: Task Affects Versions: 1.0 Reporter: Michael Boyles Stage plugin only has 1 test and it's ignored. The comment next to it says "This test fails in various ways on different platforms - from hanging permanently to erroring out. Temporarily exclude it." We should fix this test so that it's cross-platform and remove it from the list of ignored tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARCHETYPE-476) Decide what to do with the Archetypes List wiki page
[ https://issues.apache.org/jira/browse/ARCHETYPE-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206715#comment-17206715 ] Michael Boyles commented on ARCHETYPE-476: -- It used to be [http://docs.codehaus.org/display/MAVENUSER/Archetypes+List] but it's dead now. According to [this|https://cwiki.apache.org/confluence/display/MAVEN/Wiki+migration] the main "MAVEN" wiki was migrated, but MAVENUSER remained on Codehaus. It's gone now though. Maybe [~hboutemy] knows what happened to MAVENUSER? If it's been lost, we should close this ticket > Decide what to do with the Archetypes List wiki page > > > Key: ARCHETYPE-476 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-476 > Project: Maven Archetype > Issue Type: Task > Components: Documentation > Environment: n/a >Reporter: Anders Hammar >Priority: Major > > On the wiki there is an "Archetypes List" page, suggesting that it "holds the > complete list of archetypes (even not hosted at apache)". This is not true > and I don't think it is feasible to keep it updated, not desirable to keep > such a list. In the central repository there is an archetype catalog that > lists all archetypes there which should be, and is, used instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MCHECKSTYLE-334) "mvn install site" works differently than "mvn install" or "mvn site"
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206710#comment-17206710
]
Michael Boyles edited comment on MCHECKSTYLE-334 at 10/3/20, 2:20 PM:
--
Seems like this should be closed.
# Exclusion ant pattern is wrong
# There is no reason to call mvn install site. Just call mvn site
# better way to exclude generated source is set to
${project.build.sourceDirectory}
was (Author: michaelboyles):
Seems like this should be closed.
# Exclusion ant pattern is wrong
# There is no reason to call mvn install site. Just call mvn site
# target dir where generated sources exist is not included without some funky
> "mvn install site" works differently than "mvn install" or "mvn site"
> -
>
> Key: MCHECKSTYLE-334
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-334
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
> Components: checkstyle:checkstyle
>Affects Versions: 2.17
> Environment: both windows/linux
>Reporter: Frank Luo
>Priority: Major
> Labels: maven
>
> I am trying to ignore files in the dir of "target/generated-sources". So I
> have "**/generated-sources/**/*" in configure.
> When I do "mvn install" or "mvn site", checkstyle has no complains.
> But when I run "mvn install site", I got a ton of complains from
> "generated-sources" dir.
> Here is a sample:
> C:\work\project\atlas\trunk\atlas_reformat_engine\target\generated-sources\config\com\merkleinc\atlas\reformat\config\Rule.java:157:
> error: Do not use Windows line endings
> Please help
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCHECKSTYLE-334) "mvn install site" works differently than "mvn install" or "mvn site"
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206710#comment-17206710 ] Michael Boyles commented on MCHECKSTYLE-334: Seems like this should be closed. # Exclusion ant pattern is wrong # There is no reason to call mvn install site. Just call mvn site # target dir where generated sources exist is not included without some funky > "mvn install site" works differently than "mvn install" or "mvn site" > - > > Key: MCHECKSTYLE-334 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-334 > Project: Maven Checkstyle Plugin > Issue Type: Bug > Components: checkstyle:checkstyle >Affects Versions: 2.17 > Environment: both windows/linux >Reporter: Frank Luo >Priority: Major > Labels: maven > > I am trying to ignore files in the dir of "target/generated-sources". So I > have "**/generated-sources/**/*" in configure. > When I do "mvn install" or "mvn site", checkstyle has no complains. > But when I run "mvn install site", I got a ton of complains from > "generated-sources" dir. > Here is a sample: > C:\work\project\atlas\trunk\atlas_reformat_engine\target\generated-sources\config\com\merkleinc\atlas\reformat\config\Rule.java:157: > error: Do not use Windows line endings > Please help -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MDEP-715) Hamcrest used and unused
[ https://issues.apache.org/jira/browse/MDEP-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206570#comment-17206570 ] Michael Boyles commented on MDEP-715: - I suppose the important bit there is "when named modules are used", which is unfortunate. Plenty of people don't bother with the module system > Hamcrest used and unused > > > Key: MDEP-715 > URL: https://issues.apache.org/jira/browse/MDEP-715 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: analyze >Reporter: Elliotte Rusty Harold >Priority: Major > Labels: S2, intern > > This is something I've seen when analyzing several Maven plugins. For > example, maven-shared-utils circa July 20, 2020: > > [WARNING] Used undeclared dependencies found: > [WARNING] org.hamcrest:hamcrest:jar:2.2:test > [WARNING] org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M2a:test > [WARNING] Unused declared dependencies found: > [WARNING] org.hamcrest:hamcrest-core:jar:2.2:test > [WARNING] org.apache.maven:maven-core:jar:3.1.0:test > [WARNING] org.codehaus.plexus:plexus-container-default:jar:2.1.0:provided > > Easy fix, right? don't declare org.hamcrest:hamcrest-core:jar:2.2:test and > instead declare org.hamcrest:hamcrest:jar:2.2:test > > But when I do that: > > [WARNING] Used undeclared dependencies found: > [WARNING] org.hamcrest:hamcrest-core:jar:1.3:test > [WARNING] org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M2a:test > [WARNING] Unused declared dependencies found: > [WARNING] org.hamcrest:hamcrest:jar:2.2:test > [WARNING] org.apache.maven:maven-core:jar:3.1.0:test > [WARNING] org.codehaus.plexus:plexus-container-default:jar:2.1.0:provided > > Figure out what's going on here and fix it. Is hamcrest-core needed and used > or not? is hamcrest needed and used or not? Be consistent. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MDEP-715) Hamcrest used and unused
[
https://issues.apache.org/jira/browse/MDEP-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205867#comment-17205867
]
Michael Boyles edited comment on MDEP-715 at 10/1/20, 11:42 PM:
The issue seems to be that a class with the same FQN exists in two dependencies.
When shared-utils dependencies are like this
{code:java}
junit
junit
4.13
test
org.hamcrest
hamcrest-core
2.2
test
{code}
The hamcrest-core we explicitly declare overrides Junit's. The 2.2 core is
actually deprecated and just contains a text file, but crucially gives us the
transitive dependency to hamcrest:2.2, which has the classes we actually want.
Actually, we only use 1 class, org.hamcrest.CoreMatchers
So in this case we have a transitive dependency on hamcrest:2.2 which we did
not declare, so the output of analyze is *correct*.
However, when we make the seemingly obvious fix and replace hamcrest-core with
hamcrest:
{code:java}
org.hamcrest
hamcrest
2.2
test
{code}
Then now what we have is a transitive dependency on hamcrest-core:1.3 via Junit
and our own dependency on hamcrest:2.2. Both contain a class with the FQN.
hamcrest-core must "win" the lookup, so the dependency plugin assumes
org.hamcrest.CoreMatchers comes *only* from there. If that assumption were
true, hamcrest-core would be used and undeclared, transitive through junit,
while hamcrest would be unused, hence the spurious result.
I found 2 ways you can work around it:
* Move Junit after hamcrest. hamcrest "wins" the ownership of the class so is
now counted as being "used", while hamcrest-core is "unused" (but that's
transitive – "unused" and undeclared, so not a warning)
* Exclude the hamcrest-core from junit. There are no longer 2 classes with the
same FQN, so no ambiguity
—
The ideal fix is less clear to me.
Should we should emit some warning that we found a class that exists in two or
more dependencies, and consider all such dependencies to be used, and advise
them to solve the problem manually (via exclusions etc.)?
was (Author: michaelboyles):
The issue seems to be that a class with the same FQN exists in two dependencies.
When shared-utils dependencies are like this
{code:java}
junit
junit
4.13
test
org.hamcrest
hamcrest-core
2.2
test
{code}
The hamcrest-core we explicitly declare overrides Junit's. The 2.2 core is
actually deprecated and just contains a text file, but crucially gives us the
transitive dependency to hamcrest:2.2, which has the classes we actually want.
Actually, we only use 1 class, org.hamcrest.CoreMatchers
So in this case we have a transitive dependency on hamcrest:2.2 which we did
not declare, so the output of analyze is *correct*.
However, when we make the seemingly obvious fix and replace hamcrest-core with
hamcrest:
{code:java}
org.hamcrest
hamcrest
2.2
test
{code}
Then now what we have is a transitive dependency on hamcrest-core:1.3 via Junit
and our own dependency on hamcrest:2.2. Both contain a class with the FQN.
hamcrest-core must "win" the lookup, so the dependency plugin assumes
org.hamcrest.CoreMatchers comes *only* from there. If that assumption were
true, hamcrest-core would be used and undeclared, transitive through junit,
while hamcrest would be unused, hence the spurious result.
I found 2 ways you can work around it:
* Move Junit after hamcrest. hamcrest "wins" the ownership of the class so is
now counted as being "used", while hamcrest-core is "unused" (but that's
transitive – "unused" and undeclared, so not a warning)
* Exclude the hamcrest-core from junit. There are no longer 2 classes with the
same FQN, so no ambiguity
—
The ideal fix is less clear to me.
Should we should omit some warning that we found a class that exists in two or
more dependencies, and consider all such dependencies to be used, and advise
them to solve the problem manually (via exclusions etc.)?
> Hamcrest used and unused
>
>
> Key: MDEP-715
> URL: https://issues.apache.org/jira/browse/MDEP-715
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Reporter: Elliotte Rusty Harold
>Priority: Major
> Labels: S2, intern
>
> This is something I've seen when analyzing several Maven plugins. For
> example, maven-shared-utils circa July 20, 2020:
>
> [WARNING] Used undeclared dependencies found:
> [WARNING] org.hamcrest:hamcrest:jar:2.2:test
> [WARNING] org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M2a:test
> [WARNING] Unused declared dependencies found:
> [WARNING] org.hamcrest:hamcrest-core:jar:2.2:test
> [WARNING] org.apache.maven:maven-core:jar:3.1.0:test
> [WARNING] org.codehaus.plexus:plexus-container-default
[jira] [Comment Edited] (MDEP-715) Hamcrest used and unused
[
https://issues.apache.org/jira/browse/MDEP-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205867#comment-17205867
]
Michael Boyles edited comment on MDEP-715 at 10/1/20, 11:02 PM:
The issue seems to be that a class with the same FQN exists in two dependencies.
When shared-utils dependencies are like this
{code:java}
junit
junit
4.13
test
org.hamcrest
hamcrest-core
2.2
test
{code}
The hamcrest-core we explicitly declare overrides Junit's. The 2.2 core is
actually deprecated and just contains a text file, but crucially gives us the
transitive dependency to hamcrest:2.2, which has the classes we actually want.
Actually, we only use 1 class, org.hamcrest.CoreMatchers
So in this case we have a transitive dependency on hamcrest:2.2 which we did
not declare, so the output of analyze is *correct*.
However, when we make the seemingly obvious fix and replace hamcrest-core with
hamcrest:
{code:java}
org.hamcrest
hamcrest
2.2
test
{code}
Then now what we have is a transitive dependency on hamcrest-core:1.3 via Junit
and our own dependency on hamcrest:2.2. Both contain a class with the FQN.
hamcrest-core must "win" the lookup, so the dependency plugin assumes
org.hamcrest.CoreMatchers comes *only* from there. If that assumption were
true, hamcrest-core would be used and undeclared, transitive through junit,
while hamcrest would be unused, hence the spurious result.
I found 2 ways you can work around it:
* Move Junit after hamcrest. hamcrest "wins" the ownership of the class so is
now counted as being "used", while hamcrest-core is "unused" (but that's
transitive – "unused" and undeclared, so not a warning)
* Exclude the hamcrest-core from junit. There are no longer 2 classes with the
same FQN, so no ambiguity
—
The ideal fix is less clear to me.
Should we should omit some warning that we found a class that exists in two or
more dependencies, and consider all such dependencies to be used, and advise
them the solve the problem manually (via exclusions etc.)?
was (Author: michaelboyles):
The issue seems to be that a class with the same FQN exists in two dependencies.
When shared-utils dependencies are like this
{code:java}
junit
junit
4.13
test
org.hamcrest
hamcrest-core
2.2
test
{code}
The hamcrest-core we explicitly declare overrides Junit's. The 2.2 core is
actually deprecated and just contains a text file, but crucially gives us the
transitive dependency to hamcrest:2.2, which has the classes we actually want.
Actually, we only use 1 class, org.hamcrest.CoreMatchers
So in this case we have a transitive dependency on hamcrest:2.2 which we did
not declare, so the output of analyze is *correct*.
However, when we make the seemingly obvious fix and replace hamcrest-core with
hamcrest:
{code:java}
org.hamcrest
hamcrest
2.2
test
{code}
Then now what we have is a transitive dependency on hamcrest-core:1.3 via Junit
and our own dependency on hamcrest:2.2. Both contain a class with the FQN.
hamcrest-core must "win" the lookup, so the dependency plugin assumes
org.hamcrest.CoreMatchers comes *only* from there. If that assumption were
true, hamcrest-core would be used and undeclared, transitive through junit,
while hamcrest would be unused, hence the spurious result.
I found 2 ways you can work around it:
* Move Junit after hamcrest. hamcrest "wins" the ownership of the class so is
now counted as being "used", while hamcrest-core is "unused" (but that's
transitive – "unused" and undeclared, so not a warning)
* Exclude the hamcrest-core from junit
—
The ideal fix is less clear to me.
Should we should omit some warning that we found a class that exists in two or
more dependencies, and consider all such dependencies to be used, and advise
them the solve the problem manually (via exclusions etc.)?
> Hamcrest used and unused
>
>
> Key: MDEP-715
> URL: https://issues.apache.org/jira/browse/MDEP-715
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Reporter: Elliotte Rusty Harold
>Priority: Major
> Labels: S2, intern
>
> This is something I've seen when analyzing several Maven plugins. For
> example, maven-shared-utils circa July 20, 2020:
>
> [WARNING] Used undeclared dependencies found:
> [WARNING] org.hamcrest:hamcrest:jar:2.2:test
> [WARNING] org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M2a:test
> [WARNING] Unused declared dependencies found:
> [WARNING] org.hamcrest:hamcrest-core:jar:2.2:test
> [WARNING] org.apache.maven:maven-core:jar:3.1.0:test
> [WARNING] org.codehaus.plexus:plexus-container-default:jar:2.1.0:provided
>
> Easy fix, right? don't declare org.hamcr
[jira] [Comment Edited] (MDEP-715) Hamcrest used and unused
[
https://issues.apache.org/jira/browse/MDEP-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205867#comment-17205867
]
Michael Boyles edited comment on MDEP-715 at 10/1/20, 11:02 PM:
The issue seems to be that a class with the same FQN exists in two dependencies.
When shared-utils dependencies are like this
{code:java}
junit
junit
4.13
test
org.hamcrest
hamcrest-core
2.2
test
{code}
The hamcrest-core we explicitly declare overrides Junit's. The 2.2 core is
actually deprecated and just contains a text file, but crucially gives us the
transitive dependency to hamcrest:2.2, which has the classes we actually want.
Actually, we only use 1 class, org.hamcrest.CoreMatchers
So in this case we have a transitive dependency on hamcrest:2.2 which we did
not declare, so the output of analyze is *correct*.
However, when we make the seemingly obvious fix and replace hamcrest-core with
hamcrest:
{code:java}
org.hamcrest
hamcrest
2.2
test
{code}
Then now what we have is a transitive dependency on hamcrest-core:1.3 via Junit
and our own dependency on hamcrest:2.2. Both contain a class with the FQN.
hamcrest-core must "win" the lookup, so the dependency plugin assumes
org.hamcrest.CoreMatchers comes *only* from there. If that assumption were
true, hamcrest-core would be used and undeclared, transitive through junit,
while hamcrest would be unused, hence the spurious result.
I found 2 ways you can work around it:
* Move Junit after hamcrest. hamcrest "wins" the ownership of the class so is
now counted as being "used", while hamcrest-core is "unused" (but that's
transitive – "unused" and undeclared, so not a warning)
* Exclude the hamcrest-core from junit. There are no longer 2 classes with the
same FQN, so no ambiguity
—
The ideal fix is less clear to me.
Should we should omit some warning that we found a class that exists in two or
more dependencies, and consider all such dependencies to be used, and advise
them to solve the problem manually (via exclusions etc.)?
was (Author: michaelboyles):
The issue seems to be that a class with the same FQN exists in two dependencies.
When shared-utils dependencies are like this
{code:java}
junit
junit
4.13
test
org.hamcrest
hamcrest-core
2.2
test
{code}
The hamcrest-core we explicitly declare overrides Junit's. The 2.2 core is
actually deprecated and just contains a text file, but crucially gives us the
transitive dependency to hamcrest:2.2, which has the classes we actually want.
Actually, we only use 1 class, org.hamcrest.CoreMatchers
So in this case we have a transitive dependency on hamcrest:2.2 which we did
not declare, so the output of analyze is *correct*.
However, when we make the seemingly obvious fix and replace hamcrest-core with
hamcrest:
{code:java}
org.hamcrest
hamcrest
2.2
test
{code}
Then now what we have is a transitive dependency on hamcrest-core:1.3 via Junit
and our own dependency on hamcrest:2.2. Both contain a class with the FQN.
hamcrest-core must "win" the lookup, so the dependency plugin assumes
org.hamcrest.CoreMatchers comes *only* from there. If that assumption were
true, hamcrest-core would be used and undeclared, transitive through junit,
while hamcrest would be unused, hence the spurious result.
I found 2 ways you can work around it:
* Move Junit after hamcrest. hamcrest "wins" the ownership of the class so is
now counted as being "used", while hamcrest-core is "unused" (but that's
transitive – "unused" and undeclared, so not a warning)
* Exclude the hamcrest-core from junit. There are no longer 2 classes with the
same FQN, so no ambiguity
—
The ideal fix is less clear to me.
Should we should omit some warning that we found a class that exists in two or
more dependencies, and consider all such dependencies to be used, and advise
them the solve the problem manually (via exclusions etc.)?
> Hamcrest used and unused
>
>
> Key: MDEP-715
> URL: https://issues.apache.org/jira/browse/MDEP-715
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Reporter: Elliotte Rusty Harold
>Priority: Major
> Labels: S2, intern
>
> This is something I've seen when analyzing several Maven plugins. For
> example, maven-shared-utils circa July 20, 2020:
>
> [WARNING] Used undeclared dependencies found:
> [WARNING] org.hamcrest:hamcrest:jar:2.2:test
> [WARNING] org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M2a:test
> [WARNING] Unused declared dependencies found:
> [WARNING] org.hamcrest:hamcrest-core:jar:2.2:test
> [WARNING] org.apache.maven:maven-core:jar:3.1.0:test
> [WARNING] org.codehaus.plexus:plexus-container-defaul
[jira] [Comment Edited] (MDEP-715) Hamcrest used and unused
[
https://issues.apache.org/jira/browse/MDEP-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205867#comment-17205867
]
Michael Boyles edited comment on MDEP-715 at 10/1/20, 11:01 PM:
The issue seems to be that a class with the same FQN exists in two dependencies.
When shared-utils dependencies are like this
{code:java}
junit
junit
4.13
test
org.hamcrest
hamcrest-core
2.2
test
{code}
The hamcrest-core we explicitly declare overrides Junit's. The 2.2 core is
actually deprecated and just contains a text file, but crucially gives us the
transitive dependency to hamcrest:2.2, which has the classes we actually want.
Actually, we only use 1 class, org.hamcrest.CoreMatchers
So in this case we have a transitive dependency on hamcrest:2.2 which we did
not declare, so the output of analyze is *correct*.
However, when we make the seemingly obvious fix and replace hamcrest-core with
hamcrest:
{code:java}
org.hamcrest
hamcrest
2.2
test
{code}
Then now what we have is a transitive dependency on hamcrest-core:1.3 via Junit
and our own dependency on hamcrest:2.2. Both contain a class with the FQN.
hamcrest-core must "win" the lookup, so the dependency plugin assumes
org.hamcrest.CoreMatchers comes *only* from there. If that assumption were
true, hamcrest-core would be used and undeclared, transitive through junit,
while hamcrest would be unused, hence the spurious result.
I found 2 ways you can work around it:
* Move Junit after hamcrest. hamcrest "wins" the ownership of the class so is
now counted as being "used", while hamcrest-core is "unused" (but that's
transitive – "unused" and undeclared, so not a warning)
* Exclude the hamcrest-core from junit
—
The ideal fix is less clear to me.
Should we should omit some warning that we found a class that exists in two or
more dependencies, and consider all such dependencies to be used, and advise
them the solve the problem manually (via exclusions etc.)?
was (Author: michaelboyles):
The issue seems to be that a class with the same FQN exists in two dependencies.
When shared-utils dependencies are like this
{code:java}
junit
junit
4.13
test
org.hamcrest
hamcrest-core
2.2
test
{code}
The hamcrest-core we explicitly declare overrides Junit's. The 2.2 core is
actually deprecated and just contains a text file, but crucially gives us the
transitive dependency to hamcrest:2.2, which has the classes we actually want.
Actually, we only use 1 class, org.hamcrest.CoreMatchers
So in this case we have a transitive dependency on hamcrest:2.2 which we did
not declare, so the output of analyze is *correct*.
However, when we make the seemingly obvious fix and replace hamcrest-core with
hamcrest:
{code:java}
org.hamcrest
hamcrest
2.2
test
{code}
Then now what we have is a transitive dependency on hamcrest-core:1.3 via Junit
and our own dependency on hamcrest:2.2. Both contain a class with the FQN.
hamcrest-core must "win" the lookup, so the dependency plugin thinks
org.hamcrest.CoreMatchers comes *only* from there. If that assumption were
true, hamcrest-core would be an undeclared transitive dependency through junit,
while hamcrest itself is unnecessary, hence the spurious result.
I found 2 ways you can work around it:
* Move Junit after hamcrest. hamcrest "wins" the ownership of the class so is
now counted as being "used", while hamcrest-core is "unused" (but that's
transitive – "unused" and undeclared, so not a warning)
* Exclude the hamcrest-core from junit
—
The ideal fix is less clear to me.
Should we should omit some warning that we found a class that exists in two or
more dependencies, and consider all such dependencies to be used, and advise
them the solve the problem manually (via exclusions etc.)?
> Hamcrest used and unused
>
>
> Key: MDEP-715
> URL: https://issues.apache.org/jira/browse/MDEP-715
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Reporter: Elliotte Rusty Harold
>Priority: Major
> Labels: S2, intern
>
> This is something I've seen when analyzing several Maven plugins. For
> example, maven-shared-utils circa July 20, 2020:
>
> [WARNING] Used undeclared dependencies found:
> [WARNING] org.hamcrest:hamcrest:jar:2.2:test
> [WARNING] org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M2a:test
> [WARNING] Unused declared dependencies found:
> [WARNING] org.hamcrest:hamcrest-core:jar:2.2:test
> [WARNING] org.apache.maven:maven-core:jar:3.1.0:test
> [WARNING] org.codehaus.plexus:plexus-container-default:jar:2.1.0:provided
>
> Easy fix, right? don't declare org.hamcrest:hamcrest-core:jar:2.2:test and
> instead declare org.h
[jira] [Comment Edited] (MDEP-715) Hamcrest used and unused
[
https://issues.apache.org/jira/browse/MDEP-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205867#comment-17205867
]
Michael Boyles edited comment on MDEP-715 at 10/1/20, 10:57 PM:
The issue seems to be that a class with the same FQN exists in two dependencies.
When shared-utils dependencies are like this
{code:java}
junit
junit
4.13
test
org.hamcrest
hamcrest-core
2.2
test
{code}
The hamcrest-core we explicitly declare overrides Junit's. The 2.2 core is
actually deprecated and just contains a text file, but crucially gives us the
transitive dependency to hamcrest:2.2, which has the classes we actually want.
Actually, we only use 1 class, org.hamcrest.CoreMatchers
So in this case we have a transitive dependency on hamcrest:2.2 which we did
not declare, so the output of analyze is *correct*.
However, when we make the seemingly obvious fix and replace hamcrest-core with
hamcrest:
{code:java}
org.hamcrest
hamcrest
2.2
test
{code}
Then now what we have is a transitive dependency on hamcrest-core:1.3 via Junit
and our own dependency on hamcrest:2.2. Both contain a class with the FQN.
hamcrest-core must "win" the lookup, so the dependency plugin thinks
org.hamcrest.CoreMatchers comes *only* from there. If that assumption were
true, hamcrest-core would be an undeclared transitive dependency through junit,
while hamcrest itself is unnecessary, hence the spurious result.
I found 2 ways you can work around it:
* Move Junit after hamcrest. hamcrest "wins" the ownership of the class so is
now counted as being "used", while hamcrest-core is "unused" (but that's
transitive – "unused" and undeclared, so not a warning)
* Exclude the hamcrest-core from junit
—
The ideal fix is less clear to me.
Should we should omit some warning that we found a class that exists in two or
more dependencies, and consider all such dependencies to be used, and advise
them the solve the problem manually (via exclusions etc.)?
was (Author: michaelboyles):
The issue seems to be that a class with the same FQN exists in two dependencies.
When shared-utils dependencies are like this
{code:java}
junit
junit
4.13
test
org.hamcrest
hamcrest-core
2.2
test
{code}
The hamcrest-core we explicitly declare overrides Junit's. The 2.2 core is
actually deprecated and just contains a text file, but crucially gives us the
transitive dependency to hamcrest:2.2, which has the classes we actually want.
Actually, we only use 1 class, org.hamcrest.CoreMatchers
So in this case we have a transitive dependency on hamcrest:2.2 which we did
not declare, so the output of analyze is *correct*.
However, when we make the seemingly obvious fix:
{code:java}
org.hamcrest
hamcrest
2.2
test
{code}
Then now what we have is a transitive dependency on hamcrest-core:1.3 via Junit
and our own dependency on hamcrest:2.2. Both contain a class with the FQN.
hamcrest-core must "win" the lookup, so the dependency plugin thinks
org.hamcrest.CoreMatchers comes *only* from there. If that assumption were
true, hamcrest-core would be an undeclared transitive dependency through junit,
while hamcrest itself is unnecessary, hence the spurious result.
I found 2 ways you can work around it:
* Move Junit after hamcrest. hamcrest "wins" the ownership of the class so is
now counted as being "used", while hamcrest-core is "unused" (but that's
transitive – "unused" and undeclared, so not a warning)
* Exclude the hamcrest-core from junit
—
The ideal fix is less clear to me.
Should we should omit some warning that we found a class that exists in two or
more dependencies, and consider all such dependencies to be used, and advise
them the solve the problem manually (via exclusions etc.)?
> Hamcrest used and unused
>
>
> Key: MDEP-715
> URL: https://issues.apache.org/jira/browse/MDEP-715
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Reporter: Elliotte Rusty Harold
>Priority: Major
> Labels: S2, intern
>
> This is something I've seen when analyzing several Maven plugins. For
> example, maven-shared-utils circa July 20, 2020:
>
> [WARNING] Used undeclared dependencies found:
> [WARNING] org.hamcrest:hamcrest:jar:2.2:test
> [WARNING] org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M2a:test
> [WARNING] Unused declared dependencies found:
> [WARNING] org.hamcrest:hamcrest-core:jar:2.2:test
> [WARNING] org.apache.maven:maven-core:jar:3.1.0:test
> [WARNING] org.codehaus.plexus:plexus-container-default:jar:2.1.0:provided
>
> Easy fix, right? don't declare org.hamcrest:hamcrest-core:jar:2.2:test and
> instead declare org.hamcrest:hamcrest:jar:2.2:test
>
[jira] [Comment Edited] (MDEP-715) Hamcrest used and unused
[
https://issues.apache.org/jira/browse/MDEP-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205867#comment-17205867
]
Michael Boyles edited comment on MDEP-715 at 10/1/20, 10:56 PM:
The issue seems to be that a class with the same FQN exists in two dependencies.
When shared-utils dependencies are like this
{code:java}
junit
junit
4.13
test
org.hamcrest
hamcrest-core
2.2
test
{code}
The hamcrest-core we explicitly declare overrides Junit's. The 2.2 core is
actually deprecated and just contains a text file, but crucially gives us the
transitive dependency to hamcrest:2.2, which has the classes we actually want.
Actually, we only use 1 class, org.hamcrest.CoreMatchers
So in this case we have a transitive dependency on hamcrest:2.2 which we did
not declare, so the output of analyze is *correct*.
However, when we make the seemingly obvious fix:
{code:java}
org.hamcrest
hamcrest
2.2
test
{code}
Then now what we have is a transitive dependency on hamcrest-core:1.3 via Junit
and our own dependency on hamcrest:2.2. Both contain a class with the FQN.
hamcrest-core must "win" the lookup, so the dependency plugin thinks
org.hamcrest.CoreMatchers comes *only* from there. If that assumption were
true, hamcrest-core would be an undeclared transitive dependency through junit,
while hamcrest itself is unnecessary, hence the spurious result.
I found 2 ways you can work around it:
* Move Junit after hamcrest. hamcrest "wins" the ownership of the class so is
now counted as being "used", while hamcrest-core is "unused" (but that's
transitive – "unused" and undeclared, so not a warning)
* Exclude the hamcrest-core from junit
—
The ideal fix is less clear to me.
Should we should omit some warning that we found a class that exists in two or
more dependencies, and consider all such dependencies to be used, and advise
them the solve the problem manually (via exclusions etc.)?
was (Author: michaelboyles):
The issue seems to be that a class with the same FQN exists in two dependencies.
When shared-utils dependencies are like this
{code:java}
junit
junit
4.13
test
org.hamcrest
hamcrest-core
2.2
test
{code}
The hamcrest-core we explicitly declare overrides Junit's. The 2.2 core is
actually deprecated and just contains a text file, but crucially gives us the
transitive dependency to hamcrest:2.2, which has the classes we actually want.
Actually, we only use 1 class, org.hamcrest.CoreMatchers
So in this case we have a transitive dependency on hamcrest:2.2 which we did
not declare, so the output of analyze is *correct*.
However, when we make the seemingly obvious fix:
{code:java}
org.hamcrest
hamcrest
2.2
test
{code}
Then now what we have is a transitive dependency on hamcrest-core:1.3 via Junit
and our own dependency on hamcrest:2.2. Both contain a class with the FQN.
hamcrest-core must "win" the lookup, so the dependency plugin thinks
org.hamcrest.CoreMatchers comes *only* from there. If that assumption were
true, hamcrest-core would be an undeclared transitive dependency through junit,
while hamcrest itself is unnecessary, hence the spurious result.
I found 2 ways you can work around it:
* Move Junit after hamcrest. hamcrest "wins" the ownership of the class so is
now counted as being "used", while hamcrest-core is "unused" (but that's
transitive, so not a warning)
* Exclude the hamcrest-core from junit
—
The ideal fix is less clear to me.
Should we should omit some warning that we found a class that exists in two or
more dependencies, and consider all such dependencies to be used, and advise
them the solve the problem manually (via exclusions etc.)?
> Hamcrest used and unused
>
>
> Key: MDEP-715
> URL: https://issues.apache.org/jira/browse/MDEP-715
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Reporter: Elliotte Rusty Harold
>Priority: Major
> Labels: S2, intern
>
> This is something I've seen when analyzing several Maven plugins. For
> example, maven-shared-utils circa July 20, 2020:
>
> [WARNING] Used undeclared dependencies found:
> [WARNING] org.hamcrest:hamcrest:jar:2.2:test
> [WARNING] org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M2a:test
> [WARNING] Unused declared dependencies found:
> [WARNING] org.hamcrest:hamcrest-core:jar:2.2:test
> [WARNING] org.apache.maven:maven-core:jar:3.1.0:test
> [WARNING] org.codehaus.plexus:plexus-container-default:jar:2.1.0:provided
>
> Easy fix, right? don't declare org.hamcrest:hamcrest-core:jar:2.2:test and
> instead declare org.hamcrest:hamcrest:jar:2.2:test
>
> But when I do that:
>
> [WARNING] Used undeclared dependencies fo
[jira] [Commented] (MDEP-715) Hamcrest used and unused
[
https://issues.apache.org/jira/browse/MDEP-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205867#comment-17205867
]
Michael Boyles commented on MDEP-715:
-
The issue seems to be that a class with the same FQN exists in two dependencies.
When shared-utils dependencies are like this
{code:java}
junit
junit
4.13
test
org.hamcrest
hamcrest-core
2.2
test
{code}
The hamcrest-core we explicitly declare overrides Junit's. The 2.2 core is
actually deprecated and just contains a text file, but crucially gives us the
transitive dependency to hamcrest:2.2, which has the classes we actually want.
Actually, we only use 1 class, org.hamcrest.CoreMatchers
So in this case we have a transitive dependency on hamcrest:2.2 which we did
not declare, so the output of analyze is *correct*.
However, when we make the seemingly obvious fix:
{code:java}
org.hamcrest
hamcrest
2.2
test
{code}
Then now what we have is a transitive dependency on hamcrest-core:1.3 via Junit
and our own dependency on hamcrest:2.2. Both contain a class with the FQN.
hamcrest-core must "win" the lookup, so the dependency plugin thinks
org.hamcrest.CoreMatchers comes *only* from there. If that assumption were
true, hamcrest-core would be an undeclared transitive dependency through junit,
while hamcrest itself is unnecessary, hence the spurious result.
I found 2 ways you can work around it:
* Move Junit after hamcrest. hamcrest "wins" the ownership of the class so is
now counted as being "used", while hamcrest-core is "unused" (but that's
transitive, so not a warning)
* Exclude the hamcrest-core from junit
—
The ideal fix is less clear to me.
Should we should omit some warning that we found a class that exists in two or
more dependencies, and consider all such dependencies to be used, and advise
them the solve the problem manually (via exclusions etc.)?
> Hamcrest used and unused
>
>
> Key: MDEP-715
> URL: https://issues.apache.org/jira/browse/MDEP-715
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Reporter: Elliotte Rusty Harold
>Priority: Major
> Labels: S2, intern
>
> This is something I've seen when analyzing several Maven plugins. For
> example, maven-shared-utils circa July 20, 2020:
>
> [WARNING] Used undeclared dependencies found:
> [WARNING] org.hamcrest:hamcrest:jar:2.2:test
> [WARNING] org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M2a:test
> [WARNING] Unused declared dependencies found:
> [WARNING] org.hamcrest:hamcrest-core:jar:2.2:test
> [WARNING] org.apache.maven:maven-core:jar:3.1.0:test
> [WARNING] org.codehaus.plexus:plexus-container-default:jar:2.1.0:provided
>
> Easy fix, right? don't declare org.hamcrest:hamcrest-core:jar:2.2:test and
> instead declare org.hamcrest:hamcrest:jar:2.2:test
>
> But when I do that:
>
> [WARNING] Used undeclared dependencies found:
> [WARNING] org.hamcrest:hamcrest-core:jar:1.3:test
> [WARNING] org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M2a:test
> [WARNING] Unused declared dependencies found:
> [WARNING] org.hamcrest:hamcrest:jar:2.2:test
> [WARNING] org.apache.maven:maven-core:jar:3.1.0:test
> [WARNING] org.codehaus.plexus:plexus-container-default:jar:2.1.0:provided
>
> Figure out what's going on here and fix it. Is hamcrest-core needed and used
> or not? is hamcrest needed and used or not? Be consistent.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MINDEXER-125) Spring Boot Starter artifact missing
[
https://issues.apache.org/jira/browse/MINDEXER-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202363#comment-17202363
]
Michael Boyles commented on MINDEXER-125:
-
This is not a maven issue. If you have think something is missing, you should
speak to the people who publish it.
Anyway, I'm looking at the same repo you linked and the jar is there.
> Spring Boot Starter artifact missing
>
>
> Key: MINDEXER-125
> URL: https://issues.apache.org/jira/browse/MINDEXER-125
> Project: Maven Indexer
> Issue Type: Bug
>Reporter: Marco Rizzi
>Priority: Major
>
> For the artifacts in
> [https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/,]
> in the Maven Index I can only find 3 of them (module, javadoc and source).
> I can not find any entry for the
> "{{spring-boot-starter-web-2.3.2.RELEASE.jar}}".
> Could the cause be related to the fact that the "module" artifact
> ("{{spring-boot-starter-web-2.3.2.RELEASE.module}}") has the
> "{{u:org.springframework.boot|spring-boot-starter-web|2.3.2.RELEASE|NA}}"?
> AFAIK it should have a further suffix "{{module}}" since module is the
> extension (according to "{{u}}" filed definition in [1]).
> Or could it be related to
> [spring-boot-starter-web-2.3.2.RELEASE.jar.sha1|https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/spring-boot-starter-web-2.3.2.RELEASE.jar.sha1]
> and
> [spring-boot-starter-web-2.3.2.RELEASE-javadoc.jar.sha1|https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/spring-boot-starter-web-2.3.2.RELEASE-javadoc.jar.sha1]
> having the same value (i.e. "{{85f79121fdaabcbcac085d0d4aad34af9f8dbba2}}")
> Thanks in advance,
> Marco
> [1]
> [https://maven.apache.org/maven-indexer-archives/maven-indexer-LATEST/indexer-core/index.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSOURCES-129) The IT for MSOURCES-95 consistently fails on Linux+JDK8
[ https://issues.apache.org/jira/browse/MSOURCES-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17201781#comment-17201781 ] Michael Boyles commented on MSOURCES-129: - The link for the PR is broken because the period is included. Real link is [https://github.com/codehaus-plexus/plexus-archiver/pull/149] > The IT for MSOURCES-95 consistently fails on Linux+JDK8 > --- > > Key: MSOURCES-129 > URL: https://issues.apache.org/jira/browse/MSOURCES-129 > Project: Maven Source Plugin > Issue Type: Bug >Reporter: Martin Kanters >Priority: Major > > As can be seen on > [Jenkins|https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-source-plugin/job/master/], > the integration test for MSOURCES-95 fails consistently and has been from > the introduction of the IT. > I was able to trace this back to a bug in the JDK which the plexus-archiver > unfortunately affects. > The fix in plexus-archiver has been proposed: > [https://github.com/codehaus-plexus/plexus-archiver/pull/149.] > After the PR has been merged in and a new version has been released, we > should upgrade the plexus-archiver dependency in maven-source-plugin to fix > it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MCOMPILER-425) Compiler argument with newline treated as multiple arguments in fork mode
[
https://issues.apache.org/jira/browse/MCOMPILER-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17201501#comment-17201501
]
Michael Boyles edited comment on MCOMPILER-425 at 9/24/20, 12:42 PM:
-
Shouldn't you be doing this? They're on different lines, which is what you
wanted.
{code:java}
-XDcompilePolicy=simple
-Xplugin:ErrorProne
-Xep:ObjectToString:ERROR
{code}
You say that it works when not forking, but these parameters are only used
when forking. As per [the
docs|https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerArgs]
"Sets the arguments to be passed to the compiler if {{fork}} is set to
{{true"}}
So if you think that these params are being applied to non-forked version, you
are mistaken. (I doubled-checked with latest build to see whether the docs were
accurate, by passing a spurious compiler parameter, and it was indeed not
applied)
was (Author: michaelboyles):
Shouldn't you be doing this? They're on different lines, which is what you
wanted.
-XDcompilePolicy=simple-Xplugin:ErrorProne
-Xep:ObjectToString:ERROR
You say that it works when not forking, but these parameters are only used when
forking. As per [the
docs|https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerArgs]
"Sets the arguments to be passed to the compiler if {{fork}} is set to
{{true"}}
So if you think that these params are being applied to non-forked version, you
are mistaken. (I doubled-checked with latest build to see whether the docs were
accurate, by passing a spurious compiler parameter, and it was indeed not
applied)
> Compiler argument with newline treated as multiple arguments in fork mode
> -
>
> Key: MCOMPILER-425
> URL: https://issues.apache.org/jira/browse/MCOMPILER-425
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: David Phillips
>Priority: Major
>
> In the below example, we want to pass the second argument as a single
> argument to the compiler, but we add newlines in the XML for readability.
> This works correctly when not forking, but when forking, the argument is
> treated as multiple arguments.
> {code:xml}
>
> true
>
> -XDcompilePolicy=simple
>
> -Xplugin:ErrorProne
> -Xep:ObjectToString:ERROR
>
>
>
>
> com.google.errorprone
> error_prone_core
> 2.4.0
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCOMPILER-425) Compiler argument with newline treated as multiple arguments in fork mode
[
https://issues.apache.org/jira/browse/MCOMPILER-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17201501#comment-17201501
]
Michael Boyles commented on MCOMPILER-425:
--
Shouldn't you be doing this? They're on different lines, which is what you
wanted.
-XDcompilePolicy=simple-Xplugin:ErrorProne
-Xep:ObjectToString:ERROR
You say that it works when not forking, but these parameters are only used when
forking. As per [the
docs|https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerArgs]
"Sets the arguments to be passed to the compiler if {{fork}} is set to
{{true"}}
So if you think that these params are being applied to non-forked version, you
are mistaken. (I doubled-checked with latest build to see whether the docs were
accurate, by passing a spurious compiler parameter, and it was indeed not
applied)
> Compiler argument with newline treated as multiple arguments in fork mode
> -
>
> Key: MCOMPILER-425
> URL: https://issues.apache.org/jira/browse/MCOMPILER-425
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: David Phillips
>Priority: Major
>
> In the below example, we want to pass the second argument as a single
> argument to the compiler, but we add newlines in the XML for readability.
> This works correctly when not forking, but when forking, the argument is
> treated as multiple arguments.
> {code:xml}
>
> true
>
> -XDcompilePolicy=simple
>
> -Xplugin:ErrorProne
> -Xep:ObjectToString:ERROR
>
>
>
>
> com.google.errorprone
> error_prone_core
> 2.4.0
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1834) Make warnings for skipped tests configurable
[
https://issues.apache.org/jira/browse/SUREFIRE-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17201476#comment-17201476
]
Michael Boyles commented on SUREFIRE-1834:
--
Happy to work on this. A new parameter for the test goal, something like
false
defaulting to the current behaviour: true.
That is, if someone gives the go-ahead that this is indeed a desirable feature.
Seems fair enough to me
> Make warnings for skipped tests configurable
>
>
> Key: SUREFIRE-1834
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1834
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Martin Winandy
>Priority: Major
>
> Currently, Surefire outputs warnings for skipped tests.
> For example:
> {noformat}
> [WARNING] Tests run: 4, Failures: 0, Errors: 0, Skipped: 2, Time elapsed:
> 0.037 s - in org.tinylog.core.runtime.LegacyStackTraceAccessTest
> [WARNING] Tests run: 62, Failures: 0, Errors: 0, Skipped: 2
> {noformat}
> I have some platform depending tests, which are enabled or disabled depending
> on the actual platform. It would be great, if a property could be introduced
> to disable warnings for skipped tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MASSEMBLY-852) permissions are lost if is present
[
https://issues.apache.org/jira/browse/MASSEMBLY-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17201153#comment-17201153
]
Michael Boyles edited comment on MASSEMBLY-852 at 9/23/20, 10:54 PM:
-
Looked into it a bit more. The problem is that ant pattern * does not match
root directory, and nor is it supposed to. But obviously the archiver still
needs to create the intermediate directories. It has 2 types of directory mode,
and we're only setting 1 of them. We need to set the other.
I think you should be able to work around this by using the following pattern.
It seems undocumented but [if you dig down into the code
enough|https://github.com/codehaus-plexus/plexus-utils/blob/master/src/main/java/org/codehaus/plexus/util/MatchPattern.java#L45],
it's supported
{code:java}
%regex[.*] {code}
Unlike the ant pattern, this will match everything.
We can fix it on the plugin side, will raise a PR.
was (Author: michaelboyles):
Looked into it a bit more. The problem is that ant pattern * does not match
root directory, and nor is it supposed to.
I think you should be able to work around this by using the following pattern.
It seems undocumented but [if you dig down into the code
enough|https://github.com/codehaus-plexus/plexus-utils/blob/master/src/main/java/org/codehaus/plexus/util/MatchPattern.java#L45],
it's supported
{code:java}
%regex[.*] {code}
Unlike the ant pattern, this will match everything.
We can fix it on the plugin side, will raise a PR.
> permissions are lost if is present
>
>
> Key: MASSEMBLY-852
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-852
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: component descriptor, permissions
>Affects Versions: 3.0.0
> Environment: Java HotSpot(TM) 64-Bit Server VM warning: ignoring
> option MaxPermSize=256m; support was removed in 8.0
> Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4;
> 2014-08-12T00:58:10+03:00)
> Java version: 1.8.0_51, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_51/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-573.8.1.el6.x86_64", arch: "amd64",
> family: "unix"
>Reporter: Anton
>Priority: Minor
> Attachments: test.rar
>
>
> Used next descriptor:
> {code:xml}
>
> test
>
> zip
>
> false
>
>
> bin
> bin-include
>
> *
>
> 700
> 700
>
>
> bin
> bin-no-include
> 700
> 700
>
>
>
> {code}
> For both ** same *directoryMode* is set, but for case where
> ** pattern is present directory permissions are broken.
> Listing:
> {noformat}
> $ zipinfo target/testpom-1.0.0.zip
> Archive: target/testpom-1.0.0.zip
> Zip file size: 502 bytes, number of entries: 4
> drwxr-xr-x 2.0 unx0 b- stor 17-Apr-19 17:48 bin-include/
> drwx-- 2.0 unx0 b- stor 17-Apr-19 15:48 bin-no-include/
> -rwx-- 2.0 unx0 bl defN 17-Apr-19 15:48 bin-include/testfile
> -rwx-- 2.0 unx0 bl defN 17-Apr-19 15:48 bin-no-include/testfile
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MASSEMBLY-852) permissions are lost if is present
[
https://issues.apache.org/jira/browse/MASSEMBLY-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17201153#comment-17201153
]
Michael Boyles edited comment on MASSEMBLY-852 at 9/23/20, 10:53 PM:
-
Looked into it a bit more. The problem is that ant pattern * does not match
root directory, and nor is it supposed to.
I think you should be able to work around this by using the following pattern.
It seems undocumented but [if you dig down into the code
enough|https://github.com/codehaus-plexus/plexus-utils/blob/master/src/main/java/org/codehaus/plexus/util/MatchPattern.java#L45],
it's supported
{code:java}
%regex[.*] {code}
Unlike the ant pattern, this will match everything.
We can fix it on the plugin side, will raise a PR.
was (Author: michaelboyles):
Looked into it a bit more. The problem is that ant pattern `*` does not match
root directory, and nor is it supposed to.
I think you should be able to work around this by using the following pattern.
It seems undocumented but [if you dig down into the code
enough|https://github.com/codehaus-plexus/plexus-utils/blob/master/src/main/java/org/codehaus/plexus/util/MatchPattern.java#L45],
it's supported
{code:java}
%regex[.*] {code}
Unlike the ant pattern, this will match everything.
We can fix it on the plugin side, will raise a PR.
> permissions are lost if is present
>
>
> Key: MASSEMBLY-852
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-852
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: component descriptor, permissions
>Affects Versions: 3.0.0
> Environment: Java HotSpot(TM) 64-Bit Server VM warning: ignoring
> option MaxPermSize=256m; support was removed in 8.0
> Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4;
> 2014-08-12T00:58:10+03:00)
> Java version: 1.8.0_51, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_51/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-573.8.1.el6.x86_64", arch: "amd64",
> family: "unix"
>Reporter: Anton
>Priority: Minor
> Attachments: test.rar
>
>
> Used next descriptor:
> {code:xml}
>
> test
>
> zip
>
> false
>
>
> bin
> bin-include
>
> *
>
> 700
> 700
>
>
> bin
> bin-no-include
> 700
> 700
>
>
>
> {code}
> For both ** same *directoryMode* is set, but for case where
> ** pattern is present directory permissions are broken.
> Listing:
> {noformat}
> $ zipinfo target/testpom-1.0.0.zip
> Archive: target/testpom-1.0.0.zip
> Zip file size: 502 bytes, number of entries: 4
> drwxr-xr-x 2.0 unx0 b- stor 17-Apr-19 17:48 bin-include/
> drwx-- 2.0 unx0 b- stor 17-Apr-19 15:48 bin-no-include/
> -rwx-- 2.0 unx0 bl defN 17-Apr-19 15:48 bin-include/testfile
> -rwx-- 2.0 unx0 bl defN 17-Apr-19 15:48 bin-no-include/testfile
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MASSEMBLY-852) permissions are lost if is present
[
https://issues.apache.org/jira/browse/MASSEMBLY-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17201153#comment-17201153
]
Michael Boyles commented on MASSEMBLY-852:
--
Looked into it a bit more. The problem is that ant pattern `*` does not match
root directory, and nor is it supposed to.
I think you should be able to work around this by using the following pattern.
It seems undocumented but [if you dig down into the code
enough|https://github.com/codehaus-plexus/plexus-utils/blob/master/src/main/java/org/codehaus/plexus/util/MatchPattern.java#L45],
it's supported
{code:java}
%regex[.*] {code}
Unlike the ant pattern, this will match everything.
We can fix it on the plugin side, will raise a PR.
> permissions are lost if is present
>
>
> Key: MASSEMBLY-852
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-852
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: component descriptor, permissions
>Affects Versions: 3.0.0
> Environment: Java HotSpot(TM) 64-Bit Server VM warning: ignoring
> option MaxPermSize=256m; support was removed in 8.0
> Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4;
> 2014-08-12T00:58:10+03:00)
> Java version: 1.8.0_51, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_51/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-573.8.1.el6.x86_64", arch: "amd64",
> family: "unix"
>Reporter: Anton
>Priority: Minor
> Attachments: test.rar
>
>
> Used next descriptor:
> {code:xml}
>
> test
>
> zip
>
> false
>
>
> bin
> bin-include
>
> *
>
> 700
> 700
>
>
> bin
> bin-no-include
> 700
> 700
>
>
>
> {code}
> For both ** same *directoryMode* is set, but for case where
> ** pattern is present directory permissions are broken.
> Listing:
> {noformat}
> $ zipinfo target/testpom-1.0.0.zip
> Archive: target/testpom-1.0.0.zip
> Zip file size: 502 bytes, number of entries: 4
> drwxr-xr-x 2.0 unx0 b- stor 17-Apr-19 17:48 bin-include/
> drwx-- 2.0 unx0 b- stor 17-Apr-19 15:48 bin-no-include/
> -rwx-- 2.0 unx0 bl defN 17-Apr-19 15:48 bin-include/testfile
> -rwx-- 2.0 unx0 bl defN 17-Apr-19 15:48 bin-no-include/testfile
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MASSEMBLY-852) permissions are lost if is present
[
https://issues.apache.org/jira/browse/MASSEMBLY-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17200991#comment-17200991
]
Michael Boyles commented on MASSEMBLY-852:
--
Raised [https://github.com/codehaus-plexus/plexus-archiver/issues/148] with
reproducible example
> permissions are lost if is present
>
>
> Key: MASSEMBLY-852
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-852
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: component descriptor, permissions
>Affects Versions: 3.0.0
> Environment: Java HotSpot(TM) 64-Bit Server VM warning: ignoring
> option MaxPermSize=256m; support was removed in 8.0
> Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4;
> 2014-08-12T00:58:10+03:00)
> Java version: 1.8.0_51, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_51/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-573.8.1.el6.x86_64", arch: "amd64",
> family: "unix"
>Reporter: Anton
>Priority: Minor
> Attachments: test.rar
>
>
> Used next descriptor:
> {code:xml}
>
> test
>
> zip
>
> false
>
>
> bin
> bin-include
>
> *
>
> 700
> 700
>
>
> bin
> bin-no-include
> 700
> 700
>
>
>
> {code}
> For both ** same *directoryMode* is set, but for case where
> ** pattern is present directory permissions are broken.
> Listing:
> {noformat}
> $ zipinfo target/testpom-1.0.0.zip
> Archive: target/testpom-1.0.0.zip
> Zip file size: 502 bytes, number of entries: 4
> drwxr-xr-x 2.0 unx0 b- stor 17-Apr-19 17:48 bin-include/
> drwx-- 2.0 unx0 b- stor 17-Apr-19 15:48 bin-no-include/
> -rwx-- 2.0 unx0 bl defN 17-Apr-19 15:48 bin-include/testfile
> -rwx-- 2.0 unx0 bl defN 17-Apr-19 15:48 bin-no-include/testfile
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MASSEMBLY-852) permissions are lost if is present
[
https://issues.apache.org/jira/browse/MASSEMBLY-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17200948#comment-17200948
]
Michael Boyles edited comment on MASSEMBLY-852 at 9/23/20, 4:49 PM:
The problem is with plexus-archiver, not with the assembly plugin.
I traced it as far as this iterator.
[https://github.com/codehaus-plexus/plexus-archiver/blob/master/src/main/java/org/codehaus/plexus/archiver/AbstractArchiver.java#L525]
Two items go in (AbstractZipArchiver.resources), but three come out:
* bin-include/testfile
* bin-no-include
* bin-no-include/testfile
The bin-include version realises it needs to create the parent directories, so
just uses the default mode. For the no-include version, since the directory and
file are created as separate entities, the correct mode is preserved.
I would raise a PR against that repo, but just looking at this iterator started
to give me a headache.
was (Author: michaelboyles):
The problem is with plexus-archiver, not with the assembly plugin.
I traced it as far as this iterator.
[https://github.com/codehaus-plexus/plexus-archiver/blob/master/src/main/java/org/codehaus/plexus/archiver/AbstractArchiver.java#L525]
Two items go in (AbstractZipArchiver.resources), but three come out:
* bin-include/testfile
* bin-no-include
* bin-no-include/testfile
The bin-include version realises it needs to creates the parent directories, so
just uses the default mode. For the no-include version, since the directory and
file are created as separate entities, the correct mode is preserved.
I would raise a PR against that repo, but just looking at this iterator started
to give me a headache.
> permissions are lost if is present
>
>
> Key: MASSEMBLY-852
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-852
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: component descriptor, permissions
>Affects Versions: 3.0.0
> Environment: Java HotSpot(TM) 64-Bit Server VM warning: ignoring
> option MaxPermSize=256m; support was removed in 8.0
> Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4;
> 2014-08-12T00:58:10+03:00)
> Java version: 1.8.0_51, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_51/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-573.8.1.el6.x86_64", arch: "amd64",
> family: "unix"
>Reporter: Anton
>Priority: Minor
> Attachments: test.rar
>
>
> Used next descriptor:
> {code:xml}
>
> test
>
> zip
>
> false
>
>
> bin
> bin-include
>
> *
>
> 700
> 700
>
>
> bin
> bin-no-include
> 700
> 700
>
>
>
> {code}
> For both ** same *directoryMode* is set, but for case where
> ** pattern is present directory permissions are broken.
> Listing:
> {noformat}
> $ zipinfo target/testpom-1.0.0.zip
> Archive: target/testpom-1.0.0.zip
> Zip file size: 502 bytes, number of entries: 4
> drwxr-xr-x 2.0 unx0 b- stor 17-Apr-19 17:48 bin-include/
> drwx-- 2.0 unx0 b- stor 17-Apr-19 15:48 bin-no-include/
> -rwx-- 2.0 unx0 bl defN 17-Apr-19 15:48 bin-include/testfile
> -rwx-- 2.0 unx0 bl defN 17-Apr-19 15:48 bin-no-include/testfile
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MASSEMBLY-852) permissions are lost if is present
[
https://issues.apache.org/jira/browse/MASSEMBLY-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17200948#comment-17200948
]
Michael Boyles edited comment on MASSEMBLY-852 at 9/23/20, 4:49 PM:
The problem is with plexus-archiver, not with the assembly plugin.
I traced it as far as this iterator.
[https://github.com/codehaus-plexus/plexus-archiver/blob/master/src/main/java/org/codehaus/plexus/archiver/AbstractArchiver.java#L525]
Two items go in (AbstractZipArchiver.resources), but three come out:
* bin-include/testfile
* bin-no-include
* bin-no-include/testfile
The bin-include version realises it needs to creates the parent directories, so
just uses the default mode. For the no-include version, since the directory and
file are created as separate entities, the correct mode is preserved.
I would raise a PR against that repo, but just looking at this iterator started
to give me a headache.
was (Author: michaelboyles):
The problem is with plexus-archiver, not with the assembly plugin.
I traced it was far as this iterator.
[https://github.com/codehaus-plexus/plexus-archiver/blob/master/src/main/java/org/codehaus/plexus/archiver/AbstractArchiver.java#L525]
Two items go in (AbstractZipArchiver.resources), but three come out:
* bin-include/testfile
* bin-no-include
* bin-no-include/testfile
The bin-include version realises it needs to creates the parent directories, so
just uses the default mode. For the no-include version, since the directory and
file are created as separate entities, the correct mode is preserved.
I would raise a PR against that repo, but just looking at this iterator started
to give me a headache.
> permissions are lost if is present
>
>
> Key: MASSEMBLY-852
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-852
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: component descriptor, permissions
>Affects Versions: 3.0.0
> Environment: Java HotSpot(TM) 64-Bit Server VM warning: ignoring
> option MaxPermSize=256m; support was removed in 8.0
> Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4;
> 2014-08-12T00:58:10+03:00)
> Java version: 1.8.0_51, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_51/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-573.8.1.el6.x86_64", arch: "amd64",
> family: "unix"
>Reporter: Anton
>Priority: Minor
> Attachments: test.rar
>
>
> Used next descriptor:
> {code:xml}
>
> test
>
> zip
>
> false
>
>
> bin
> bin-include
>
> *
>
> 700
> 700
>
>
> bin
> bin-no-include
> 700
> 700
>
>
>
> {code}
> For both ** same *directoryMode* is set, but for case where
> ** pattern is present directory permissions are broken.
> Listing:
> {noformat}
> $ zipinfo target/testpom-1.0.0.zip
> Archive: target/testpom-1.0.0.zip
> Zip file size: 502 bytes, number of entries: 4
> drwxr-xr-x 2.0 unx0 b- stor 17-Apr-19 17:48 bin-include/
> drwx-- 2.0 unx0 b- stor 17-Apr-19 15:48 bin-no-include/
> -rwx-- 2.0 unx0 bl defN 17-Apr-19 15:48 bin-include/testfile
> -rwx-- 2.0 unx0 bl defN 17-Apr-19 15:48 bin-no-include/testfile
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MASSEMBLY-852) permissions are lost if is present
[
https://issues.apache.org/jira/browse/MASSEMBLY-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17200948#comment-17200948
]
Michael Boyles commented on MASSEMBLY-852:
--
The problem is with plexus-archiver, not with the assembly plugin.
I traced it was far as this iterator.
[https://github.com/codehaus-plexus/plexus-archiver/blob/master/src/main/java/org/codehaus/plexus/archiver/AbstractArchiver.java#L525]
Two items go in (AbstractZipArchiver.resources), but three come out:
* bin-include/testfile
* bin-no-include
* bin-no-include/testfile
The bin-include version realises it needs to creates the parent directories, so
just uses the default mode. For the no-include version, since the directory and
file are created as separate entities, the correct mode is preserved.
I would raise a PR against that repo, but just looking at this iterator started
to give me a headache.
> permissions are lost if is present
>
>
> Key: MASSEMBLY-852
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-852
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: component descriptor, permissions
>Affects Versions: 3.0.0
> Environment: Java HotSpot(TM) 64-Bit Server VM warning: ignoring
> option MaxPermSize=256m; support was removed in 8.0
> Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4;
> 2014-08-12T00:58:10+03:00)
> Java version: 1.8.0_51, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_51/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-573.8.1.el6.x86_64", arch: "amd64",
> family: "unix"
>Reporter: Anton
>Priority: Minor
> Attachments: test.rar
>
>
> Used next descriptor:
> {code:xml}
>
> test
>
> zip
>
> false
>
>
> bin
> bin-include
>
> *
>
> 700
> 700
>
>
> bin
> bin-no-include
> 700
> 700
>
>
>
> {code}
> For both ** same *directoryMode* is set, but for case where
> ** pattern is present directory permissions are broken.
> Listing:
> {noformat}
> $ zipinfo target/testpom-1.0.0.zip
> Archive: target/testpom-1.0.0.zip
> Zip file size: 502 bytes, number of entries: 4
> drwxr-xr-x 2.0 unx0 b- stor 17-Apr-19 17:48 bin-include/
> drwx-- 2.0 unx0 b- stor 17-Apr-19 15:48 bin-no-include/
> -rwx-- 2.0 unx0 bl defN 17-Apr-19 15:48 bin-include/testfile
> -rwx-- 2.0 unx0 bl defN 17-Apr-19 15:48 bin-no-include/testfile
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MSKINS-171) Trademarks / privacy policy footer displays broken
[ https://issues.apache.org/jira/browse/MSKINS-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17200666#comment-17200666 ] Michael Boyles edited comment on MSKINS-171 at 9/23/20, 9:00 AM: - [~michael-o] Before I submitted my PR, I checked other sites using the same version of the theme and they were fine. The problem just that those pull-left divs are nested in the footer, which is part of SureFire's site.xml. I've removed them. was (Author: michaelboyles): [~michael-o] Before I submitted my PR, I checked other sites using the same version of the theme and they were fine. The problem just that those pull-list divs are nested in the footer, which is part of SureFire's site.xml. I've removed them. > Trademarks / privacy policy footer displays broken > -- > > Key: MSKINS-171 > URL: https://issues.apache.org/jira/browse/MSKINS-171 > Project: Maven Skins > Issue Type: Bug > Components: Fluido Skin >Reporter: Philippe Cloutier >Priority: Trivial > Attachments: image-2020-09-22-17-29-40-357.png > > Original Estimate: 1h > Remaining Estimate: 1h > > The footer which is at the end of Surefire's documentation pages, such as > [this > one|https://maven.apache.org/surefire/maven-surefire-plugin/index.html], have > a broken display (at least in Firefox 81 and Google Chrome 85). The > horizontal alignment is incorrect, causing the sentence to start outside the > visible area and its end to overlap with the "Privacy policy" link, as can be > seen in the screenshot below: > !image-2020-09-22-17-29-40-357.png|thumbnail! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSKINS-171) Trademarks / privacy policy footer displays broken
[ https://issues.apache.org/jira/browse/MSKINS-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17200666#comment-17200666 ] Michael Boyles commented on MSKINS-171: --- [~michael-o] Before I submitted my PR, I checked other sites using the same version of the theme and they were fine. The problem just that those pull-list divs are nested in the footer, which is part of SureFire's site.xml. I've removed them. > Trademarks / privacy policy footer displays broken > -- > > Key: MSKINS-171 > URL: https://issues.apache.org/jira/browse/MSKINS-171 > Project: Maven Skins > Issue Type: Bug > Components: Fluido Skin >Reporter: Philippe Cloutier >Priority: Trivial > Attachments: image-2020-09-22-17-29-40-357.png > > Original Estimate: 1h > Remaining Estimate: 1h > > The footer which is at the end of Surefire's documentation pages, such as > [this > one|https://maven.apache.org/surefire/maven-surefire-plugin/index.html], have > a broken display (at least in Firefox 81 and Google Chrome 85). The > horizontal alignment is incorrect, causing the sentence to start outside the > visible area and its end to overlap with the "Privacy policy" link, as can be > seen in the screenshot below: > !image-2020-09-22-17-29-40-357.png|thumbnail! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1842) Surefire - NPE at end of successful test run
[ https://issues.apache.org/jira/browse/SUREFIRE-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199453#comment-17199453 ] Michael Boyles commented on SUREFIRE-1842: -- I'm going to submit a PR to fix that, but it seems like another reason you're seeing this issue is that you're mixing Junit and TestNG. Are you expecting that? If you run Maven with debug logging (-X) you should see some line beginning with "Using the provider ". All the above code I contained within a JUnit provider, but I can see from your profile that you're including TestNG too. > Surefire - NPE at end of successful test run > > > Key: SUREFIRE-1842 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1842 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.19.1, 2.21.0, 2.22.1, 3.0.0-M2, 3.0.0-M1, 3.0.0-M3, > 3.0.0-M4 >Reporter: Jack Leech >Priority: Major > Attachments: stack_trace.txt, test_profile.xml > > > While using surefire to run a mock test pack all tests are passed, followed > by an exception in the surefire plugin (NPE) at the end which causes the run > to be marked as a failure. > I've tried various surefire versions of surefire and other testing libraries > involved. > I have attached a stack trace of the exception in question and a copy of the > test profile xml. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1842) Surefire - NPE at end of successful test run
[ https://issues.apache.org/jira/browse/SUREFIRE-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199426#comment-17199426 ] Michael Boyles edited comment on SUREFIRE-1842 at 9/21/20, 3:18 PM: The only thing which can throw NPE on that line is [this instance of RunOrderCalculator|https://github.com/apache/maven-surefire/blob/b0325d4b7142832696d22fea1ea654348a69c675/surefire-providers/surefire-junit47/src/main/java/org/apache/maven/surefire/junitcore/JUnitCoreProvider.java#L294] This is the [only implementation|https://github.com/apache/maven-surefire/blob/b0325d4b7142832696d22fea1ea654348a69c675/surefire-api/src/main/java/org/apache/maven/surefire/booter/BaseProviderFactory.java#L113] of the provider, and the return is indeed nullable. This null check seems spurious. It checks directoryScannerParameters, but doesn't use it for anything. Seems like it should be checking runOrderParameters. When it was [originally introduced,|https://github.com/apache/maven-surefire/blob/877873b08a8fb62c7d31a0019eb2a1b419a2876e/surefire-api/src/main/java/org/apache/maven/surefire/booter/BaseProviderFactory.java#L80] this check made sense, but [a subsequent change to support parallelizing tests|https://github.com/apache/maven-surefire/commit/13e6736b8cabc04be9b98c71a2a9695391d1f1a1#diff-868fd02a40a6474205d7b259d320b806L86] seemed to break it. As a workaround, the reason directoryScannerParameters is null stems from the fact that [you are using suiteXmlFiles|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1832], so maybe you can find an alternative way to configure your tests, while avoiding using that. was (Author: michaelboyles): The only thing which can throw NPE on that line is [this instance of RunOrderCalculator|https://github.com/apache/maven-surefire/blob/b0325d4b7142832696d22fea1ea654348a69c675/surefire-providers/surefire-junit47/src/main/java/org/apache/maven/surefire/junitcore/JUnitCoreProvider.java#L294] This is the [only implementation|https://github.com/apache/maven-surefire/blob/b0325d4b7142832696d22fea1ea654348a69c675/surefire-api/src/main/java/org/apache/maven/surefire/booter/BaseProviderFactory.java#L113] of the provider, and the return is indeed nullable. This null check seems spurious. It checks directoryScannerParameters, but doesn't use it for anything. Seems like it should be checking runOrderParameters. When it was [originally introduced,|https://github.com/apache/maven-surefire/blob/877873b08a8fb62c7d31a0019eb2a1b419a2876e/surefire-api/src/main/java/org/apache/maven/surefire/booter/BaseProviderFactory.java#L80] this check made sense, but [a subsequent change to support parallelizing tests|https://github.com/apache/maven-surefire/commit/13e6736b8cabc04be9b98c71a2a9695391d1f1a1#diff-868fd02a40a6474205d7b259d320b806L86] seemed to break it. As a workaround, the reason directoryScannerParameters is null stems from the fact that [you are using suiteXmlFiles|(https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1832], so maybe you can find an alternative way to configure your tests, while avoiding using that. > Surefire - NPE at end of successful test run > > > Key: SUREFIRE-1842 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1842 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.19.1, 2.21.0, 2.22.1, 3.0.0-M2, 3.0.0-M1, 3.0.0-M3, > 3.0.0-M4 >Reporter: Jack Leech >Priority: Major > Attachments: stack_trace.txt, test_profile.xml > > > While using surefire to run a mock test pack all tests are passed, followed > by an exception in the surefire plugin (NPE) at the end which causes the run > to be marked as a failure. > I've tried various surefire versions of surefire and other testing libraries > involved. > I have attached a stack trace of the exception in question and a copy of the > test profile xml. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1842) Surefire - NPE at end of successful test run
[ https://issues.apache.org/jira/browse/SUREFIRE-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199426#comment-17199426 ] Michael Boyles edited comment on SUREFIRE-1842 at 9/21/20, 3:17 PM: The only thing which can throw NPE on that line is [this instance of RunOrderCalculator|https://github.com/apache/maven-surefire/blob/b0325d4b7142832696d22fea1ea654348a69c675/surefire-providers/surefire-junit47/src/main/java/org/apache/maven/surefire/junitcore/JUnitCoreProvider.java#L294] This is the [only implementation|https://github.com/apache/maven-surefire/blob/b0325d4b7142832696d22fea1ea654348a69c675/surefire-api/src/main/java/org/apache/maven/surefire/booter/BaseProviderFactory.java#L113] of the provider, and the return is indeed nullable. This null check seems spurious. It checks directoryScannerParameters, but doesn't use it for anything. Seems like it should be checking runOrderParameters. When it was [originally introduced,|https://github.com/apache/maven-surefire/blob/877873b08a8fb62c7d31a0019eb2a1b419a2876e/surefire-api/src/main/java/org/apache/maven/surefire/booter/BaseProviderFactory.java#L80] this check made sense, but [a subsequent change to support parallelizing tests|https://github.com/apache/maven-surefire/commit/13e6736b8cabc04be9b98c71a2a9695391d1f1a1#diff-868fd02a40a6474205d7b259d320b806L86] seemed to break it. As a workaround, the reason directoryScannerParameters is null stems from the fact that [you are using suiteXmlFiles|(https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1832], so maybe you can find an alternative way to configure your tests, while avoiding using that. was (Author: michaelboyles): The only thing which can throw NPE on that line is [this instance of RunOrderCalculator|https://github.com/apache/maven-surefire/blob/b0325d4b7142832696d22fea1ea654348a69c675/surefire-providers/surefire-junit47/src/main/java/org/apache/maven/surefire/junitcore/JUnitCoreProvider.java#L294] This is the [only implementation|https://github.com/apache/maven-surefire/blob/b0325d4b7142832696d22fea1ea654348a69c675/surefire-api/src/main/java/org/apache/maven/surefire/booter/BaseProviderFactory.java#L113] of the provider, and the return is indeed nullable. This null check seems spurious. It checks directoryScannerParameters, but doesn't use it for anything. Seems like it should be checking runOrderParameters. When it was [originally introduced,|https://github.com/apache/maven-surefire/blob/877873b08a8fb62c7d31a0019eb2a1b419a2876e/surefire-api/src/main/java/org/apache/maven/surefire/booter/BaseProviderFactory.java#L80] this check made sense, but [a subsequent change to support parallelizing tests|https://github.com/apache/maven-surefire/commit/13e6736b8cabc04be9b98c71a2a9695391d1f1a1#diff-868fd02a40a6474205d7b259d320b806L86] seemed to break it. As a workaround, the reason directoryScannerParameters is null stems from the fact that [you are using |(https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1832], so maybe you can find an alternative way to configure your tests, while avoiding using that. > Surefire - NPE at end of successful test run > > > Key: SUREFIRE-1842 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1842 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.19.1, 2.21.0, 2.22.1, 3.0.0-M2, 3.0.0-M1, 3.0.0-M3, > 3.0.0-M4 >Reporter: Jack Leech >Priority: Major > Attachments: stack_trace.txt, test_profile.xml > > > While using surefire to run a mock test pack all tests are passed, followed > by an exception in the surefire plugin (NPE) at the end which causes the run > to be marked as a failure. > I've tried various surefire versions of surefire and other testing libraries > involved. > I have attached a stack trace of the exception in question and a copy of the > test profile xml. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1842) Surefire - NPE at end of successful test run
[ https://issues.apache.org/jira/browse/SUREFIRE-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199426#comment-17199426 ] Michael Boyles edited comment on SUREFIRE-1842 at 9/21/20, 2:49 PM: The only thing which can throw NPE on that line is [this instance of RunOrderCalculator|https://github.com/apache/maven-surefire/blob/b0325d4b7142832696d22fea1ea654348a69c675/surefire-providers/surefire-junit47/src/main/java/org/apache/maven/surefire/junitcore/JUnitCoreProvider.java#L294] This is the [only implementation|https://github.com/apache/maven-surefire/blob/b0325d4b7142832696d22fea1ea654348a69c675/surefire-api/src/main/java/org/apache/maven/surefire/booter/BaseProviderFactory.java#L113] of the provider, and the return is indeed nullable. This null check seems spurious. It checks directoryScannerParameters, but doesn't use it for anything. Seems like it should be checking runOrderParameters. When it was [originally introduced,|https://github.com/apache/maven-surefire/blob/877873b08a8fb62c7d31a0019eb2a1b419a2876e/surefire-api/src/main/java/org/apache/maven/surefire/booter/BaseProviderFactory.java#L80] this check made sense, but [a subsequent change to support parallelizing tests|https://github.com/apache/maven-surefire/commit/13e6736b8cabc04be9b98c71a2a9695391d1f1a1#diff-868fd02a40a6474205d7b259d320b806L86] seemed to break it. As a workaround, the reason directoryScannerParameters is null stems from the fact that [you are using |(https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1832], so maybe you can find an alternative way to configure your tests, while avoiding using that. was (Author: michaelboyles): The only thing which can throw is [this instance of RunOrderCalculator|https://github.com/apache/maven-surefire/blob/b0325d4b7142832696d22fea1ea654348a69c675/surefire-providers/surefire-junit47/src/main/java/org/apache/maven/surefire/junitcore/JUnitCoreProvider.java#L294] This is the [only implementation|https://github.com/apache/maven-surefire/blob/b0325d4b7142832696d22fea1ea654348a69c675/surefire-api/src/main/java/org/apache/maven/surefire/booter/BaseProviderFactory.java#L113] of the provider, and the return is indeed nullable. This null check seems spurious. It checks directoryScannerParameters, but doesn't use it for anything. Seems like it should be checking runOrderParameters. When it was [originally introduced,|https://github.com/apache/maven-surefire/blob/877873b08a8fb62c7d31a0019eb2a1b419a2876e/surefire-api/src/main/java/org/apache/maven/surefire/booter/BaseProviderFactory.java#L80] this check made sense, but [a subsequent change to support parallelizing tests|https://github.com/apache/maven-surefire/commit/13e6736b8cabc04be9b98c71a2a9695391d1f1a1#diff-868fd02a40a6474205d7b259d320b806L86] seemed to break it. As a workaround, the reason directoryScannerParameters is null stems from the fact that [you are using |(https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1832], so maybe you can find an alternative way to configure your tests, while avoiding using that. > Surefire - NPE at end of successful test run > > > Key: SUREFIRE-1842 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1842 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.19.1, 2.21.0, 2.22.1, 3.0.0-M2, 3.0.0-M1, 3.0.0-M3, > 3.0.0-M4 >Reporter: Jack Leech >Priority: Major > Attachments: stack_trace.txt, test_profile.xml > > > While using surefire to run a mock test pack all tests are passed, followed > by an exception in the surefire plugin (NPE) at the end which causes the run > to be marked as a failure. > I've tried various surefire versions of surefire and other testing libraries > involved. > I have attached a stack trace of the exception in question and a copy of the > test profile xml. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1842) Surefire - NPE at end of successful test run
[ https://issues.apache.org/jira/browse/SUREFIRE-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199426#comment-17199426 ] Michael Boyles commented on SUREFIRE-1842: -- The only thing which can throw is [this instance of RunOrderCalculator|https://github.com/apache/maven-surefire/blob/b0325d4b7142832696d22fea1ea654348a69c675/surefire-providers/surefire-junit47/src/main/java/org/apache/maven/surefire/junitcore/JUnitCoreProvider.java#L294] This is the [only implementation|https://github.com/apache/maven-surefire/blob/b0325d4b7142832696d22fea1ea654348a69c675/surefire-api/src/main/java/org/apache/maven/surefire/booter/BaseProviderFactory.java#L113] of the provider, and the return is indeed nullable. This null check seems spurious. It checks directoryScannerParameters, but doesn't use it for anything. Seems like it should be checking runOrderParameters. When it was [originally introduced,|https://github.com/apache/maven-surefire/blob/877873b08a8fb62c7d31a0019eb2a1b419a2876e/surefire-api/src/main/java/org/apache/maven/surefire/booter/BaseProviderFactory.java#L80] this check made sense, but [a subsequent change to support parallelizing tests|https://github.com/apache/maven-surefire/commit/13e6736b8cabc04be9b98c71a2a9695391d1f1a1#diff-868fd02a40a6474205d7b259d320b806L86] seemed to break it. As a workaround, the reason directoryScannerParameters is null stems from the fact that [you are using |(https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1832], so maybe you can find an alternative way to configure your tests, while avoiding using that. > Surefire - NPE at end of successful test run > > > Key: SUREFIRE-1842 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1842 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.19.1, 2.21.0, 2.22.1, 3.0.0-M2, 3.0.0-M1, 3.0.0-M3, > 3.0.0-M4 >Reporter: Jack Leech >Priority: Major > Attachments: stack_trace.txt, test_profile.xml > > > While using surefire to run a mock test pack all tests are passed, followed > by an exception in the surefire plugin (NPE) at the end which causes the run > to be marked as a failure. > I've tried various surefire versions of surefire and other testing libraries > involved. > I have attached a stack trace of the exception in question and a copy of the > test profile xml. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNGSITE-429) Doubled Text in create text jar page
[ https://issues.apache.org/jira/browse/MNGSITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17198517#comment-17198517 ] Michael Boyles commented on MNGSITE-429: https://github.com/apache/maven-jar-plugin/pull/16 > Doubled Text in create text jar page > > > Key: MNGSITE-429 > URL: https://issues.apache.org/jira/browse/MNGSITE-429 > Project: Maven Project Web Site > Issue Type: Bug > Environment: PROD >Reporter: Ion C Freeman >Priority: Major > Original Estimate: 336h > Remaining Estimate: 336h > > [https://maven.apache.org/plugins/maven-jar-plugin/examples/create-test-jar.html] > reads "which can be changed if you need by using the configuration in the > jar goal [using the configuration in the jar > goal|https://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html]."; > So, there's one 'using the configuration in the jar goal' followed by another > one with a link. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MARCHETYPES-69) com.google.inject.ProvisionException: Unable to provision, see the following errors
[ https://issues.apache.org/jira/browse/MARCHETYPES-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17197673#comment-17197673 ] Michael Boyles edited comment on MARCHETYPES-69 at 9/17/20, 9:56 PM: - Please give some context to the problem, this is just an error log was (Author: michaelboyles): Please give some context to the problem, don't just dump an error log > com.google.inject.ProvisionException: Unable to provision, see the following > errors > --- > > Key: MARCHETYPES-69 > URL: https://issues.apache.org/jira/browse/MARCHETYPES-69 > Project: Maven Archetype Bundles > Issue Type: Bug > Components: Maven Plugin Archetype >Reporter: AMITKUMAR Karnik >Priority: Major > Attachments: maven-debug.log > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MARCHETYPES-69) com.google.inject.ProvisionException: Unable to provision, see the following errors
[ https://issues.apache.org/jira/browse/MARCHETYPES-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17197673#comment-17197673 ] Michael Boyles commented on MARCHETYPES-69: --- Please give some context to the problem, don't just dump an error log > com.google.inject.ProvisionException: Unable to provision, see the following > errors > --- > > Key: MARCHETYPES-69 > URL: https://issues.apache.org/jira/browse/MARCHETYPES-69 > Project: Maven Archetype Bundles > Issue Type: Bug > Components: Maven Plugin Archetype >Reporter: AMITKUMAR Karnik >Priority: Major > Attachments: maven-debug.log > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6978) Setting inherited to false on execution has no effect
[ https://issues.apache.org/jira/browse/MNG-6978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196173#comment-17196173 ] Michael Boyles commented on MNG-6978: - Should be filed under Enforcer Plugin https://issues.apache.org/jira/projects/MENFORCER/issues/ > Setting inherited to false on execution has no effect > - > > Key: MNG-6978 > URL: https://issues.apache.org/jira/browse/MNG-6978 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.6.3 >Reporter: László Stahorszki >Priority: Major > > Minimal reproducible example > [https://github.com/rolaca11/maven-inherited-min/tree/master] > When the execution configuration comes from a tag, > disabling inheritance doesn't work on subsequent child projects. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNGSITE-425) Deadlink showed on page
[ https://issues.apache.org/jira/browse/MNGSITE-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196166#comment-17196166 ] Michael Boyles commented on MNGSITE-425: This is filed under the wrong project. In any case, raised a PR here. https://github.com/apache/maven-shade-plugin/pull/71/commits > Deadlink showed on page > --- > > Key: MNGSITE-425 > URL: https://issues.apache.org/jira/browse/MNGSITE-425 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Zhenbo Li >Priority: Major > > I was reading the document > [https://maven.apache.org/plugins/maven-shade-plugin/] > Content Contributors can check out the project from our [source > repository|https://maven.apache.org/plugins/maven-shade-plugin/source-repository.html] > pointing to an invalid link > https://maven.apache.org/plugins/maven-shade-plugin/source-repository.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCOMPILER-428) Documentation regarding useIncrementalCompilation not very useful
[ https://issues.apache.org/jira/browse/MCOMPILER-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196126#comment-17196126 ] Michael Boyles commented on MCOMPILER-428: -- I suspect your description may be inaccurate. As per the comments on that ticket by Robert: "if 1 file has been changed or removed, all files are deleted and recompiled" As per your description: "any source file was **added**, removed or changed". I don't know whether this optimization actually exists, but it seems plausible: If the only change is purely adding a class or classes, and no other existing classes changed, we can infer that the whole module does not need recompiling. Suppose we add a new Spring @Component. It would be sufficient to just compile this new class, and Spring's DI will pick it up at runtime. Recompiling everything else when we know they haven't changed would be a waste of time. > Documentation regarding useIncrementalCompilation not very useful > - > > Key: MCOMPILER-428 > URL: https://issues.apache.org/jira/browse/MCOMPILER-428 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: Thomas Bracher >Priority: Minor > Labels: documentation > > As of today, maven-compiler-plugin documentation for > useIncrementalCompilation says: "to enable/disable incrementation compilation > feature". Since there is no documentation of said feature, users will have to > either: > 1) take a guess at how the feature behaves > 2) painfully read the plugin code to understand what it does > This is less than optimal and lead to misunderstanding, like this comment > https://issues.apache.org/jira/browse/MCOMPILER-205?focusedCommentId=14428972&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14428972 > > So far the most explicit documentation I have found is in answer of a > stackoverflow issue: https://stackoverflow.com/a/49700942 > I think it would benefit a lot of users to understand the implication of both > options of this flag. I am trying to submit a PR providing an example of text. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6989) The page "Introduction to the Dependency Mechanism" shows deprecated practices
[ https://issues.apache.org/jira/browse/MNG-6989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196034#comment-17196034 ] Michael Boyles commented on MNG-6989: - It's here: https://github.com/apache/maven-site/blob/master/content/apt/guides/introduction/introduction-to-dependency-mechanism.apt > The page "Introduction to the Dependency Mechanism" shows deprecated practices > -- > > Key: MNG-6989 > URL: https://issues.apache.org/jira/browse/MNG-6989 > Project: Maven > Issue Type: Bug > Components: Documentation: Introductions >Affects Versions: 3.6.3 >Reporter: Mikaël Barbero >Priority: Major > > Page URL: > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > The section "[Bill of > Materials|https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms]"; > explains that one should use some properties to define submodules versions > (e.g., project1Version). Defining versions this way lead to publish pom files > with $variable in in their . This a bad practice that Maven warns > about during builds. I think this should not be advocated in an introduction > guide. AFAICT, the "standard" way for handling a bom setup is to have all > modules inheriting their versions from the parent pom. > If one committer is willing to point me where the code of this guide is > stored, I may be able to submit a patch. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCOMPILER-430) Improve documentation for setting the Java version
[ https://issues.apache.org/jira/browse/MCOMPILER-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17195666#comment-17195666 ] Michael Boyles commented on MCOMPILER-430: -- Prominence is of course subjective, but for your second point are you suggesting changing that page to mention the existing [ |https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#release] parameter, or have I misunderstood? The first time I read it, I thought you were suggesting a change in behaviour. > Improve documentation for setting the Java version > -- > > Key: MCOMPILER-430 > URL: https://issues.apache.org/jira/browse/MCOMPILER-430 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: Arend v. Reinersdorff >Priority: Major > > Setting the Java version is documented here: > [https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html] > Proposal for improvement: > # Make this documentation more prominent. This should be documented on the > "Usage" page. > In my experience, the Java version is set in every Maven project. Because the > default version of 1.6 is quite old and the default version is also not > obvious. > # Make -release as the preferred way to set the Java version >= 9. Keep the > documentation of -source/-target for Java version <= 8 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCOMPILER-430) Improve documentation for setting the Java version
[ https://issues.apache.org/jira/browse/MCOMPILER-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17195655#comment-17195655 ] Michael Boyles commented on MCOMPILER-430: -- Related to MCOMPILER-427 > Improve documentation for setting the Java version > -- > > Key: MCOMPILER-430 > URL: https://issues.apache.org/jira/browse/MCOMPILER-430 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: Arend v. Reinersdorff >Priority: Major > > Setting the Java version is documented here: > [https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html] > Proposal for improvement: > # Make this documentation more prominent. This should be documented on the > "Usage" page. > In my experience, the Java version is set in every Maven project. Because the > default version of 1.6 is quite old and the default version is also not > obvious. > # Make -release as the preferred way to set the Java version >= 9. Keep the > documentation of -source/-target for Java version <= 8 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DOXIA-606) fix javadoc issues with JDK 8 when generating documentation
[
https://issues.apache.org/jira/browse/DOXIA-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17195493#comment-17195493
]
Michael Boyles commented on DOXIA-606:
--
Aha! Forgive the misunderstanding. I thought you were saying "_if there are_
some javadoc issues _then_ the build will fail", and was trying to get an
example of such an issue. I didn't realise that it always happens when running
that command. Thanks for the clarification
> fix javadoc issues with JDK 8 when generating documentation
> ---
>
> Key: DOXIA-606
> URL: https://issues.apache.org/jira/browse/DOXIA-606
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Documentation
>Affects Versions: 1.9.1
>Reporter: Herve Boutemy
>Priority: Major
> Labels: up-for-grabs
> Fix For: 1.9.2
>
>
> when building Doxia documentation with JDK 8:
> {noformat}mvn -Preporting site site:stage{noformat}
> some javadoc issues make site generation failure
> I had to build Doxia 1.9.1 release documentation with JDK 7, even if I built
> the artifacts with JDK 8...
> for next release, it would be nice to not hit this issue any more
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (DOXIA-606) fix javadoc issues with JDK 8 when generating documentation
[
https://issues.apache.org/jira/browse/DOXIA-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Boyles updated DOXIA-606:
-
Comment: was deleted
(was: Your description doesn't make sense to me. I will leave it for someone
else.)
> fix javadoc issues with JDK 8 when generating documentation
> ---
>
> Key: DOXIA-606
> URL: https://issues.apache.org/jira/browse/DOXIA-606
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Documentation
>Affects Versions: 1.9.1
>Reporter: Herve Boutemy
>Priority: Major
> Labels: up-for-grabs
> Fix For: 1.9.2
>
>
> when building Doxia documentation with JDK 8:
> {noformat}mvn -Preporting site site:stage{noformat}
> some javadoc issues make site generation failure
> I had to build Doxia 1.9.1 release documentation with JDK 7, even if I built
> the artifacts with JDK 8...
> for next release, it would be nice to not hit this issue any more
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DOXIA-606) fix javadoc issues with JDK 8 when generating documentation
[
https://issues.apache.org/jira/browse/DOXIA-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17195063#comment-17195063
]
Michael Boyles commented on DOXIA-606:
--
Your description doesn't make sense to me. I will leave it for someone else.
> fix javadoc issues with JDK 8 when generating documentation
> ---
>
> Key: DOXIA-606
> URL: https://issues.apache.org/jira/browse/DOXIA-606
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Documentation
>Affects Versions: 1.9.1
>Reporter: Herve Boutemy
>Priority: Major
> Labels: up-for-grabs
> Fix For: 1.9.2
>
>
> when building Doxia documentation with JDK 8:
> {noformat}mvn -Preporting site site:stage{noformat}
> some javadoc issues make site generation failure
> I had to build Doxia 1.9.1 release documentation with JDK 7, even if I built
> the artifacts with JDK 8...
> for next release, it would be nice to not hit this issue any more
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DOXIA-606) fix javadoc issues with JDK 8 when generating documentation
[
https://issues.apache.org/jira/browse/DOXIA-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17194738#comment-17194738
]
Michael Boyles commented on DOXIA-606:
--
Can you define "some javadoc issues"?
> fix javadoc issues with JDK 8 when generating documentation
> ---
>
> Key: DOXIA-606
> URL: https://issues.apache.org/jira/browse/DOXIA-606
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Documentation
>Affects Versions: 1.9.1
>Reporter: Herve Boutemy
>Priority: Major
> Labels: up-for-grabs
> Fix For: 1.9.2
>
>
> when building Doxia documentation with JDK 8:
> {noformat}mvn -Preporting site site:stage{noformat}
> some javadoc issues make site generation failure
> I had to build Doxia 1.9.1 release documentation with JDK 7, even if I built
> the artifacts with JDK 8...
> for next release, it would be nice to not hit this issue any more
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCOMPILER-427) Lack of guide for cross-compilation for JDK 9+
[ https://issues.apache.org/jira/browse/MCOMPILER-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17193612#comment-17193612 ] Michael Boyles commented on MCOMPILER-427: -- You are looking at the wrong page. That page describes how to use a JDK other than the one Maven itself is running on, not how to target a lower version while running on the same JDK. There is already a page describing in detail what you need: [https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html] It is just one below the page you linked on the sidebar. > Lack of guide for cross-compilation for JDK 9+ > -- > > Key: MCOMPILER-427 > URL: https://issues.apache.org/jira/browse/MCOMPILER-427 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: Peter Lee >Priority: Minor > > For JDK9+, we need the _release_ or _maven.compiler.target_ to specify the > target jdk bytecode version. But this is not stated out in the website guide > page : > [https://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html] > I think this should be stated here. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MPIR-395) Add TeamCity as a possibility for ciManagement entry
[ https://issues.apache.org/jira/browse/MPIR-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17193580#comment-17193580 ] Michael Boyles commented on MPIR-395: - I sent a PR here [https://github.com/apache/maven-project-info-reports-plugin/pull/26] > Add TeamCity as a possibility for ciManagement entry > > > Key: MPIR-395 > URL: https://issues.apache.org/jira/browse/MPIR-395 > Project: Maven Project Info Reports Plugin > Issue Type: New Feature > Components: ci-management >Reporter: Erik Brangs >Priority: Trivial > Labels: up-for-grabs > > The ciManagement entry doesn't support TeamCity. TeamCity ( > [https://teamcity.com/] ) is a CI server by JetBrains. Could support for it > be added? -- This message was sent by Atlassian Jira (v8.3.4#803005)
