[jira] [Commented] (MNG-5961) Maven possibly not aware of log4j2
[
https://issues.apache.org/jira/browse/MNG-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848117#comment-15848117
]
Arnaud HERITIER commented on MNG-5961:
--
About the fact to replace {{org.slf4j.helpers.Log4jLoggerFactory}} by
{{org.apache.logging.slf4j.Log4jLoggerFactory}} and not the addition of a new
entry it is because the old one was wrong.
{{org.slf4j.helpers.Log4jLoggerFactory}} is for LOG4J 1.x not 2.x
https://www.slf4j.org/xref/org/slf4j/impl/Log4jLoggerFactory.html
> Maven possibly not aware of log4j2
> --
>
> Key: MNG-5961
> URL: https://issues.apache.org/jira/browse/MNG-5961
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.3.9
>Reporter: Mike Drob
>Assignee: Arnaud HERITIER
> Fix For: 3.5.0
>
>
> Using a fresh install of maven 3.3.9 I followed the steps at
> https://garygregory.wordpress.com/2015/03/23/watch-maven-in-color to add
> color highlighting to my output. Everything works as expected, however on all
> usages I would get the warning:
> {noformat}
> [WARN] The SLF4J binding actually used is not supported by Maven:
> org.apache.logging.slf4j.Log4jLoggerFactory
> [WARN] Maven supported bindings are:
> [WARN] (from
> jar:file:/opt/apache-maven-3.3.9/lib/maven-embedder-3.3.9.jar!/META-INF/maven/slf4j-configuration.properties)
> - ch.qos.logback.classic.LoggerContext
> - org.slf4j.helpers.Log4jLoggerFactory
> - org.slf4j.impl.SimpleLoggerFactory
> {noformat}
> This looks pretty harmless, and I was able to suppress it by manually adding
> the line
> {code}
> org.apache.logging.slf4j.Log4jLoggerFactory
> org.apache.maven.cli.logging.impl.Log4j2Configuration
> {code}
> to {{/META-INF/maven/slf4j-configuration.properties}} in
> {{maven-embedder-3.3.9.jar}}.
> I'm not sure that this is a "correct" solution, and I'm not even confident I
> could explain what effect it has, hence not posting a patch, but somebody
> with more knowledge might be able to triage this better. Or offer an
> "official" way to do colorized output.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-5961) Maven possibly not aware of log4j2
[
https://issues.apache.org/jira/browse/MNG-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud HERITIER updated MNG-5961:
-
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
3.5.0
> Maven possibly not aware of log4j2
> --
>
> Key: MNG-5961
> URL: https://issues.apache.org/jira/browse/MNG-5961
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.3.9
>Reporter: Mike Drob
>Assignee: Arnaud HERITIER
> Fix For: 3.5.0
>
>
> Using a fresh install of maven 3.3.9 I followed the steps at
> https://garygregory.wordpress.com/2015/03/23/watch-maven-in-color to add
> color highlighting to my output. Everything works as expected, however on all
> usages I would get the warning:
> {noformat}
> [WARN] The SLF4J binding actually used is not supported by Maven:
> org.apache.logging.slf4j.Log4jLoggerFactory
> [WARN] Maven supported bindings are:
> [WARN] (from
> jar:file:/opt/apache-maven-3.3.9/lib/maven-embedder-3.3.9.jar!/META-INF/maven/slf4j-configuration.properties)
> - ch.qos.logback.classic.LoggerContext
> - org.slf4j.helpers.Log4jLoggerFactory
> - org.slf4j.impl.SimpleLoggerFactory
> {noformat}
> This looks pretty harmless, and I was able to suppress it by manually adding
> the line
> {code}
> org.apache.logging.slf4j.Log4jLoggerFactory
> org.apache.maven.cli.logging.impl.Log4j2Configuration
> {code}
> to {{/META-INF/maven/slf4j-configuration.properties}} in
> {{maven-embedder-3.3.9.jar}}.
> I'm not sure that this is a "correct" solution, and I'm not even confident I
> could explain what effect it has, hence not posting a patch, but somebody
> with more knowledge might be able to triage this better. Or offer an
> "official" way to do colorized output.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Issue Comment Deleted] (MSHADE-195) createSourcesJar with source:jar-no-fork causes sources.jar to be deployed twice, causing the build to fail
[
https://issues.apache.org/jira/browse/MSHADE-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MSHADE-195:
---
Comment: was deleted
(was: I am out of the office between 2016-07-22 and 2016-08-15.
This is an auto reply message sent by my Out of Office Assistance.
We only send and receive email on the basis of the term set out at
www.ericsson.com/email_disclaimer
br,
Christian
)
> createSourcesJar with source:jar-no-fork causes sources.jar to be deployed
> twice, causing the build to fail
> ---
>
> Key: MSHADE-195
> URL: https://issues.apache.org/jira/browse/MSHADE-195
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.3, 2.4
>Reporter: Esko Luontola
>Assignee: Christian Schulte
> Fix For: 2.4.3
>
> Attachments: MSHADE-195-example.zip
>
>
> The workaround described in https://issues.apache.org/jira/browse/MSHADE-120
> (i.e. running maven-source-plugin's jar-no-fork goal before shading) causes
> the problem that Maven will install and deploy the same sources.jar file
> twice:
> {noformat}
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> pricing-client ---
> [INFO] Installing xxx/pricing-client/target/pricing-client-0-SNAPSHOT.jar to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT.jar
> [INFO] Installing xxx/pricing-client/target/dependency-reduced-pom.xml to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT.pom
> [INFO] Installing
> xxx/pricing-client/target/pricing-client-0-SNAPSHOT-sources.jar to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT-sources.jar
> [INFO] Installing
> xxx/pricing-client/target/pricing-client-0-SNAPSHOT-sources.jar to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT-sources.jar
> {noformat}
> With maven-install-plugin this doesn't matter that much, but with
> maven-deploy-plugin it *fails the build*, because it tries to upload the
> sources.jar twice to the Maven repository and _Nexus doesn't allow that_:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on
> project project: Failed to deploy artifacts: Could not transfer artifact
> xxx.availability:availability-client:jar:sources:1.0.24 from/to xxx-releases
> (http://xxx/nexus/content/repositories/releases): Failed to transfer file:
> http://xxx/nexus/content/repositories/releases//availability/availability-client/1.0.24/availability-client-1.0.24-sources.jar.
> Return code is: 400, ReasonPhrase: Bad Request.
> {noformat}
> I'm suspecting this to be something like the maven-source-plugin and
> maven-shade-plugin both attaching the same sources.jar to the build, when
> only one of them should do it. This problem only happens with the sources jar
> and not the main artifact, so a trick similar to replacing the main artifact
> is needed also for the sources jar.
> h4. Workaround
> Configure maven-source-plugin with {{false}}. Then the shade
> plugin will find the sources and include them in the shaded sources jar, but
> the sources jar won't be attached to the build twice.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) does not produce a failure
[
https://issues.apache.org/jira/browse/MNG-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise reopened MNG-5868:
--
Assignee: Karl Heinz Marbaise (was: Christian Schulte)
> Adding serval times the same artifact via MavenProjectHelper (attachArtifact)
> does not produce a failure
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.3
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
> Fix For: 3.5.1
>
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at:
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> MSHADE-195-example ---
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO]
> {noformat}
> Install plugin tries to install two identical artifacts which will work for
> maven-install-plugin but would fail a deploy to repository manager (for
> releases) etc.
> So after diving into the problem i found the following code in maven-core
> (MavenProject.java):
> {code:java}
> /**
> * Add or replace an artifact. This method is now deprecated. Use the
> @{MavenProjectHelper} to attach artifacts to a
> * project. In spite of the 'throws' declaration on this API, this method
> has never thrown an exception since Maven
> * 3.0.x. Historically, it logged and ignored a second addition of the
> same g/a/v/c/t. Now it replaces the file for
> * the artifact, so that plugins (e.g. shade) can change the pathname of
> the file for a particular set of
> * coordinates.
> *
> * @param artifact the artifact to add or replace.
> * @throws DuplicateArtifactAttachmentException
> */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
> * Add an attached artifact or replace the file for an existing artifact.
> *
> * @see
> MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
> * @param project project reference.
> * @param artifact artifact to add or replace.
> */
> public void attachArtifact( MavenProject project, Artifact artifact )
> {
> project.addAttachedArtifact( artifact );
> }
> {code}
> which means that there is not check if an artifacts is already attached.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) does not produce a failure
[
https://issues.apache.org/jira/browse/MNG-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MNG-5868:
-
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
3.5.1
> Adding serval times the same artifact via MavenProjectHelper (attachArtifact)
> does not produce a failure
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.3
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
> Fix For: 3.5.1
>
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at:
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> MSHADE-195-example ---
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO]
> {noformat}
> Install plugin tries to install two identical artifacts which will work for
> maven-install-plugin but would fail a deploy to repository manager (for
> releases) etc.
> So after diving into the problem i found the following code in maven-core
> (MavenProject.java):
> {code:java}
> /**
> * Add or replace an artifact. This method is now deprecated. Use the
> @{MavenProjectHelper} to attach artifacts to a
> * project. In spite of the 'throws' declaration on this API, this method
> has never thrown an exception since Maven
> * 3.0.x. Historically, it logged and ignored a second addition of the
> same g/a/v/c/t. Now it replaces the file for
> * the artifact, so that plugins (e.g. shade) can change the pathname of
> the file for a particular set of
> * coordinates.
> *
> * @param artifact the artifact to add or replace.
> * @throws DuplicateArtifactAttachmentException
> */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
> * Add an attached artifact or replace the file for an existing artifact.
> *
> * @see
> MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
> * @param project project reference.
> * @param artifact artifact to add or replace.
> */
> public void attachArtifact( MavenProject project, Artifact artifact )
> {
> project.addAttachedArtifact( artifact );
> }
> {code}
> which means that there is not check if an artifacts is already attached.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5567) Zip files are not included in classpaths at all
[
https://issues.apache.org/jira/browse/MNG-5567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848143#comment-15848143
]
Joerg Schaible commented on MNG-5567:
-
Still I have major concerns to include this at all. Currently ZIPs are often
used as attached artifacts to transport some additional resources. With this
functionality these artifacts add suddenly all kind of unwanted transitive
dependencies. If you look at Central for ZIP artifacts then you'll have trouble
to find one that is usable as a JAR.
> Zip files are not included in classpaths at all
> ---
>
> Key: MNG-5567
> URL: https://issues.apache.org/jira/browse/MNG-5567
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Pablo La Greca
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.5.1
>
>
> when i added a dependency that was zip file
> eg
> {code:xml}
> hsqldb
> hsqldb
> 1.7.3.0
> provided
> zip
>
> {code}
> this file was not included in the test classpath and so the test would not
> pass
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6037) add gossip slf4j provider support
[ https://issues.apache.org/jira/browse/MNG-6037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848156#comment-15848156 ] Michael Osipov commented on MNG-6037: - Gossip is not necessary anymore, all is done through SLF4J Simple. > add gossip slf4j provider support > - > > Key: MNG-6037 > URL: https://issues.apache.org/jira/browse/MNG-6037 > Project: Maven > Issue Type: New Feature > Components: Logging >Affects Versions: 3.3.9 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: needing-scrub-3.4.0-fallout > > > Gossip slf4j provider: https://github.com/jdillon/gossip > Jason Dillon provided a pull request https://github.com/apache/maven/pull/81 > this implementation adds color to level rendering and error rendering > I removed the message colorization support (that added color by recognizing > patterns in messages) from the logging implementation and implemented it > directly in messages in MNG-3507 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-5600) Dependency management import should support exclusions.
[
https://issues.apache.org/jira/browse/MNG-5600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848161#comment-15848161
]
Michael Osipov commented on MNG-5600:
-
Where is the commit link and the branch for 3.5.1? I am confused.
> Dependency management import should support exclusions.
> ---
>
> Key: MNG-5600
> URL: https://issues.apache.org/jira/browse/MNG-5600
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Radai Rosenblatt
>Assignee: Christian Schulte
> Fix For: 3.5.1-candidate
>
>
> suppose i have a multi-module project that uses spring, and so have this in
> dependency-managements in a parent pom:
> {code:xml}
>
> org.springframework
> spring-framework-bom
> ${org.springframework.version}
> pom
> import
>
> {code}
> spring artifacts (or at least a lot of them) have a dependency on
> commons-logging. right now, if i want to exclude commons-logging i have to
> add an exclusion to every spring dependency in every module of my project,
> which is actually more XML overall than giving up on using the bom dependency
> altogether and listing all spring dependencies with excludes once in the
> parent dependency management.
> I'd like to be able to do this:
> {code:xml}
>
> org.springframework
> spring-framework-bom
> ${org.springframework.version}
> pom
> import
>
>
> commons-logging
> commons-logging
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5567) Zip files are not included in classpaths at all
[
https://issues.apache.org/jira/browse/MNG-5567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848162#comment-15848162
]
Michael Osipov commented on MNG-5567:
-
First of all, how are ZIP files going to have transitive dependencies? We do
not have a {{zip}} packaging yet. ZIP files aren't JAR files, there is no need
to pretend to be usable as a JAR. Both qualify equally on the class path.
> Zip files are not included in classpaths at all
> ---
>
> Key: MNG-5567
> URL: https://issues.apache.org/jira/browse/MNG-5567
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Pablo La Greca
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.5.1
>
>
> when i added a dependency that was zip file
> eg
> {code:xml}
> hsqldb
> hsqldb
> 1.7.3.0
> provided
> zip
>
> {code}
> this file was not included in the test classpath and so the test would not
> pass
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5961) Maven possibly not aware of log4j2
[
https://issues.apache.org/jira/browse/MNG-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848164#comment-15848164
]
Michael Osipov commented on MNG-5961:
-
If you think this is wrong, please create a new issue.
> Maven possibly not aware of log4j2
> --
>
> Key: MNG-5961
> URL: https://issues.apache.org/jira/browse/MNG-5961
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.3.9
>Reporter: Mike Drob
>Assignee: Arnaud HERITIER
> Fix For: 3.5.0
>
>
> Using a fresh install of maven 3.3.9 I followed the steps at
> https://garygregory.wordpress.com/2015/03/23/watch-maven-in-color to add
> color highlighting to my output. Everything works as expected, however on all
> usages I would get the warning:
> {noformat}
> [WARN] The SLF4J binding actually used is not supported by Maven:
> org.apache.logging.slf4j.Log4jLoggerFactory
> [WARN] Maven supported bindings are:
> [WARN] (from
> jar:file:/opt/apache-maven-3.3.9/lib/maven-embedder-3.3.9.jar!/META-INF/maven/slf4j-configuration.properties)
> - ch.qos.logback.classic.LoggerContext
> - org.slf4j.helpers.Log4jLoggerFactory
> - org.slf4j.impl.SimpleLoggerFactory
> {noformat}
> This looks pretty harmless, and I was able to suppress it by manually adding
> the line
> {code}
> org.apache.logging.slf4j.Log4jLoggerFactory
> org.apache.maven.cli.logging.impl.Log4j2Configuration
> {code}
> to {{/META-INF/maven/slf4j-configuration.properties}} in
> {{maven-embedder-3.3.9.jar}}.
> I'm not sure that this is a "correct" solution, and I'm not even confident I
> could explain what effect it has, hence not posting a patch, but somebody
> with more knowledge might be able to triage this better. Or offer an
> "official" way to do colorized output.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5961) Maven possibly not aware of log4j2
[
https://issues.apache.org/jira/browse/MNG-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848169#comment-15848169
]
Arnaud HERITIER commented on MNG-5961:
--
no it's good [~michael-o] it was just to explain why I replaced the entry and I
didn't add a new one (I had the question, thus I prefer to keep a public trace
of it)
> Maven possibly not aware of log4j2
> --
>
> Key: MNG-5961
> URL: https://issues.apache.org/jira/browse/MNG-5961
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.3.9
>Reporter: Mike Drob
>Assignee: Arnaud HERITIER
> Fix For: 3.5.0
>
>
> Using a fresh install of maven 3.3.9 I followed the steps at
> https://garygregory.wordpress.com/2015/03/23/watch-maven-in-color to add
> color highlighting to my output. Everything works as expected, however on all
> usages I would get the warning:
> {noformat}
> [WARN] The SLF4J binding actually used is not supported by Maven:
> org.apache.logging.slf4j.Log4jLoggerFactory
> [WARN] Maven supported bindings are:
> [WARN] (from
> jar:file:/opt/apache-maven-3.3.9/lib/maven-embedder-3.3.9.jar!/META-INF/maven/slf4j-configuration.properties)
> - ch.qos.logback.classic.LoggerContext
> - org.slf4j.helpers.Log4jLoggerFactory
> - org.slf4j.impl.SimpleLoggerFactory
> {noformat}
> This looks pretty harmless, and I was able to suppress it by manually adding
> the line
> {code}
> org.apache.logging.slf4j.Log4jLoggerFactory
> org.apache.maven.cli.logging.impl.Log4j2Configuration
> {code}
> to {{/META-INF/maven/slf4j-configuration.properties}} in
> {{maven-embedder-3.3.9.jar}}.
> I'm not sure that this is a "correct" solution, and I'm not even confident I
> could explain what effect it has, hence not posting a patch, but somebody
> with more knowledge might be able to triage this better. Or offer an
> "official" way to do colorized output.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MSHADE-247) NullpointerException when createSourcesJar = true and source jar cannot be found
Sodasmile created MSHADE-247:
Summary: NullpointerException when createSourcesJar = true and
source jar cannot be found
Key: MSHADE-247
URL: https://issues.apache.org/jira/browse/MSHADE-247
Project: Maven Shade Plugin
Issue Type: Bug
Affects Versions: 3.0.0
Reporter: Sodasmile
Priority: Critical
Configuration as follows:
{code}
org.apache.maven.plugins
maven-shade-plugin
true
package
shade
{code}
Dependency defined as follows:
{code}
javax.jnlp
jnlp-api
1.7.0_06
{code}
Sources for javax.jnlp for some reason disappeared from our maven repo proxy,
which made maven-shade-plugin to output:
{code}
[INFO] Including javax.jnlp:jnlp-api:jar:1.7.0_06 in the shaded jar.
[WARNING] Could not get sources for javax.jnlp:jnlp-api:jar:1.7.0_06:compile
{code}
and in turn:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-shade-plugin:3.0.0:shade (default) on project
x: Execution default of goal
org.apache.maven.plugins:maven-shade-plugin:3.0.0:shade failed.
NullPointerException -> [Help 1]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MSHADE-247) NullpointerException when createSourcesJar = true and source jar cannot be found
[
https://issues.apache.org/jira/browse/MSHADE-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sodasmile updated MSHADE-247:
-
Attachment:
Resolving_nullpointer_exception_when_resolvedArtifact_is_null_.patch
Patch to resolve nullpointer problem
> NullpointerException when createSourcesJar = true and source jar cannot be
> found
> -
>
> Key: MSHADE-247
> URL: https://issues.apache.org/jira/browse/MSHADE-247
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Sodasmile
>Priority: Critical
> Attachments:
> Resolving_nullpointer_exception_when_resolvedArtifact_is_null_.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Configuration as follows:
> {code}
>
> org.apache.maven.plugins
> maven-shade-plugin
>
> true
>
>
>
> package
>
> shade
>
>
>
>
> {code}
> Dependency defined as follows:
> {code}
>
> javax.jnlp
> jnlp-api
> 1.7.0_06
>
> {code}
> Sources for javax.jnlp for some reason disappeared from our maven repo proxy,
> which made maven-shade-plugin to output:
> {code}
> [INFO] Including javax.jnlp:jnlp-api:jar:1.7.0_06 in the shaded jar.
> [WARNING] Could not get sources for javax.jnlp:jnlp-api:jar:1.7.0_06:compile
> {code}
> and in turn:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-shade-plugin:3.0.0:shade (default) on project
> x: Execution default of goal
> org.apache.maven.plugins:maven-shade-plugin:3.0.0:shade failed.
> NullPointerException -> [Help 1]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5567) Zip files are not included in classpaths at all
[
https://issues.apache.org/jira/browse/MNG-5567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848221#comment-15848221
]
Grzegorz Slowikowski commented on MNG-5567:
---
As Joerg writes, zip files are often used for non-classpath resources. I'd like
to describe my case.
My Maven plugin for Play! Framework 1.x requires zip dependency in project (not
plugin) dependencies containing the resources which must be extracted and
accessed as *files* later during the build cycle. Check
'com.google.code.maven-play-plugin.org.playframework:play:1.4.3:framework:zip'
as an example. It has over 20MB and should not be present on the classpath.
Plugin finds dependency with 'framework' classifier and 'zip' extension,
extracts it, and doesn't expect it to be in the classpath.
Since zip files were newer added to classpath, so the scope of such dependency
wasn't important. If declared without a scope (using default 'compile' scope)
it will be available in runtime (for example, added to war files).
I cannot predict, how it will influence user projects using my plugin.
BTW
The original issue was about hsql zip-type dependency. There is no such
dependency, check http://repo1.maven.org/maven2/hsqldb/hsqldb/1.7.3.0/
> Zip files are not included in classpaths at all
> ---
>
> Key: MNG-5567
> URL: https://issues.apache.org/jira/browse/MNG-5567
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Pablo La Greca
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.5.1
>
>
> when i added a dependency that was zip file
> eg
> {code:xml}
> hsqldb
> hsqldb
> 1.7.3.0
> provided
> zip
>
> {code}
> this file was not included in the test classpath and so the test would not
> pass
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5567) Zip files are not included in classpaths at all
[
https://issues.apache.org/jira/browse/MNG-5567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848251#comment-15848251
]
Michael Osipov commented on MNG-5567:
-
In your case, you can tell the Maven Dependency Plugin to download your ZIP
file and extract it, not from dependency tree, you can also set scope to
{{provided}}, of course. For you, ZIP files shouldn't be on the classpath, for
others they should because it is standard behavior. You can always exclude such
a dep, but not the other way unless this is fixed.
What is your proposal to fix this issue, make is compliant with the docs of
{{java(1)}}? I have abused JARs for bundle CSS/JS files just because ZIP
packaging isn't available. This is overdesigned too.
It does not really matter wether the HSQLDB dep exists, the matter was the
missing ZIP file on cp.
> Zip files are not included in classpaths at all
> ---
>
> Key: MNG-5567
> URL: https://issues.apache.org/jira/browse/MNG-5567
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Pablo La Greca
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.5.1
>
>
> when i added a dependency that was zip file
> eg
> {code:xml}
> hsqldb
> hsqldb
> 1.7.3.0
> provided
> zip
>
> {code}
> this file was not included in the test classpath and so the test would not
> pass
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5567) Zip files are not included in classpaths at all
[
https://issues.apache.org/jira/browse/MNG-5567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848309#comment-15848309
]
Grzegorz Slowikowski commented on MNG-5567:
---
I'm plugin developer, not user. Zip finding and processing logic is in my
plugin. I would have to change my plugin and instruct all plugin users to
upgrade and remove all zip dependencies from their project files or at least to
change scope to `provided`. All this just because Maven decides to break
backward compatibility.
I know that jars can contain sources, javadocs, etc. They were always added to
classpaths (and e.g. Maven GWT Plugin even requires jars with sources to be
added to dependencies because GWT will need then on the classpath) so all users
and developers know about it.
Zip format is very uncommon in Java world and some (including me) used it on
purpose to package non-classpath Maven dependencies.
My proposal is to not change current behavior. I don't see any really important
reason to do this. Backward compatibility is more important than compliance
with Java technical notes (after so many years of not being compliant) IMO.
> Zip files are not included in classpaths at all
> ---
>
> Key: MNG-5567
> URL: https://issues.apache.org/jira/browse/MNG-5567
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Pablo La Greca
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.5.1
>
>
> when i added a dependency that was zip file
> eg
> {code:xml}
> hsqldb
> hsqldb
> 1.7.3.0
> provided
> zip
>
> {code}
> this file was not included in the test classpath and so the test would not
> pass
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1216) TEST-*.xml files generated by Surefire are invalid
[
https://issues.apache.org/jira/browse/SUREFIRE-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848331#comment-15848331
]
ASF GitHub Bot commented on SUREFIRE-1216:
--
Github user jonenst commented on the issue:
https://github.com/apache/maven-surefire/pull/110
Hi @Tibor17
"54 of 55 issues have been resolved" on the roadmap, when can we expect a
release ...?
Is there something I can do to help with the release ?
Cheers,
Jon
> TEST-*.xml files generated by Surefire are invalid
> --
>
> Key: SUREFIRE-1216
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1216
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Mirko Friedenhagen
>Assignee: Mirko Friedenhagen
> Fix For: 2.19.2
>
>
> See SUREFIRE-964 as well. The XML produced is invalid because
> {{schemaLocation}} *must* include two URIs, as outlined in
> [xmlschema-1|http://www.w3.org/TR/xmlschema-1/#schema-loc].
> Because of this, the Xerces parser fails in the Jenkins XUnit plugin and e.g.
> IntelliJ is not able to parse the file correctly.
> Suggested solution is to replace {{xsi:schemaLocation}} by
> {{xsi:noNamespaceSchemaLocation}}, which fixes this for the Unit plugin as
> well the file is parseable by IntelliJ.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5567) Zip files are not included in classpaths at all
[
https://issues.apache.org/jira/browse/MNG-5567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848342#comment-15848342
]
Michael Osipov commented on MNG-5567:
-
Which version do you expect this to be in? 3.6? 4.0?
> Zip files are not included in classpaths at all
> ---
>
> Key: MNG-5567
> URL: https://issues.apache.org/jira/browse/MNG-5567
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Pablo La Greca
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.5.1
>
>
> when i added a dependency that was zip file
> eg
> {code:xml}
> hsqldb
> hsqldb
> 1.7.3.0
> provided
> zip
>
> {code}
> this file was not included in the test classpath and so the test would not
> pass
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MDEP-552) Change characters used to diplay trees to make relationships clearer
Keir created MDEP-552: - Summary: Change characters used to diplay trees to make relationships clearer Key: MDEP-552 URL: https://issues.apache.org/jira/browse/MDEP-552 Project: Maven Dependency Plugin Issue Type: Improvement Components: tree Reporter: Keir NPM for example uses characters such as: ├── foo │ ├── bar │ └── baz I feel these characters make it much clearer then there is a large tree on screen what is related to what. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-5961) Maven possibly not aware of log4j2
[
https://issues.apache.org/jira/browse/MNG-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848566#comment-15848566
]
ASF GitHub Bot commented on MNG-5961:
-
Github user stephenc commented on the issue:
https://github.com/apache/maven/pull/104
> we don't have a CI validation here
Yep waiting to get SCM API 2.0.x back into the uc and then pester infra to
upgrade
> Maven possibly not aware of log4j2
> --
>
> Key: MNG-5961
> URL: https://issues.apache.org/jira/browse/MNG-5961
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.3.9
>Reporter: Mike Drob
>Assignee: Arnaud HERITIER
> Fix For: 3.5.0
>
>
> Using a fresh install of maven 3.3.9 I followed the steps at
> https://garygregory.wordpress.com/2015/03/23/watch-maven-in-color to add
> color highlighting to my output. Everything works as expected, however on all
> usages I would get the warning:
> {noformat}
> [WARN] The SLF4J binding actually used is not supported by Maven:
> org.apache.logging.slf4j.Log4jLoggerFactory
> [WARN] Maven supported bindings are:
> [WARN] (from
> jar:file:/opt/apache-maven-3.3.9/lib/maven-embedder-3.3.9.jar!/META-INF/maven/slf4j-configuration.properties)
> - ch.qos.logback.classic.LoggerContext
> - org.slf4j.helpers.Log4jLoggerFactory
> - org.slf4j.impl.SimpleLoggerFactory
> {noformat}
> This looks pretty harmless, and I was able to suppress it by manually adding
> the line
> {code}
> org.apache.logging.slf4j.Log4jLoggerFactory
> org.apache.maven.cli.logging.impl.Log4j2Configuration
> {code}
> to {{/META-INF/maven/slf4j-configuration.properties}} in
> {{maven-embedder-3.3.9.jar}}.
> I'm not sure that this is a "correct" solution, and I'm not even confident I
> could explain what effect it has, hence not posting a patch, but somebody
> with more knowledge might be able to triage this better. Or offer an
> "official" way to do colorized output.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MRELEASE-979) Allow VersionPolicies to manage Branch and Tag names
[ https://issues.apache.org/jira/browse/MRELEASE-979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848599#comment-15848599 ] Henning Schmiedehausen commented on MRELEASE-979: - pretty ping? :-) [~rfscholte] is the second implementation (pull #12) along what you were thinking? I would love to get this in before a 3.0.0 release; this change makes it possible for us to codify our branch and tag strategy in code and use this across the organization. > Allow VersionPolicies to manage Branch and Tag names > > > Key: MRELEASE-979 > URL: https://issues.apache.org/jira/browse/MRELEASE-979 > Project: Maven Release Plugin > Issue Type: Improvement > Components: branch, prepare, update-versions >Affects Versions: 2.5.3 >Reporter: Henning Schmiedehausen > Fix For: 3.0.0 > > > The newly introduced VersionPolicy facility allows managing the development > and release versions of projects when releasing, branching and updating > versions. > Most organizations will also have a policy around how branches and tags are > named (which often have to match specific versioning patterns). The current > VersionPolicy implementations do not allow this but it should be possible. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6135) Maven plugins and core extensions are not dependencies, they should be resolved the same way as projects.
[
https://issues.apache.org/jira/browse/MNG-6135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848675#comment-15848675
]
Michael Osipov commented on MNG-6135:
-
Why is this fixed, where is the commit link?
> Maven plugins and core extensions are not dependencies, they should be
> resolved the same way as projects.
> -
>
> Key: MNG-6135
> URL: https://issues.apache.org/jira/browse/MNG-6135
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Critical
> Fix For: 3.6.0-candidate
>
>
> Due to a bug in the Maven resolver, plugin and core extensions were resolved
> incorrectly: the direct {{test}} and {{provided}} dependencies were ignored.
> Ironically, this fix breaks some plugins because direct {{test}} dependencies
> now take precedence over transitive {{compile}} one: see MNG-5739
> (we know only one case where {{provided}} case has an impact: MPLUGIN-296,
> and in this only case, the new behaviour is more consistent than the previous)
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5567) Zip files are not included in classpaths at all
[
https://issues.apache.org/jira/browse/MNG-5567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848793#comment-15848793
]
Joerg Schaible commented on MNG-5567:
-
bq. First of all, how are ZIP files going to have transitive dependencies? We
do not have a zip packaging yet.
It is quite common to create attached ZIP files with the assembly plugin. An
attached artifact shares the same transitive dependencies than the main
artifact. How often I wished that could be stopped for EJB clients ;-)
> Zip files are not included in classpaths at all
> ---
>
> Key: MNG-5567
> URL: https://issues.apache.org/jira/browse/MNG-5567
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Pablo La Greca
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.5.1
>
>
> when i added a dependency that was zip file
> eg
> {code:xml}
> hsqldb
> hsqldb
> 1.7.3.0
> provided
> zip
>
> {code}
> this file was not included in the test classpath and so the test would not
> pass
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5567) Zip files are not included in classpaths at all
[
https://issues.apache.org/jira/browse/MNG-5567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848801#comment-15848801
]
Michael Osipov commented on MNG-5567:
-
The you are looking for MNG-1683. This issue should likely to tied to it.
> Zip files are not included in classpaths at all
> ---
>
> Key: MNG-5567
> URL: https://issues.apache.org/jira/browse/MNG-5567
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Pablo La Greca
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.5.1
>
>
> when i added a dependency that was zip file
> eg
> {code:xml}
> hsqldb
> hsqldb
> 1.7.3.0
> provided
> zip
>
> {code}
> this file was not included in the test classpath and so the test would not
> pass
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5567) Zip files are not included in classpaths at all
[
https://issues.apache.org/jira/browse/MNG-5567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848811#comment-15848811
]
Joerg Schaible commented on MNG-5567:
-
For me those two issues are not related apart from the fact that both address
ZIP files. If I add a dependency of type zip it does not matter if the
dependency is a main artifact or addressed with a classifier. I am in both
cases affected if ZIP artifacts suddenly provide transitive dependencies.
> Zip files are not included in classpaths at all
> ---
>
> Key: MNG-5567
> URL: https://issues.apache.org/jira/browse/MNG-5567
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Pablo La Greca
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.5.1
>
>
> when i added a dependency that was zip file
> eg
> {code:xml}
> hsqldb
> hsqldb
> 1.7.3.0
> provided
> zip
>
> {code}
> this file was not included in the test classpath and so the test would not
> pass
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (MNG-5567) Zip files are not included in classpaths at all
[
https://issues.apache.org/jira/browse/MNG-5567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848801#comment-15848801
]
Michael Osipov edited comment on MNG-5567 at 2/1/17 7:18 PM:
-
Then you are looking for MNG-1683. This issue should likely to tied to it.
was (Author: michael-o):
The you are looking for MNG-1683. This issue should likely to tied to it.
> Zip files are not included in classpaths at all
> ---
>
> Key: MNG-5567
> URL: https://issues.apache.org/jira/browse/MNG-5567
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Pablo La Greca
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.5.1
>
>
> when i added a dependency that was zip file
> eg
> {code:xml}
> hsqldb
> hsqldb
> 1.7.3.0
> provided
> zip
>
> {code}
> this file was not included in the test classpath and so the test would not
> pass
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5567) Zip files are not included in classpaths at all
[
https://issues.apache.org/jira/browse/MNG-5567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848818#comment-15848818
]
Michael Osipov commented on MNG-5567:
-
They are because with a main zip packaging file you are in full control of your
dependency list, with an attached artifact, you aren't.
> Zip files are not included in classpaths at all
> ---
>
> Key: MNG-5567
> URL: https://issues.apache.org/jira/browse/MNG-5567
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Pablo La Greca
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.5.1
>
>
> when i added a dependency that was zip file
> eg
> {code:xml}
> hsqldb
> hsqldb
> 1.7.3.0
> provided
> zip
>
> {code}
> this file was not included in the test classpath and so the test would not
> pass
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (MNG-5567) Zip files are not included in classpaths at all
[
https://issues.apache.org/jira/browse/MNG-5567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848818#comment-15848818
]
Michael Osipov edited comment on MNG-5567 at 2/1/17 7:21 PM:
-
They are because with a main zip packaging file you are in full control of your
dependency list, with an attached artifact you aren't.
was (Author: michael-o):
They are because with a main zip packaging file you are in full control of your
dependency list, with an attached artifact, you aren't.
> Zip files are not included in classpaths at all
> ---
>
> Key: MNG-5567
> URL: https://issues.apache.org/jira/browse/MNG-5567
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Pablo La Greca
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.5.1
>
>
> when i added a dependency that was zip file
> eg
> {code:xml}
> hsqldb
> hsqldb
> 1.7.3.0
> provided
> zip
>
> {code}
> this file was not included in the test classpath and so the test would not
> pass
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MCHECKSTYLE-333) Intermittent NPE on checkstyle:check
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848837#comment-15848837
]
James Short commented on MCHECKSTYLE-333:
-
I would say that users of the maven checkstyle plugin will frequently have an
IDE open and pointing to a git repository and then run a build/analysis from
the command line. Users would expect that this would *not* cause intermittent
failures in the checkstyle:check goal.
> Intermittent NPE on checkstyle:check
>
>
> Key: MCHECKSTYLE-333
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-333
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.17
> Environment: OSX El Captain, java 8, maven 3.x, checkstyle 6.19
>Reporter: James Short
>
> I generally run checkstyle:check manually but I wanted to integrate it into
> the validate phase of my root build.
> After doing this, it will intermittent fail with an NPE:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check (checkstyle) on
> project dropwizard-api: Execution checkstyle of goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check (checkstyle)
> on project dropwizard-api: Execution checkstyle of goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> checkstyle of goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> ... 20 more
> Caused by: java.lang.NullPointerException
> at java.util.zip.ZipFile.getZipEntry(ZipFile.java:566)
> at java.util.zip.ZipFile.access$900(ZipFile.java:60)
> at java.util.zip.ZipFile$ZipEntryIterator.next(ZipFile.java:524)
> at java.util.zip.ZipFile$ZipEntryIterator.nextElement(ZipFile.java:499)
> at java.util.zip.ZipFile$ZipEntryIterator.nextElement(ZipFile.java:480)
> at java.util.jar.JarFile$JarEntryIterator.next(JarFile.java:257)
> at java.util.jar.JarFile$JarEntryIterator.nextElement(JarFile.java:266)
> at java.util.jar.JarFile$JarEntryIterator.nextElement(JarFile.java:247)
> at
> org.codehaus.plexus.resource.loader.JarHolder.getEntries(JarHolder.java:132)
> at
> org.codehaus.plexus.resource.loader.JarResourceLoader.loadJar(JarResourceLoader.java:100)
> at
> org.codehaus.plexus.resource.loader.JarResourceLoader.initialize(JarResourceLoader.java:63)
> at
> org.codehaus.plexus.resource.loader.JarResourceLoader.getResource(JarResourceLoader.jav
[jira] [Commented] (MRELEASE-979) Allow VersionPolicies to manage Branch and Tag names
[ https://issues.apache.org/jira/browse/MRELEASE-979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848846#comment-15848846 ] Robert Scholte commented on MRELEASE-979: - This is getting better. However, the calculation of the name is still done outside of the policy, that's not what I would expect. Instead the request should at least have the artifactId and version, the result of the DefaultNamingPolicy would be artifactId-version. And it shouldn't matter for the policy if it is a branch or not. > Allow VersionPolicies to manage Branch and Tag names > > > Key: MRELEASE-979 > URL: https://issues.apache.org/jira/browse/MRELEASE-979 > Project: Maven Release Plugin > Issue Type: Improvement > Components: branch, prepare, update-versions >Affects Versions: 2.5.3 >Reporter: Henning Schmiedehausen > Fix For: 3.0.0 > > > The newly introduced VersionPolicy facility allows managing the development > and release versions of projects when releasing, branching and updating > versions. > Most organizations will also have a policy around how branches and tags are > named (which often have to match specific versioning patterns). The current > VersionPolicy implementations do not allow this but it should be possible. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1216) TEST-*.xml files generated by Surefire are invalid
[
https://issues.apache.org/jira/browse/SUREFIRE-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848855#comment-15848855
]
ASF GitHub Bot commented on SUREFIRE-1216:
--
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/110
@jonenst
I was about to finish the last one and suddenly we had internal collision
and now we reverted 11 commits. I am going to fix them but the procedure will
be that we have to create branch for each cherry pick, make code review and
then merge with master. I don't want to blame anyone in ASF so I will rather
work now and make you happy.
> TEST-*.xml files generated by Surefire are invalid
> --
>
> Key: SUREFIRE-1216
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1216
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Mirko Friedenhagen
>Assignee: Mirko Friedenhagen
> Fix For: 2.19.2
>
>
> See SUREFIRE-964 as well. The XML produced is invalid because
> {{schemaLocation}} *must* include two URIs, as outlined in
> [xmlschema-1|http://www.w3.org/TR/xmlschema-1/#schema-loc].
> Because of this, the Xerces parser fails in the Jenkins XUnit plugin and e.g.
> IntelliJ is not able to parse the file correctly.
> Suggested solution is to replace {{xsi:schemaLocation}} by
> {{xsi:noNamespaceSchemaLocation}}, which fixes this for the Unit plugin as
> well the file is parseable by IntelliJ.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MCHECKSTYLE-333) Intermittent NPE on checkstyle:check
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848866#comment-15848866
]
Robert Scholte commented on MCHECKSTYLE-333:
Did you try to contact IntelliJ? They should be able to provide an answer and
maybe come with a solution, either on their side or our side.
> Intermittent NPE on checkstyle:check
>
>
> Key: MCHECKSTYLE-333
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-333
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.17
> Environment: OSX El Captain, java 8, maven 3.x, checkstyle 6.19
>Reporter: James Short
>
> I generally run checkstyle:check manually but I wanted to integrate it into
> the validate phase of my root build.
> After doing this, it will intermittent fail with an NPE:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check (checkstyle) on
> project dropwizard-api: Execution checkstyle of goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check (checkstyle)
> on project dropwizard-api: Execution checkstyle of goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> checkstyle of goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> ... 20 more
> Caused by: java.lang.NullPointerException
> at java.util.zip.ZipFile.getZipEntry(ZipFile.java:566)
> at java.util.zip.ZipFile.access$900(ZipFile.java:60)
> at java.util.zip.ZipFile$ZipEntryIterator.next(ZipFile.java:524)
> at java.util.zip.ZipFile$ZipEntryIterator.nextElement(ZipFile.java:499)
> at java.util.zip.ZipFile$ZipEntryIterator.nextElement(ZipFile.java:480)
> at java.util.jar.JarFile$JarEntryIterator.next(JarFile.java:257)
> at java.util.jar.JarFile$JarEntryIterator.nextElement(JarFile.java:266)
> at java.util.jar.JarFile$JarEntryIterator.nextElement(JarFile.java:247)
> at
> org.codehaus.plexus.resource.loader.JarHolder.getEntries(JarHolder.java:132)
> at
> org.codehaus.plexus.resource.loader.JarResourceLoader.loadJar(JarResourceLoader.java:100)
> at
> org.codehaus.plexus.resource.loader.JarResourceLoader.initialize(JarResourceLoader.java:63)
> at
> org.codehaus.plexus.resource.loader.JarResourceLoader.getResource(JarResourceLoader.java:141)
> at
> org.apache.maven.plugin.checkstyle.resource.LicenseResourceManager.getResource(LicenseResourceManager.java:
[jira] [Commented] (MNG-5981) Plexus lifecycle could be activated too late during overlapping parallel requests
[
https://issues.apache.org/jira/browse/MNG-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848894#comment-15848894
]
Hudson commented on MNG-5981:
-
SUCCESS: Integrated in Jenkins build maven-3.x #1537 (See
[https://builds.apache.org/job/maven-3.x/1537/])
[MNG-5981] upgrade Sisu to 0.3.3 to pick up lifecycle fix (schulte:
[http://git-wip-us.apache.org/repos/asf/?p=maven.git&a=commit&h=bd57ec9666531fa2e32b8fd1aa68b85ac86f7790])
* (edit) pom.xml
> Plexus lifecycle could be activated too late during overlapping parallel
> requests
> -
>
> Key: MNG-5981
> URL: https://issues.apache.org/jira/browse/MNG-5981
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.3.1, 3.3.3, 3.3.9
>Reporter: Stuart McCulloch
>Assignee: Christian Schulte
> Fix For: needing-scrub-3.4.0-fallout
>
>
> A user reported seeing NPEs when running a particular project in parallel:
> http://www.mail-archive.com/users%40felix.apache.org/msg17072.html
> This was tracked down to the way we defer lifecycle activation for components
> (potentially) involved in dependency injection cycles (A->B->A). This bug is
> only triggered by specific lookup sequences when running parallel builds.
> The key fix was to move when we start cycle detection to the first scoped
> component in the lookup: https://bugs.eclipse.org/bugs/show_bug.cgi?id=487090
> (since a cycle can only ever involve scoped components - unscoped/per-lookup
> components can never repeat)
> The accuracy was also improved by using {{Scopes.isCircularProxy}} to spot
> when we inject a circular dependency proxy (which is when when we need to
> defer activation until the end of the cycle to allow that proxy to be
> populated). Previously the code was overly pessimistic when considering what
> might end up as a cycle.
> Sisu 0.3.3 contains both these fixes:
> https://wiki.eclipse.org/Sisu/Changelog#Release_0.3.3
> Previous releases can be patched by replacing the old org.eclipse.sisu.inject
> and org.eclipse.sisu.plexus jars with the ones from the 0.3.3 release.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5567) Zip files are not included in classpaths at all
[
https://issues.apache.org/jira/browse/MNG-5567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15849018#comment-15849018
]
Joerg Schaible commented on MNG-5567:
-
OK, that makes sense. However, it does not help for the attached artifacts.
IMHO it is quite common to pack stuff like additional SQL files, WSDLs and
their schema files, etc. into an attached ZIP for later use. It would be quite
surprising if Maven changes behaviour for these kind of artifacts.
> Zip files are not included in classpaths at all
> ---
>
> Key: MNG-5567
> URL: https://issues.apache.org/jira/browse/MNG-5567
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Pablo La Greca
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.5.1
>
>
> when i added a dependency that was zip file
> eg
> {code:xml}
> hsqldb
> hsqldb
> 1.7.3.0
> provided
> zip
>
> {code}
> this file was not included in the test classpath and so the test would not
> pass
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1216) TEST-*.xml files generated by Surefire are invalid
[
https://issues.apache.org/jira/browse/SUREFIRE-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15849090#comment-15849090
]
ASF GitHub Bot commented on SUREFIRE-1216:
--
Github user jonenst commented on the issue:
https://github.com/apache/maven-surefire/pull/110
@Tibor17 thanks for sharing. Your work is much appreciated. I hope
everything works out with this person.
> TEST-*.xml files generated by Surefire are invalid
> --
>
> Key: SUREFIRE-1216
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1216
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Mirko Friedenhagen
>Assignee: Mirko Friedenhagen
> Fix For: 2.19.2
>
>
> See SUREFIRE-964 as well. The XML produced is invalid because
> {{schemaLocation}} *must* include two URIs, as outlined in
> [xmlschema-1|http://www.w3.org/TR/xmlschema-1/#schema-loc].
> Because of this, the Xerces parser fails in the Jenkins XUnit plugin and e.g.
> IntelliJ is not able to parse the file correctly.
> Suggested solution is to replace {{xsi:schemaLocation}} by
> {{xsi:noNamespaceSchemaLocation}}, which fixes this for the Unit plugin as
> well the file is parseable by IntelliJ.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6135) Maven plugins and core extensions are not dependencies, they should be resolved the same way as projects.
[
https://issues.apache.org/jira/browse/MNG-6135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15849302#comment-15849302
]
Christian Schulte commented on MNG-6135:
See [this
thread|http://www.mail-archive.com/dev@maven.apache.org/msg112480.html] on
dev@. Issue is resolved, not closed.
> Maven plugins and core extensions are not dependencies, they should be
> resolved the same way as projects.
> -
>
> Key: MNG-6135
> URL: https://issues.apache.org/jira/browse/MNG-6135
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Critical
> Fix For: 3.6.0-candidate
>
>
> Due to a bug in the Maven resolver, plugin and core extensions were resolved
> incorrectly: the direct {{test}} and {{provided}} dependencies were ignored.
> Ironically, this fix breaks some plugins because direct {{test}} dependencies
> now take precedence over transitive {{compile}} one: see MNG-5739
> (we know only one case where {{provided}} case has an impact: MPLUGIN-296,
> and in this only case, the new behaviour is more consistent than the previous)
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5600) Dependency management import should support exclusions.
[
https://issues.apache.org/jira/browse/MNG-5600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15849304#comment-15849304
]
Christian Schulte commented on MNG-5600:
See [this
thread|http://www.mail-archive.com/dev@maven.apache.org/msg112480.html] on
dev@. Issue is resolved, not closed.
> Dependency management import should support exclusions.
> ---
>
> Key: MNG-5600
> URL: https://issues.apache.org/jira/browse/MNG-5600
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Radai Rosenblatt
>Assignee: Christian Schulte
> Fix For: 3.5.1-candidate
>
>
> suppose i have a multi-module project that uses spring, and so have this in
> dependency-managements in a parent pom:
> {code:xml}
>
> org.springframework
> spring-framework-bom
> ${org.springframework.version}
> pom
> import
>
> {code}
> spring artifacts (or at least a lot of them) have a dependency on
> commons-logging. right now, if i want to exclude commons-logging i have to
> add an exclusion to every spring dependency in every module of my project,
> which is actually more XML overall than giving up on using the bom dependency
> altogether and listing all spring dependencies with excludes once in the
> parent dependency management.
> I'd like to be able to do this:
> {code:xml}
>
> org.springframework
> spring-framework-bom
> ${org.springframework.version}
> pom
> import
>
>
> commons-logging
> commons-logging
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
