[jira] [Commented] (MNG-6833) Add an option to fail a build when dependency pom is invalid and transitive dependencies are not available
[ https://issues.apache.org/jira/browse/MNG-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003441#comment-17003441 ] Jiahongchao commented on MNG-6833: -- I want an option "bar", if use "mvn -bar clean compile", maven will exit with error when "The POM for xxx is invalid" > Add an option to fail a build when dependency pom is invalid and transitive > dependencies are not available > -- > > Key: MNG-6833 > URL: https://issues.apache.org/jira/browse/MNG-6833 > Project: Maven > Issue Type: Wish > Components: Command Line >Affects Versions: 3.6.1 >Reporter: Jiahongchao >Priority: Minor > Fix For: wontfix-candidate > > > Once, I build a war file on jenkins, then put it in tomcat. Then I got a > "class not found" exception when I start tomcat, after that I found there are > some jar files missing in the war file. > At last, I checked maven logs on jenkins, found warnings like "The POM for > xxx is invalid, transitive dependencies (if any) will not be available“, so > some transitive dependency jar files are not included, which caused "class > not found" exception. > So I think it is better to have an option to fail a build when dependency pom > is invalid, so I can get the error at the build time. I would rathar see > error in jenkins instead of in tomcat. > E.g. if use "mvn -bar clean compile", maven will exit with error when "The > POM for xxx is invalid" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6833) Add a option to fail a build when dependency pom is invalid and transitive dependencies are not available
[ https://issues.apache.org/jira/browse/MNG-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiahongchao updated MNG-6833: - Description: Once, I build a war file on jenkins, then put it in tomcat. Then I got a "class not found" exception when I start tomcat, after that I found there are some jar files missing in the war file. At last, I checked maven logs on jenkins, found warnings like "The POM for xxx is invalid, transitive dependencies (if any) will not be available“, so some transitive dependency jar files are not included, which caused "class not found" exception. So I think it is better to have an option to fail a build when dependency pom is invalid, so I can get the error at the build time. I would rathar see error in jenkins instead of in tomcat. E.g. if use "mvn -bar clean compile", maven will exit with error when "The POM for xxx is invalid" was: When I build a war file on jenkins, I got a warning:The POM for xxx is invalid, transitive dependencies (if any) will not be available However this war file is build successfully and I didn't notice that warning. But there are jar files missing in that war file, so I got a "class not found exception" in tomcat after I put that war file in it. So I think it is better to have a option to fail a build when dependency pom is invalid, so I can get the error in jenkins instead of tomcat. > Add a option to fail a build when dependency pom is invalid and transitive > dependencies are not available > - > > Key: MNG-6833 > URL: https://issues.apache.org/jira/browse/MNG-6833 > Project: Maven > Issue Type: Wish > Components: Command Line >Affects Versions: 3.6.1 >Reporter: Jiahongchao >Priority: Minor > Fix For: wontfix-candidate > > > Once, I build a war file on jenkins, then put it in tomcat. Then I got a > "class not found" exception when I start tomcat, after that I found there are > some jar files missing in the war file. > At last, I checked maven logs on jenkins, found warnings like "The POM for > xxx is invalid, transitive dependencies (if any) will not be available“, so > some transitive dependency jar files are not included, which caused "class > not found" exception. > So I think it is better to have an option to fail a build when dependency pom > is invalid, so I can get the error at the build time. I would rathar see > error in jenkins instead of in tomcat. > E.g. if use "mvn -bar clean compile", maven will exit with error when "The > POM for xxx is invalid" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6833) Add an option to fail a build when dependency pom is invalid and transitive dependencies are not available
[ https://issues.apache.org/jira/browse/MNG-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiahongchao updated MNG-6833: - Summary: Add an option to fail a build when dependency pom is invalid and transitive dependencies are not available (was: Add a option to fail a build when dependency pom is invalid and transitive dependencies are not available) > Add an option to fail a build when dependency pom is invalid and transitive > dependencies are not available > -- > > Key: MNG-6833 > URL: https://issues.apache.org/jira/browse/MNG-6833 > Project: Maven > Issue Type: Wish > Components: Command Line >Affects Versions: 3.6.1 >Reporter: Jiahongchao >Priority: Minor > Fix For: wontfix-candidate > > > Once, I build a war file on jenkins, then put it in tomcat. Then I got a > "class not found" exception when I start tomcat, after that I found there are > some jar files missing in the war file. > At last, I checked maven logs on jenkins, found warnings like "The POM for > xxx is invalid, transitive dependencies (if any) will not be available“, so > some transitive dependency jar files are not included, which caused "class > not found" exception. > So I think it is better to have an option to fail a build when dependency pom > is invalid, so I can get the error at the build time. I would rathar see > error in jenkins instead of in tomcat. > E.g. if use "mvn -bar clean compile", maven will exit with error when "The > POM for xxx is invalid" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6420) ComparableVersion incorrectly parses certain version strings
[ https://issues.apache.org/jira/browse/MNG-6420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003383#comment-17003383 ] Elliotte Rusty Harold commented on MNG-6420: Do all the bugs involve version strings that contain hyphens? That's a pretty weird case, so I'm not sure how much I personally care abut backwards compatibility here. The buggy behavior seems pretty surprising and unintuitive, so I'm inclined to fix it instead of blessing it. > ComparableVersion incorrectly parses certain version strings > > > Key: MNG-6420 > URL: https://issues.apache.org/jira/browse/MNG-6420 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.3 >Reporter: Ross Goldberg >Priority: Major > Fix For: wontfix-candidate > > > For certain version strings, ComparableVersion doesn't follow the Maven > version order spec > (https://maven.apache.org/pom.html#Version_Order_Specification). > To improve the code & fix the following bugs, I completely rewrote the > version parser (using Java 10 & Google Guava 25.1). It is attached & passes > all of the tests from ComparableVersionTest. > Bug 1: > > java -jar /usr/local/Cellar/maven/3.5.3/libexec/lib/maven-artifact-3.5.3.jar > 1-0.3 1 > > Outputs: > > 1. 1-0.3 == 1-0.3 > 1-0.3 == 1 > 2. 1 == 1 > > This probleem stems from: > > [https://github.com/apache/maven/blob/b8c06e61ab73cd9e25a5b2c93d9e5077b2196751/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java#L295-L296] > > > > Bug 2: > > java -jar /usr/local/Cellar/maven/3.5.3/libexec/lib/maven-artifact-3.5.3.jar > 1-0-2 1-0.1 > > 1. 1-0-2 == 1-2 > 1-0-2 < 1-0.1 > 2. 1-0.1 == 1-0.1 > > This problem stems from retaining ListItems that, after normalization, have > no children other than the subsequent ListItem. Removing the unnecessary > ListItem should fix this (i.e. remove the extraneous ListItem (named > extraneous) from its parent ListItem (named parent), then add the only child > of extraneous to parent). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MSHADE-286) Shading fails when a dependency's main artifact does not exist
[
https://issues.apache.org/jira/browse/MSHADE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003368#comment-17003368
]
Peter De Maeyer edited comment on MSHADE-286 at 12/25/19 8:41 PM:
--
[~struberg], I noticed you assigned this to yourself - are you working on this?
I'm working on a fix myself too...
was (Author: peterdm):
I'm working on a solution on a branch in my fork.
> Shading fails when a dependency's main artifact does not exist
> --
>
> Key: MSHADE-286
> URL: https://issues.apache.org/jira/browse/MSHADE-286
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Assignee: Mark Struberg
>Priority: Minor
>
> Shading fails when a dependency's main artifact does not exist, see the
> methods {{ShadeMojo.invalidMainArtifact/createErrorOutput}} and their caller.
> A similar existence check (luckily) does not exist for the other artifacts:
> test jar, sources, and test sources.
> This was done intentionally, but it's overly strict because it prohibits a
> legitimate use case: some projects don't produce a main artifact, but only
> e.g. a test artifact.
> Such projects can't be shaded because of this existence check.
> It would be better to:
> - Get rid of this check, or at least relax it, such that shading also works
> for projects that don't have a main artifact.
> - Complete the symmetry between jar, test jar, sources and test sources by
> adding a {{shadeJar}} boolean with default value {{true}}, which disables
> shading of main artifacts in a similar way {{shadeTestJar}},
> {{createSourcesJar}} and {{createTestSourcesJar}} work. This will allow
> shading to disable creation of a main artifact altogether, even when the
> dependencies _do_ have a main artifact.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-286) Shading fails when a dependency's main artifact does not exist
[
https://issues.apache.org/jira/browse/MSHADE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003368#comment-17003368
]
Peter De Maeyer commented on MSHADE-286:
I'm working on a solution on a branch in my fork.
> Shading fails when a dependency's main artifact does not exist
> --
>
> Key: MSHADE-286
> URL: https://issues.apache.org/jira/browse/MSHADE-286
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Assignee: Mark Struberg
>Priority: Minor
>
> Shading fails when a dependency's main artifact does not exist, see the
> methods {{ShadeMojo.invalidMainArtifact/createErrorOutput}} and their caller.
> A similar existence check (luckily) does not exist for the other artifacts:
> test jar, sources, and test sources.
> This was done intentionally, but it's overly strict because it prohibits a
> legitimate use case: some projects don't produce a main artifact, but only
> e.g. a test artifact.
> Such projects can't be shaded because of this existence check.
> It would be better to:
> - Get rid of this check, or at least relax it, such that shading also works
> for projects that don't have a main artifact.
> - Complete the symmetry between jar, test jar, sources and test sources by
> adding a {{shadeJar}} boolean with default value {{true}}, which disables
> shading of main artifacts in a similar way {{shadeTestJar}},
> {{createSourcesJar}} and {{createTestSourcesJar}} work. This will allow
> shading to disable creation of a main artifact altogether, even when the
> dependencies _do_ have a main artifact.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHADE-286) Shading fails when a dependency's main artifact does not exist
[
https://issues.apache.org/jira/browse/MSHADE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter De Maeyer updated MSHADE-286:
---
Description:
Shading fails when a dependency's main artifact does not exist, see the methods
{{ShadeMojo.invalidMainArtifact/createErrorOutput}} and their caller.
A similar existence check (luckily) does not exist for the other artifacts:
test jar, sources, and test sources.
This was done intentionally, but it's overly strict because it prohibits a
legitimate use case: some projects don't produce a main artifact, but only e.g.
a test artifact.
Such projects can't be shaded because of this existence check.
It would be better to:
- Get rid of this check, or at least relax it, such that shading also works for
projects that don't have a main artifact.
- Complete the symmetry between jar, test jar, sources and test sources by
adding a {{shadeJar}} boolean with default value {{true}}, which disables
shading of main artifacts in a similar way {{shadeTestJar}},
{{createSourcesJar}} and {{createTestSourcesJar}} work. This will allow shading
to disable creation of a main artifact altogether, even when the dependencies
_do_ have a main artifact.
was:
While looking at {{ShadeMojo.execute}}, I noticed that the artifacts to be
included for shading are not consistently checked for existence.
For example, on line 404, the main artifact file is _not_ checked for existence:
{code:java}
artifacts.add( project.getArtifact().getFile() );
{code}
But immediately below, the sources artifact file _is_ checked for existence:
{code:java}
if ( createSourcesJar )
{
File file = shadedSourcesArtifactFile();
if ( file.isFile() )
{
sourceArtifacts.add( file );
}
}
{code}
Apparently, it's a conscious choice to fail when the main artifact does not
exist.
> Shading fails when a dependency's main artifact does not exist
> --
>
> Key: MSHADE-286
> URL: https://issues.apache.org/jira/browse/MSHADE-286
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Assignee: Mark Struberg
>Priority: Minor
>
> Shading fails when a dependency's main artifact does not exist, see the
> methods {{ShadeMojo.invalidMainArtifact/createErrorOutput}} and their caller.
> A similar existence check (luckily) does not exist for the other artifacts:
> test jar, sources, and test sources.
> This was done intentionally, but it's overly strict because it prohibits a
> legitimate use case: some projects don't produce a main artifact, but only
> e.g. a test artifact.
> Such projects can't be shaded because of this existence check.
> It would be better to:
> - Get rid of this check, or at least relax it, such that shading also works
> for projects that don't have a main artifact.
> - Complete the symmetry between jar, test jar, sources and test sources by
> adding a {{shadeJar}} boolean with default value {{true}}, which disables
> shading of main artifacts in a similar way {{shadeTestJar}},
> {{createSourcesJar}} and {{createTestSourcesJar}} work. This will allow
> shading to disable creation of a main artifact altogether, even when the
> dependencies _do_ have a main artifact.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHADE-286) Shading fails when a dependency's main artifact does not exist
[
https://issues.apache.org/jira/browse/MSHADE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter De Maeyer updated MSHADE-286:
---
Issue Type: Bug (was: Improvement)
> Shading fails when a dependency's main artifact does not exist
> --
>
> Key: MSHADE-286
> URL: https://issues.apache.org/jira/browse/MSHADE-286
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Assignee: Mark Struberg
>Priority: Minor
>
> While looking at {{ShadeMojo.execute}}, I noticed that the artifacts to be
> included for shading are not consistently checked for existence.
> For example, on line 404, the main artifact file is _not_ checked for
> existence:
> {code:java}
> artifacts.add( project.getArtifact().getFile() );
> {code}
> But immediately below, the sources artifact file _is_ checked for existence:
> {code:java}
> if ( createSourcesJar )
> {
> File file = shadedSourcesArtifactFile();
> if ( file.isFile() )
> {
> sourceArtifacts.add( file );
> }
> }
> {code}
> Apparently, it's a conscious choice to fail when the main artifact does not
> exist.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHADE-286) Shading fails when a dependency's main artifact does not exist
[
https://issues.apache.org/jira/browse/MSHADE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter De Maeyer updated MSHADE-286:
---
Summary: Shading fails when a dependency's main artifact does not exist
(was: Artifacts to be included for shading are not consistently checked for
existence)
> Shading fails when a dependency's main artifact does not exist
> --
>
> Key: MSHADE-286
> URL: https://issues.apache.org/jira/browse/MSHADE-286
> Project: Maven Shade Plugin
> Issue Type: Improvement
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Assignee: Mark Struberg
>Priority: Minor
>
> While looking at {{ShadeMojo.execute}}, I noticed that the artifacts to be
> included for shading are not consistently checked for existence.
> For example, on line 404, the main artifact file is _not_ checked for
> existence:
> {code:java}
> artifacts.add( project.getArtifact().getFile() );
> {code}
> But immediately below, the sources artifact file _is_ checked for existence:
> {code:java}
> if ( createSourcesJar )
> {
> File file = shadedSourcesArtifactFile();
> if ( file.isFile() )
> {
> sourceArtifacts.add( file );
> }
> }
> {code}
> Apparently, it's a conscious choice to fail when the main artifact does not
> exist.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHADE-286) Artifacts to be included for shading are not consistently checked for existence
[
https://issues.apache.org/jira/browse/MSHADE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter De Maeyer updated MSHADE-286:
---
Description:
While looking at {{ShadeMojo.execute}}, I noticed that the artifacts to be
included for shading are not consistently checked for existence.
For example, on line 404, the main artifact file is _not_ checked for existence:
{code:java}
artifacts.add( project.getArtifact().getFile() );
{code}
But immediately below, the sources artifact file _is_ checked for existence:
{code:java}
if ( createSourcesJar )
{
File file = shadedSourcesArtifactFile();
if ( file.isFile() )
{
sourceArtifacts.add( file );
}
}
{code}
Apparently, it's a conscious choice to fail when the main artifact does not
exist.
was:
While looking at {{ShadeMojo.execute}}, I noticed that the artifacts to be
included for shading are not consistently checked for existence.
For example, on line 404, the main artifact file is _not_ checked for existence:
{code:java}
artifacts.add( project.getArtifact().getFile() );
{code}
But immediately below, the sources artifact file _is_ checked for existence:
{code:java}
if ( createSourcesJar )
{
File file = shadedSourcesArtifactFile();
if ( file.isFile() )
{
sourceArtifacts.add( file );
}
}
{code}
The line above
> Artifacts to be included for shading are not consistently checked for
> existence
> ---
>
> Key: MSHADE-286
> URL: https://issues.apache.org/jira/browse/MSHADE-286
> Project: Maven Shade Plugin
> Issue Type: Improvement
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Assignee: Mark Struberg
>Priority: Minor
>
> While looking at {{ShadeMojo.execute}}, I noticed that the artifacts to be
> included for shading are not consistently checked for existence.
> For example, on line 404, the main artifact file is _not_ checked for
> existence:
> {code:java}
> artifacts.add( project.getArtifact().getFile() );
> {code}
> But immediately below, the sources artifact file _is_ checked for existence:
> {code:java}
> if ( createSourcesJar )
> {
> File file = shadedSourcesArtifactFile();
> if ( file.isFile() )
> {
> sourceArtifacts.add( file );
> }
> }
> {code}
> Apparently, it's a conscious choice to fail when the main artifact does not
> exist.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-340) Shaded test jar artifact is not attached
[
https://issues.apache.org/jira/browse/MSHADE-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003366#comment-17003366
]
Peter De Maeyer commented on MSHADE-340:
Integration test added illustrating scenario, fix committed, PR created.
> Shaded test jar artifact is not attached
>
>
> Key: MSHADE-340
> URL: https://issues.apache.org/jira/browse/MSHADE-340
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When {{shadedArtifactAttached=true}} and {{shadeTestJar=true}}, the shaded
> test jar file is created but the artifact is not attached to the project.
> As a result, projects that depend on the attached test artifact don't compile.
> This does not affect the default case {{shadedArtifactAttached=false}} where
> the shaded artifact replaces the original artifact.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-shade-plugin] peterdemaeyer commented on issue #34: [MSHADE-340] - Shaded test jar artifact is not attached to the project
peterdemaeyer commented on issue #34: [MSHADE-340] - Shaded test jar artifact
is not attached to the project
URL: https://github.com/apache/maven-shade-plugin/pull/34#issuecomment-568925286
Fixed {{ShadeMojo}} such that the shaded test JAR is attached to the project
also when {{shadedArtifactAttached=true}}.
Integration test added illustrating scenario, fails without fix and succeeds
with the fix.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [maven-shade-plugin] peterdemaeyer opened a new pull request #34: [MSHADE-340] - Shaded test jar artifact is not attached to the project
peterdemaeyer opened a new pull request #34: [MSHADE-340] - Shaded test jar artifact is not attached to the project URL: https://github.com/apache/maven-shade-plugin/pull/34 Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MSHADE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MSHADE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MSHADE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (MSHADE-340) Shaded test jar artifact is not attached
[
https://issues.apache.org/jira/browse/MSHADE-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter De Maeyer updated MSHADE-340:
---
Description:
When {{shadedArtifactAttached=true}} and {{shadeTestJar=true}}, the shaded test
jar file is created but the artifact is not attached to the project.
As a result, projects that depend on the attached test artifact don't compile.
This does not affect the default case {{shadedArtifactAttached=false}} where
the shaded artifact replaces the original artifact.
was:
When {{shadedTestJar}} is set to {{true}}, the shaded test jar is not attached.
This does not affect the default case where the shaded artifact replaces the
original artifact.
> Shaded test jar artifact is not attached
>
>
> Key: MSHADE-340
> URL: https://issues.apache.org/jira/browse/MSHADE-340
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Major
>
> When {{shadedArtifactAttached=true}} and {{shadeTestJar=true}}, the shaded
> test jar file is created but the artifact is not attached to the project.
> As a result, projects that depend on the attached test artifact don't compile.
> This does not affect the default case {{shadedArtifactAttached=false}} where
> the shaded artifact replaces the original artifact.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCOMPILER-372) Unable to compile modularized test code depending on test-jar
[
https://issues.apache.org/jira/browse/MCOMPILER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003361#comment-17003361
]
François Loison commented on MCOMPILER-372:
---
The exception is this one:
javac -d target\test-classes ^
-classpath
target\test-classes;..\prj1\target\test-classes;%LOCAL_REPO%\junit\junit\3.8.2\junit-3.8.2.jar;
^
--module-path target\classes;..\prj1\target\classes; ^
-sourcepath src\test\java;target\generated-test-sources\test-annotations; ^
-s target\generated-test-sources\test-annotations ^
-g -nowarn --release 11 -encoding UTF-8 ^
--patch-module
prj2_372=target\classes;src\test\java;target\generated-test-sources\test-annotations;
^
*( notice that junit.framework.TestCase is removed from following patch module
)*
--patch-module
prj1_372=target\test-classes;..\prj1\target\classes;..\prj1\target\test-classes;
^
--add-reads prj2_372=ALL-UNNAMED ^
src\test\java\prj2\Prj2Test.java
{color:#FF}src\test\java\prj2\Prj2Test.java:24: error: cannot access
TestCase{color}
{color:#FF}public class Prj2Test extends Prj1Test{color}
{color:#FF} ^{color}
{color:#FF} class file for junit.framework.TestCase not found{color}
{color:#FF}1 error{color}
{color:#172b4d}OK to remove the multi-module code which is not relevant for
test compile.{color}
{color:#172b4d}Unfortunately, I found another issue when test code uses 2
modules. I'm working on it.{color}
> Unable to compile modularized test code depending on test-jar
> -
>
> Key: MCOMPILER-372
> URL: https://issues.apache.org/jira/browse/MCOMPILER-372
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.0
> Environment: Manjaro Linux 64 bit, Open JDK 11, Apache-Maven-3.6.0
>Reporter: Jeronimo Backes
>Assignee: Robert Scholte
>Priority: Blocker
> Attachments: maven-compiler-plugin.MCOMPILER-372.patch,
> univocity-all.zip
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I'm refactoring
> [univocity-parsers|https://github.com/uniVocity/univocity-parsers] into
> multiple projects with modules (attached a zip with everything I got)
> However I'm unable to reliably build the attached project with its unit
> tests. Unpack then cd into "univocity-all-parent", then run "mvn clean
> install".
>
> All projects generate test-jars, but for some reason class
> *com.univocity.parsers.core.routine.ResultSetWritingRoutine* inside
> "univocity-parsers-core/src/test/java/" is not found when compiling the tests
> of projects "univocity-csv", "univocity-tsv" and "univocity-fixedwidth".
>
> Interestingly, the issue doesn't seem to be consistent as I got
> "univocity-csv" and "univocity-tsv" building without errors a few times.
> "univocity-fixedwidth" however failed consistently every single time.
> Some of the errors I get are:
> {{[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.0:testCompile
> (default-testCompile) on project univocity-csv: Compilation failure:
> Compilation failure: }}
> {{[ERROR]
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[27,49]
> cannot find symbol}}
> {{[ERROR] symbol: class ResultSetWritingRoutine}}
> {{[ERROR] location: package com.univocity.parsers.core.routine}}
> {{[ERROR]
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[681,17]
> cannot find symbol}}
> {{[ERROR] symbol: class ResultSetWritingRoutine}}
> {{[ERROR] location: class com.univocity.csv.CsvWriterTest}}
> {{[ERROR]
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[681,52]
> cannot find symbol}}
> {{[ERROR] symbol: class ResultSetWritingRoutine}}
> {{[ERROR] location: class com.univocity.csv.CsvWriterTest}}
> {{[ERROR]
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[691,17]
> cannot find symbol}}
> {{[ERROR] symbol: class ResultSetTest}}
> {{[ERROR] location: class com.univocity.csv.CsvWriterTest}}
> {{[ERROR]
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[691,45]
> cannot find symbol}}
> {{[ERROR] symbol: class ResultSetTest}}
> {{[ERROR] location: class com.univocity.csv.CsvWriterTest}}
> {{[ERROR]
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/routine/CsvRoutinesTest.java:[123,17]
> cannot find symbol}}
> {{[ERROR] symbol: class ResultSetWritingRoutine}}
> {{[ERROR] location: class com.univocity.csv.routine.CsvRoutinesTest}}
> {{[ERROR]
>
[jira] [Commented] (MRESOURCES-250) Add ability to flatten folder structure into target directory when copying resources
[ https://issues.apache.org/jira/browse/MRESOURCES-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003352#comment-17003352 ] Jamie Spence commented on MRESOURCES-250: - I think you guys are on the right track. The overwrite flag behaviour sounds about right. Maybe overwrite should be ignored if two files are exactly the same anyway? > Add ability to flatten folder structure into target directory when copying > resources > > > Key: MRESOURCES-250 > URL: https://issues.apache.org/jira/browse/MRESOURCES-250 > Project: Maven Resources Plugin > Issue Type: New Feature > Components: copy >Reporter: Jamie Spence >Priority: Major > Labels: up-for-grabs > > See flatten description at: > h[ttps://ant.apache.org/manual/Tasks/copy.html|https://ant.apache.org/manual/Tasks/copy.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6420) ComparableVersion incorrectly parses certain version strings
[ https://issues.apache.org/jira/browse/MNG-6420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003351#comment-17003351 ] Ross Goldberg commented on MNG-6420: I assume lambdas are OK, then. Is there any way to see what I originally attached to this issue? I want to ensure I use the same base code in case I’ve already made subsequent changes to it. > ComparableVersion incorrectly parses certain version strings > > > Key: MNG-6420 > URL: https://issues.apache.org/jira/browse/MNG-6420 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.3 >Reporter: Ross Goldberg >Priority: Major > Fix For: wontfix-candidate > > > For certain version strings, ComparableVersion doesn't follow the Maven > version order spec > (https://maven.apache.org/pom.html#Version_Order_Specification). > To improve the code & fix the following bugs, I completely rewrote the > version parser (using Java 10 & Google Guava 25.1). It is attached & passes > all of the tests from ComparableVersionTest. > Bug 1: > > java -jar /usr/local/Cellar/maven/3.5.3/libexec/lib/maven-artifact-3.5.3.jar > 1-0.3 1 > > Outputs: > > 1. 1-0.3 == 1-0.3 > 1-0.3 == 1 > 2. 1 == 1 > > This probleem stems from: > > [https://github.com/apache/maven/blob/b8c06e61ab73cd9e25a5b2c93d9e5077b2196751/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java#L295-L296] > > > > Bug 2: > > java -jar /usr/local/Cellar/maven/3.5.3/libexec/lib/maven-artifact-3.5.3.jar > 1-0-2 1-0.1 > > 1. 1-0-2 == 1-2 > 1-0-2 < 1-0.1 > 2. 1-0.1 == 1-0.1 > > This problem stems from retaining ListItems that, after normalization, have > no children other than the subsequent ListItem. Removing the unnecessary > ListItem should fix this (i.e. remove the extraneous ListItem (named > extraneous) from its parent ListItem (named parent), then add the only child > of extraneous to parent). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6420) ComparableVersion incorrectly parses certain version strings
[ https://issues.apache.org/jira/browse/MNG-6420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003350#comment-17003350 ] Karl Heinz Marbaise commented on MNG-6420: -- Based on the current state we could think about Java 8 solutions but we should prevent to add more dependencies. I see currently only two things at the moment: * Keep the code as it is; In the end it does not matter if there are code issues cause if we change the behaviour this would break compatibility. It might be possible to make an opt-in feature toggle and change the behaviour related to this. * We can address this for Maven 4.X > ComparableVersion incorrectly parses certain version strings > > > Key: MNG-6420 > URL: https://issues.apache.org/jira/browse/MNG-6420 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.3 >Reporter: Ross Goldberg >Priority: Major > Fix For: wontfix-candidate > > > For certain version strings, ComparableVersion doesn't follow the Maven > version order spec > (https://maven.apache.org/pom.html#Version_Order_Specification). > To improve the code & fix the following bugs, I completely rewrote the > version parser (using Java 10 & Google Guava 25.1). It is attached & passes > all of the tests from ComparableVersionTest. > Bug 1: > > java -jar /usr/local/Cellar/maven/3.5.3/libexec/lib/maven-artifact-3.5.3.jar > 1-0.3 1 > > Outputs: > > 1. 1-0.3 == 1-0.3 > 1-0.3 == 1 > 2. 1 == 1 > > This probleem stems from: > > [https://github.com/apache/maven/blob/b8c06e61ab73cd9e25a5b2c93d9e5077b2196751/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java#L295-L296] > > > > Bug 2: > > java -jar /usr/local/Cellar/maven/3.5.3/libexec/lib/maven-artifact-3.5.3.jar > 1-0-2 1-0.1 > > 1. 1-0-2 == 1-2 > 1-0-2 < 1-0.1 > 2. 1-0.1 == 1-0.1 > > This problem stems from retaining ListItems that, after normalization, have > no children other than the subsequent ListItem. Removing the unnecessary > ListItem should fix this (i.e. remove the extraneous ListItem (named > extraneous) from its parent ListItem (named parent), then add the only child > of extraneous to parent). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6420) ComparableVersion incorrectly parses certain version strings
[ https://issues.apache.org/jira/browse/MNG-6420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003348#comment-17003348 ] Michael Osipov commented on MNG-6420: - It should be Java 7/8 w/o external deps. > ComparableVersion incorrectly parses certain version strings > > > Key: MNG-6420 > URL: https://issues.apache.org/jira/browse/MNG-6420 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.3 >Reporter: Ross Goldberg >Priority: Major > Fix For: wontfix-candidate > > > For certain version strings, ComparableVersion doesn't follow the Maven > version order spec > (https://maven.apache.org/pom.html#Version_Order_Specification). > To improve the code & fix the following bugs, I completely rewrote the > version parser (using Java 10 & Google Guava 25.1). It is attached & passes > all of the tests from ComparableVersionTest. > Bug 1: > > java -jar /usr/local/Cellar/maven/3.5.3/libexec/lib/maven-artifact-3.5.3.jar > 1-0.3 1 > > Outputs: > > 1. 1-0.3 == 1-0.3 > 1-0.3 == 1 > 2. 1 == 1 > > This probleem stems from: > > [https://github.com/apache/maven/blob/b8c06e61ab73cd9e25a5b2c93d9e5077b2196751/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java#L295-L296] > > > > Bug 2: > > java -jar /usr/local/Cellar/maven/3.5.3/libexec/lib/maven-artifact-3.5.3.jar > 1-0-2 1-0.1 > > 1. 1-0-2 == 1-2 > 1-0-2 < 1-0.1 > 2. 1-0.1 == 1-0.1 > > This problem stems from retaining ListItems that, after normalization, have > no children other than the subsequent ListItem. Removing the unnecessary > ListItem should fix this (i.e. remove the extraneous ListItem (named > extraneous) from its parent ListItem (named parent), then add the only child > of extraneous to parent). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6420) ComparableVersion incorrectly parses certain version strings
[ https://issues.apache.org/jira/browse/MNG-6420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003345#comment-17003345 ] Ross Goldberg commented on MNG-6420: I can redo the new version parser for whatever Java version you want, and without Guava. > ComparableVersion incorrectly parses certain version strings > > > Key: MNG-6420 > URL: https://issues.apache.org/jira/browse/MNG-6420 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.3 >Reporter: Ross Goldberg >Priority: Major > Fix For: wontfix-candidate > > > For certain version strings, ComparableVersion doesn't follow the Maven > version order spec > (https://maven.apache.org/pom.html#Version_Order_Specification). > To improve the code & fix the following bugs, I completely rewrote the > version parser (using Java 10 & Google Guava 25.1). It is attached & passes > all of the tests from ComparableVersionTest. > Bug 1: > > java -jar /usr/local/Cellar/maven/3.5.3/libexec/lib/maven-artifact-3.5.3.jar > 1-0.3 1 > > Outputs: > > 1. 1-0.3 == 1-0.3 > 1-0.3 == 1 > 2. 1 == 1 > > This probleem stems from: > > [https://github.com/apache/maven/blob/b8c06e61ab73cd9e25a5b2c93d9e5077b2196751/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java#L295-L296] > > > > Bug 2: > > java -jar /usr/local/Cellar/maven/3.5.3/libexec/lib/maven-artifact-3.5.3.jar > 1-0-2 1-0.1 > > 1. 1-0-2 == 1-2 > 1-0-2 < 1-0.1 > 2. 1-0.1 == 1-0.1 > > This problem stems from retaining ListItems that, after normalization, have > no children other than the subsequent ListItem. Removing the unnecessary > ListItem should fix this (i.e. remove the extraneous ListItem (named > extraneous) from its parent ListItem (named parent), then add the only child > of extraneous to parent). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6420) ComparableVersion incorrectly parses certain version strings
[ https://issues.apache.org/jira/browse/MNG-6420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003316#comment-17003316 ] Michael Osipov commented on MNG-6420: - No we don't, but we need to address this issue somehow. > ComparableVersion incorrectly parses certain version strings > > > Key: MNG-6420 > URL: https://issues.apache.org/jira/browse/MNG-6420 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.3 >Reporter: Ross Goldberg >Priority: Major > Fix For: wontfix-candidate > > > For certain version strings, ComparableVersion doesn't follow the Maven > version order spec > (https://maven.apache.org/pom.html#Version_Order_Specification). > To improve the code & fix the following bugs, I completely rewrote the > version parser (using Java 10 & Google Guava 25.1). It is attached & passes > all of the tests from ComparableVersionTest. > Bug 1: > > java -jar /usr/local/Cellar/maven/3.5.3/libexec/lib/maven-artifact-3.5.3.jar > 1-0.3 1 > > Outputs: > > 1. 1-0.3 == 1-0.3 > 1-0.3 == 1 > 2. 1 == 1 > > This probleem stems from: > > [https://github.com/apache/maven/blob/b8c06e61ab73cd9e25a5b2c93d9e5077b2196751/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java#L295-L296] > > > > Bug 2: > > java -jar /usr/local/Cellar/maven/3.5.3/libexec/lib/maven-artifact-3.5.3.jar > 1-0-2 1-0.1 > > 1. 1-0-2 == 1-2 > 1-0-2 < 1-0.1 > 2. 1-0.1 == 1-0.1 > > This problem stems from retaining ListItems that, after normalization, have > no children other than the subsequent ListItem. Removing the unnecessary > ListItem should fix this (i.e. remove the extraneous ListItem (named > extraneous) from its parent ListItem (named parent), then add the only child > of extraneous to parent). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6420) ComparableVersion incorrectly parses certain version strings
[ https://issues.apache.org/jira/browse/MNG-6420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003299#comment-17003299 ] Elliotte Rusty Harold commented on MNG-6420: Patch wise, I don't think we want to introduce a dependency on Guava or Java 10. I might have some code in my dependencies project we could adopt for this though. > ComparableVersion incorrectly parses certain version strings > > > Key: MNG-6420 > URL: https://issues.apache.org/jira/browse/MNG-6420 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.3 >Reporter: Ross Goldberg >Priority: Major > Fix For: wontfix-candidate > > > For certain version strings, ComparableVersion doesn't follow the Maven > version order spec > (https://maven.apache.org/pom.html#Version_Order_Specification). > To improve the code & fix the following bugs, I completely rewrote the > version parser (using Java 10 & Google Guava 25.1). It is attached & passes > all of the tests from ComparableVersionTest. > Bug 1: > > java -jar /usr/local/Cellar/maven/3.5.3/libexec/lib/maven-artifact-3.5.3.jar > 1-0.3 1 > > Outputs: > > 1. 1-0.3 == 1-0.3 > 1-0.3 == 1 > 2. 1 == 1 > > This probleem stems from: > > [https://github.com/apache/maven/blob/b8c06e61ab73cd9e25a5b2c93d9e5077b2196751/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java#L295-L296] > > > > Bug 2: > > java -jar /usr/local/Cellar/maven/3.5.3/libexec/lib/maven-artifact-3.5.3.jar > 1-0-2 1-0.1 > > 1. 1-0-2 == 1-2 > 1-0-2 < 1-0.1 > 2. 1-0.1 == 1-0.1 > > This problem stems from retaining ListItems that, after normalization, have > no children other than the subsequent ListItem. Removing the unnecessary > ListItem should fix this (i.e. remove the extraneous ListItem (named > extraneous) from its parent ListItem (named parent), then add the only child > of extraneous to parent). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MASSEMBLY-775) Emit WARNING instead of ERROR
[
https://issues.apache.org/jira/browse/MASSEMBLY-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003278#comment-17003278
]
Mark Struberg commented on MASSEMBLY-775:
-
proposed change up for review
[https://github.com/apache/maven-assembly-plugin/pull/14]
Gonna commit it in the next 2 days if no one is yelling ;)
> Emit WARNING instead of ERROR
> -
>
> Key: MASSEMBLY-775
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-775
> Project: Maven Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.5
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I have currently a build which creates several tar/tar.gz/zip archives etc.
> {code}
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor-inner-tar.xml
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor.xml
> [INFO] Building tar: C:\...\xyz-X.y.z-SNAPSHOT-dist.tar
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> {code}
> In my opinion the message could be a WARNING instead of an error ? WDYT ?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-6749) Maven 3.x fails when following 301 redirects
[ https://issues.apache.org/jira/browse/MNG-6749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-6749. --- Fix Version/s: (was: wontfix-candidate) Resolution: Incomplete No reaction since August. > Maven 3.x fails when following 301 redirects > > > Key: MNG-6749 > URL: https://issues.apache.org/jira/browse/MNG-6749 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0.3, 3.3.9 >Reporter: Bex Warner >Priority: Major > > Hello there, my team uses Maven 3.0.3 and 3.3.9 and has ran into this issue > where maven fails to follow HTTP 301 redirections. Instead Maven receives the > HTTP error code and tries to copy it as if it were a jar file. > > We do know that this is a duplicate of the issue described in > https://issues.apache.org/jira/browse/WAGON-314; however, we are reopening it > to bring it to your attention as that issue only fixed the probably in Maven > version 2.2.0. https://issues.apache.org/jira/browse/MNG-4816 also seems to > have been opened to address this regression of not supporting http redirects. > Both of these tickets are many years old, so we hoped to surface this problem > through a new ticket to get a fresh set of eyes on the issue. > > Thank you in advance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6833) Add a option to fail a build when dependency pom is invalid and transitive dependencies are not available
[ https://issues.apache.org/jira/browse/MNG-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003242#comment-17003242 ] Michael Osipov commented on MNG-6833: - I still don't understand what you want. > Add a option to fail a build when dependency pom is invalid and transitive > dependencies are not available > - > > Key: MNG-6833 > URL: https://issues.apache.org/jira/browse/MNG-6833 > Project: Maven > Issue Type: Wish > Components: Command Line >Affects Versions: 3.6.1 >Reporter: Jiahongchao >Priority: Minor > Fix For: wontfix-candidate > > > When I build a war file on jenkins, I got a warning:The POM for xxx is > invalid, transitive dependencies (if any) will not be available > > However this war file is build successfully and I didn't notice that > warning. But there are jar files missing in that war file, so I got a "class > not found exception" in tomcat after I put that war file in it. > > So I think it is better to have a option to fail a build when dependency pom > is invalid, so I can get the error in jenkins instead of tomcat. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6833) Add a option to fail a build when dependency pom is invalid and transitive dependencies are not available
[ https://issues.apache.org/jira/browse/MNG-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003232#comment-17003232 ] Jiahongchao commented on MNG-6833: -- Never mind. It is a wish, not a bug. > Add a option to fail a build when dependency pom is invalid and transitive > dependencies are not available > - > > Key: MNG-6833 > URL: https://issues.apache.org/jira/browse/MNG-6833 > Project: Maven > Issue Type: Wish > Components: Command Line >Affects Versions: 3.6.1 >Reporter: Jiahongchao >Priority: Minor > Fix For: wontfix-candidate > > > When I build a war file on jenkins, I got a warning:The POM for xxx is > invalid, transitive dependencies (if any) will not be available > > However this war file is build successfully and I didn't notice that > warning. But there are jar files missing in that war file, so I got a "class > not found exception" in tomcat after I put that war file in it. > > So I think it is better to have a option to fail a build when dependency pom > is invalid, so I can get the error in jenkins instead of tomcat. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6420) ComparableVersion incorrectly parses certain version strings
[ https://issues.apache.org/jira/browse/MNG-6420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003229#comment-17003229 ] Michael Osipov commented on MNG-6420: - [~elharo], you may want to take a look at this. Maybe work on the docs if we cannot change the code. > ComparableVersion incorrectly parses certain version strings > > > Key: MNG-6420 > URL: https://issues.apache.org/jira/browse/MNG-6420 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.3 >Reporter: Ross Goldberg >Priority: Major > Fix For: wontfix-candidate > > > For certain version strings, ComparableVersion doesn't follow the Maven > version order spec > (https://maven.apache.org/pom.html#Version_Order_Specification). > To improve the code & fix the following bugs, I completely rewrote the > version parser (using Java 10 & Google Guava 25.1). It is attached & passes > all of the tests from ComparableVersionTest. > Bug 1: > > java -jar /usr/local/Cellar/maven/3.5.3/libexec/lib/maven-artifact-3.5.3.jar > 1-0.3 1 > > Outputs: > > 1. 1-0.3 == 1-0.3 > 1-0.3 == 1 > 2. 1 == 1 > > This probleem stems from: > > [https://github.com/apache/maven/blob/b8c06e61ab73cd9e25a5b2c93d9e5077b2196751/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java#L295-L296] > > > > Bug 2: > > java -jar /usr/local/Cellar/maven/3.5.3/libexec/lib/maven-artifact-3.5.3.jar > 1-0-2 1-0.1 > > 1. 1-0-2 == 1-2 > 1-0-2 < 1-0.1 > 2. 1-0.1 == 1-0.1 > > This problem stems from retaining ListItems that, after normalization, have > no children other than the subsequent ListItem. Removing the unnecessary > ListItem should fix this (i.e. remove the extraneous ListItem (named > extraneous) from its parent ListItem (named parent), then add the only child > of extraneous to parent). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6833) Add a option to fail a build when dependency pom is invalid and transitive dependencies are not available
[ https://issues.apache.org/jira/browse/MNG-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiahongchao updated MNG-6833: - Priority: Minor (was: Major) > Add a option to fail a build when dependency pom is invalid and transitive > dependencies are not available > - > > Key: MNG-6833 > URL: https://issues.apache.org/jira/browse/MNG-6833 > Project: Maven > Issue Type: Wish > Components: core >Affects Versions: 3.6.1 >Reporter: Jiahongchao >Priority: Minor > Fix For: wontfix-candidate > > > When I build a war file on jenkins, I got a warning:The POM for xxx is > invalid, transitive dependencies (if any) will not be available > > However this war file is build successfully and I didn't notice that > warning. But there are jar files missing in that war file, so I got a "class > not found exception" in tomcat after I put that war file in it. > > So I think it is better to have a option to fail a build when dependency pom > is invalid, so I can get the error in jenkins instead of tomcat. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6833) Add a option to fail a build when dependency pom is invalid and transitive dependencies are not available
[ https://issues.apache.org/jira/browse/MNG-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiahongchao updated MNG-6833: - Component/s: (was: core) Command Line > Add a option to fail a build when dependency pom is invalid and transitive > dependencies are not available > - > > Key: MNG-6833 > URL: https://issues.apache.org/jira/browse/MNG-6833 > Project: Maven > Issue Type: Wish > Components: Command Line >Affects Versions: 3.6.1 >Reporter: Jiahongchao >Priority: Minor > Fix For: wontfix-candidate > > > When I build a war file on jenkins, I got a warning:The POM for xxx is > invalid, transitive dependencies (if any) will not be available > > However this war file is build successfully and I didn't notice that > warning. But there are jar files missing in that war file, so I got a "class > not found exception" in tomcat after I put that war file in it. > > So I think it is better to have a option to fail a build when dependency pom > is invalid, so I can get the error in jenkins instead of tomcat. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6833) Add a option to fail a build when dependency pom is invalid and transitive dependencies are not available
[ https://issues.apache.org/jira/browse/MNG-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003205#comment-17003205 ] Michael Osipov commented on MNG-6833: - Still not helpful. Unless you provide some log output or sample project... > Add a option to fail a build when dependency pom is invalid and transitive > dependencies are not available > - > > Key: MNG-6833 > URL: https://issues.apache.org/jira/browse/MNG-6833 > Project: Maven > Issue Type: Wish > Components: core >Affects Versions: 3.6.1 >Reporter: Jiahongchao >Priority: Major > Fix For: wontfix-candidate > > > When I build a war file on jenkins, I got a warning:The POM for xxx is > invalid, transitive dependencies (if any) will not be available > > However this war file is build successfully and I didn't notice that > warning. But there are jar files missing in that war file, so I got a "class > not found exception" in tomcat after I put that war file in it. > > So I think it is better to have a option to fail a build when dependency pom > is invalid, so I can get the error in jenkins instead of tomcat. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6833) Add a option to fail a build when dependency pom is invalid and transitive dependencies are not available
[ https://issues.apache.org/jira/browse/MNG-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003203#comment-17003203 ] Jiahongchao commented on MNG-6833: -- updated this issue > Add a option to fail a build when dependency pom is invalid and transitive > dependencies are not available > - > > Key: MNG-6833 > URL: https://issues.apache.org/jira/browse/MNG-6833 > Project: Maven > Issue Type: Wish > Components: core >Affects Versions: 3.6.1 >Reporter: Jiahongchao >Priority: Major > Fix For: wontfix-candidate > > > When I build a war file on jenkins, I got a warning:The POM for xxx is > invalid, transitive dependencies (if any) will not be available > > However this war file is build successfully and I didn't notice that > warning. But there are jar files missing in that war file, so I got a "class > not found exception" in tomcat after I put that war file in it. > > So I think it is better to have a option to fail a build when dependency pom > is invalid, so I can get the error in jenkins instead of tomcat. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MNG-6833) Add a option to fail a build when dependency pom is invalid and transitive dependencies are not available
[ https://issues.apache.org/jira/browse/MNG-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003203#comment-17003203 ] Jiahongchao edited comment on MNG-6833 at 12/25/19 10:27 AM: - updated description was (Author: ihavenoem...@163.com): updated this issue > Add a option to fail a build when dependency pom is invalid and transitive > dependencies are not available > - > > Key: MNG-6833 > URL: https://issues.apache.org/jira/browse/MNG-6833 > Project: Maven > Issue Type: Wish > Components: core >Affects Versions: 3.6.1 >Reporter: Jiahongchao >Priority: Major > Fix For: wontfix-candidate > > > When I build a war file on jenkins, I got a warning:The POM for xxx is > invalid, transitive dependencies (if any) will not be available > > However this war file is build successfully and I didn't notice that > warning. But there are jar files missing in that war file, so I got a "class > not found exception" in tomcat after I put that war file in it. > > So I think it is better to have a option to fail a build when dependency pom > is invalid, so I can get the error in jenkins instead of tomcat. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6833) Add a option to fail a build when dependency pom is invalid and transitive dependencies are not available
[ https://issues.apache.org/jira/browse/MNG-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiahongchao updated MNG-6833: - Description: When I build a war file on jenkins, I got a warning:The POM for xxx is invalid, transitive dependencies (if any) will not be available However this war file is build successfully and I didn't notice that warning. But there are jar files missing in that war file, so I got a "class not found exception" in tomcat after I put that war file in it. So I think it is better to have a option to fail a build when dependency pom is invalid, so I can get the error in jenkins instead of tomcat. was: When I build a war file on jenkins, I got a warning:The POM for xxx is invalid, transitive dependencies (if any) will not be available However this war file is build successfully and I didn't notice that warning. But there are jar files missing in that war file, so I got a "class not found exception" in tomcat after I put that war file in it. So I think it is better to have a option to fail a build when dependency pom is invalid, so I can get the error in jenkins instead of tomcat. > Add a option to fail a build when dependency pom is invalid and transitive > dependencies are not available > - > > Key: MNG-6833 > URL: https://issues.apache.org/jira/browse/MNG-6833 > Project: Maven > Issue Type: Wish > Components: core >Affects Versions: 3.6.1 >Reporter: Jiahongchao >Priority: Major > Fix For: wontfix-candidate > > > When I build a war file on jenkins, I got a warning:The POM for xxx is > invalid, transitive dependencies (if any) will not be available > > However this war file is build successfully and I didn't notice that > warning. But there are jar files missing in that war file, so I got a "class > not found exception" in tomcat after I put that war file in it. > > So I think it is better to have a option to fail a build when dependency pom > is invalid, so I can get the error in jenkins instead of tomcat. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6833) Add a option to fail a build when dependency pom is invalid and transitive dependencies are not available
[ https://issues.apache.org/jira/browse/MNG-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiahongchao updated MNG-6833: - Description: When I build a war file on jenkins, I got a warning:The POM for xxx is invalid, transitive dependencies (if any) will not be available However this war file is build successfully and I didn't notice that warning. But there are jar files missing in that war file, so I got a "class not found exception" in tomcat after I put that war file in it. So I think it is better to have a option to fail a build when dependency pom is invalid, so I can get the error in jenkins instead of tomcat. was: When I build a war file, I got a warning like this.However this war file is build successfully and I got a "class not found exception" in my tomcat. So I think it is better to have a option to fail a build when dependency pom is invalid, so I can get the error in jenkins. > Add a option to fail a build when dependency pom is invalid and transitive > dependencies are not available > - > > Key: MNG-6833 > URL: https://issues.apache.org/jira/browse/MNG-6833 > Project: Maven > Issue Type: Wish > Components: core >Affects Versions: 3.6.1 >Reporter: Jiahongchao >Priority: Major > Fix For: wontfix-candidate > > > When I build a war file on jenkins, I got a warning:The POM for xxx is > invalid, transitive dependencies (if any) will not be available > > > However this war file is build successfully and I didn't notice that warning. > But there are jar files missing in that war file, so I got a "class not found > exception" in tomcat after I put that war file in it. > > So I think it is better to have a option to fail a build when dependency pom > is invalid, so I can get the error in jenkins instead of tomcat. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6833) Add a option to fail a build when dependency pom is invalid and transitive dependencies are not available
[ https://issues.apache.org/jira/browse/MNG-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003192#comment-17003192 ] Michael Osipov commented on MNG-6833: - Please provide subtantial information about the problem. I fail to see any with the minimal you have provided. > Add a option to fail a build when dependency pom is invalid and transitive > dependencies are not available > - > > Key: MNG-6833 > URL: https://issues.apache.org/jira/browse/MNG-6833 > Project: Maven > Issue Type: Wish > Components: core >Affects Versions: 3.6.1 >Reporter: Jiahongchao >Priority: Major > Fix For: wontfix-candidate > > > When I build a war file, I got a warning like this.However this war file is > build successfully and I got a "class not found exception" in my tomcat. > > So I think it is better to have a option to fail a build when dependency pom > is invalid, so I can get the error in jenkins. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6833) Add a option to fail a build when dependency pom is invalid and transitive dependencies are not available
[ https://issues.apache.org/jira/browse/MNG-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6833: Fix Version/s: wontfix-candidate > Add a option to fail a build when dependency pom is invalid and transitive > dependencies are not available > - > > Key: MNG-6833 > URL: https://issues.apache.org/jira/browse/MNG-6833 > Project: Maven > Issue Type: Wish > Components: core >Affects Versions: 3.6.1 >Reporter: Jiahongchao >Priority: Major > Fix For: wontfix-candidate > > > When I build a war file, I got a warning like this.However this war file is > build successfully and I got a "class not found exception" in my tomcat. > > So I think it is better to have a option to fail a build when dependency pom > is invalid, so I can get the error in jenkins. -- This message was sent by Atlassian Jira (v8.3.4#803005)
