[jira] [Updated] (MNG-6506) Mojos are unable to load package annotations on Java >= 9
[
https://issues.apache.org/jira/browse/MNG-6506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MNG-6506:
---
Description:
On Java 9 and above, calls to {{java.lang.Package.getAnnotation(Class)}} from
within a Mojo always return {{null}} (unless the {{package-info}} class has
been loaded by some other means before).
The reason appears to be an incompatibility between Java 9 and Plexus
Classworlds:
* Java 9 ultimately calls {{findClass}} (instead of {{loadClass}}) to get the
{{package-info}} class.
* The {{findClass}} implementation in {{ClassRealm}} always throws
{{ClassNotFoundException}}:
https://github.com/codehaus-plexus/plexus-classworlds/blob/master/src/main/java/org/codehaus/plexus/classworlds/realm/ClassRealm.java#L275.
This in particular affects plugins that interact with the JAXB API because it
relies on package annotations.
A workaround is to preload the required {{package-info}} classes using
{{loadClass}}; see e.g. http://svn.apache.org/viewvc?rev=1845026=rev.
was:
On Java 9 and above, calls to {{java.lang.Package.getAnnotation(Class)}} from
within a Mojo always return {{null}} (unless the {{package-info}} class has
been loaded by some other means before).
The reason appears to be an incompatibility between Java 9 and Plexus
Classworlds:
* Java 9 ultimately calls {{findClass}} (instead of {{loadClass}}) to get the
{{package-info}} class.
* The {{findClass}} implementation in {{ClassRealm}} always throws
{{ClassNotFoundException}}:
https://github.com/codehaus-plexus/plexus-classworlds/blob/master/src/main/java/org/codehaus/plexus/classworlds/realm/ClassRealm.java#L275.
This in particular affects plugins that interact with the JAXB API because it
relies on package annotations. A workaround is to preload the required
{{package-info}} classes using {{loadClass}}; see e.g.
http://svn.apache.org/viewvc?rev=1845026=rev.
> Mojos are unable to load package annotations on Java >= 9
> -
>
> Key: MNG-6506
> URL: https://issues.apache.org/jira/browse/MNG-6506
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.6.0
>Reporter: Andreas Veithen
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.6.1
>
>
> On Java 9 and above, calls to {{java.lang.Package.getAnnotation(Class)}} from
> within a Mojo always return {{null}} (unless the {{package-info}} class has
> been loaded by some other means before).
> The reason appears to be an incompatibility between Java 9 and Plexus
> Classworlds:
> * Java 9 ultimately calls {{findClass}} (instead of {{loadClass}}) to get the
> {{package-info}} class.
> * The {{findClass}} implementation in {{ClassRealm}} always throws
> {{ClassNotFoundException}}:
> https://github.com/codehaus-plexus/plexus-classworlds/blob/master/src/main/java/org/codehaus/plexus/classworlds/realm/ClassRealm.java#L275.
> This in particular affects plugins that interact with the JAXB API because it
> relies on package annotations.
> A workaround is to preload the required {{package-info}} classes using
> {{loadClass}}; see e.g. http://svn.apache.org/viewvc?rev=1845026=rev.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6543) Upgrade plexus classworld to support java 9+ ClassLoader.findClass(String moduleName, String name) in Mojos
[ https://issues.apache.org/jira/browse/MNG-6543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734783#comment-16734783 ] Hervé Boutemy commented on MNG-6543: oh yes, MNG-6506 is exactly what I was looking for: thanks Andreas!!! [~slachiewicz] any chance to integrate the demo into core IT? > Upgrade plexus classworld to support java 9+ ClassLoader.findClass(String > moduleName, String name) in Mojos > --- > > Key: MNG-6543 > URL: https://issues.apache.org/jira/browse/MNG-6543 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.6.0 >Reporter: Romain Manni-Bucau >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 3.6.1 > > Attachments: MNG-6543-xjc.zip > > > Goal is to include > https://github.com/codehaus-plexus/plexus-classworlds/pull/4 in Maven and > enable Mojos using this Java 9 new JPMS API to work under java 9+ > see [Java 9 ClassLoader.findClass(String moduleName,String > name)|https://docs.oracle.com/javase/9/docs/api/java/lang/ClassLoader.html#findClass-java.lang.String-java.lang.String-] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MJAVADOC-561) Not possible to link to JDK classes since Java 11
[
https://issues.apache.org/jira/browse/MJAVADOC-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16733751#comment-16733751
]
Gili edited comment on MJAVADOC-561 at 1/5/19 2:46 AM:
---
Okay, now we've got a problem. Although JDK 12 contains a fix, it cannot be
used for maven plugins (which just so happens to affect my use-case).
* If you invoke {{javadoc:jar}} on a maven plugin that depends on named
modules (ones with *module-info.java*) it will fail because of
[https://bugs.openjdk.java.net/browse/JDK-8212233]
* Per MPLUGIN-341 maven plugins cannot contain *module-info.java*.
OpenJDK 11 will not receive any "stability updates" per Oracle policy and
OpenJDK 12+ won't support mixing modules and non-modules. So (unless I missed
something) the only solution is very far away (not even planned for
implementation): MPLUGIN-341
I filed MJAVADOC-562 thinking that passing in *\-source 11* or *--release 11*
might help (the JDK bug report hinted as much), but it did not make a
difference.
was (Author: cowwoc):
Okay, now we've got a problem. Although JDK 12 contains a fix, it cannot be
used for maven plugins (which just so happens to affect my use-case).
* If you invoke {{javadoc:jar}} on a maven plugin that depends on named
modules (ones with *module-info.java*) it will fail because of
[https://bugs.openjdk.java.net/browse/JDK-8212233]
* Per MPLUGIN-341 maven plugins cannot contain *module-info.java*.
OpenJDK 11 will not receive any "stability updates" per Oracle policy and
OpenJDK 12+ won't support mixing modules and non-modules. So (unless I missed
something) the only solution is very far away (not even planned for
implementation): MPLUGIN-341
I filed MJAVADOC-562 thinking that passing in *-source 11* or *--release 11*
might help (the JDK bug report hinted as much), but it did not make a
difference.
> Not possible to link to JDK classes since Java 11
> -
>
> Key: MJAVADOC-561
> URL: https://issues.apache.org/jira/browse/MJAVADOC-561
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.1.0
>Reporter: Gili
>Assignee: Michael Osipov
>Priority: Critical
> Attachments: testcase.zip
>
>
> 1. Open testcase
> 2. {{mvn javadoc:jar}}
> 3. Notice that generated Javadoc contains broken link to {{java.lang.Number}}
> It doesn't look like one can link to the JDK as of version 11 because the URL
> structure changed since Java 10.
> Java 10: https://docs.oracle.com/javase/10/docs/api/java/lang/Number.html
> Java 11:
> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Number.html
> Please see https://bugs.openjdk.java.net/browse/JDK-8191363 for a related
> discussion. If any syntax change is required in the pom, please consider
> updating
> https://maven.apache.org/plugins/maven-javadoc-plugin/examples/links-configuration.html
> accordingly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MJAVADOC-561) Not possible to link to JDK classes since Java 11
[
https://issues.apache.org/jira/browse/MJAVADOC-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16733751#comment-16733751
]
Gili edited comment on MJAVADOC-561 at 1/5/19 2:45 AM:
---
Okay, now we've got a problem. Although JDK 12 contains a fix, it cannot be
used for maven plugins (which just so happens to affect my use-case).
* If you invoke {{javadoc:jar}} on a maven plugin that depends on named
modules (ones with *module-info.java*) it will fail because of
[https://bugs.openjdk.java.net/browse/JDK-8212233]
* Per MPLUGIN-341 maven plugins cannot contain *module-info.java*.
OpenJDK 11 will not receive any "stability updates" per Oracle policy and
OpenJDK 12+ won't support mixing modules and non-modules. So (unless I missed
something) the only solution is very far away (not even planned for
implementation): MPLUGIN-341
I filed MJAVADOC-562 thinking that passing in *-source 11* or *--release 11*
might help (the JDK bug report hinted as much), but it did not make a
difference.
was (Author: cowwoc):
Okay, now we've got a problem. Although JDK 12 contains a fix, it cannot be
used for maven plugins (which just so happens to affect my use-case).
* If you invoke {{javadoc:jar}} on a maven plugin that depends on named modules
(ones with **module-info.java**) it will fail because of
https://bugs.openjdk.java.net/browse/JDK-8212233
* Per MPLUGIN-341 maven plugins cannot contain **module-info.java**.
OpenJDK 11 will not receive any "stability updates" per Oracle policy and
OpenJDK 12+ won't support mixing modules and non-modules. So (unless I missed
something) the only solution is very far away (not even planned for
implementation): MPLUGIN-341
I filed MJAVADOC-562 thinking that passing in *\-source 11* or *--release 11*
might help (the JDK bug report hinted as much), but it did not make a
difference.
> Not possible to link to JDK classes since Java 11
> -
>
> Key: MJAVADOC-561
> URL: https://issues.apache.org/jira/browse/MJAVADOC-561
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.1.0
>Reporter: Gili
>Assignee: Michael Osipov
>Priority: Critical
> Attachments: testcase.zip
>
>
> 1. Open testcase
> 2. {{mvn javadoc:jar}}
> 3. Notice that generated Javadoc contains broken link to {{java.lang.Number}}
> It doesn't look like one can link to the JDK as of version 11 because the URL
> structure changed since Java 10.
> Java 10: https://docs.oracle.com/javase/10/docs/api/java/lang/Number.html
> Java 11:
> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Number.html
> Please see https://bugs.openjdk.java.net/browse/JDK-8191363 for a related
> discussion. If any syntax change is required in the pom, please consider
> updating
> https://maven.apache.org/plugins/maven-javadoc-plugin/examples/links-configuration.html
> accordingly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MJAVADOC-561) Not possible to link to JDK classes since Java 11
[
https://issues.apache.org/jira/browse/MJAVADOC-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16733751#comment-16733751
]
Gili edited comment on MJAVADOC-561 at 1/5/19 2:27 AM:
---
Okay, now we've got a problem. Although JDK 12 contains a fix, it cannot be
used for maven plugins (which just so happens to affect my use-case).
* If you invoke {{javadoc:jar}} on a maven plugin that depends on named modules
(ones with **module-info.java**) it will fail because of
https://bugs.openjdk.java.net/browse/JDK-8212233
* Per MPLUGIN-341 maven plugins cannot contain **module-info.java**.
OpenJDK 11 will not receive any "stability updates" per Oracle policy and
OpenJDK 12+ won't support mixing modules and non-modules. So (unless I missed
something) the only solution is very far away (not even planned for
implementation): MPLUGIN-341
I filed MJAVADOC-562 thinking that passing in *\-source 11* or *--release 11*
might help (the JDK bug report hinted as much), but it did not make a
difference.
was (Author: cowwoc):
Okay, now we've got a problem. Although JDK 12 contains a fix, it cannot be
used for maven plugins (which just so happens to affect my use-case).
* If you invoke {{javadoc:jar}} on a maven plugin that depends on named modules
(ones with **module-info.java**) it will fail because of
https://bugs.openjdk.java.net/browse/JDK-8212233
* Per MPLUGIN-341 maven plugins cannot contain **module-info.java**.
OpenJDK 11 will not receive any "stability updates" per Oracle policy and
OpenJDK 12+ won't support mixing modules and non-modules. So (unless I missed
something) the only solution is very far away (not even planned for
implementation): MPLUGIN-341
I filed MJAVADOC-562 thinking that passing in **-source 11** or **--release
11** might help (the JDK bug report hinted as much), but it did not make a
difference.
> Not possible to link to JDK classes since Java 11
> -
>
> Key: MJAVADOC-561
> URL: https://issues.apache.org/jira/browse/MJAVADOC-561
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.1.0
>Reporter: Gili
>Assignee: Michael Osipov
>Priority: Critical
> Attachments: testcase.zip
>
>
> 1. Open testcase
> 2. {{mvn javadoc:jar}}
> 3. Notice that generated Javadoc contains broken link to {{java.lang.Number}}
> It doesn't look like one can link to the JDK as of version 11 because the URL
> structure changed since Java 10.
> Java 10: https://docs.oracle.com/javase/10/docs/api/java/lang/Number.html
> Java 11:
> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Number.html
> Please see https://bugs.openjdk.java.net/browse/JDK-8191363 for a related
> discussion. If any syntax change is required in the pom, please consider
> updating
> https://maven.apache.org/plugins/maven-javadoc-plugin/examples/links-configuration.html
> accordingly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (WAGON-541) Command Line Not Showing ReasonPhrase for Errors
[ https://issues.apache.org/jira/browse/WAGON-541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox reopened WAGON-541: - We've also experienced this as a regression. When the server chooses to provide additional context, it is not helpful to the user that we squash it. Maven should pass this information on in the error so someone has a chance of understanding what happened. > Command Line Not Showing ReasonPhrase for Errors > > > Key: WAGON-541 > URL: https://issues.apache.org/jira/browse/WAGON-541 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 3.2.0 > Environment: Windows 10 >Reporter: Aurelie Pluche >Priority: Minor > Attachments: MvnCmdLineV339.PNG, MvnCmdLineV339V2.PNG, > MvnCmdLineV360.PNG, MvnCmdLineV360V2.PNG > > > Hi, > I work in the Azure DevOps Artifacts Packaging team at Microsoft where we > provide a Maven service to our customers. We often use a Reason-Phrase to > return information on failed requests to customers. This functionality was > available in previous versions of maven but seems to have disappeared in > Maven 3.6.0. Was this intentional? > I have included screenshots of the cmd line response using two different > maven versions (3.3.9 and 3.6.0). I intentionally made a call that would > return a 405 error to be able to get an error response. I also used the same > package. > Thanks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MJAVADOC-555) Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain module-info.java
[
https://issues.apache.org/jira/browse/MJAVADOC-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734600#comment-16734600
]
Gili edited comment on MJAVADOC-555 at 1/5/19 2:02 AM:
---
The JDK issue is saying this behavior is by design so nothing was changed.
I'm not sure why the restriction is there for external links having to be
modules. Are you able to ask Doug from Oracle?
was (Author: cowwoc):
The JDK issue is saying this behavior is by design so nothing was changed.
I'm not sure why the restriction is there for external links having to be
modules. Are you able to ask Doug from Oracle?
> Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain
> module-info.java
> ---
>
> Key: MJAVADOC-555
> URL: https://issues.apache.org/jira/browse/MJAVADOC-555
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (required for Java 11 support)
>Reporter: Gili
>Priority: Major
> Attachments: javadoc-cannot-link-to-automatic-modules.zip,
> testcase.zip, toolchains.xml
>
>
> # Unzip testcase
> # Run {{mvn clean install javadoc:aggregate}}
> # Build fails with: {{Exit code: 2 - javadoc: error - No source files for
> package module2}}
> Per MPLUGIN-341, Maven plugins cannot contain {{module.info.java}}. One of my
> projects builds under Java 11 and is fully modularized except for one module
> which is a Maven plugin. Due to the aforementioned issue, I cannot use
> {{javadoc:aggregate.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (WAGON-541) Command Line Not Showing ReasonPhrase for Errors
[
https://issues.apache.org/jira/browse/WAGON-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734730#comment-16734730
]
Brian Fox edited comment on WAGON-541 at 1/5/19 1:59 AM:
-
We've also experienced this as a regression. When the server chooses to provide
additional context, it is not helpful to the user that we squash it. Maven
should pass this information on in the error so someone has a chance of
understanding what happened.
Here is a more salient example of how this handling regressed:
Maven build failures due to firewalled component before Maven 3.6.0 printed a
message like
{quote}
Access denied to: , ReasonPhrase:*Requested item is
quarantined*
{quote}
With Wagon release 3.2.0 ( Maven 3.6.0 ), the reason phrase is no longer
printed - it now looks simply like this:
{quote}
Access denied to:
{quote}
was (Author: brianf):
We've also experienced this as a regression. When the server chooses to provide
additional context, it is not helpful to the user that we squash it. Maven
should pass this information on in the error so someone has a chance of
understanding what happened.
> Command Line Not Showing ReasonPhrase for Errors
>
>
> Key: WAGON-541
> URL: https://issues.apache.org/jira/browse/WAGON-541
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 3.2.0
> Environment: Windows 10
>Reporter: Aurelie Pluche
>Priority: Minor
> Attachments: MvnCmdLineV339.PNG, MvnCmdLineV339V2.PNG,
> MvnCmdLineV360.PNG, MvnCmdLineV360V2.PNG
>
>
> Hi,
> I work in the Azure DevOps Artifacts Packaging team at Microsoft where we
> provide a Maven service to our customers. We often use a Reason-Phrase to
> return information on failed requests to customers. This functionality was
> available in previous versions of maven but seems to have disappeared in
> Maven 3.6.0. Was this intentional?
> I have included screenshots of the cmd line response using two different
> maven versions (3.3.9 and 3.6.0). I intentionally made a call that would
> return a 405 error to be able to get an error response. I also used the same
> package.
> Thanks
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6541) less restrictive "is referencing itself" check
[
https://issues.apache.org/jira/browse/MNG-6541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734711#comment-16734711
]
Sylwester Lachiewicz commented on MNG-6541:
---
I was pretty sure that I saw that code somewhere..
Small update, in MNG-6490 I changed this part of a code and now also classifier
is part of validation. Could You verify with Maven 3.6.0?
> less restrictive "is referencing itself" check
> --
>
> Key: MNG-6541
> URL: https://issues.apache.org/jira/browse/MNG-6541
> Project: Maven
> Issue Type: Wish
> Components: Dependencies
>Affects Versions: 3.5.4
>Reporter: Václav Haisman
>Priority: Major
>
> I have issues when building site:site in project with OpenJFX. The
> javafx-graphics artifact sort of references itself:
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
> 4.0.0
> org.openjfx
> javafx-graphics
> 11.0.1
>
> org.openjfx
> javafx
> 11.0.1
>
>
>
> org.openjfx
> javafx-graphics
> 11.0.1
> ${javafx.platform}
>
>
> org.openjfx
> javafx-base
> 11.0.1
>
>
>
> {code}
> But it does so with additional classifier. When I run site:site, it gives me
> this:
> {code}
> [WARNING] Unable to create Maven project from repository.
> org.apache.maven.project.ProjectBuildingException: 1 problem was encountered
> while building the effective model for org.openjfx:javafx-graphics:11.0.1
> [FATAL] 'dependencies.dependency org.openjfx:javafx-graphics:11.0.1' for
> org.openjfx:javafx-graphics:11.0.1 is referencing itself. @ line 13, column 17
> for project org.openjfx:javafx-graphics:11.0.1
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:165)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:327)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository
> (RepositoryUtils.java:125)
> {code}
> I was wondering if the check could not be relaxed to accommodate this
> situation that seems to be common even in core Java components?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6520) Update assembly descriptors to 2.0.0
[ https://issues.apache.org/jira/browse/MNG-6520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MNG-6520: -- Fix Version/s: 3.6.1 > Update assembly descriptors to 2.0.0 > > > Key: MNG-6520 > URL: https://issues.apache.org/jira/browse/MNG-6520 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Trivial > Fix For: 3.6.1 > > > Update namespaces to the version compatible with 3.0+ maven-assembly-plugin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6520) Update assembly descriptors to 2.0.0
[ https://issues.apache.org/jira/browse/MNG-6520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MNG-6520: -- Description: Update namespaces to the version compatible with 3.0+ maven-assembly-plugin (was: Update to the version compatible with 3.0+ maven-assembly-plugin) > Update assembly descriptors to 2.0.0 > > > Key: MNG-6520 > URL: https://issues.apache.org/jira/browse/MNG-6520 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Priority: Trivial > > Update namespaces to the version compatible with 3.0+ maven-assembly-plugin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MNG-6520) Update assembly descriptors to 2.0.0
[ https://issues.apache.org/jira/browse/MNG-6520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MNG-6520: - Assignee: Sylwester Lachiewicz > Update assembly descriptors to 2.0.0 > > > Key: MNG-6520 > URL: https://issues.apache.org/jira/browse/MNG-6520 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Trivial > > Update namespaces to the version compatible with 3.0+ maven-assembly-plugin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6262) getCanonicalFile() is not used consistently during project resolution
[
https://issues.apache.org/jira/browse/MNG-6262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz updated MNG-6262:
--
Fix Version/s: 3.x / Backlog
> getCanonicalFile() is not used consistently during project resolution
> -
>
> Key: MNG-6262
> URL: https://issues.apache.org/jira/browse/MNG-6262
> Project: Maven
> Issue Type: Bug
> Components: core, Reactor and workspace
>Affects Versions: 3.0-alpha-1, 3.5.0
> Environment: Windows 7
>Reporter: Gene Smith
>Priority: Minor
> Fix For: 3.x / Backlog
>
> Attachments: test-inconsistent-canonicalization.zip
>
>
> This bug manifests with...
> * maven 3.5.0 *AND WITH* maven built from 3.5.1's unreleased sources
> * on Windows 7 when the "Drive Letter" is configured with the wrong case.
> * in projects which descend from a pom which does not reference them.
> On Windows getCanonicalFile() is used on module File objects before they
> are wrapped in a FileSource and cached. But DefaultModelBuilder compares
> its cache hits against a File which has not been made cananonical.
> Normally it does not matter on Windows, because the lack of symbolic links
> makes it difficult to find an "Absolute File" which is not the same as its
> "Canonical File", but there is at least one use case it happens in...
> If invoking scripts use a "lower case drive letter" (ex: c:\, d:\, etc...)
> then the "Canonical File" has an "upper case drive letter".
> The error only seems to occur if a POM references a parent which does not list
> the referencing POM as a child. In other words, when there is POM inheritance
> without a reactor module relationship. In my use case there is a Dependency
> Management POM which does not reference all the modules which list it as their
> parent.
> A simple work around is...
> Make sure all your Windows Environments have capital drive letters in the
> Jenkins node configuration, and scripting.
> ..
> {noformat}
> Testing from sources:
> https://git-wip-us.apache.org/repos/asf/maven.git
> origin/master
> b10025751 (HEAD -> master, origin/master, origin/MNG-5457_2,
> origin/HEAD) [MNG-5457] Show repository id when downloading or uploading
> from/to a remote repository
> https://git-wip-us.apache.org/repos/asf/maven-resolver.git
> origin/master
> c9212232 (HEAD -> master, origin/master, origin/HEAD)
> [maven-release-plugin] prepare for next development iteration
> {noformat}
> I found {{DefaultModelBuilder}} compares a POM's Non-Canonical File's URI
> against a
> cached Model's POM's Canonical File's URI.
> {code:java}
> org.apache.maven.model.building.DefaultModelBuilder
> File pomFile = parentData.getModel().getPomFile();
> if ( pomFile != null )
> {
> ModelSource expectedParentSource = getParentPomFile( childModel,
> childSource );
> if ( expectedParentSource instanceof ModelSource2
> && !pomFile.toURI().equals( ( (ModelSource2)
> expectedParentSource ).getLocationURI() ) )
> {
> parentData = readParentExternally( childModel, request,
> problems );
> }
> }
> {code}
> Where {{ModelSource2}} is a {{org.apache.maven.building.FileSource}} which
> has been
> made from a canonical file.
> In my test environment it composed and compared these two URIs for
> test-inconsistent-canonicalization:dependency-management:pom:1.0.0-SNAPSHOT
> and found they did not match:
>
> [file:/C:/Jenkins/workspace/test/pom.xml|file:///C:/Jenkins/workspace/test/pom.xml]
>
> [file:/c:/Jenkins/workspace/test/pom.xml|file:///C:/Jenkins/workspace/test/pom.xml]
> resulting in this error output:
> {noformat}
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-resolvable parent POM for
> test-inconsistent-canonicalization:reactor:1.0.0-SNAPSHOT: Could not find
> artifact
> test-inconsistent-canonicalization:dependency-management:pom:1.0.0-SNAPSHOT
> and 'parent.relativePath' points at wrong local POM @
> test-inconsistent-canonicalization:reactor:1.0.0-SNAPSHOT,
> C:\Jenkins\workspace\test\reactor\pom.xml, line 5, column 11
> @
> [ERROR] The build could not read 1 project -> [Help 1]
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs:
> [FATAL] Non-resolvable parent POM for
> test-inconsistent-canonicalization:reactor:1.0.0-SNAPSHOT: Could not find
> artifact
> test-inconsistent-canonicalization:dependency-management:pom:1.0.0-SNAPSHOT
> and 'parent.relativePath' points at wrong local POM @
> test-inconsistent-canonicalization:reactor:1.0.0-SNAPSHOT,
>
[jira] [Updated] (MNG-6262) getCanonicalFile() is not used consistently during project resolution
[
https://issues.apache.org/jira/browse/MNG-6262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz updated MNG-6262:
--
Description:
This bug manifests with...
* maven 3.5.0 *AND WITH* maven built from 3.5.1's unreleased sources
* on Windows 7 when the "Drive Letter" is configured with the wrong case.
* in projects which descend from a pom which does not reference them.
On Windows getCanonicalFile() is used on module File objects before they
are wrapped in a FileSource and cached. But DefaultModelBuilder compares
its cache hits against a File which has not been made cananonical.
Normally it does not matter on Windows, because the lack of symbolic links
makes it difficult to find an "Absolute File" which is not the same as its
"Canonical File", but there is at least one use case it happens in...
If invoking scripts use a "lower case drive letter" (ex: c:\, d:\, etc...)
then the "Canonical File" has an "upper case drive letter".
The error only seems to occur if a POM references a parent which does not list
the referencing POM as a child. In other words, when there is POM inheritance
without a reactor module relationship. In my use case there is a Dependency
Management POM which does not reference all the modules which list it as their
parent.
A simple work around is...
Make sure all your Windows Environments have capital drive letters in the
Jenkins node configuration, and scripting.
..
{noformat}
Testing from sources:
https://git-wip-us.apache.org/repos/asf/maven.git
origin/master
b10025751 (HEAD -> master, origin/master, origin/MNG-5457_2,
origin/HEAD) [MNG-5457] Show repository id when downloading or uploading
from/to a remote repository
https://git-wip-us.apache.org/repos/asf/maven-resolver.git
origin/master
c9212232 (HEAD -> master, origin/master, origin/HEAD)
[maven-release-plugin] prepare for next development iteration
{noformat}
I found {{DefaultModelBuilder}} compares a POM's Non-Canonical File's URI
against a
cached Model's POM's Canonical File's URI.
{code:java}
org.apache.maven.model.building.DefaultModelBuilder
File pomFile = parentData.getModel().getPomFile();
if ( pomFile != null )
{
ModelSource expectedParentSource = getParentPomFile( childModel,
childSource );
if ( expectedParentSource instanceof ModelSource2
&& !pomFile.toURI().equals( ( (ModelSource2)
expectedParentSource ).getLocationURI() ) )
{
parentData = readParentExternally( childModel, request,
problems );
}
}
{code}
Where {{ModelSource2}} is a {{org.apache.maven.building.FileSource}} which has
been
made from a canonical file.
In my test environment it composed and compared these two URIs for
test-inconsistent-canonicalization:dependency-management:pom:1.0.0-SNAPSHOT
and found they did not match:
[file:/C:/Jenkins/workspace/test/pom.xml|file:///C:/Jenkins/workspace/test/pom.xml]
[file:/c:/Jenkins/workspace/test/pom.xml|file:///C:/Jenkins/workspace/test/pom.xml]
resulting in this error output:
{noformat}
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for
test-inconsistent-canonicalization:reactor:1.0.0-SNAPSHOT: Could not find
artifact
test-inconsistent-canonicalization:dependency-management:pom:1.0.0-SNAPSHOT and
'parent.relativePath' points at wrong local POM @
test-inconsistent-canonicalization:reactor:1.0.0-SNAPSHOT,
C:\Jenkins\workspace\test\reactor\pom.xml, line 5, column 11
@
[ERROR] The build could not read 1 project -> [Help 1]
org.apache.maven.project.ProjectBuildingException: Some problems were
encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for
test-inconsistent-canonicalization:reactor:1.0.0-SNAPSHOT: Could not find
artifact
test-inconsistent-canonicalization:dependency-management:pom:1.0.0-SNAPSHOT and
'parent.relativePath' points at wrong local POM @
test-inconsistent-canonicalization:reactor:1.0.0-SNAPSHOT,
C:\Jenkins\workspace\test\reactor\pom.xml, line 5, column 11
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:382)
at
org.apache.maven.graph.DefaultGraphBuilder.collectProjects(DefaultGraphBuilder.java:400)
at
org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor(DefaultGraphBuilder.java:391)
at
org.apache.maven.graph.DefaultGraphBuilder.build(DefaultGraphBuilder.java:78)
at org.apache.maven.DefaultMaven.buildGraph(DefaultMaven.java:511)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:221)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
at
[jira] [Assigned] (MNG-6469) Upload to Nexus hangs
[
https://issues.apache.org/jira/browse/MNG-6469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz reassigned MNG-6469:
-
Assignee: Sylwester Lachiewicz
> Upload to Nexus hangs
> -
>
> Key: MNG-6469
> URL: https://issues.apache.org/jira/browse/MNG-6469
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.4
> Environment: macOS High Sierra 10.13.6
>Reporter: Haotian Wu
>Assignee: Sylwester Lachiewicz
>Priority: Minor
> Fix For: waiting-for-feedback
>
> Attachments: maven_3.5.3.log, maven_3.5.4.log
>
>
> I am able to upload my project to Nexus staging successfully using Maven
> 3.3.9. But if I switch to maven 3.5.4 to upload the same project the upload
> will just hang forever during the uploading process. I have to use -X to see
> the actual stack trace:
> {noformat}
> [DEBUG] Failed to dispatch transfer event 'PUT PROGRESSED
> http://oss.sonatype.org/service/local/staging/deploy/maven2/myProject.pom <>
> /Users/haotianw/workplace/myProject/pom.xml' to
> org.apache.maven.cli.transfer.ConsoleMavenTransferListener
> java.lang.IllegalArgumentException: progressed file size cannot be greater
> than size: 6984 > 4936
> at org.apache.commons.lang3.Validate.isTrue (Validate.java:158)
> at
> org.apache.maven.cli.transfer.AbstractMavenTransferListener$FileSizeFormat.formatProgress
> (AbstractMavenTransferListener.java:195)
> at org.apache.maven.cli.transfer.ConsoleMavenTransferListener.getStatus
> (ConsoleMavenTransferListener.java:117)
> at
> org.apache.maven.cli.transfer.ConsoleMavenTransferListener.transferProgressed
> (ConsoleMavenTransferListener.java:90)
> at org.eclipse.aether.internal.impl.SafeTransferListener.transferProgressed
> (SafeTransferListener.java:114)
> at
> org.eclipse.aether.connector.basic.TransferTransportListener.transportProgressed
> (TransferTransportListener.java:95)
> at org.eclipse.aether.transport.wagon.WagonTransferListener.transferProgress
> (WagonTransferListener.java:64)
> at org.apache.maven.wagon.events.TransferEventSupport.fireTransferProgress
> (TransferEventSupport.java:121)
> at org.apache.maven.wagon.AbstractWagon.fireTransferProgress
> (AbstractWagon.java:594)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.access$100
> (AbstractHttpClientWagon.java:96)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon$RequestEntityImplementation.writeTo
> (AbstractHttpClientWagon.java:194)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.DefaultBHttpClientConnection.sendRequestEntity
> (DefaultBHttpClientConnection.java:156)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.conn.CPoolProxy.sendRequestEntity
> (CPoolProxy.java:160)
> at
> org.apache.maven.wagon.providers.http.httpclient.protocol.HttpRequestExecutor.doSendRequest
> (HttpRequestExecutor.java:238)
> at
> org.apache.maven.wagon.providers.http.httpclient.protocol.HttpRequestExecutor.execute
> (HttpRequestExecutor.java:123)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.MainClientExec.execute
> (MainClientExec.java:272)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.ProtocolExec.execute
> (ProtocolExec.java:185)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec.execute
> (RetryExec.java:89)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RedirectExec.execute
> (RedirectExec.java:111)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.client.InternalHttpClient.doExecute
> (InternalHttpClient.java:185)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.client.CloseableHttpClient.execute
> (CloseableHttpClient.java:83)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.execute
> (AbstractHttpClientWagon.java:825)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.put
> (AbstractHttpClientWagon.java:587)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.put
> (AbstractHttpClientWagon.java:544)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.put
> (AbstractHttpClientWagon.java:608)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.put
> (AbstractHttpClientWagon.java:544)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.put
> (AbstractHttpClientWagon.java:526)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.put
> (AbstractHttpClientWagon.java:520)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.put
> (AbstractHttpClientWagon.java:500)
> at
[jira] [Updated] (MNG-6069) Migrate to non deprecated parts of Commons CLI
[
https://issues.apache.org/jira/browse/MNG-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz updated MNG-6069:
--
Fix Version/s: (was: 3.6.x-candidate)
3.6.1
> Migrate to non deprecated parts of Commons CLI
> --
>
> Key: MNG-6069
> URL: https://issues.apache.org/jira/browse/MNG-6069
> Project: Maven
> Issue Type: Improvement
> Components: Embedding
>Affects Versions: 3.3.9, 3.5.0-alpha-1, 3.5.0-beta-1, 3.5.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.6.1
>
>
> At the moment all parts of {{OptionBuilder...}} are marked deprecated in
> {{CLIManager}}. They should be migrated to:
> {code:java}
> Option.builder( HELP ).longOpt( "help" ).desc( "Display help information"
> ).build()
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MNG-6069) Migrate to non deprecated parts of Commons CLI
[
https://issues.apache.org/jira/browse/MNG-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz reassigned MNG-6069:
-
Assignee: Sylwester Lachiewicz (was: Karl Heinz Marbaise)
> Migrate to non deprecated parts of Commons CLI
> --
>
> Key: MNG-6069
> URL: https://issues.apache.org/jira/browse/MNG-6069
> Project: Maven
> Issue Type: Improvement
> Components: Embedding
>Affects Versions: 3.3.9, 3.5.0-alpha-1, 3.5.0-beta-1, 3.5.0
>Reporter: Karl Heinz Marbaise
>Assignee: Sylwester Lachiewicz
>Priority: Minor
> Fix For: 3.6.1
>
>
> At the moment all parts of {{OptionBuilder...}} are marked deprecated in
> {{CLIManager}}. They should be migrated to:
> {code:java}
> Option.builder( HELP ).longOpt( "help" ).desc( "Display help information"
> ).build()
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6374) ModelBuilder hangs with malformed pom.xml
[
https://issues.apache.org/jira/browse/MNG-6374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz updated MNG-6374:
--
Fix Version/s: 3.6.x-candidate
> ModelBuilder hangs with malformed pom.xml
> -
>
> Key: MNG-6374
> URL: https://issues.apache.org/jira/browse/MNG-6374
> Project: Maven
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.5.2, 3.5.3
>Reporter: Rohan Padhye
>Priority: Minor
> Fix For: 3.6.x-candidate
>
> Attachments: MNG-6374.patch
>
>
> Maven hangs when provided with a malformed pom.xml file that contains a
> question mark in a tag name.
> Minimal example for a pom.xml:
> {noformat}
> {noformat}
>
> Running {{mvn}} results in the output:
> {noformat}
> [INFO] Scanning for projects...{noformat}
>
> And is stuck there forever, instead of providing an error message.
> I found this issue using [JQF|https://github.com/rohanpadhye/jqf].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MNG-6063) rg.apache.maven.InternalErrorException: Internal error: java.lang.RuntimeException: "No solution found because the problem is unsatisfiable
[ https://issues.apache.org/jira/browse/MNG-6063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed MNG-6063. - Resolution: Won't Fix > rg.apache.maven.InternalErrorException: Internal error: > java.lang.RuntimeException: "No solution found because the problem is > unsatisfiable > --- > > Key: MNG-6063 > URL: https://issues.apache.org/jira/browse/MNG-6063 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0.4 >Reporter: chenna >Priority: Major > Attachments: build_log.xt > > > rg.apache.maven.InternalErrorException: Internal error: > java.lang.RuntimeException: "No solution found because the problem is > unsatisfiable -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6063) rg.apache.maven.InternalErrorException: Internal error: java.lang.RuntimeException: "No solution found because the problem is unsatisfiable
[ https://issues.apache.org/jira/browse/MNG-6063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734699#comment-16734699 ] Sylwester Lachiewicz commented on MNG-6063: --- This issue has been auto closed because it has been inactive for a long period of time. If you think this issue still applies, retest your problem with the most recent version of Maven and the affected component, reopen and post your results. > rg.apache.maven.InternalErrorException: Internal error: > java.lang.RuntimeException: "No solution found because the problem is > unsatisfiable > --- > > Key: MNG-6063 > URL: https://issues.apache.org/jira/browse/MNG-6063 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0.4 >Reporter: chenna >Priority: Major > Attachments: build_log.xt > > > rg.apache.maven.InternalErrorException: Internal error: > java.lang.RuntimeException: "No solution found because the problem is > unsatisfiable -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6346) ... was unexpected at this time when using -f option and path contains brackets
[ https://issues.apache.org/jira/browse/MNG-6346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734695#comment-16734695 ] Sylwester Lachiewicz commented on MNG-6346: --- To debug the issue set environment variable _MAVEN_BATCH_ECHO=on_ We need to add " around echo statements in mvn.cmd script (lines 118 and 127) PR: [https://gitbox.apache.org/repos/asf?p=maven.git;a=commitdiff;h=d2cb7e61d8106409a6d3e4af91d313c06fa97ef3;hp=9c946263facbfa851fb646b3fac62cf1d3302ded] > ... was unexpected at this time when using -f option and path contains > brackets > --- > > Key: MNG-6346 > URL: https://issues.apache.org/jira/browse/MNG-6346 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.0, 3.5.2 > Environment: Win10 & Win Server 2012 > jdk1.8.0_151 >Reporter: Patrik Jetzer >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 3.6.1 > > Attachments: mmm(example).zip > > > Since maven version 3.50 and later when running a simple command with -f > option the command fails reporting: > "\pom.xml was unexpected at this time." > command: > mvn -f C:\mmm(example)\pom.xml clean install > This must be related to changes in 3.5.x since it works as expected with > version 3.3.9 > Removing the brackets from the folder name resolves the issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6346) ... was unexpected at this time when using -f option and path contains brackets
[ https://issues.apache.org/jira/browse/MNG-6346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MNG-6346: -- Fix Version/s: 3.6.1 > ... was unexpected at this time when using -f option and path contains > brackets > --- > > Key: MNG-6346 > URL: https://issues.apache.org/jira/browse/MNG-6346 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.0, 3.5.2 > Environment: Win10 & Win Server 2012 > jdk1.8.0_151 >Reporter: Patrik Jetzer >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 3.6.1 > > Attachments: mmm(example).zip > > > Since maven version 3.50 and later when running a simple command with -f > option the command fails reporting: > "\pom.xml was unexpected at this time." > command: > mvn -f C:\mmm(example)\pom.xml clean install > This must be related to changes in 3.5.x since it works as expected with > version 3.3.9 > Removing the brackets from the folder name resolves the issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MNG-6346) ... was unexpected at this time when using -f option and path contains brackets
[ https://issues.apache.org/jira/browse/MNG-6346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MNG-6346: - Assignee: Sylwester Lachiewicz > ... was unexpected at this time when using -f option and path contains > brackets > --- > > Key: MNG-6346 > URL: https://issues.apache.org/jira/browse/MNG-6346 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.0, 3.5.2 > Environment: Win10 & Win Server 2012 > jdk1.8.0_151 >Reporter: Patrik Jetzer >Assignee: Sylwester Lachiewicz >Priority: Major > Attachments: mmm(example).zip > > > Since maven version 3.50 and later when running a simple command with -f > option the command fails reporting: > "\pom.xml was unexpected at this time." > command: > mvn -f C:\mmm(example)\pom.xml clean install > This must be related to changes in 3.5.x since it works as expected with > version 3.3.9 > Removing the brackets from the folder name resolves the issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAVADOC-555) Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain module-info.java
[
https://issues.apache.org/jira/browse/MJAVADOC-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734669#comment-16734669
]
Gili commented on MJAVADOC-555:
---
I just noticed that in the 3rd comment Jonathan Gibson writes "this looks like
a Maven issue". Maybe that's why they closed it as Not an Issue. Let me know
what you find out.
> Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain
> module-info.java
> ---
>
> Key: MJAVADOC-555
> URL: https://issues.apache.org/jira/browse/MJAVADOC-555
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (required for Java 11 support)
>Reporter: Gili
>Priority: Major
> Attachments: javadoc-cannot-link-to-automatic-modules.zip,
> testcase.zip, toolchains.xml
>
>
> # Unzip testcase
> # Run {{mvn clean install javadoc:aggregate}}
> # Build fails with: {{Exit code: 2 - javadoc: error - No source files for
> package module2}}
> Per MPLUGIN-341, Maven plugins cannot contain {{module.info.java}}. One of my
> projects builds under Java 11 and is fully modularized except for one module
> which is a Maven plugin. Due to the aforementioned issue, I cannot use
> {{javadoc:aggregate.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-5950) Only first active proxy considered
[ https://issues.apache.org/jira/browse/MNG-5950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MNG-5950: -- Fix Version/s: 3.x / Backlog > Only first active proxy considered > -- > > Key: MNG-5950 > URL: https://issues.apache.org/jira/browse/MNG-5950 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.0.5 > Environment: windows 7 ,jdk 1.8 >Reporter: Jiahongchao >Priority: Major > Fix For: 3.x / Backlog > > > only http proxy or https proxy can be used at the same time,however,only one > proxy should be used for both http and https -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MNG-5577) Convert the core to use JSR 330 and remove the use of Plexus
[ https://issues.apache.org/jira/browse/MNG-5577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MNG-5577: - Assignee: Sylwester Lachiewicz (was: Jason van Zyl) > Convert the core to use JSR 330 and remove the use of Plexus > > > Key: MNG-5577 > URL: https://issues.apache.org/jira/browse/MNG-5577 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Jason van Zyl >Assignee: Sylwester Lachiewicz >Priority: Major > > Remove the use of Plexus annotations and use JSR330 annotations throughout > the core. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6355) HTTP connector does not honor nonProxyHosts when following redirects
[ https://issues.apache.org/jira/browse/MNG-6355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MNG-6355: -- Fix Version/s: 3.x / Backlog > HTTP connector does not honor nonProxyHosts when following redirects > > > Key: MNG-6355 > URL: https://issues.apache.org/jira/browse/MNG-6355 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.3 > Environment: Linux >Reporter: Roy >Priority: Major > Fix For: 3.x / Backlog > > > Setup: An external maven repository hosting website (outside the firewall) > that does a redirect to an internal website (for authentication). The > external website requires a proxy, the internal one does not. > Observation through Wagon trace: The proxy settings in the POM are used to > access the external website, but the nonProxyHosts in the same POM are not > referred to when accessing the internal website. The request keeps using the > proxy when following redirects. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-5995) Maven itself cannot run without maven-compat
[
https://issues.apache.org/jira/browse/MNG-5995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734655#comment-16734655
]
Robert Scholte commented on MNG-5995:
-
Right, ideally maven-compat is not available on the classpath, unless a plugin
explicitly requires it. Only in that case the maven-compat jar of the Maven
Runtime should be added to the classpath (like now: the version of maven
dependencies of the plugin doesn't have any effect, they are filtered out and
the Maven Runtime dependencies are used).
This is probably too complex is doesn't gain enough.
However, we might hit similar issues with the next major version of Maven, but
that's for later.
> Maven itself cannot run without maven-compat
>
>
> Key: MNG-5995
> URL: https://issues.apache.org/jira/browse/MNG-5995
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap Build, core
>Affects Versions: 3.3.9
>Reporter: Robert Scholte
>Assignee: Sylwester Lachiewicz
>Priority: Critical
> Fix For: 3.6.1
>
>
> For all the 3.0 versions of the maven-plugins we require to not depend on
> maven-compat anymore. However, the Maven distribution still requires
> maven-compat. A simple proof: remove {{lib/maven-compat-3.x.y}} and execute
> {{mvn validate}}.
> You'll get the following exception:
> {noformat}[WARNING] Error injecting:
> org.apache.maven.project.DefaultProjectBuildingHelper
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) No implementation for org.apache.maven.repository.RepositorySystem was
> bound.
> while locating
> org.apache.maven.project.DefaultProjectBuildingHelper{noformat}
> Reason: there's only one implementation: o.a.m.r.l.LegacyRepositorySystem,
> which is part of maven-compat.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-5577) Convert the core to use JSR 330 and remove the use of Plexus
[ https://issues.apache.org/jira/browse/MNG-5577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MNG-5577: -- Fix Version/s: 3.6.x-candidate > Convert the core to use JSR 330 and remove the use of Plexus > > > Key: MNG-5577 > URL: https://issues.apache.org/jira/browse/MNG-5577 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Jason van Zyl >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 3.6.x-candidate > > > Remove the use of Plexus annotations and use JSR330 annotations throughout > the core. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAVADOC-555) Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain module-info.java
[
https://issues.apache.org/jira/browse/MJAVADOC-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734646#comment-16734646
]
Robert Scholte commented on MJAVADOC-555:
-
Something changed. I will try to get in touch with the javadoc team about this.
> Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain
> module-info.java
> ---
>
> Key: MJAVADOC-555
> URL: https://issues.apache.org/jira/browse/MJAVADOC-555
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (required for Java 11 support)
>Reporter: Gili
>Priority: Major
> Attachments: javadoc-cannot-link-to-automatic-modules.zip,
> testcase.zip, toolchains.xml
>
>
> # Unzip testcase
> # Run {{mvn clean install javadoc:aggregate}}
> # Build fails with: {{Exit code: 2 - javadoc: error - No source files for
> package module2}}
> Per MPLUGIN-341, Maven plugins cannot contain {{module.info.java}}. One of my
> projects builds under Java 11 and is fully modularized except for one module
> which is a Maven plugin. Due to the aforementioned issue, I cannot use
> {{javadoc:aggregate.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MNG-6506) Mojos are unable to load package annotations on Java >= 9
[
https://issues.apache.org/jira/browse/MNG-6506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz reassigned MNG-6506:
-
Assignee: Sylwester Lachiewicz
> Mojos are unable to load package annotations on Java >= 9
> -
>
> Key: MNG-6506
> URL: https://issues.apache.org/jira/browse/MNG-6506
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.6.0
>Reporter: Andreas Veithen
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.6.1
>
>
> On Java 9 and above, calls to {{java.lang.Package.getAnnotation(Class)}} from
> within a Mojo always return {{null}} (unless the {{package-info}} class has
> been loaded by some other means before).
> The reason appears to be an incompatibility between Java 9 and Plexus
> Classworlds:
> * Java 9 ultimately calls {{findClass}} (instead of {{loadClass}}) to get the
> {{package-info}} class.
> * The {{findClass}} implementation in {{ClassRealm}} always throws
> {{ClassNotFoundException}}:
> https://github.com/codehaus-plexus/plexus-classworlds/blob/master/src/main/java/org/codehaus/plexus/classworlds/realm/ClassRealm.java#L275.
> This in particular affects plugins that interact with the JAXB API because it
> relies on package annotations. A workaround is to preload the required
> {{package-info}} classes using {{loadClass}}; see e.g.
> http://svn.apache.org/viewvc?rev=1845026=rev.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6294) Convert MavenPluginValidator into a plexus component
[ https://issues.apache.org/jira/browse/MNG-6294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MNG-6294: -- Fix Version/s: (was: 3.6.x-candidate) 3.6.1 > Convert MavenPluginValidator into a plexus component > > > Key: MNG-6294 > URL: https://issues.apache.org/jira/browse/MNG-6294 > Project: Maven > Issue Type: Improvement > Components: core >Reporter: Michael Simacek >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 3.6.1 > > > [XMvn|https://github.com/fedora-java/xmvn] is a maven extension that helps > with creating RPM packages. In order to comply with packaging requirements, > it needs to relax some checks that maven does. One of those is plugin > validation done in MavenPluginValidator class. Currently, it overrides that > by shadowing the class on the classpath, which is a hack. It would help if > MavenPluginValidator was a plexus component and thus the implementation could > be selected by configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6543) Upgrade plexus classworld to support java 9+ ClassLoader.findClass(String moduleName, String name) in Mojos
[ https://issues.apache.org/jira/browse/MNG-6543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734629#comment-16734629 ] Sylwester Lachiewicz commented on MNG-6543: --- one more sample project to show problem MNG-6506 - thx [~veithen] ! > Upgrade plexus classworld to support java 9+ ClassLoader.findClass(String > moduleName, String name) in Mojos > --- > > Key: MNG-6543 > URL: https://issues.apache.org/jira/browse/MNG-6543 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.6.0 >Reporter: Romain Manni-Bucau >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 3.6.1 > > Attachments: MNG-6543-xjc.zip > > > Goal is to include > https://github.com/codehaus-plexus/plexus-classworlds/pull/4 in Maven and > enable Mojos using this Java 9 new JPMS API to work under java 9+ > see [Java 9 ClassLoader.findClass(String moduleName,String > name)|https://docs.oracle.com/javase/9/docs/api/java/lang/ClassLoader.html#findClass-java.lang.String-java.lang.String-] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] eolivelli commented on a change in pull request #134: [MNG-6294] Convert MavenPluginValidator into a plexus component
eolivelli commented on a change in pull request #134: [MNG-6294] Convert
MavenPluginValidator into a plexus component
URL: https://github.com/apache/maven/pull/134#discussion_r245435453
##
File path:
maven-core/src/test/java/org/apache/maven/plugin/MavenPluginValidatorTest.java
##
@@ -0,0 +1,70 @@
+package org.apache.maven.plugin;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.util.ArrayList;
+import java.util.List;
+import org.apache.maven.artifact.Artifact;
+import org.apache.maven.artifact.DefaultArtifact;
+import org.apache.maven.artifact.handler.DefaultArtifactHandler;
+import org.apache.maven.plugin.descriptor.PluginDescriptor;
+import org.codehaus.plexus.PlexusTestCase;
+
+/**
+ * @author Michael Simacek
+ */
+public class MavenPluginValidatorTest
+extends PlexusTestCase
+{
+private MavenPluginValidator mavenPluginValidator;
+
+@Override
+protected void setUp()
+throws Exception
+{
+super.setUp();
+mavenPluginValidator = (MavenPluginValidator) lookup(
MavenPluginValidator.class );
+}
+
+public void testValidate()
+{
+Artifact plugin = new DefaultArtifact( "org.apache.maven.its.plugins",
"maven-it-plugin", "0.1", "compile",
+"jar", null, new DefaultArtifactHandler() );
+PluginDescriptor descriptor = new PluginDescriptor();
+descriptor.setGroupId( "org.apache.maven.its.plugins" );
+descriptor.setArtifactId( "maven-it-plugin" );
+descriptor.setVersion( "0.1" );
+List errors = new ArrayList<>();
+mavenPluginValidator.validate( plugin, descriptor, errors );
+assertTrue( errors.isEmpty() );
+}
+
+public void testInvalid()
+{
+Artifact plugin = new DefaultArtifact( "org.apache.maven.its.plugins",
"maven-it-plugin", "0.1", "compile",
+"jar", null, new DefaultArtifactHandler() );
+PluginDescriptor descriptor = new PluginDescriptor();
+descriptor.setGroupId( "org.apache.maven.its.plugins" );
+descriptor.setArtifactId( "maven-it-plugin" );
+List errors = new ArrayList<>();
+mavenPluginValidator.validate( plugin, descriptor, errors );
+assertFalse( errors.isEmpty() );
Review comment:
nit: we should test more the "errors" result, it is not clear that we are
catching the error we are generating with the lines above.
We have three validations which can fire an error, we should test every of
them.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Updated] (MNG-6506) Mojos are unable to load package annotations on Java >= 9
[
https://issues.apache.org/jira/browse/MNG-6506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz updated MNG-6506:
--
Fix Version/s: 3.6.1
> Mojos are unable to load package annotations on Java >= 9
> -
>
> Key: MNG-6506
> URL: https://issues.apache.org/jira/browse/MNG-6506
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.6.0
>Reporter: Andreas Veithen
>Priority: Major
> Fix For: 3.6.1
>
>
> On Java 9 and above, calls to {{java.lang.Package.getAnnotation(Class)}} from
> within a Mojo always return {{null}} (unless the {{package-info}} class has
> been loaded by some other means before).
> The reason appears to be an incompatibility between Java 9 and Plexus
> Classworlds:
> * Java 9 ultimately calls {{findClass}} (instead of {{loadClass}}) to get the
> {{package-info}} class.
> * The {{findClass}} implementation in {{ClassRealm}} always throws
> {{ClassNotFoundException}}:
> https://github.com/codehaus-plexus/plexus-classworlds/blob/master/src/main/java/org/codehaus/plexus/classworlds/realm/ClassRealm.java#L275.
> This in particular affects plugins that interact with the JAXB API because it
> relies on package annotations. A workaround is to preload the required
> {{package-info}} classes using {{loadClass}}; see e.g.
> http://svn.apache.org/viewvc?rev=1845026=rev.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1222) ForkClient attempts to consume unrelated lines
[
https://issues.apache.org/jira/browse/SUREFIRE-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734620#comment-16734620
]
Enrico Olivelli commented on SUREFIRE-1222:
---
[~tibor17] as we are going to fix this issue by introducing a completely new
way of communication between surefire and the forked JVM I think it will be
clearer to create a new Jira issue like "Use sockets to comunicate with Forked
JVMs" and then we will link this issue.
Does this approach work for you ?
> ForkClient attempts to consume unrelated lines
> --
>
> Key: SUREFIRE-1222
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1222
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.17
> Environment: Oracle JDK7 (build 1.7.0_79-b15)
> Linux 3.13 x86_64 with default locale cs_CZ
>Reporter: Martin Kouba
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M4
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This month the [Weld
> SE|https://github.com/weld/core/tree/2.3/environments/se/tests] test suite
> suddenly started to fail on a Linux machine with Oracle JDK7 and the default
> locale {{cs_CZ}}:
> {code}
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of
> range: -1
> at java.lang.String.substring(String.java:1911)
> at
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:128)
> at
> org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> A {{java.util.logging.Logger}} is used in the forked process. The exception
> occurs when the following log message is written to the standard output:
> {code}
> I 29, 2016 2:01:43 ODP. org.jboss.arquillian.container.se.server.Main main
> {code}
> We have found out that the timestamp *I 29, 2016 2:01:43* (i.e. 2016-01-29
> 14:01:43) is incorrectly parsed as {{ForkingRunListener.BOOTERCODE_SYSPROPS}}
> operation.
> I think the protocol should be robust enough to avoid similar collisions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
[
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5869:
Fix Version/s: 3.6.x-candidate
> Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
>
>
> Key: MNG-5869
> URL: https://issues.apache.org/jira/browse/MNG-5869
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.2.5, 3.3.3
>Reporter: Arnaud HERITIER
>Priority: Major
> Fix For: 3.6.x-candidate
>
> Attachments: settings.xml, threaddumps.log
>
>
> We recently discovered a strange bug of frozen dependencies downloads
> I didn't yet studied a lot the issue but I guess it may be something in
> recent versions of Wagon.
> I created few jobs to demonstrate the Maven issue and I would like to have
> some guidance to deeply analyse it.
> The project used is https://github.com/kenzanmedia/bowtie/ which has a really
> simple Maven build : https://github.com/kenzanmedia/bowtie/blob/master/pom.xml
> All my builds are using Apache Maven in versions 3.1.1, 3.2.5 or 3.3.3
> We are using some custom global and user maven settings but only to setup
> some mirrors, some credentials and to (re)define some repositories
> Here are my results jobs on https://aheritier.ci.cloudbees.com
> * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.cloudbees.com (http)
> * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.maven.apache.org (https)
> * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo1.maven.org (http)
> * (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
> * (/) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.maven.apache.org (https)
> * (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo1.maven.org (http)
> * (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.cloudbees.com (http)
> * (/) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.maven.apache.org (https)
> * (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo1.maven.org (http)
> Result: Builds are always working with Maven 3.1.1 while for Maven 3.2.5 and
> 3.3.3 it works only if we use the https access to maven central
> For Maven 3.2 and 3.3 with http repositories the build is frozen and killed
> after the timeout I defined (5 minutes - I did also a test with 1h)
> All builds are frozen at the same point in the download process to grab
> surefire artefacts
> DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
> {code}
> 06:28:06 [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ bowtie
> ---
> 06:28:06 [INFO] Downloading:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
> 06:28:06 [INFO] Downloaded:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
> (3 KB at 3.2 KB/sec)
> 06:28:07 [INFO] Downloading:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
> 06:28:07 [INFO] Downloaded:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
> (3 KB at 42.7 KB/sec)
> 06:28:07 [INFO] Downloading:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
> 06:28:07 [INFO] Downloaded:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
> (6 KB at 52.9 KB/sec)
> 06:28:07 [INFO] Downloading:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
> 06:28:07 [INFO] Downloaded:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
> (2 KB at 2.2 KB/sec)
> 06:28:07 [INFO] Downloading:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
> 06:28:07 [INFO] Downloaded:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
> (16 KB at 154.9 KB/sec)
> 06:28:08 [INFO] Downloading:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
> 06:28:08 [INFO] Downloaded:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
> (2 KB at 62.8 KB/sec)
> 06:28:08 [INFO] Downloading:
>
[jira] [Updated] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
[
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5869:
Fix Version/s: (was: 3.6.x-candidate)
waiting-for-feedback
> Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
>
>
> Key: MNG-5869
> URL: https://issues.apache.org/jira/browse/MNG-5869
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.2.5, 3.3.3
>Reporter: Arnaud HERITIER
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: settings.xml, threaddumps.log
>
>
> We recently discovered a strange bug of frozen dependencies downloads
> I didn't yet studied a lot the issue but I guess it may be something in
> recent versions of Wagon.
> I created few jobs to demonstrate the Maven issue and I would like to have
> some guidance to deeply analyse it.
> The project used is https://github.com/kenzanmedia/bowtie/ which has a really
> simple Maven build : https://github.com/kenzanmedia/bowtie/blob/master/pom.xml
> All my builds are using Apache Maven in versions 3.1.1, 3.2.5 or 3.3.3
> We are using some custom global and user maven settings but only to setup
> some mirrors, some credentials and to (re)define some repositories
> Here are my results jobs on https://aheritier.ci.cloudbees.com
> * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.cloudbees.com (http)
> * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.maven.apache.org (https)
> * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo1.maven.org (http)
> * (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
> * (/) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.maven.apache.org (https)
> * (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo1.maven.org (http)
> * (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.cloudbees.com (http)
> * (/) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.maven.apache.org (https)
> * (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo1.maven.org (http)
> Result: Builds are always working with Maven 3.1.1 while for Maven 3.2.5 and
> 3.3.3 it works only if we use the https access to maven central
> For Maven 3.2 and 3.3 with http repositories the build is frozen and killed
> after the timeout I defined (5 minutes - I did also a test with 1h)
> All builds are frozen at the same point in the download process to grab
> surefire artefacts
> DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
> {code}
> 06:28:06 [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ bowtie
> ---
> 06:28:06 [INFO] Downloading:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
> 06:28:06 [INFO] Downloaded:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
> (3 KB at 3.2 KB/sec)
> 06:28:07 [INFO] Downloading:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
> 06:28:07 [INFO] Downloaded:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
> (3 KB at 42.7 KB/sec)
> 06:28:07 [INFO] Downloading:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
> 06:28:07 [INFO] Downloaded:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
> (6 KB at 52.9 KB/sec)
> 06:28:07 [INFO] Downloading:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
> 06:28:07 [INFO] Downloaded:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
> (2 KB at 2.2 KB/sec)
> 06:28:07 [INFO] Downloading:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
> 06:28:07 [INFO] Downloaded:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
> (16 KB at 154.9 KB/sec)
> 06:28:08 [INFO] Downloading:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
> 06:28:08 [INFO] Downloaded:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
> (2 KB at 62.8 KB/sec)
>
[jira] [Commented] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
[
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734624#comment-16734624
]
Michael Osipov commented on MNG-5869:
-
Is this one still valid?
> Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
>
>
> Key: MNG-5869
> URL: https://issues.apache.org/jira/browse/MNG-5869
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.2.5, 3.3.3
>Reporter: Arnaud HERITIER
>Priority: Major
> Attachments: settings.xml, threaddumps.log
>
>
> We recently discovered a strange bug of frozen dependencies downloads
> I didn't yet studied a lot the issue but I guess it may be something in
> recent versions of Wagon.
> I created few jobs to demonstrate the Maven issue and I would like to have
> some guidance to deeply analyse it.
> The project used is https://github.com/kenzanmedia/bowtie/ which has a really
> simple Maven build : https://github.com/kenzanmedia/bowtie/blob/master/pom.xml
> All my builds are using Apache Maven in versions 3.1.1, 3.2.5 or 3.3.3
> We are using some custom global and user maven settings but only to setup
> some mirrors, some credentials and to (re)define some repositories
> Here are my results jobs on https://aheritier.ci.cloudbees.com
> * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.cloudbees.com (http)
> * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.maven.apache.org (https)
> * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo1.maven.org (http)
> * (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
> * (/) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.maven.apache.org (https)
> * (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo1.maven.org (http)
> * (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.cloudbees.com (http)
> * (/) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.maven.apache.org (https)
> * (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo1.maven.org (http)
> Result: Builds are always working with Maven 3.1.1 while for Maven 3.2.5 and
> 3.3.3 it works only if we use the https access to maven central
> For Maven 3.2 and 3.3 with http repositories the build is frozen and killed
> after the timeout I defined (5 minutes - I did also a test with 1h)
> All builds are frozen at the same point in the download process to grab
> surefire artefacts
> DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
> {code}
> 06:28:06 [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ bowtie
> ---
> 06:28:06 [INFO] Downloading:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
> 06:28:06 [INFO] Downloaded:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
> (3 KB at 3.2 KB/sec)
> 06:28:07 [INFO] Downloading:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
> 06:28:07 [INFO] Downloaded:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
> (3 KB at 42.7 KB/sec)
> 06:28:07 [INFO] Downloading:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
> 06:28:07 [INFO] Downloaded:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
> (6 KB at 52.9 KB/sec)
> 06:28:07 [INFO] Downloading:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
> 06:28:07 [INFO] Downloaded:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
> (2 KB at 2.2 KB/sec)
> 06:28:07 [INFO] Downloading:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
> 06:28:07 [INFO] Downloaded:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
> (16 KB at 154.9 KB/sec)
> 06:28:08 [INFO] Downloading:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
> 06:28:08 [INFO] Downloaded:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
> (2 KB at 62.8 KB/sec)
> 06:28:08 [INFO] Downloading:
>
[jira] [Closed] (MRELEASE-916) release:prepare attempts to push to different git repo
[
https://issues.apache.org/jira/browse/MRELEASE-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MRELEASE-916.
---
Resolution: Incomplete
No information provided for years.
> release:prepare attempts to push to different git repo
> --
>
> Key: MRELEASE-916
> URL: https://issues.apache.org/jira/browse/MRELEASE-916
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.5.2
>Reporter: Steve Suehs
>Priority: Major
>
> The documentation describing the scm format is at:
> https://maven.apache.org/scm/git.html
> and it suggests the format
> {code}
> scm:git:ssh://github.com/path_to_repository
> {code}
> Ours is similar to (redacted)
> {code}
>
> https://github.com/mycompany/my_api/
>
> scm:git:ssh://g...@github.com:mycompany/my_api.git
>
> scm:git:ssh://g...@github.com:mycompany/my_api.git
>
> {code}
> When the maven-release-plugin attempts to push, it specifies
> {code}
> Executing: /bin/sh -c cd /home/ssuehs/work/my_api && git push
> ssh://g...@github.com:mycompany/my_api.git
> refs/heads/mvnreleasework:refs/heads/mvnreleasework
> {code}
> Note the {{ssh}}. In deed, executing this from an interactive command prompt
> also does not work.
> Which is correct? The documentation? The plugin? Or could be I am just wrong.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6525) Create Maven Installer
[ https://issues.apache.org/jira/browse/MNG-6525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734617#comment-16734617 ] Sylwester Lachiewicz commented on MNG-6525: --- We have lots of external community tools to do that - to install Maven on Ubuntu: apt-get install maven On Windows, You can use [https://chocolatey.org/packages/maven] and for Mac, [https://formulae.brew.sh/formula/maven@3.5] probably can work. > Create Maven Installer > -- > > Key: MNG-6525 > URL: https://issues.apache.org/jira/browse/MNG-6525 > Project: Maven > Issue Type: Wish > Components: core >Reporter: Gabriel >Priority: Major > Fix For: wontfix-candidate > > > Instead of unzipping and adding to PATH, please, create a Windows/Linux/Mac > installer, just like Node JS have one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6523) System Dependencies Deprication
[ https://issues.apache.org/jira/browse/MNG-6523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734610#comment-16734610 ] Sylwester Lachiewicz commented on MNG-6523: --- Imagine a library that injects the code into the application. If it is known only to a CI server and no developer can check how its application is modified - a pretty good idea ;-) > System Dependencies Deprication > --- > > Key: MNG-6523 > URL: https://issues.apache.org/jira/browse/MNG-6523 > Project: Maven > Issue Type: Wish >Reporter: Alireza Fattahi >Priority: Major > Fix For: wontfix-candidate > > > Please let me know if this is wrong place for discussions about this. > > As mentioned in > [https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#System_Dependencies] > the System Dependencies will be depreciated and should not be used. > Well this feature seems very useful in some cases and must developers find it > easy to use: > [https://stackoverflow.com/a/4491469/2648077] > [https://stackoverflow.com/a/22300875/2648077] > > Well I wish it wouldn't be deprecated at all :) > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAVADOC-562) Ability to pass --release to Javadoc tool
[
https://issues.apache.org/jira/browse/MJAVADOC-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734608#comment-16734608
]
Michael Osipov commented on MJAVADOC-562:
-
I agree.
> Ability to pass --release to Javadoc tool
> -
>
> Key: MJAVADOC-562
> URL: https://issues.apache.org/jira/browse/MJAVADOC-562
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: jar, javadoc
>Affects Versions: 3.1.0
>Reporter: Gili
>Priority: Major
>
> Users of the {{maven-compiler-plugin}} are able to build in one compiler
> version while targeting an older version. We need the same ability for this
> plugin.
> Justification: https://bugs.openjdk.java.net/browse/JDK-8212233
> Workaround: Build the project using the same JDK version as the project is
> targetting.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-555) Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain module-info.java
[
https://issues.apache.org/jira/browse/MJAVADOC-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734600#comment-16734600
]
Gili commented on MJAVADOC-555:
---
The JDK issue is saying this behavior is by design so nothing was changed.
I'm not sure why the restriction is there for external links having to be
modules. Are you able to ask Doug from Oracle?
> Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain
> module-info.java
> ---
>
> Key: MJAVADOC-555
> URL: https://issues.apache.org/jira/browse/MJAVADOC-555
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (required for Java 11 support)
>Reporter: Gili
>Priority: Major
> Attachments: javadoc-cannot-link-to-automatic-modules.zip,
> testcase.zip, toolchains.xml
>
>
> # Unzip testcase
> # Run {{mvn clean install javadoc:aggregate}}
> # Build fails with: {{Exit code: 2 - javadoc: error - No source files for
> package module2}}
> Per MPLUGIN-341, Maven plugins cannot contain {{module.info.java}}. One of my
> projects builds under Java 11 and is fully modularized except for one module
> which is a Maven plugin. Due to the aforementioned issue, I cannot use
> {{javadoc:aggregate.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6535) Add unit tests for org.apache.maven.model.path.DefaultUrlNormalizer
[ https://issues.apache.org/jira/browse/MNG-6535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MNG-6535: -- Priority: Trivial (was: Major) > Add unit tests for org.apache.maven.model.path.DefaultUrlNormalizer > --- > > Key: MNG-6535 > URL: https://issues.apache.org/jira/browse/MNG-6535 > Project: Maven > Issue Type: Test >Reporter: Louis Mills >Priority: Trivial > Labels: pull-request-available > > These tests were written by Diffblue Cover. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MNG-5817) Maven 3.3, gradle-maven-plugin fails missing class org/slf4j/impl/NewMojoLogger
[
https://issues.apache.org/jira/browse/MNG-5817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz closed MNG-5817.
-
Resolution: Won't Fix
> Maven 3.3, gradle-maven-plugin fails missing class
> org/slf4j/impl/NewMojoLogger
> ---
>
> Key: MNG-5817
> URL: https://issues.apache.org/jira/browse/MNG-5817
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.3.1, 3.3.3
>Reporter: Jim Divine
>Priority: Major
>
> This works with 3.2.5, but fails with 3.3.1 and 3.3.3.
> Error output including stacktrace below.
> {noformat}
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building platform.prodenv 7.3.0.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ platform.prodenv ---
> [INFO]
> [INFO] --- gradle-maven-plugin:1.0.5:invoke (clean) @ platform.prodenv ---
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.441 s
> [INFO] Finished at: 2015-04-29T13:58:11-05:00
> [INFO] Final Memory: 10M/310M
> [INFO]
>
> [ERROR] Failed to execute goal org.fortasoft:gradle-maven-plugin:1.0.5:invoke
> (clean) on project platform.prodenv: Execution clean of goal
> org.fortasoft:gradle-maven-plugin:1.0.5:invoke failed: A required class was
> missing while executing org.fortasoft:gradle-maven-plugin:1.0.5:invoke:
> org/slf4j/impl/NewMojoLogger
> [ERROR] -
> [ERROR] realm =plugin>org.fortasoft:gradle-maven-plugin:1.0.5
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] =
> file:/Users/jdivine/.m2/repository/org/fortasoft/gradle-maven-plugin/1.0.5/gradle-maven-plugin-1.0.5.jar
> [ERROR] urls[1] =
> file:/Users/jdivine/.m2/repository/org/gradle/gradle-tooling-api/1.6/gradle-tooling-api-1.6.jar
> [ERROR] urls[2] =
> file:/Users/jdivine/.m2/repository/org/codehaus/groovy/groovy-all/2.0.6/groovy-all-2.0.6.jar
> [ERROR] urls[3] =
> file:/Users/jdivine/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> [ERROR] Number of foreign imports: 1
> [ERROR] import: Entry[import from realm ClassRealm[maven.api, parent: null]]
> [ERROR]
> [ERROR] -
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.fortasoft:gradle-maven-plugin:1.0.5:invoke (clean) on project
> platform.prodenv: Execution clean of goal
> org.fortasoft:gradle-maven-plugin:1.0.5:invoke failed: A required class was
> missing while executing org.fortasoft:gradle-maven-plugin:1.0.5:invoke:
> org/slf4j/impl/NewMojoLogger
> -
> realm =plugin>org.fortasoft:gradle-maven-plugin:1.0.5
> strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> urls[0] =
> file:/Users/jdivine/.m2/repository/org/fortasoft/gradle-maven-plugin/1.0.5/gradle-maven-plugin-1.0.5.jar
> urls[1] =
> file:/Users/jdivine/.m2/repository/org/gradle/gradle-tooling-api/1.6/gradle-tooling-api-1.6.jar
> urls[2] =
> file:/Users/jdivine/.m2/repository/org/codehaus/groovy/groovy-all/2.0.6/groovy-all-2.0.6.jar
> urls[3] =
> file:/Users/jdivine/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> Number of foreign imports: 1
> import: Entry[import from realm ClassRealm[maven.api, parent: null]]
> -
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> 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)
>
[jira] [Commented] (MNG-5817) Maven 3.3, gradle-maven-plugin fails missing class org/slf4j/impl/NewMojoLogger
[
https://issues.apache.org/jira/browse/MNG-5817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734598#comment-16734598
]
Sylwester Lachiewicz commented on MNG-5817:
---
This issue has been auto closed because it has been inactive for a long period
of time. If you think this issue still applies, retest your problem with the
most recent version of Maven and the affected component, reopen and post your
results.
> Maven 3.3, gradle-maven-plugin fails missing class
> org/slf4j/impl/NewMojoLogger
> ---
>
> Key: MNG-5817
> URL: https://issues.apache.org/jira/browse/MNG-5817
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.3.1, 3.3.3
>Reporter: Jim Divine
>Priority: Major
>
> This works with 3.2.5, but fails with 3.3.1 and 3.3.3.
> Error output including stacktrace below.
> {noformat}
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building platform.prodenv 7.3.0.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ platform.prodenv ---
> [INFO]
> [INFO] --- gradle-maven-plugin:1.0.5:invoke (clean) @ platform.prodenv ---
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.441 s
> [INFO] Finished at: 2015-04-29T13:58:11-05:00
> [INFO] Final Memory: 10M/310M
> [INFO]
>
> [ERROR] Failed to execute goal org.fortasoft:gradle-maven-plugin:1.0.5:invoke
> (clean) on project platform.prodenv: Execution clean of goal
> org.fortasoft:gradle-maven-plugin:1.0.5:invoke failed: A required class was
> missing while executing org.fortasoft:gradle-maven-plugin:1.0.5:invoke:
> org/slf4j/impl/NewMojoLogger
> [ERROR] -
> [ERROR] realm =plugin>org.fortasoft:gradle-maven-plugin:1.0.5
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] =
> file:/Users/jdivine/.m2/repository/org/fortasoft/gradle-maven-plugin/1.0.5/gradle-maven-plugin-1.0.5.jar
> [ERROR] urls[1] =
> file:/Users/jdivine/.m2/repository/org/gradle/gradle-tooling-api/1.6/gradle-tooling-api-1.6.jar
> [ERROR] urls[2] =
> file:/Users/jdivine/.m2/repository/org/codehaus/groovy/groovy-all/2.0.6/groovy-all-2.0.6.jar
> [ERROR] urls[3] =
> file:/Users/jdivine/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> [ERROR] Number of foreign imports: 1
> [ERROR] import: Entry[import from realm ClassRealm[maven.api, parent: null]]
> [ERROR]
> [ERROR] -
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.fortasoft:gradle-maven-plugin:1.0.5:invoke (clean) on project
> platform.prodenv: Execution clean of goal
> org.fortasoft:gradle-maven-plugin:1.0.5:invoke failed: A required class was
> missing while executing org.fortasoft:gradle-maven-plugin:1.0.5:invoke:
> org/slf4j/impl/NewMojoLogger
> -
> realm =plugin>org.fortasoft:gradle-maven-plugin:1.0.5
> strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> urls[0] =
> file:/Users/jdivine/.m2/repository/org/fortasoft/gradle-maven-plugin/1.0.5/gradle-maven-plugin-1.0.5.jar
> urls[1] =
> file:/Users/jdivine/.m2/repository/org/gradle/gradle-tooling-api/1.6/gradle-tooling-api-1.6.jar
> urls[2] =
> file:/Users/jdivine/.m2/repository/org/codehaus/groovy/groovy-all/2.0.6/groovy-all-2.0.6.jar
> urls[3] =
> file:/Users/jdivine/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> Number of foreign imports: 1
> import: Entry[import from realm ClassRealm[maven.api, parent: null]]
> -
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> 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
>
[jira] [Commented] (MJAVADOC-555) Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain module-info.java
[
https://issues.apache.org/jira/browse/MJAVADOC-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734594#comment-16734594
]
Robert Scholte commented on MJAVADOC-555:
-
Looking closer to the exception:
https://google.github.io/guava/releases/27.0.1-jre/api/docs/ is indeed plain
old javadoc, it doesn't contain modules as we want to generate here.
I think this is a weird restriction, is there a reason why the external links
should be module-based too?
> Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain
> module-info.java
> ---
>
> Key: MJAVADOC-555
> URL: https://issues.apache.org/jira/browse/MJAVADOC-555
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (required for Java 11 support)
>Reporter: Gili
>Priority: Major
> Attachments: javadoc-cannot-link-to-automatic-modules.zip,
> testcase.zip, toolchains.xml
>
>
> # Unzip testcase
> # Run {{mvn clean install javadoc:aggregate}}
> # Build fails with: {{Exit code: 2 - javadoc: error - No source files for
> package module2}}
> Per MPLUGIN-341, Maven plugins cannot contain {{module.info.java}}. One of my
> projects builds under Java 11 and is fully modularized except for one module
> which is a Maven plugin. Due to the aforementioned issue, I cannot use
> {{javadoc:aggregate.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-555) Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain module-info.java
[
https://issues.apache.org/jira/browse/MJAVADOC-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734585#comment-16734585
]
Robert Scholte commented on MJAVADOC-555:
-
A link to [JDK-8212233|https://bugs.openjdk.java.net/browse/JDK-8212233], but
it is unclear to me what to change (it has been closed as 'not an issue'...)
> Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain
> module-info.java
> ---
>
> Key: MJAVADOC-555
> URL: https://issues.apache.org/jira/browse/MJAVADOC-555
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (required for Java 11 support)
>Reporter: Gili
>Priority: Major
> Attachments: javadoc-cannot-link-to-automatic-modules.zip,
> testcase.zip, toolchains.xml
>
>
> # Unzip testcase
> # Run {{mvn clean install javadoc:aggregate}}
> # Build fails with: {{Exit code: 2 - javadoc: error - No source files for
> package module2}}
> Per MPLUGIN-341, Maven plugins cannot contain {{module.info.java}}. One of my
> projects builds under Java 11 and is fully modularized except for one module
> which is a Maven plugin. Due to the aforementioned issue, I cannot use
> {{javadoc:aggregate.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6275) ServiceLoaderFactory can't find implementations via ClassRealm
[
https://issues.apache.org/jira/browse/MNG-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz updated MNG-6275:
--
Fix Version/s: (was: 3.5.2)
3.x / Backlog
> ServiceLoaderFactory can't find implementations via ClassRealm
> --
>
> Key: MNG-6275
> URL: https://issues.apache.org/jira/browse/MNG-6275
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Reporter: Robert Scholte
>Assignee: Stephen Connolly
>Priority: Critical
> Fix For: 3.x / Backlog
>
>
> Spotted this issue via MANTRUN-200. The reason is that in the
> {{DefaultClassRealmManager}} a new realm is created where the parent
> classLoader is {{null}}. This implies that the bootstrap classloader is used
> as parent.
> With Java8 nashorn has become an extension and is not part of the bootstrap
> classloader anymore.
> It is kind of strange that we want the bootstrap classloader here, it makes
> more sense if the system classloader is used (but with Java 7 and older
> versions of Java this was not an issue, both worked fine).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-2184) Possible problem with @aggregator and forked lifecycles
[
https://issues.apache.org/jira/browse/MNG-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz updated MNG-2184:
--
Priority: Major (was: Blocker)
> Possible problem with @aggregator and forked lifecycles
> ---
>
> Key: MNG-2184
> URL: https://issues.apache.org/jira/browse/MNG-2184
> Project: Maven
> Issue Type: Bug
> Components: Design, Patterns Best Practices, Plugins and
> Lifecycle
>Affects Versions: 2.0.3
> Environment: Revision 974 of Cargo
> (https://svn.codehaus.org/cargo/cargo/trunk/core/api/)
>Reporter: Vincent Massol
>Assignee: John Casey
>Priority: Major
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: cargo.log
>
>
> In the Clover plugin the report mojo is an aggregator
> (http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-clover-plugin/src/main/java/org/apache/maven/plugin/clover/CloverReportMojo.java).
> It also spawns a forked lifecycle:
> {code}
> * @execute phase="test" lifecycle="clover"
> * @aggregator
> {code}
> When I run this clover report on the Cargo API module, which contains
> children modules, all the modules are executed several times as shown in the
> attached logs. They should be executed only once. The @aggregator is supposed
> to execute only once and it executes several times.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config
[ https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MNG-6083: -- Priority: Major (was: Blocker) > Maven 3.3.9 breaks release:perform by not including maven.config > > > Key: MNG-6083 > URL: https://issues.apache.org/jira/browse/MNG-6083 > Project: Maven > Issue Type: Bug > Components: General >Affects Versions: 3.3.9 >Reporter: Robert Patrick >Priority: Major > > Our release process runs both our build and our integration tests. The > integration tests rely on our project root directory's .mvn/maven.config file > to run properly. The maven.config file is NOT checked into the source tree > because it contains environment-specific values so each developer has their > own version of it on each machine on which they build. > This has been working fine for months now but simply changing the version of > Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having > the -Ds defined in $PROJECT_ROOT/.mvn/maven.config. > It appears that the release:perform goal checks out the release source in > another location and with Maven 3.3.9, the maven.config from the original > location is not being used. The build specifies the release-plugin version > so the difference seems to be in the core Maven distribution. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6024) maven-antrun-plugin:instrument failing NoClassDefFoundError: org/slf4j/LoggerFactory
[ https://issues.apache.org/jira/browse/MNG-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MNG-6024: -- Priority: Major (was: Blocker) > maven-antrun-plugin:instrument failing NoClassDefFoundError: > org/slf4j/LoggerFactory > > > Key: MNG-6024 > URL: https://issues.apache.org/jira/browse/MNG-6024 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.3.1, 3.3.3, 3.3.9 > Environment: Window 7, JDK 1.8.0_40 >Reporter: S V Mohana Rao >Priority: Major > Attachments: maven-core-slf4j-issue.zip, mvn-coreslf4j-issue.txt > > > Related issues : MNG-5783, MNG-5817. I was using maven-antrun-plugin added > dependency cobertura which requires slf4j-api dependent jar. Even i tried > using 3.4.0-SNAPSHOT version but problem persists. As i was observed it's > been excluded from the child dependent artifacts of cobertura cause it's part > maven core. But it's not referring from maven core which hasn't been added > class path. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAVADOC-555) Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain module-info.java
[
https://issues.apache.org/jira/browse/MJAVADOC-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734571#comment-16734571
]
Robert Scholte commented on MJAVADOC-555:
-
I'm not using toolchain, I'm running it directly on the JDKs. Just tested it
with JDK12, which succeeds but misses the link. JDK9 and JDK11 work as expected
> Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain
> module-info.java
> ---
>
> Key: MJAVADOC-555
> URL: https://issues.apache.org/jira/browse/MJAVADOC-555
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (required for Java 11 support)
>Reporter: Gili
>Priority: Major
> Attachments: javadoc-cannot-link-to-automatic-modules.zip,
> testcase.zip, toolchains.xml
>
>
> # Unzip testcase
> # Run {{mvn clean install javadoc:aggregate}}
> # Build fails with: {{Exit code: 2 - javadoc: error - No source files for
> package module2}}
> Per MPLUGIN-341, Maven plugins cannot contain {{module.info.java}}. One of my
> projects builds under Java 11 and is fully modularized except for one module
> which is a Maven plugin. Due to the aforementioned issue, I cannot use
> {{javadoc:aggregate.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-555) Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain module-info.java
[
https://issues.apache.org/jira/browse/MJAVADOC-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734568#comment-16734568
]
Hudson commented on MJAVADOC-555:
-
Build failed in Jenkins: Maven TLP » maven-javadoc-plugin » MJAVADOC-555 #2
See
https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/MJAVADOC-555/2/
> Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain
> module-info.java
> ---
>
> Key: MJAVADOC-555
> URL: https://issues.apache.org/jira/browse/MJAVADOC-555
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (required for Java 11 support)
>Reporter: Gili
>Priority: Major
> Attachments: javadoc-cannot-link-to-automatic-modules.zip,
> testcase.zip, toolchains.xml
>
>
> # Unzip testcase
> # Run {{mvn clean install javadoc:aggregate}}
> # Build fails with: {{Exit code: 2 - javadoc: error - No source files for
> package module2}}
> Per MPLUGIN-341, Maven plugins cannot contain {{module.info.java}}. One of my
> projects builds under Java 11 and is fully modularized except for one module
> which is a Maven plugin. Due to the aforementioned issue, I cannot use
> {{javadoc:aggregate.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-5995) Maven itself cannot run without maven-compat
[
https://issues.apache.org/jira/browse/MNG-5995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734563#comment-16734563
]
Sylwester Lachiewicz commented on MNG-5995:
---
No, with my change You can just remove maven-compat.jat from dist and Maven
should run fine for simple projects so it no longer depends on 2.0x classes.
But.. we still have many old plugins and without compat this will not run.
So I used this version to test what plugins are necessary to compile Maven Core
(ie migrate all required plugins to 3.0+ api) and others dev can also test.
So in short - It would b good to include in 3.6.1
> Maven itself cannot run without maven-compat
>
>
> Key: MNG-5995
> URL: https://issues.apache.org/jira/browse/MNG-5995
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap Build, core
>Affects Versions: 3.3.9
>Reporter: Robert Scholte
>Assignee: Sylwester Lachiewicz
>Priority: Critical
> Fix For: 3.6.1
>
>
> For all the 3.0 versions of the maven-plugins we require to not depend on
> maven-compat anymore. However, the Maven distribution still requires
> maven-compat. A simple proof: remove {{lib/maven-compat-3.x.y}} and execute
> {{mvn validate}}.
> You'll get the following exception:
> {noformat}[WARNING] Error injecting:
> org.apache.maven.project.DefaultProjectBuildingHelper
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) No implementation for org.apache.maven.repository.RepositorySystem was
> bound.
> while locating
> org.apache.maven.project.DefaultProjectBuildingHelper{noformat}
> Reason: there's only one implementation: o.a.m.r.l.LegacyRepositorySystem,
> which is part of maven-compat.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-555) Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain module-info.java
[
https://issues.apache.org/jira/browse/MJAVADOC-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734547#comment-16734547
]
Gili commented on MJAVADOC-555:
---
That is really odd. Maybe something is different about our environments.
Do you have toolchain.xml in your home directory pointing to JDK 12-ea+19? I've
attached my toolchain.xml file above.
> Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain
> module-info.java
> ---
>
> Key: MJAVADOC-555
> URL: https://issues.apache.org/jira/browse/MJAVADOC-555
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (required for Java 11 support)
>Reporter: Gili
>Priority: Major
> Attachments: javadoc-cannot-link-to-automatic-modules.zip,
> testcase.zip, toolchains.xml
>
>
> # Unzip testcase
> # Run {{mvn clean install javadoc:aggregate}}
> # Build fails with: {{Exit code: 2 - javadoc: error - No source files for
> package module2}}
> Per MPLUGIN-341, Maven plugins cannot contain {{module.info.java}}. One of my
> projects builds under Java 11 and is fully modularized except for one module
> which is a Maven plugin. Due to the aforementioned issue, I cannot use
> {{javadoc:aggregate.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MJAVADOC-555) Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain module-info.java
[
https://issues.apache.org/jira/browse/MJAVADOC-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gili updated MJAVADOC-555:
--
Attachment: toolchains.xml
> Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain
> module-info.java
> ---
>
> Key: MJAVADOC-555
> URL: https://issues.apache.org/jira/browse/MJAVADOC-555
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (required for Java 11 support)
>Reporter: Gili
>Priority: Major
> Attachments: javadoc-cannot-link-to-automatic-modules.zip,
> testcase.zip, toolchains.xml
>
>
> # Unzip testcase
> # Run {{mvn clean install javadoc:aggregate}}
> # Build fails with: {{Exit code: 2 - javadoc: error - No source files for
> package module2}}
> Per MPLUGIN-341, Maven plugins cannot contain {{module.info.java}}. One of my
> projects builds under Java 11 and is fully modularized except for one module
> which is a Maven plugin. Due to the aforementioned issue, I cannot use
> {{javadoc:aggregate.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-555) Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain module-info.java
[
https://issues.apache.org/jira/browse/MJAVADOC-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734541#comment-16734541
]
Robert Scholte commented on MJAVADOC-555:
-
Just added the other testcase to the branch, works without modification to the
main code.
> Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain
> module-info.java
> ---
>
> Key: MJAVADOC-555
> URL: https://issues.apache.org/jira/browse/MJAVADOC-555
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (required for Java 11 support)
>Reporter: Gili
>Priority: Major
> Attachments: javadoc-cannot-link-to-automatic-modules.zip,
> testcase.zip
>
>
> # Unzip testcase
> # Run {{mvn clean install javadoc:aggregate}}
> # Build fails with: {{Exit code: 2 - javadoc: error - No source files for
> package module2}}
> Per MPLUGIN-341, Maven plugins cannot contain {{module.info.java}}. One of my
> projects builds under Java 11 and is fully modularized except for one module
> which is a Maven plugin. Due to the aforementioned issue, I cannot use
> {{javadoc:aggregate.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-555) Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain module-info.java
[
https://issues.apache.org/jira/browse/MJAVADOC-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734537#comment-16734537
]
Gili commented on MJAVADOC-555:
---
[~rfscholte] I see what you are doing:
* Using --patch-module to compile module2 as if it were a module
* Adding module2 to the list of sources
In theory, this should work for javadoc-cannot-link-to-automatic-modules.zip as
well but in practice it does not. Did you try running that testcase against
your latest code? It doesn't seem to be doing the above patching. I'm not sure
why.
> Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain
> module-info.java
> ---
>
> Key: MJAVADOC-555
> URL: https://issues.apache.org/jira/browse/MJAVADOC-555
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (required for Java 11 support)
>Reporter: Gili
>Priority: Major
> Attachments: javadoc-cannot-link-to-automatic-modules.zip,
> testcase.zip
>
>
> # Unzip testcase
> # Run {{mvn clean install javadoc:aggregate}}
> # Build fails with: {{Exit code: 2 - javadoc: error - No source files for
> package module2}}
> Per MPLUGIN-341, Maven plugins cannot contain {{module.info.java}}. One of my
> projects builds under Java 11 and is fully modularized except for one module
> which is a Maven plugin. Due to the aforementioned issue, I cannot use
> {{javadoc:aggregate.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] eolivelli commented on issue #2: [MJAR-238] Allow setting of module main class
eolivelli commented on issue #2: [MJAR-238] Allow setting of module main class URL: https://github.com/apache/maven-jar-plugin/pull/2#issuecomment-451546885 We are experiencing problems with Windows machines. We have to wait a bit, I am sorry. I will launch the build again as soon as possible. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MJAVADOC-527) detectLinks may pass invalid URLs to javadoc(1)
[ https://issues.apache.org/jira/browse/MJAVADOC-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734474#comment-16734474 ] Hudson commented on MJAVADOC-527: - Build failed in Jenkins: Maven TLP » maven-javadoc-plugin » master #125 See https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/master/125/ > detectLinks may pass invalid URLs to javadoc(1) > --- > > Key: MJAVADOC-527 > URL: https://issues.apache.org/jira/browse/MJAVADOC-527 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.0.1 > Environment: Windows 10 > JDK 8 > Maven 3.5.2 >Reporter: Roberto Benedetti >Assignee: Michael Osipov >Priority: Major > Labels: detectLinks > Fix For: 3.1.0 > > Time Spent: 10m > Remaining Estimate: 0h > > The url of artifact com.sun.mail:mailapi:1.5.5 is > [http://javamail.java.net/mailapi], so the plugin tests if > [http://javamail.java.net/mailapi/apidocs/package-list] is valid. > That url redirects to [https://javaee.github.io/javamail/] which is JavaMail > home page, so the plugin thinks the url is valid and passes it to javadoc. > javadoc warns about invalid link. > Maybe checking if the effective url is still "package-list" would be safer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] plamentotev commented on issue #2: [MJAR-238] Allow setting of module main class
plamentotev commented on issue #2: [MJAR-238] Allow setting of module main class URL: https://github.com/apache/maven-jar-plugin/pull/2#issuecomment-451536961 @eolivelli Looks like the build failed because of some problem with the windows machine (could not delete the workspace) This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] grimsa commented on issue #4: (doc) - Add note on dependecy:tree -Dverbose support in 3.0+
grimsa commented on issue #4: (doc) - Add note on dependecy:tree -Dverbose support in 3.0+ URL: https://github.com/apache/maven-dependency-plugin/pull/4#issuecomment-451534166 Rebased on master. Also updated the suggestion to use an older version of the plugin instead of debug flag (`-X` ). This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MJAVADOC-555) Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain module-info.java
[
https://issues.apache.org/jira/browse/MJAVADOC-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734469#comment-16734469
]
Robert Scholte commented on MJAVADOC-555:
-
To see my result, clone the project and run {{mvn verify -Prun-its
-Dinvoker.test=MJAVADOC-555* -Dmaven.test.skip}} and have a look at the
following files in {{target/it/MJAVADOC-555_aggr_mixed/target/site/apidocs}}:
javadoc options packages argfile.
> Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain
> module-info.java
> ---
>
> Key: MJAVADOC-555
> URL: https://issues.apache.org/jira/browse/MJAVADOC-555
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (required for Java 11 support)
>Reporter: Gili
>Priority: Major
> Attachments: javadoc-cannot-link-to-automatic-modules.zip,
> testcase.zip
>
>
> # Unzip testcase
> # Run {{mvn clean install javadoc:aggregate}}
> # Build fails with: {{Exit code: 2 - javadoc: error - No source files for
> package module2}}
> Per MPLUGIN-341, Maven plugins cannot contain {{module.info.java}}. One of my
> projects builds under Java 11 and is fully modularized except for one module
> which is a Maven plugin. Due to the aforementioned issue, I cannot use
> {{javadoc:aggregate.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-555) Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain module-info.java
[
https://issues.apache.org/jira/browse/MJAVADOC-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734445#comment-16734445
]
Gili commented on MJAVADOC-555:
---
[~rfscholte] I just noticed our comments crossed paths. I checked out your
MJAVADOC-555 branch and ran it against
javadoc-cannot-link-to-automatic-modules.zip but the test still fails. So it
seems we've got another loose end to tie up.
> Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain
> module-info.java
> ---
>
> Key: MJAVADOC-555
> URL: https://issues.apache.org/jira/browse/MJAVADOC-555
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (required for Java 11 support)
>Reporter: Gili
>Priority: Major
> Attachments: javadoc-cannot-link-to-automatic-modules.zip,
> testcase.zip
>
>
> # Unzip testcase
> # Run {{mvn clean install javadoc:aggregate}}
> # Build fails with: {{Exit code: 2 - javadoc: error - No source files for
> package module2}}
> Per MPLUGIN-341, Maven plugins cannot contain {{module.info.java}}. One of my
> projects builds under Java 11 and is fully modularized except for one module
> which is a Maven plugin. Due to the aforementioned issue, I cannot use
> {{javadoc:aggregate.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MJAVADOC-527) detectLinks may pass invalid URLs to javadoc(1)
[ https://issues.apache.org/jira/browse/MJAVADOC-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MJAVADOC-527. --- Resolution: Fixed Fixed with [34fccfb151ba0603556d57e1972ac897bce05a5e|https://gitbox.apache.org/repos/asf?p=maven-javadoc-plugin.git;a=commit;h=34fccfb151ba0603556d57e1972ac897bce05a5e]. > detectLinks may pass invalid URLs to javadoc(1) > --- > > Key: MJAVADOC-527 > URL: https://issues.apache.org/jira/browse/MJAVADOC-527 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.0.1 > Environment: Windows 10 > JDK 8 > Maven 3.5.2 >Reporter: Roberto Benedetti >Assignee: Michael Osipov >Priority: Major > Labels: detectLinks > Fix For: 3.1.0 > > Time Spent: 10m > Remaining Estimate: 0h > > The url of artifact com.sun.mail:mailapi:1.5.5 is > [http://javamail.java.net/mailapi], so the plugin tests if > [http://javamail.java.net/mailapi/apidocs/package-list] is valid. > That url redirects to [https://javaee.github.io/javamail/] which is JavaMail > home page, so the plugin thinks the url is valid and passes it to javadoc. > javadoc warns about invalid link. > Maybe checking if the effective url is still "package-list" would be safer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] asfgit closed pull request #4: [MJAVADOC-527] - detectLinks may pass invalid urls to javadoc
asfgit closed pull request #4: [MJAVADOC-527] - detectLinks may pass invalid
urls to javadoc
URL: https://github.com/apache/maven-javadoc-plugin/pull/4
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java
b/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java
index 7ae705b..a068b74 100644
--- a/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java
+++ b/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java
@@ -1766,7 +1766,7 @@
DEFAULT_JAVA_API_LINKS.put( "api_1.8",
"https://docs.oracle.com/javase/8/docs/api/; );
DEFAULT_JAVA_API_LINKS.put( "api_9",
"https://docs.oracle.com/javase/9/docs/api/; );
DEFAULT_JAVA_API_LINKS.put( "api_10",
"https://docs.oracle.com/javase/10/docs/api/; );
-DEFAULT_JAVA_API_LINKS.put( "api_11",
"https://docs.oracle.com/en/java/javase/11/docs/api; );
+DEFAULT_JAVA_API_LINKS.put( "api_11",
"https://docs.oracle.com/en/java/javase/11/docs/api/; );
}
// --
diff --git a/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java
b/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java
index e2f9b26..7b21981 100644
--- a/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java
+++ b/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java
@@ -33,10 +33,13 @@
import org.apache.http.client.protocol.HttpClientContext;
import org.apache.http.conn.params.ConnRoutePNames;
import org.apache.http.impl.client.DefaultHttpClient;
+import org.apache.http.impl.client.RedirectLocations;
import org.apache.http.impl.conn.PoolingClientConnectionManager;
import org.apache.http.message.BasicHeader;
import org.apache.http.params.CoreConnectionPNames;
import org.apache.http.params.CoreProtocolPNames;
+import org.apache.http.protocol.BasicHttpContext;
+import org.apache.http.protocol.HttpContext;
import org.apache.maven.plugin.logging.Log;
import org.apache.maven.project.MavenProject;
import org.apache.maven.settings.Proxy;
@@ -1679,14 +1682,15 @@ private static BufferedReader getReader( URL url,
Settings settings ) throws IOE
final HttpGet httpMethod = new HttpGet( url.toString() );
HttpResponse response;
+HttpContext context = new BasicHttpContext();
try
{
-response = httpClient.execute( httpMethod );
+response = httpClient.execute( httpMethod, context );
}
catch ( SocketTimeoutException e )
{
// could be a sporadic failure, one more retry before we give
up
-response = httpClient.execute( httpMethod );
+response = httpClient.execute( httpMethod, context );
}
int status = response.getStatusLine().getStatusCode();
@@ -1695,6 +1699,23 @@ private static BufferedReader getReader( URL url,
Settings settings ) throws IOE
throw new FileNotFoundException( "Unexpected HTTP status code
" + status + " getting resource "
+ url.toExternalForm() + "." );
}
+else
+{
+int pos = url.getPath().lastIndexOf( '/' );
+RedirectLocations redirects = (RedirectLocations)
+context.getAttribute(
"http.protocol.redirect-locations" );
+if ( pos >= 0 && redirects != null )
+{
+URI location = redirects.get( redirects.size() - 1 );
+String suffix = url.getPath().substring( pos );
+// Redirections shall point to the same file, e.g.
/package-list
+if ( !location.toURL().getPath().endsWith( suffix ) )
+{
+throw new FileNotFoundException( url.toExternalForm()
+ " redirects to "
++ location.toURL().toExternalForm() + "." );
+}
+}
+}
// Intentionally using the platform default encoding here since
this is what Javadoc uses internally.
reader = new BufferedReader( new InputStreamReader(
response.getEntity().getContent() ) )
diff --git
a/src/test/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojoTest.java
b/src/test/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojoTest.java
index 56988f7..83dbb3d 100644
---
a/src/test/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojoTest.java
+++
b/src/test/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojoTest.java
@@ -76,4 +76,15 @@
[jira] [Commented] (MJAVADOC-563) Javadoc generation fails if module name contains restricted keyword in non-terminal position
[
https://issues.apache.org/jira/browse/MJAVADOC-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734434#comment-16734434
]
Gili commented on MJAVADOC-563:
---
Quoting
[https://github.com/codehaus-plexus/plexus-languages/issues/23#issuecomment-451519954:]
{quote}This is already fixed in QDox ( have a closer look at the stacktrace )
and plexus-java is already using its latest version.
The problem here is that maven-javadoc-plugin also has a direct dependency on
QDox, used for the several javadoc:fix goals. However, in the plugin the
version hasn't been updated yet.
The solution is quite simple, ensure that the maven-javadoc-plugin is using
the latest version of QDox too.
{quote}
> Javadoc generation fails if module name contains restricted keyword in
> non-terminal position
>
>
> Key: MJAVADOC-563
> URL: https://issues.apache.org/jira/browse/MJAVADOC-563
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.1.0
>Reporter: Gili
>Priority: Major
>
> Please incorporate the fix to
> https://github.com/codehaus-plexus/plexus-languages/issues/23 once it becomes
> available.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MJAVADOC-555) Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain module-info.java
[
https://issues.apache.org/jira/browse/MJAVADOC-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734428#comment-16734428
]
Gili edited comment on MJAVADOC-555 at 1/4/19 6:11 PM:
---
You mentioned that you managed to work around this problem using automatic
modules so I tried the following:
* Main project is a named module that depends upon an automatic module (in this
case, guava). Note that this is an external dependency so maven-javadoc-plugin
can't really alter its contents.
* Run {{mvn clean install}}.
* The project builds but javadoc generation fails with *The code being
documented uses modules but the packages defined in
https://google.github.io/guava/releases/27.0.1-jre/api/docs/ are in the unnamed
module.*
I've attached this testcase as javadoc-cannot-link-to-automatic-modules.zip for
your review.
Please let me know how to reproduce your workaround so I can proceed a bit
further with my project which is currently blocked on this. Thank you.
was (Author: cowwoc):
You mentioned that you managed to work around this problem using automatic
modules so I tried the following:
* Main project is a named module that depends upon an automatic module (in this
case, guava). Note that this is an external dependency so maven-javadoc-plugin
can't really alter its contents.
* Run {{mvn clean install}}.
* The project builds but javadoc generation fails with **The code being
documented uses modules but the packages defined in
https://google.github.io/guava/releases/27.0.1-jre/api/docs/ are in the unnamed
module.**
I've attached this testcase as javadoc-cannot-link-to-automatic-modules.zip for
your review.
Please let me know how to reproduce your workaround so I can proceed a bit
further with my project which is currently blocked on this. Thank you.
> Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain
> module-info.java
> ---
>
> Key: MJAVADOC-555
> URL: https://issues.apache.org/jira/browse/MJAVADOC-555
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (required for Java 11 support)
>Reporter: Gili
>Priority: Major
> Attachments: javadoc-cannot-link-to-automatic-modules.zip,
> testcase.zip
>
>
> # Unzip testcase
> # Run {{mvn clean install javadoc:aggregate}}
> # Build fails with: {{Exit code: 2 - javadoc: error - No source files for
> package module2}}
> Per MPLUGIN-341, Maven plugins cannot contain {{module.info.java}}. One of my
> projects builds under Java 11 and is fully modularized except for one module
> which is a Maven plugin. Due to the aforementioned issue, I cannot use
> {{javadoc:aggregate.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-555) Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain module-info.java
[
https://issues.apache.org/jira/browse/MJAVADOC-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734428#comment-16734428
]
Gili commented on MJAVADOC-555:
---
You mentioned that you managed to work around this problem using automatic
modules so I tried the following:
* Main project is a named module that depends upon an automatic module (in this
case, guava). Note that this is an external dependency so maven-javadoc-plugin
can't really alter its contents.
* Run {{mvn clean install}}.
* The project builds but javadoc generation fails with **The code being
documented uses modules but the packages defined in
https://google.github.io/guava/releases/27.0.1-jre/api/docs/ are in the unnamed
module.**
I've attached this testcase as javadoc-cannot-link-to-automatic-modules.zip for
your review.
Please let me know how to reproduce your workaround so I can proceed a bit
further with my project which is currently blocked on this. Thank you.
> Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain
> module-info.java
> ---
>
> Key: MJAVADOC-555
> URL: https://issues.apache.org/jira/browse/MJAVADOC-555
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (required for Java 11 support)
>Reporter: Gili
>Priority: Major
> Attachments: javadoc-cannot-link-to-automatic-modules.zip,
> testcase.zip
>
>
> # Unzip testcase
> # Run {{mvn clean install javadoc:aggregate}}
> # Build fails with: {{Exit code: 2 - javadoc: error - No source files for
> package module2}}
> Per MPLUGIN-341, Maven plugins cannot contain {{module.info.java}}. One of my
> projects builds under Java 11 and is fully modularized except for one module
> which is a Maven plugin. Due to the aforementioned issue, I cannot use
> {{javadoc:aggregate.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-555) Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain module-info.java
[
https://issues.apache.org/jira/browse/MJAVADOC-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734426#comment-16734426
]
Robert Scholte commented on MJAVADOC-555:
-
It is already fixed, see
https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/MJAVADOC-555/
I'll wait for MJAVADOC-527 to be merged, then I'll merge this issue.
> Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain
> module-info.java
> ---
>
> Key: MJAVADOC-555
> URL: https://issues.apache.org/jira/browse/MJAVADOC-555
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (required for Java 11 support)
>Reporter: Gili
>Priority: Major
> Attachments: javadoc-cannot-link-to-automatic-modules.zip,
> testcase.zip
>
>
> # Unzip testcase
> # Run {{mvn clean install javadoc:aggregate}}
> # Build fails with: {{Exit code: 2 - javadoc: error - No source files for
> package module2}}
> Per MPLUGIN-341, Maven plugins cannot contain {{module.info.java}}. One of my
> projects builds under Java 11 and is fully modularized except for one module
> which is a Maven plugin. Due to the aforementioned issue, I cannot use
> {{javadoc:aggregate.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MJAVADOC-555) Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain module-info.java
[
https://issues.apache.org/jira/browse/MJAVADOC-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gili updated MJAVADOC-555:
--
Attachment: javadoc-cannot-link-to-automatic-modules.zip
> Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain
> module-info.java
> ---
>
> Key: MJAVADOC-555
> URL: https://issues.apache.org/jira/browse/MJAVADOC-555
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (required for Java 11 support)
>Reporter: Gili
>Priority: Major
> Attachments: javadoc-cannot-link-to-automatic-modules.zip,
> testcase.zip
>
>
> # Unzip testcase
> # Run {{mvn clean install javadoc:aggregate}}
> # Build fails with: {{Exit code: 2 - javadoc: error - No source files for
> package module2}}
> Per MPLUGIN-341, Maven plugins cannot contain {{module.info.java}}. One of my
> projects builds under Java 11 and is fully modularized except for one module
> which is a Maven plugin. Due to the aforementioned issue, I cannot use
> {{javadoc:aggregate.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] kwin commented on issue #9: [MJAVADOC-513] make order of classpath predictable
kwin commented on issue #9: [MJAVADOC-513] make order of classpath predictable URL: https://github.com/apache/maven-javadoc-plugin/pull/9#issuecomment-451520042 @michael-o This has been partially merged already. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] kwin closed pull request #9: [MJAVADOC-513] make order of classpath predictable
kwin closed pull request #9: [MJAVADOC-513] make order of classpath predictable
URL: https://github.com/apache/maven-javadoc-plugin/pull/9
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java
b/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java
index e19b68f..f1fe71a 100644
--- a/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java
+++ b/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java
@@ -117,7 +117,6 @@
import java.util.Calendar;
import java.util.Collection;
import java.util.Collections;
-import java.util.HashMap;
import java.util.HashSet;
import java.util.LinkedHashMap;
import java.util.LinkedHashSet;
@@ -2596,7 +2595,18 @@ private String getSourcePath( Collection
sourcePaths )
throws MavenReportException
{
List classpathElements = new ArrayList<>();
-Map compileArtifactMap = new HashMap<>();
+// keep the insertion order
+Map compileArtifactMap = new LinkedHashMap<>();
+
+if ( additionalDependencies != null )
+{
+for ( Dependency dependency : additionalDependencies )
+{
+Artifact artifact = resolveDependency( dependency );
+getLog().debug( "add additional artifact with path " +
artifact.getFile() );
+classpathElements.add( artifact.getFile() );
+}
+}
if ( isTest() )
{
@@ -2667,16 +2677,6 @@ private String getSourcePath( Collection
sourcePaths )
classpathElements.add( a.getFile() );
}
-if ( additionalDependencies != null )
-{
-for ( Dependency dependency : additionalDependencies )
-{
-Artifact artifact = resolveDependency( dependency );
-getLog().debug( "add additional artifact with path " +
artifact.getFile() );
-classpathElements.add( artifact.getFile() );
-}
-}
-
return classpathElements;
}
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Updated] (MDEP-625) Upgrade maven-artifact-transfer to 0.10.1
[ https://issues.apache.org/jira/browse/MDEP-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MDEP-625: - Summary: Upgrade maven-artifact-transfer to 0.10.1 (was: Upgrade maven-artifact-transfer to 0.10.0) > Upgrade maven-artifact-transfer to 0.10.1 > - > > Key: MDEP-625 > URL: https://issues.apache.org/jira/browse/MDEP-625 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.1.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.1.2 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] khmarbaise commented on issue #4: (doc) - Add note on dependecy:tree -Dverbose support in 3.0+
khmarbaise commented on issue #4: (doc) - Add note on dependecy:tree -Dverbose support in 3.0+ URL: https://github.com/apache/maven-dependency-plugin/pull/4#issuecomment-451517732 Hi, could you please so kind to rebase your PR against most recent master. I appreciate to merge you PR This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] khmarbaise commented on issue #8: [MDEP-613] - Fixes bug Analyze failed: Unsupported class file major version 55 (Java 11)
khmarbaise commented on issue #8: [MDEP-613] - Fixes bug Analyze failed: Unsupported class file major version 55 (Java 11) URL: https://github.com/apache/maven-dependency-plugin/pull/8#issuecomment-451516848 Ok. Build your PR successfully. Thanks for your contribution. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] khmarbaise closed pull request #8: [MDEP-613] - Fixes bug Analyze failed: Unsupported class file major version 55 (Java 11)
khmarbaise closed pull request #8: [MDEP-613] - Fixes bug Analyze failed: Unsupported class file major version 55 (Java 11) URL: https://github.com/apache/maven-dependency-plugin/pull/8 This is a PR merged from a forked repository. As GitHub hides the original diff on merge, it is displayed below for the sake of provenance: As this is a foreign pull request (from a fork), the diff is supplied below (as it won't show otherwise due to GitHub magic): diff --git a/pom.xml b/pom.xml index 378e0d5..5496cb4 100644 --- a/pom.xml +++ b/pom.xml @@ -207,7 +207,7 @@ under the License. org.apache.maven.shared maven-dependency-analyzer - 1.10 + 1.11.1 maven-project This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MDEP-613) Analyze failed: Unsupported class file major version 55 (Java 11)
[
https://issues.apache.org/jira/browse/MDEP-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734384#comment-16734384
]
Hudson commented on MDEP-613:
-
Build succeeded in Jenkins: Maven TLP » maven-dependency-plugin » master #54
See
https://builds.apache.org/job/maven-box/job/maven-dependency-plugin/job/master/54/
> Analyze failed: Unsupported class file major version 55 (Java 11)
> -
>
> Key: MDEP-613
> URL: https://issues.apache.org/jira/browse/MDEP-613
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.1.0
>Reporter: Mincong Huang
>Assignee: Karl Heinz Marbaise
>Priority: Major
> Labels: up-for-grabs
> Fix For: 3.1.2
>
> Attachments: log.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Class file of major version 55 (Java 11) is not yet supported by Maven
> Dependency Plugin. So when running command {{mvn dependency:analysis}} on
> classes created by Java 11, il failed. See {{log.txt}} for the full log trace.
> This is caused by ASM, which does not support major version 55 (Java 11) yet.
> However, their HEAD contains already the solution, so using the SNAPSHOT
> version will work. This support will be included in the next release 6.2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-527) detectLinks may pass invalid URLs to javadoc(1)
[ https://issues.apache.org/jira/browse/MJAVADOC-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734358#comment-16734358 ] Hudson commented on MJAVADOC-527: - Build failed in Jenkins: Maven TLP » maven-javadoc-plugin » MJAVADOC-527 #4 See https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/MJAVADOC-527/4/ > detectLinks may pass invalid URLs to javadoc(1) > --- > > Key: MJAVADOC-527 > URL: https://issues.apache.org/jira/browse/MJAVADOC-527 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.0.1 > Environment: Windows 10 > JDK 8 > Maven 3.5.2 >Reporter: Roberto Benedetti >Assignee: Michael Osipov >Priority: Major > Labels: detectLinks > Fix For: 3.1.0 > > > The url of artifact com.sun.mail:mailapi:1.5.5 is > [http://javamail.java.net/mailapi], so the plugin tests if > [http://javamail.java.net/mailapi/apidocs/package-list] is valid. > That url redirects to [https://javaee.github.io/javamail/] which is JavaMail > home page, so the plugin thinks the url is valid and passes it to javadoc. > javadoc warns about invalid link. > Maybe checking if the effective url is still "package-list" would be safer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] michael-o commented on issue #9: [MJAVADOC-513] make order of classpath predictable
michael-o commented on issue #9: [MJAVADOC-513] make order of classpath predictable URL: https://github.com/apache/maven-javadoc-plugin/pull/9#issuecomment-451509703 I agree with @rfscholte . This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MJAVADOC-527) detectLinks may pass invalid URLs to javadoc(1)
[ https://issues.apache.org/jira/browse/MJAVADOC-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734359#comment-16734359 ] Hudson commented on MJAVADOC-527: - Build failed in Jenkins: Maven TLP » maven-javadoc-plugin » MJAVADOC-527 #5 See https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/MJAVADOC-527/5/ > detectLinks may pass invalid URLs to javadoc(1) > --- > > Key: MJAVADOC-527 > URL: https://issues.apache.org/jira/browse/MJAVADOC-527 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.0.1 > Environment: Windows 10 > JDK 8 > Maven 3.5.2 >Reporter: Roberto Benedetti >Assignee: Michael Osipov >Priority: Major > Labels: detectLinks > Fix For: 3.1.0 > > > The url of artifact com.sun.mail:mailapi:1.5.5 is > [http://javamail.java.net/mailapi], so the plugin tests if > [http://javamail.java.net/mailapi/apidocs/package-list] is valid. > That url redirects to [https://javaee.github.io/javamail/] which is JavaMail > home page, so the plugin thinks the url is valid and passes it to javadoc. > javadoc warns about invalid link. > Maybe checking if the effective url is still "package-list" would be safer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MDEP-613) Analyze failed: Unsupported class file major version 55 (Java 11)
[
https://issues.apache.org/jira/browse/MDEP-613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MDEP-613.
Resolution: Done
> Analyze failed: Unsupported class file major version 55 (Java 11)
> -
>
> Key: MDEP-613
> URL: https://issues.apache.org/jira/browse/MDEP-613
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.1.0
>Reporter: Mincong Huang
>Assignee: Karl Heinz Marbaise
>Priority: Major
> Labels: up-for-grabs
> Fix For: 3.1.2
>
> Attachments: log.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Class file of major version 55 (Java 11) is not yet supported by Maven
> Dependency Plugin. So when running command {{mvn dependency:analysis}} on
> classes created by Java 11, il failed. See {{log.txt}} for the full log trace.
> This is caused by ASM, which does not support major version 55 (Java 11) yet.
> However, their HEAD contains already the solution, so using the SNAPSHOT
> version will work. This support will be included in the next release 6.2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MDEP-613) Analyze failed: Unsupported class file major version 55 (Java 11)
[
https://issues.apache.org/jira/browse/MDEP-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734352#comment-16734352
]
Karl Heinz Marbaise commented on MDEP-613:
--
Done in
[c756d9edcff039aebe9a0e2d150ad4af49b60b10|https://gitbox.apache.org/repos/asf?p=maven-dependency-plugin.git;a=commitdiff;h=c756d9edcff039aebe9a0e2d150ad4af49b60b10]
> Analyze failed: Unsupported class file major version 55 (Java 11)
> -
>
> Key: MDEP-613
> URL: https://issues.apache.org/jira/browse/MDEP-613
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.1.0
>Reporter: Mincong Huang
>Assignee: Karl Heinz Marbaise
>Priority: Major
> Labels: up-for-grabs
> Fix For: 3.1.2
>
> Attachments: log.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Class file of major version 55 (Java 11) is not yet supported by Maven
> Dependency Plugin. So when running command {{mvn dependency:analysis}} on
> classes created by Java 11, il failed. See {{log.txt}} for the full log trace.
> This is caused by ASM, which does not support major version 55 (Java 11) yet.
> However, their HEAD contains already the solution, so using the SNAPSHOT
> version will work. This support will be included in the next release 6.2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MJAVADOC-563) Javadoc generation fails if module name contains restricted keyword in non-terminal position
Gili created MJAVADOC-563: - Summary: Javadoc generation fails if module name contains restricted keyword in non-terminal position Key: MJAVADOC-563 URL: https://issues.apache.org/jira/browse/MJAVADOC-563 Project: Maven Javadoc Plugin Issue Type: Bug Components: jar Affects Versions: 3.1.0 Reporter: Gili Please incorporate the fix to https://github.com/codehaus-plexus/plexus-languages/issues/23 once it becomes available. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MSHARED-793) Support for default value
[
https://issues.apache.org/jira/browse/MSHARED-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734247#comment-16734247
]
Michael Osipov edited comment on MSHARED-793 at 1/4/19 3:44 PM:
Right, so none of these files is being used by Maven, but they are generated by
Maven to be consumed by Spring.
The setup as shown by Michael is exactly what I would expect: your
{{app.properties}} will contains {{$\{toto:tutu}}} while your app-secrets may
or may not contain {{toto=tatu}}
I prefer to solve this at Spring Application level and not by changing the
property-mechanism of Maven. (maybe we should add an example page to the
documentation)
was (Author: rfscholte):
Right, so none of these files is being used by Maven, but they are generated by
Maven to be consumed by Spring.
The setup as shown by Michael is exactly what I whould expect: your
app.properties will contains {{${toto:tutu\}}} while your app-secrets may or
may not contain {{toto=tatu}}
I prefer to solve this at Spring Application level and not by changing the
property-mechanism of Maven. (maybe we should add an example page to the
documentation)
> Support for default value
> -
>
> Key: MSHARED-793
> URL: https://issues.apache.org/jira/browse/MSHARED-793
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-filtering
>Affects Versions: maven-filtering-3.1.2
>Reporter: Jean-Charles Manoury
>Priority: Major
> Labels: pull-request-available
>
> The goal is to manage default value like ${toto:tutu} where tutu is used when
> no value for toto is found.
> It is the same behavior as Spring's
> [PropertyPlaceholderConfigurer|https://www.mkyong.com/spring/spring-propertyplaceholderconfigurer-example/]
> This will make properties files from a Spring project compatible with
> maven-filtering.
> A pull request had been created on Github :
> https://github.com/apache/maven-filtering/pull/1
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHARED-793) Support for default value
[
https://issues.apache.org/jira/browse/MSHARED-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734247#comment-16734247
]
Robert Scholte commented on MSHARED-793:
Right, so none of these files is being used by Maven, but they are generated by
Maven to be consumed by Spring.
The setup as shown by Michael is exactly what I whould expect: your
app.properties will contains {{${toto:tutu\}}} while your app-secrets may or
may not contain {{toto=tatu}}
I prefer to solve this at Spring Application level and not by changing the
property-mechanism of Maven. (maybe we should add an example page to the
documentation)
> Support for default value
> -
>
> Key: MSHARED-793
> URL: https://issues.apache.org/jira/browse/MSHARED-793
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-filtering
>Affects Versions: maven-filtering-3.1.2
>Reporter: Jean-Charles Manoury
>Priority: Major
> Labels: pull-request-available
>
> The goal is to manage default value like ${toto:tutu} where tutu is used when
> no value for toto is found.
> It is the same behavior as Spring's
> [PropertyPlaceholderConfigurer|https://www.mkyong.com/spring/spring-propertyplaceholderconfigurer-example/]
> This will make properties files from a Spring project compatible with
> maven-filtering.
> A pull request had been created on Github :
> https://github.com/apache/maven-filtering/pull/1
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHARED-793) Support for default value
[
https://issues.apache.org/jira/browse/MSHARED-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734231#comment-16734231
]
Michael Osipov commented on MSHARED-793:
I have the exact same case at work. I solved it that way:
The base application has a {{.properties}} file which can be
overridden with {{-custom.properties}} then read by Spring with:
{code}
http://www.w3.org/2001/XMLSchema-instance;
xmlns:beans="http://www.springframework.org/schema/beans;
xmlns:context="http://www.springframework.org/schema/context;
xmlns:c="http://www.springframework.org/schema/c;
xmlns:p="http://www.springframework.org/schema/p;
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context.xsd;>
classpath:com/company/webapp/build.properties
classpath:app.properties
classpath:app-custom.properties
file:${catalina.base}/conf/app-secrets.properties
{code}
> Support for default value
> -
>
> Key: MSHARED-793
> URL: https://issues.apache.org/jira/browse/MSHARED-793
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-filtering
>Affects Versions: maven-filtering-3.1.2
>Reporter: Jean-Charles Manoury
>Priority: Major
> Labels: pull-request-available
>
> The goal is to manage default value like ${toto:tutu} where tutu is used when
> no value for toto is found.
> It is the same behavior as Spring's
> [PropertyPlaceholderConfigurer|https://www.mkyong.com/spring/spring-propertyplaceholderconfigurer-example/]
> This will make properties files from a Spring project compatible with
> maven-filtering.
> A pull request had been created on Github :
> https://github.com/apache/maven-filtering/pull/1
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHARED-793) Support for default value
[
https://issues.apache.org/jira/browse/MSHARED-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734226#comment-16734226
]
Jean-Charles Manoury commented on MSHARED-793:
--
Sorry I shouldn't have mentioned Spring compatibility, it's confusing.
Here an example :
We are using a properties file for each environment of our project (dev, QA,
pre-production, etc...) and we setup this .properties file during the build
with maven-filters (at the end properties are read by Spring but that's not the
point), I would like to avoid empty properties when they are not set
specifically for an environment, that's why I would like to have a default
value.
> Support for default value
> -
>
> Key: MSHARED-793
> URL: https://issues.apache.org/jira/browse/MSHARED-793
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-filtering
>Affects Versions: maven-filtering-3.1.2
>Reporter: Jean-Charles Manoury
>Priority: Major
> Labels: pull-request-available
>
> The goal is to manage default value like ${toto:tutu} where tutu is used when
> no value for toto is found.
> It is the same behavior as Spring's
> [PropertyPlaceholderConfigurer|https://www.mkyong.com/spring/spring-propertyplaceholderconfigurer-example/]
> This will make properties files from a Spring project compatible with
> maven-filtering.
> A pull request had been created on Github :
> https://github.com/apache/maven-filtering/pull/1
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MJAVADOC-561) Not possible to link to JDK classes since Java 11
[
https://issues.apache.org/jira/browse/MJAVADOC-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MJAVADOC-561.
---
Resolution: Not A Problem
Assignee: Michael Osipov
Fix Version/s: (was: waiting-for-feedback)
By consent, this is not a problem in this plugin, but in the JDK scheduled to
be fixed soon.
> Not possible to link to JDK classes since Java 11
> -
>
> Key: MJAVADOC-561
> URL: https://issues.apache.org/jira/browse/MJAVADOC-561
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.1.0
>Reporter: Gili
>Assignee: Michael Osipov
>Priority: Critical
> Attachments: testcase.zip
>
>
> 1. Open testcase
> 2. {{mvn javadoc:jar}}
> 3. Notice that generated Javadoc contains broken link to {{java.lang.Number}}
> It doesn't look like one can link to the JDK as of version 11 because the URL
> structure changed since Java 10.
> Java 10: https://docs.oracle.com/javase/10/docs/api/java/lang/Number.html
> Java 11:
> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Number.html
> Please see https://bugs.openjdk.java.net/browse/JDK-8191363 for a related
> discussion. If any syntax change is required in the pom, please consider
> updating
> https://maven.apache.org/plugins/maven-javadoc-plugin/examples/links-configuration.html
> accordingly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MJAVADOC-555) Javadoc:aggregate, Javadoc:jar fails if one of the modules does not contain module-info.java
[
https://issues.apache.org/jira/browse/MJAVADOC-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gili updated MJAVADOC-555:
--
Component/s: jar
> Javadoc:aggregate, Javadoc:jar fails if one of the modules does not contain
> module-info.java
>
>
> Key: MJAVADOC-555
> URL: https://issues.apache.org/jira/browse/MJAVADOC-555
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (required for Java 11 support)
>Reporter: Gili
>Priority: Major
> Attachments: testcase.zip
>
>
> # Unzip testcase
> # Run {{mvn clean install javadoc:aggregate}}
> # Build fails with: {{Exit code: 2 - javadoc: error - No source files for
> package module2}}
> Per MPLUGIN-341, Maven plugins cannot contain {{module.info.java}}. One of my
> projects builds under Java 11 and is fully modularized except for one module
> which is a Maven plugin. Due to the aforementioned issue, I cannot use
> {{javadoc:aggregate.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] michael-o commented on issue #4: [MJAVADOC-527] - detectLinks may pass invalid urls to javadoc
michael-o commented on issue #4: [MJAVADOC-527] - detectLinks may pass invalid urls to javadoc URL: https://github.com/apache/maven-javadoc-plugin/pull/4#issuecomment-451463405 I have pushed branch MJAVADOC-527, take a look at the history. This what I have expected. I will now go on with the evaluation. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MJAVADOC-555) Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain module-info.java
[
https://issues.apache.org/jira/browse/MJAVADOC-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734204#comment-16734204
]
Gili commented on MJAVADOC-555:
---
{{javadoc:jar}} is similarly impacted. Reading
[https://bugs.openjdk.java.net/browse/JDK-8212233] JDK12 and up will not
support mixing named and unnamed modules.
Maven plugins cannot use Java modules due to MPLUGIN-341. If I try invoke
{{javadoc::jar}} on a Maven plugin (which is an unnamed module) that depends
upon a named module, it fails with the aforementioned error.
Hopefully the fix for {{javadoc:aggregate}} and {{javadoc:jar}} will be the
same.
> Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain
> module-info.java
> ---
>
> Key: MJAVADOC-555
> URL: https://issues.apache.org/jira/browse/MJAVADOC-555
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (required for Java 11 support)
>Reporter: Gili
>Priority: Major
> Attachments: testcase.zip
>
>
> # Unzip testcase
> # Run {{mvn clean install javadoc:aggregate}}
> # Build fails with: {{Exit code: 2 - javadoc: error - No source files for
> package module2}}
> Per MPLUGIN-341, Maven plugins cannot contain {{module.info.java}}. One of my
> projects builds under Java 11 and is fully modularized except for one module
> which is a Maven plugin. Due to the aforementioned issue, I cannot use
> {{javadoc:aggregate.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-561) Not possible to link to JDK classes since Java 11
[
https://issues.apache.org/jira/browse/MJAVADOC-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734194#comment-16734194
]
Michael Osipov commented on MJAVADOC-561:
-
[~cowwoc], can we close this issue as "Not A Problem"?
> Not possible to link to JDK classes since Java 11
> -
>
> Key: MJAVADOC-561
> URL: https://issues.apache.org/jira/browse/MJAVADOC-561
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.1.0
>Reporter: Gili
>Priority: Critical
> Fix For: waiting-for-feedback
>
> Attachments: testcase.zip
>
>
> 1. Open testcase
> 2. {{mvn javadoc:jar}}
> 3. Notice that generated Javadoc contains broken link to {{java.lang.Number}}
> It doesn't look like one can link to the JDK as of version 11 because the URL
> structure changed since Java 10.
> Java 10: https://docs.oracle.com/javase/10/docs/api/java/lang/Number.html
> Java 11:
> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Number.html
> Please see https://bugs.openjdk.java.net/browse/JDK-8191363 for a related
> discussion. If any syntax change is required in the pom, please consider
> updating
> https://maven.apache.org/plugins/maven-javadoc-plugin/examples/links-configuration.html
> accordingly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-561) Not possible to link to JDK classes since Java 11
[
https://issues.apache.org/jira/browse/MJAVADOC-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734202#comment-16734202
]
Gili commented on MJAVADOC-561:
---
[~michael-o] Yes, I'll move the JDK 12 stuff to MJAVADOC-555.
> Not possible to link to JDK classes since Java 11
> -
>
> Key: MJAVADOC-561
> URL: https://issues.apache.org/jira/browse/MJAVADOC-561
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.1.0
>Reporter: Gili
>Priority: Critical
> Fix For: waiting-for-feedback
>
> Attachments: testcase.zip
>
>
> 1. Open testcase
> 2. {{mvn javadoc:jar}}
> 3. Notice that generated Javadoc contains broken link to {{java.lang.Number}}
> It doesn't look like one can link to the JDK as of version 11 because the URL
> structure changed since Java 10.
> Java 10: https://docs.oracle.com/javase/10/docs/api/java/lang/Number.html
> Java 11:
> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Number.html
> Please see https://bugs.openjdk.java.net/browse/JDK-8191363 for a related
> discussion. If any syntax change is required in the pom, please consider
> updating
> https://maven.apache.org/plugins/maven-javadoc-plugin/examples/links-configuration.html
> accordingly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MJAVADOC-555) Javadoc:aggregate, Javadoc:jar fails if one of the modules does not contain module-info.java
[
https://issues.apache.org/jira/browse/MJAVADOC-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gili updated MJAVADOC-555:
--
Summary: Javadoc:aggregate, Javadoc:jar fails if one of the modules does
not contain module-info.java (was: Javadoc:aggregate fails if one of the
modules does not contain module-info.java)
> Javadoc:aggregate, Javadoc:jar fails if one of the modules does not contain
> module-info.java
>
>
> Key: MJAVADOC-555
> URL: https://issues.apache.org/jira/browse/MJAVADOC-555
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.1.0
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (required for Java 11 support)
>Reporter: Gili
>Priority: Major
> Attachments: testcase.zip
>
>
> # Unzip testcase
> # Run {{mvn clean install javadoc:aggregate}}
> # Build fails with: {{Exit code: 2 - javadoc: error - No source files for
> package module2}}
> Per MPLUGIN-341, Maven plugins cannot contain {{module.info.java}}. One of my
> projects builds under Java 11 and is fully modularized except for one module
> which is a Maven plugin. Due to the aforementioned issue, I cannot use
> {{javadoc:aggregate.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MJAVADOC-555) Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain module-info.java
[
https://issues.apache.org/jira/browse/MJAVADOC-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gili updated MJAVADOC-555:
--
Summary: Javadoc:aggregate, Javadoc:jar fail if one of the modules does not
contain module-info.java (was: Javadoc:aggregate, Javadoc:jar fails if one of
the modules does not contain module-info.java)
> Javadoc:aggregate, Javadoc:jar fail if one of the modules does not contain
> module-info.java
> ---
>
> Key: MJAVADOC-555
> URL: https://issues.apache.org/jira/browse/MJAVADOC-555
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (required for Java 11 support)
>Reporter: Gili
>Priority: Major
> Attachments: testcase.zip
>
>
> # Unzip testcase
> # Run {{mvn clean install javadoc:aggregate}}
> # Build fails with: {{Exit code: 2 - javadoc: error - No source files for
> package module2}}
> Per MPLUGIN-341, Maven plugins cannot contain {{module.info.java}}. One of my
> projects builds under Java 11 and is fully modularized except for one module
> which is a Maven plugin. Due to the aforementioned issue, I cannot use
> {{javadoc:aggregate.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] michael-o commented on issue #4: [MJAVADOC-527] - detectLinks may pass invalid urls to javadoc
michael-o commented on issue #4: [MJAVADOC-527] - detectLinks may pass invalid urls to javadoc URL: https://github.com/apache/maven-javadoc-plugin/pull/4#issuecomment-451459020 Thank you, I will take a look at it. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] dedabob commented on issue #4: [MJAVADOC-527] - detectLinks may pass invalid urls to javadoc
dedabob commented on issue #4: [MJAVADOC-527] - detectLinks may pass invalid urls to javadoc URL: https://github.com/apache/maven-javadoc-plugin/pull/4#issuecomment-451457576 Commit 8f6c55b01a691f07989d83b05afb4edb9379e1aa is the new rebase. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
