[jira] [Updated] (MJAR-259) Archiving to jar is very slow
[
https://issues.apache.org/jira/browse/MJAR-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MJAR-259:
---
Description:
Doing a stackdump while "maven-jar-plugin:3.1.0:jar (default-jar)" shows thread
spending a lot of time in UnixNativeDispatcher.getgrgid.
This was not visible in java 8 and jar plugin version 2.6.
Our previous build time has been increased from 5min to 3h 30min.
Tested version Java 11 and 3.1.0 of maven-jar-plugin
{code:xml}
org.apache.maven.plugins
maven-jar-plugin
${maven.jar.plugin.version}
true
true
true
{code}
{noformat}
java.lang.Thread.State: RUNNABLE
at sun.nio.fs.UnixNativeDispatcher.getgrgid(java.base@11/Native Method)
at
sun.nio.fs.UnixUserPrincipals.fromGid(java.base@11/UnixUserPrincipals.java:129)
at
sun.nio.fs.UnixFileAttributes.group(java.base@11/UnixFileAttributes.java:208)
- locked <0x00067c2b31f0> (a sun.nio.fs.UnixFileAttributes)
at
sun.nio.fs.UnixFileAttributeViews$Posix.addRequestedPosixAttributes(java.base@11/UnixFileAttributeViews.java:214)
at
sun.nio.fs.UnixFileAttributeViews$Unix.readAttributes(java.base@11/UnixFileAttributeViews.java:362)
at
sun.nio.fs.AbstractFileSystemProvider.readAttributes(java.base@11/AbstractFileSystemProvider.java:94)
at java.nio.file.Files.readAttributes(java.base@11/Files.java:1996)
at
org.codehaus.plexus.components.io.attributes.FileAttributes.(FileAttributes.java:67)
at
org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.addResources(PlexusIoFileResourceCollection.java:156)
at
org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.getResources(PlexusIoFileResourceCollection.java:254)
at
org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:506)
at
org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:256)
at
org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:234)
at
org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:987)
at
org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:649)
at
org.apache.maven.plugins.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:224)
at
org.apache.maven.plugins.jar.AbstractJarMojo.execute(AbstractJarMojo.java:255)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:200)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:196)
at java.util.concurrent.FutureTask.run(java.base@11/FutureTask.java:264)
at
java.util.concurrent.Executors$RunnableAdapter.call(java.base@11/Executors.java:515)
at java.util.concurrent.FutureTask.run(java.base@11/FutureTask.java:264)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11/ThreadPoolExecutor.java:1128)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11/ThreadPoolExecutor.java:628)
at java.lang.Thread.run(java.base@11/Thread.java:834){noformat}
was:
Doing a stackdump while "maven-jar-plugin:3.1.0:jar (default-jar)" shows thread
spending a lot of time in UnixNativeDispatcher.getgrgid.
This was not visible in java 8 and jar plugin version 2.6.
Our previous build time has been increased from 5min to 3h 30min.
Tested version Java 11 and 3.1.0 of maven-jar-plugin
{code:java}
org.apache.maven.plugins
maven-jar-plugin
${maven.jar.plugin.version}
true
true
true
{code}
{code:java}
java.lang.Thread.State: RUNNABLE
at sun.nio.fs.UnixNativeDispatcher.getgrgid(java.base@11/Native Method)
at
sun.nio.fs.UnixUserPrincipals.fromGid(java.base@11/UnixUserPrincipals.java:129)
at
sun.nio.fs.UnixFileAttributes.group(java.base@11/UnixFileAttributes.java:208)
- locked <0x00067c2b31f0> (a sun.nio.fs.UnixFileAttributes)
at
sun.nio.fs.UnixFileAttributeViews$Posix.addRequestedPosixAttributes(java.base@11/UnixFileAttributeViews.java:214)
at
sun.nio.fs.UnixFileAttributeViews$Unix.readAttributes(java.base@11/UnixFileAttributeViews.java:362)
at
sun.nio.fs.AbstractFileSystemProvider.readAttributes(java.base@11/AbstractFileSystemProvider.java:94)
at java.nio.file.Files.readAttributes(java.base@11/Files.java:1996)
at
org.codehaus.plexus.components.io.attributes.FileAttributes.(FileAttributes.java:67)
at
org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.ad
[jira] [Updated] (MJAR-257) Option to strip non-deterministic aspects of jars post-creation
[ https://issues.apache.org/jira/browse/MJAR-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MJAR-257: --- Summary: Option to strip non-deterministic aspects of jars post-creation (was: Option to strip non-deterministic aspects of jars post-reation) > Option to strip non-deterministic aspects of jars post-creation > --- > > Key: MJAR-257 > URL: https://issues.apache.org/jira/browse/MJAR-257 > Project: Maven JAR Plugin > Issue Type: New Feature >Reporter: Paul Hammant >Priority: Minor > > [https://github.com/esoule/strip-nondeterminism] is a Perl script to do the > same. > These things could be replicated in Java, and it would be good for the > community to attempt to chase some of the features of other build > technologies, and initiatives. > Optional of course: true > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MSOURCES-119) Archiving to jar is very slow
[
https://issues.apache.org/jira/browse/MSOURCES-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MSOURCES-119:
---
Description:
Doing a stackdump while "maven-source-plugin:3.0.0:jar-no-fork
(attach-sources)" shows thread spending a lot of time in
UnixNativeDispatcher.getgrgid.
This was not visible in java 8 and source plugin version 2.4.
Our previous build time has been increased from 5min to 3h 30min.
Tested version Java 11 and 3.0.0 of maven-source-plugin
maven config:
{code:xml}
org.apache.maven.plugins
maven-source-plugin
3.0.0
attach-sources
jar-no-fork
{code}
{noformat}
java.lang.Thread.State: RUNNABLE}}
at sun.nio.fs.UnixNativeDispatcher.getgrgid(java.base@11/Native Method)
at
sun.nio.fs.UnixUserPrincipals.fromGid(java.base@11/UnixUserPrincipals.java:129)
at
sun.nio.fs.UnixFileAttributes.group(java.base@11/UnixFileAttributes.java:208)
- locked <0x0006b0773fd8> (a sun.nio.fs.UnixFileAttributes)
at
sun.nio.fs.UnixFileAttributeViews$Posix.addRequestedPosixAttributes(java.base@11/UnixFileAttributeViews.java:214)
at
sun.nio.fs.UnixFileAttributeViews$Unix.readAttributes(java.base@11/UnixFileAttributeViews.java:362)
at
sun.nio.fs.AbstractFileSystemProvider.readAttributes(java.base@11/AbstractFileSystemProvider.java:94)
at java.nio.file.Files.readAttributes(java.base@11/Files.java:1996)
at
org.codehaus.plexus.components.io.attributes.Java7FileAttributes.(Java7FileAttributes.java:65)
at
org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.addResourcesJava7(PlexusIoFileResourceCollection.java:192)
at
org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.getResources(PlexusIoFileResourceCollection.java:287)
at
org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:504)
at
org.apache.maven.plugins.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:287)
{noformat}
was:
Doing a stackdump while "maven-source-plugin:3.0.0:jar-no-fork
(attach-sources)" shows thread spending a lot of time in
UnixNativeDispatcher.getgrgid.
This was not visible in java 8 and source plugin version 2.4.
Our previous build time has been increased from 5min to 3h 30min.
Tested version Java 11 and 3.0.0 of maven-source-plugin
maven config:
{code:java}
org.apache.maven.plugins
maven-source-plugin
3.0.0
attach-sources
jar-no-fork
{code}
{{java.lang.Thread.State: RUNNABLE}}
{{ at sun.nio.fs.UnixNativeDispatcher.getgrgid(java.base@11/Native Method)}}
{{ at
sun.nio.fs.UnixUserPrincipals.fromGid(java.base@11/UnixUserPrincipals.java:129)}}
{{ at
sun.nio.fs.UnixFileAttributes.group(java.base@11/UnixFileAttributes.java:208)}}
{{ - locked <0x0006b0773fd8> (a sun.nio.fs.UnixFileAttributes)}}
{{ at
sun.nio.fs.UnixFileAttributeViews$Posix.addRequestedPosixAttributes(java.base@11/UnixFileAttributeViews.java:214)}}
{{ at
sun.nio.fs.UnixFileAttributeViews$Unix.readAttributes(java.base@11/UnixFileAttributeViews.java:362)}}
{{ at
sun.nio.fs.AbstractFileSystemProvider.readAttributes(java.base@11/AbstractFileSystemProvider.java:94)}}
{{ at java.nio.file.Files.readAttributes(java.base@11/Files.java:1996)}}
{{ at
org.codehaus.plexus.components.io.attributes.Java7FileAttributes.(Java7FileAttributes.java:65)}}
{{ at
org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.addResourcesJava7(PlexusIoFileResourceCollection.java:192)}}
{{ at
org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.getResources(PlexusIoFileResourceCollection.java:287)}}
{{ at
org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:504)}}
{{ at
org.apache.maven.plugins.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:287)}}
> Archiving to jar is very slow
> -
>
> Key: MSOURCES-119
> URL: https://issues.apache.org/jira/browse/MSOURCES-119
> Project: Maven Source Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
> Environment: RedHat 7
>Reporter: Claes Nordmark
>Priority: Major
>
> Doing a stackdump while "maven-source-plugin:3.0.0:jar-no-fork
> (attach-sources)" shows thread spending a lot of time in
> UnixNativeDispatcher.getgrgid.
> This was not visible in java 8 and source plugin version 2.4.
> Our previous build time has been increased from 5min to 3h 30min.
> Tested version Java 11 and 3.0.0 of maven-source-plugin
> maven config:
> {code:xml}
>
> org.apache.maven.plugins
> maven-source-plugin
> 3.0.0
>
>
> attach-sources
>
>jar-no-fork
>
>
>
> {code}
> {noformat}
> java.lang.Thread.State: RUNNABLE}}
> at sun.nio.fs.UnixNativeDispatcher.getgrgid(java.base@11/Native Method)
> at
> sun.nio.fs.UnixUserPrincipals.fromGid(java.base@
[jira] [Created] (MSOURCES-120) Reproducible Builds: make entries in output jar files reproducible (order + timestamp)
Hervé Boutemy created MSOURCES-120: -- Summary: Reproducible Builds: make entries in output jar files reproducible (order + timestamp) Key: MSOURCES-120 URL: https://issues.apache.org/jira/browse/MSOURCES-120 Project: Maven Source Plugin Issue Type: New Feature Affects Versions: 3.0.1 Reporter: Hervé Boutemy -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MSOURCES-120) Reproducible Builds: make entries in output jar files reproducible (order + timestamp)
[ https://issues.apache.org/jira/browse/MSOURCES-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MSOURCES-120: --- Description: since a jar file is a zip file, entries order and timestamp are a natural source of non Reproducible Builds: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318 > Reproducible Builds: make entries in output jar files reproducible (order + > timestamp) > -- > > Key: MSOURCES-120 > URL: https://issues.apache.org/jira/browse/MSOURCES-120 > Project: Maven Source Plugin > Issue Type: New Feature >Affects Versions: 3.0.1 >Reporter: Hervé Boutemy >Priority: Major > > since a jar file is a zip file, entries order and timestamp are a natural > source of non Reproducible Builds: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MJAR-263) Reproducible Builds: make entries in output jar files reproducible (order + timestamp)
Hervé Boutemy created MJAR-263: -- Summary: Reproducible Builds: make entries in output jar files reproducible (order + timestamp) Key: MJAR-263 URL: https://issues.apache.org/jira/browse/MJAR-263 Project: Maven JAR Plugin Issue Type: New Feature Reporter: Hervé Boutemy since a jar file is a zip file, entries order and timestamp are a natural source of non Reproducible Builds: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318 notice: on MANIFEST.MF content, MJAR-262 is expected to make the default content reproducible -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MJAVADOC-585) Incorrect quoting and escaping of nonProxyHosts-information from settings.xml
Paul Busch created MJAVADOC-585:
---
Summary: Incorrect quoting and escaping of
nonProxyHosts-information from settings.xml
Key: MJAVADOC-585
URL: https://issues.apache.org/jira/browse/MJAVADOC-585
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: jar, javadoc
Affects Versions: 3.1.0
Environment: Maven 3.6.0 on RHEL 7.6 using OpenJDK 1.8.9.191 and Bash;
Maven 3.6.0 on Windows 7 using Oracle JDK 8 Update 201 and Windows-CMD
Reporter: Paul Busch
At my development site, I am behind a proxy server. That proxy server is
configured in my {{settings.xml}} in a corresponding {{proxies/proxy}}-section.
For site-deployments I use an internal server named {{my-site-host}}.
To bypass the proxy for access to {{my-site-host}} and several other hosts in
the local network, there is a {{nonProxyHosts}}-element in the
proxy-configuration-section of my {{settings.xml}} which looks like this:
{code:java}
my-site-host|my-nexus-host
{code}
In an internal project {{linking-project,}} which uses a class {{LinkTarget}}
from another internal project {{link-target}} in its API, I would like to have
the class {{LinkTarget}} in the Javadocs of project {{linking-project}} to be
displayed as links to the Javadocs of project {{link-target}}. The Javadocs of
project {{link-target}} are published on {{my-site-host}} as part of a
maven-site. To achieve the linking I have configured the
{{maven-javadoc-plugin}} in {{linking-project}} as follows:
{code:java}
http://my-site-host/link-target/0.1.0-SNAPSHOT/apidocs
{code}
When the report {{javadoc:javadoc}} or the goal {{javadoc:jar}} is executed
during the build, I get the following warning:
{code:java}
[WARNING] javadoc: warning - Error fetching URL:
http://my-site-host/link-target/0.1.0-SNAPSHOT/apidocs/
{code}
As a result, class {{LinkTarget}} in the generated Javadocs is displayed with
its fully qualified class name and not as a link. The expected behavior would
be class {{LinkTarget}} being displayed using its local name only and with an
underlying link to the Javadocs of that class. The problem occurs on both Linux
and Windows.
The problem also occurs when executing the {{javadoc.(sh|bat)}} script, which
is generated in {{target/site/apidocs}} when {{-Ddebug=true}} is used (on Linux
using Bash; on Windows using Windows-CMD).
The problem seems to be in the handling of the {{nonProxyHosts}}-information
from the {{settings.xml}} in {{AbstractJavadocMojo}}. In method
{{addProxyArg(Commandline)}} this information is (in two places) handled as
follows:
{code:java}
cmd.createArg().setValue( "-J-Dhttp.nonProxyHosts=\""
+ httpProxy.getNonProxyHosts().replace( "|", "^|" ) + "\"" );
{code}
When the report/goal is executed, the {{Commandline}}-object is delegated to
{{CommandLineUtils.executeCommandLine(...)}} which in the end delegates to the
{{javadoc}}-program using {{Runtime.exec(...)}}. {{Runtime.exec(...)}} is fed
the command line parts as an array of Strings and apparently does not need any
quoting and escaping. When looking at it in a debugger the
{{nonProxyHosts}}-information – escaped with the code above – is passed to the
{{javadoc}}-program as
{{"-J-Dhttp.nonProxyHosts=\"my-site-host^|my-nexus-host\""}}. I guess this
value is split by the {{javadoc}}-program at the pipe symbol, resulting in
{{"my-site-host^}} and {{my-nexus-host"}} as the two host names. Thus the
{{javadoc}}-program bypasses the proxy for the nonexisting/nonsense host name
{{"my-site-host^}} (with a leading quote and a trailing caret) but uses the
proxy for the actual host {{my-site-host}} causing the malfuntion and the
warning.
For the sake of the report/goal-execution the above code could be fixed as
follows:
{code:java}
cmd.createArg().setValue( "-J-Dhttp.nonProxyHosts=" +
httpProxy.getNonProxyHosts() );
{code}
i.e. no quoting and no escaping of pipe symbols.
This code change albeit completely breaks the generated
{{javadoc.(sh|bat)}}-scripts generated in {{target/site/apidocs}} with
{{-Ddebug=true}}. While {{Runtime.exec(...)}} *must not* have quoting and
escaping, Windows-CMD and Bash, for which the scripts are generated, *need*
special handling. Otherwise the pipe symbols in {{nonProxyHosts}} will be
interpreted as redirection of output to the input of another program.
The following aspects need to be observed regarding the generation of the debug
scripts:
# The scripts may be based on the {{Commandline}}-object but must have the
pipe symbol escaped.
# Quoting is not necessary when the pipe symbol is properly escaped and the
host-names do not contain whitespace – I would take no-whitespace-hostnames for
granted.
# The pipe symbol must be escaped in the way that matches the platform –
escaping the pip symbol with a caret {{^}} is specific to Windows-CMD, for
Linux/Bash the escaping must
[jira] [Created] (MSITE-835) Maven site generate invalid link with markdown
Dave Newton created MSITE-835: - Summary: Maven site generate invalid link with markdown Key: MSITE-835 URL: https://issues.apache.org/jira/browse/MSITE-835 Project: Maven Site Plugin Issue Type: Bug Affects Versions: 3.7.1 Reporter: Dave Newton When a markdown page index.md has a relative [my link](target.md), maven site plugin : * generate index.html and target.html (Good). * keep md extension : (Invalid link) This make the generated site unusable: the correct link should be -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAVADOC-583) javadoc: error - The code being documented uses modules but the packages defined in {URL} are in the unnamed module
[
https://issues.apache.org/jira/browse/MJAVADOC-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790407#comment-16790407
]
Sjoerd Talsma commented on MJAVADOC-583:
I'm falling from one Javadoc 11 error into another.
Let's close this and I'll re-open separate issues when/if I have a small
reproducable use case via a simple mvn project.
> javadoc: error - The code being documented uses modules but the packages
> defined in {URL} are in the unnamed module
> ---
>
> Key: MJAVADOC-583
> URL: https://issues.apache.org/jira/browse/MJAVADOC-583
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.1.0
> Environment: Travis CI, toolchain with openjdk 11.0.2
>Reporter: Sjoerd Talsma
>Priority: Major
> Attachments:
> context-propagation-dependabot-maven-org.apache.maven.plugins-maven-javadoc-plugin-3.1.0.zip,
> packages-3.0.1, packages-3.1.0
>
>
> My project build with toolchains, using both oracle JDK 8 and openjdk 11.0.2
> generating both 'jar' and 'aggregate-jar' documentation.
> This seems to inversely relate to MJAVADOC-555 somehow.
> The following error occurs:
> {quote}Exit code: 1 - javadoc: error - The code being documented uses modules
> but the packages defined in
> [https://javadoc.io/page/nl.talsmasoftware.context/context-propagation-root/1.0.6-SNAPSHOT/]
> are in the unnamed module
> {quote}
> _source:
> [https://travis-ci.org/talsma-ict/context-propagation/builds/501900168]_
> github:
> [https://github.com/talsma-ict/context-propagation/tree/dependabot/maven/org.apache.maven.plugins-maven-javadoc-plugin-3.1.0]
> pull-request: https://github.com/talsma-ict/context-propagation/pull/108
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MJAVADOC-585) Incorrect quoting and escaping of nonProxyHosts-information from settings.xml
[
https://issues.apache.org/jira/browse/MJAVADOC-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MJAVADOC-585:
Fix Version/s: 3.1.1
> Incorrect quoting and escaping of nonProxyHosts-information from settings.xml
> -
>
> Key: MJAVADOC-585
> URL: https://issues.apache.org/jira/browse/MJAVADOC-585
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0
> Environment: Maven 3.6.0 on RHEL 7.6 using OpenJDK 1.8.9.191 and
> Bash; Maven 3.6.0 on Windows 7 using Oracle JDK 8 Update 201 and Windows-CMD
>Reporter: Paul Busch
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.1.1
>
>
> At my development site, I am behind a proxy server. That proxy server is
> configured in my {{settings.xml}} in a corresponding
> {{proxies/proxy}}-section.
> For site-deployments I use an internal server named {{my-site-host}}.
> To bypass the proxy for access to {{my-site-host}} and several other hosts in
> the local network, there is a {{nonProxyHosts}}-element in the
> proxy-configuration-section of my {{settings.xml}} which looks like this:
> {code:java}
> my-site-host|my-nexus-host
> {code}
> In an internal project {{linking-project,}} which uses a class {{LinkTarget}}
> from another internal project {{link-target}} in its API, I would like to
> have the class {{LinkTarget}} in the Javadocs of project {{linking-project}}
> to be displayed as links to the Javadocs of project {{link-target}}. The
> Javadocs of project {{link-target}} are published on {{my-site-host}} as part
> of a maven-site. To achieve the linking I have configured the
> {{maven-javadoc-plugin}} in {{linking-project}} as follows:
> {code:java}
>
>
> http://my-site-host/link-target/0.1.0-SNAPSHOT/apidocs
>
>
> {code}
> When the report {{javadoc:javadoc}} or the goal {{javadoc:jar}} is executed
> during the build, I get the following warning:
> {code:java}
> [WARNING] javadoc: warning - Error fetching URL:
> http://my-site-host/link-target/0.1.0-SNAPSHOT/apidocs/
> {code}
> As a result, class {{LinkTarget}} in the generated Javadocs is displayed with
> its fully qualified class name and not as a link. The expected behavior would
> be class {{LinkTarget}} being displayed using its local name only and with an
> underlying link to the Javadocs of that class. The problem occurs on both
> Linux and Windows.
> The problem also occurs when executing the {{javadoc.(sh|bat)}} script, which
> is generated in {{target/site/apidocs}} when {{-Ddebug=true}} is used (on
> Linux using Bash; on Windows using Windows-CMD).
> The problem seems to be in the handling of the {{nonProxyHosts}}-information
> from the {{settings.xml}} in {{AbstractJavadocMojo}}. In method
> {{addProxyArg(Commandline)}} this information is (in two places) handled as
> follows:
> {code:java}
> cmd.createArg().setValue( "-J-Dhttp.nonProxyHosts=\""
> + httpProxy.getNonProxyHosts().replace( "|", "^|" ) + "\"" );
> {code}
> When the report/goal is executed, the {{Commandline}}-object is delegated to
> {{CommandLineUtils.executeCommandLine(...)}} which in the end delegates to
> the {{javadoc}}-program using {{Runtime.exec(...)}}. {{Runtime.exec(...)}} is
> fed the command line parts as an array of Strings and apparently does not
> need any quoting and escaping. When looking at it in a debugger the
> {{nonProxyHosts}}-information – escaped with the code above – is passed to
> the {{javadoc}}-program as
> {{"-J-Dhttp.nonProxyHosts=\"my-site-host^|my-nexus-host\""}}. I guess this
> value is split by the {{javadoc}}-program at the pipe symbol, resulting in
> {{"my-site-host^}} and {{my-nexus-host"}} as the two host names. Thus the
> {{javadoc}}-program bypasses the proxy for the nonexisting/nonsense host name
> {{"my-site-host^}} (with a leading quote and a trailing caret) but uses the
> proxy for the actual host {{my-site-host}} causing the malfuntion and the
> warning.
> For the sake of the report/goal-execution the above code could be fixed as
> follows:
> {code:java}
> cmd.createArg().setValue( "-J-Dhttp.nonProxyHosts=" +
> httpProxy.getNonProxyHosts() );
> {code}
> i.e. no quoting and no escaping of pipe symbols.
> This code change albeit completely breaks the generated
> {{javadoc.(sh|bat)}}-scripts generated in {{target/site/apidocs}} with
> {{-Ddebug=true}}. While {{Runtime.exec(...)}} *must not* have quoting and
> escaping, Windows-CMD and Bash, for which the scripts are generated, *need*
> special handling. Otherwise the pipe symbols in {{nonProxyHosts}} will be
> interpreted as redirection of output to the input of another program.
> The following aspects need to be observed regarding the generati
[jira] [Assigned] (MJAVADOC-585) Incorrect quoting and escaping of nonProxyHosts-information from settings.xml
[
https://issues.apache.org/jira/browse/MJAVADOC-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MJAVADOC-585:
---
Assignee: Michael Osipov
> Incorrect quoting and escaping of nonProxyHosts-information from settings.xml
> -
>
> Key: MJAVADOC-585
> URL: https://issues.apache.org/jira/browse/MJAVADOC-585
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0
> Environment: Maven 3.6.0 on RHEL 7.6 using OpenJDK 1.8.9.191 and
> Bash; Maven 3.6.0 on Windows 7 using Oracle JDK 8 Update 201 and Windows-CMD
>Reporter: Paul Busch
>Assignee: Michael Osipov
>Priority: Major
>
> At my development site, I am behind a proxy server. That proxy server is
> configured in my {{settings.xml}} in a corresponding
> {{proxies/proxy}}-section.
> For site-deployments I use an internal server named {{my-site-host}}.
> To bypass the proxy for access to {{my-site-host}} and several other hosts in
> the local network, there is a {{nonProxyHosts}}-element in the
> proxy-configuration-section of my {{settings.xml}} which looks like this:
> {code:java}
> my-site-host|my-nexus-host
> {code}
> In an internal project {{linking-project,}} which uses a class {{LinkTarget}}
> from another internal project {{link-target}} in its API, I would like to
> have the class {{LinkTarget}} in the Javadocs of project {{linking-project}}
> to be displayed as links to the Javadocs of project {{link-target}}. The
> Javadocs of project {{link-target}} are published on {{my-site-host}} as part
> of a maven-site. To achieve the linking I have configured the
> {{maven-javadoc-plugin}} in {{linking-project}} as follows:
> {code:java}
>
>
> http://my-site-host/link-target/0.1.0-SNAPSHOT/apidocs
>
>
> {code}
> When the report {{javadoc:javadoc}} or the goal {{javadoc:jar}} is executed
> during the build, I get the following warning:
> {code:java}
> [WARNING] javadoc: warning - Error fetching URL:
> http://my-site-host/link-target/0.1.0-SNAPSHOT/apidocs/
> {code}
> As a result, class {{LinkTarget}} in the generated Javadocs is displayed with
> its fully qualified class name and not as a link. The expected behavior would
> be class {{LinkTarget}} being displayed using its local name only and with an
> underlying link to the Javadocs of that class. The problem occurs on both
> Linux and Windows.
> The problem also occurs when executing the {{javadoc.(sh|bat)}} script, which
> is generated in {{target/site/apidocs}} when {{-Ddebug=true}} is used (on
> Linux using Bash; on Windows using Windows-CMD).
> The problem seems to be in the handling of the {{nonProxyHosts}}-information
> from the {{settings.xml}} in {{AbstractJavadocMojo}}. In method
> {{addProxyArg(Commandline)}} this information is (in two places) handled as
> follows:
> {code:java}
> cmd.createArg().setValue( "-J-Dhttp.nonProxyHosts=\""
> + httpProxy.getNonProxyHosts().replace( "|", "^|" ) + "\"" );
> {code}
> When the report/goal is executed, the {{Commandline}}-object is delegated to
> {{CommandLineUtils.executeCommandLine(...)}} which in the end delegates to
> the {{javadoc}}-program using {{Runtime.exec(...)}}. {{Runtime.exec(...)}} is
> fed the command line parts as an array of Strings and apparently does not
> need any quoting and escaping. When looking at it in a debugger the
> {{nonProxyHosts}}-information – escaped with the code above – is passed to
> the {{javadoc}}-program as
> {{"-J-Dhttp.nonProxyHosts=\"my-site-host^|my-nexus-host\""}}. I guess this
> value is split by the {{javadoc}}-program at the pipe symbol, resulting in
> {{"my-site-host^}} and {{my-nexus-host"}} as the two host names. Thus the
> {{javadoc}}-program bypasses the proxy for the nonexisting/nonsense host name
> {{"my-site-host^}} (with a leading quote and a trailing caret) but uses the
> proxy for the actual host {{my-site-host}} causing the malfuntion and the
> warning.
> For the sake of the report/goal-execution the above code could be fixed as
> follows:
> {code:java}
> cmd.createArg().setValue( "-J-Dhttp.nonProxyHosts=" +
> httpProxy.getNonProxyHosts() );
> {code}
> i.e. no quoting and no escaping of pipe symbols.
> This code change albeit completely breaks the generated
> {{javadoc.(sh|bat)}}-scripts generated in {{target/site/apidocs}} with
> {{-Ddebug=true}}. While {{Runtime.exec(...)}} *must not* have quoting and
> escaping, Windows-CMD and Bash, for which the scripts are generated, *need*
> special handling. Otherwise the pipe symbols in {{nonProxyHosts}} will be
> interpreted as redirection of output to the input of another program.
> The following aspects need to be observed regarding the generation of the
> debug s
[jira] [Commented] (MJAVADOC-585) Incorrect quoting and escaping of nonProxyHosts-information from settings.xml
[
https://issues.apache.org/jira/browse/MJAVADOC-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790492#comment-16790492
]
Michael Osipov commented on MJAVADOC-585:
-
This is so horribly annoying. I just have this Plexus component launching
{{cmd}}/{{sh}} instead using {{ProcessBuilder}}. I actually tested that at
work, I must have missed something. I will test this again and let you know in
the next couple of days.
> Incorrect quoting and escaping of nonProxyHosts-information from settings.xml
> -
>
> Key: MJAVADOC-585
> URL: https://issues.apache.org/jira/browse/MJAVADOC-585
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0
> Environment: Maven 3.6.0 on RHEL 7.6 using OpenJDK 1.8.9.191 and
> Bash; Maven 3.6.0 on Windows 7 using Oracle JDK 8 Update 201 and Windows-CMD
>Reporter: Paul Busch
>Priority: Major
>
> At my development site, I am behind a proxy server. That proxy server is
> configured in my {{settings.xml}} in a corresponding
> {{proxies/proxy}}-section.
> For site-deployments I use an internal server named {{my-site-host}}.
> To bypass the proxy for access to {{my-site-host}} and several other hosts in
> the local network, there is a {{nonProxyHosts}}-element in the
> proxy-configuration-section of my {{settings.xml}} which looks like this:
> {code:java}
> my-site-host|my-nexus-host
> {code}
> In an internal project {{linking-project,}} which uses a class {{LinkTarget}}
> from another internal project {{link-target}} in its API, I would like to
> have the class {{LinkTarget}} in the Javadocs of project {{linking-project}}
> to be displayed as links to the Javadocs of project {{link-target}}. The
> Javadocs of project {{link-target}} are published on {{my-site-host}} as part
> of a maven-site. To achieve the linking I have configured the
> {{maven-javadoc-plugin}} in {{linking-project}} as follows:
> {code:java}
>
>
> http://my-site-host/link-target/0.1.0-SNAPSHOT/apidocs
>
>
> {code}
> When the report {{javadoc:javadoc}} or the goal {{javadoc:jar}} is executed
> during the build, I get the following warning:
> {code:java}
> [WARNING] javadoc: warning - Error fetching URL:
> http://my-site-host/link-target/0.1.0-SNAPSHOT/apidocs/
> {code}
> As a result, class {{LinkTarget}} in the generated Javadocs is displayed with
> its fully qualified class name and not as a link. The expected behavior would
> be class {{LinkTarget}} being displayed using its local name only and with an
> underlying link to the Javadocs of that class. The problem occurs on both
> Linux and Windows.
> The problem also occurs when executing the {{javadoc.(sh|bat)}} script, which
> is generated in {{target/site/apidocs}} when {{-Ddebug=true}} is used (on
> Linux using Bash; on Windows using Windows-CMD).
> The problem seems to be in the handling of the {{nonProxyHosts}}-information
> from the {{settings.xml}} in {{AbstractJavadocMojo}}. In method
> {{addProxyArg(Commandline)}} this information is (in two places) handled as
> follows:
> {code:java}
> cmd.createArg().setValue( "-J-Dhttp.nonProxyHosts=\""
> + httpProxy.getNonProxyHosts().replace( "|", "^|" ) + "\"" );
> {code}
> When the report/goal is executed, the {{Commandline}}-object is delegated to
> {{CommandLineUtils.executeCommandLine(...)}} which in the end delegates to
> the {{javadoc}}-program using {{Runtime.exec(...)}}. {{Runtime.exec(...)}} is
> fed the command line parts as an array of Strings and apparently does not
> need any quoting and escaping. When looking at it in a debugger the
> {{nonProxyHosts}}-information – escaped with the code above – is passed to
> the {{javadoc}}-program as
> {{"-J-Dhttp.nonProxyHosts=\"my-site-host^|my-nexus-host\""}}. I guess this
> value is split by the {{javadoc}}-program at the pipe symbol, resulting in
> {{"my-site-host^}} and {{my-nexus-host"}} as the two host names. Thus the
> {{javadoc}}-program bypasses the proxy for the nonexisting/nonsense host name
> {{"my-site-host^}} (with a leading quote and a trailing caret) but uses the
> proxy for the actual host {{my-site-host}} causing the malfuntion and the
> warning.
> For the sake of the report/goal-execution the above code could be fixed as
> follows:
> {code:java}
> cmd.createArg().setValue( "-J-Dhttp.nonProxyHosts=" +
> httpProxy.getNonProxyHosts() );
> {code}
> i.e. no quoting and no escaping of pipe symbols.
> This code change albeit completely breaks the generated
> {{javadoc.(sh|bat)}}-scripts generated in {{target/site/apidocs}} with
> {{-Ddebug=true}}. While {{Runtime.exec(...)}} *must not* have quoting and
> escaping, Windows-CMD and Bash, for which the scripts are generated, *ne
[jira] [Commented] (MSITE-835) Maven site generate invalid link with markdown
[ https://issues.apache.org/jira/browse/MSITE-835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790496#comment-16790496 ] Michael Osipov commented on MSITE-835: -- This cannot work because you are linking to the source, but you have to link to the target. I do not really undersand the issue hier. > Maven site generate invalid link with markdown > -- > > Key: MSITE-835 > URL: https://issues.apache.org/jira/browse/MSITE-835 > Project: Maven Site Plugin > Issue Type: Bug >Affects Versions: 3.7.1 >Reporter: Dave Newton >Priority: Major > > When a markdown page index.md has a relative [my link](target.md), maven site > plugin : > > * generate index.html and target.html (Good). > * keep md extension : (Invalid link) > This make the generated site unusable: the correct link should be href="target.html"> -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAVADOC-583) javadoc: error - The code being documented uses modules but the packages defined in {URL} are in the unnamed module
[
https://issues.apache.org/jira/browse/MJAVADOC-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790571#comment-16790571
]
Mark Raynsford commented on MJAVADOC-583:
-
I have a small project that reproduces the issue here:
https://github.com/io7m/jrai
What's odd is that I can't reproduce the error locally, but it consistently
happens on Travis CI with two different JDKs:
https://travis-ci.org/io7m/jrai/builds/505229571
See the log output for both of those builds for the error in question.
> javadoc: error - The code being documented uses modules but the packages
> defined in {URL} are in the unnamed module
> ---
>
> Key: MJAVADOC-583
> URL: https://issues.apache.org/jira/browse/MJAVADOC-583
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.1.0
> Environment: Travis CI, toolchain with openjdk 11.0.2
>Reporter: Sjoerd Talsma
>Priority: Major
> Attachments:
> context-propagation-dependabot-maven-org.apache.maven.plugins-maven-javadoc-plugin-3.1.0.zip,
> packages-3.0.1, packages-3.1.0
>
>
> My project build with toolchains, using both oracle JDK 8 and openjdk 11.0.2
> generating both 'jar' and 'aggregate-jar' documentation.
> This seems to inversely relate to MJAVADOC-555 somehow.
> The following error occurs:
> {quote}Exit code: 1 - javadoc: error - The code being documented uses modules
> but the packages defined in
> [https://javadoc.io/page/nl.talsmasoftware.context/context-propagation-root/1.0.6-SNAPSHOT/]
> are in the unnamed module
> {quote}
> _source:
> [https://travis-ci.org/talsma-ict/context-propagation/builds/501900168]_
> github:
> [https://github.com/talsma-ict/context-propagation/tree/dependabot/maven/org.apache.maven.plugins-maven-javadoc-plugin-3.1.0]
> pull-request: https://github.com/talsma-ict/context-propagation/pull/108
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJDEPS-3) Can't handle long classpath
[ https://issues.apache.org/jira/browse/MJDEPS-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790659#comment-16790659 ] Mathieu DREANO commented on MJDEPS-3: - The issue still exist, are you planning to correct it? Or a workaround ? thank you > Can't handle long classpath > --- > > Key: MJDEPS-3 > URL: https://issues.apache.org/jira/browse/MJDEPS-3 > Project: Maven JDeps Plugin > Issue Type: Bug > Environment: Java version: 1.8.0_131, vendor: Oracle Corporation > Java home: C:\java\jdk8\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" >Reporter: Clas Forsberg >Priority: Critical > Attachments: error.txt > > > When running I got this error > Cannot run program "C:\java\jdk8\jre\..\bin\jdeps.exe": CreateProcess > error=206, The filename or extension is too long > Mavan debug log attached -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6606) Allow installation-wide parameter customization
Paul Benedict created MNG-6606:
--
Summary: Allow installation-wide parameter customization
Key: MNG-6606
URL: https://issues.apache.org/jira/browse/MNG-6606
Project: Maven
Issue Type: Improvement
Components: core
Affects Versions: 3.1.1
Reporter: Paul Benedict
In my use case, I would like to always print the version of Maven at every
execution. I am not interested in a per-project case basis; nor interested in
modifying the startup batch scripts. I want to drop in a standard configuration
file to control all my Maven installations in the same manner.
My request is to make {{/.mvn/maven.config}} and {{./mvn/bashrc}} to be put in
the Maven root itself. I am not explicitly asking for {{${maven.root}/.mvn}} to
be *the* solution, but it's the right place to start the problem solving.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MWAR-378) Package Excludes doesn't work
[
https://issues.apache.org/jira/browse/MWAR-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790694#comment-16790694
]
Cedric HENRY commented on MWAR-378:
---
Have you tried not using squared brackets within the regular expression?
e.g.:
%regex[WEB-INF/lib/(email\\-library\\-|web\\-services\\-library\\-).*\\.jar]
> Package Excludes doesn't work
> -
>
> Key: MWAR-378
> URL: https://issues.apache.org/jira/browse/MWAR-378
> Project: Maven WAR Plugin
> Issue Type: Bug
> Environment: Windows 10, eclipse Mars
>Reporter: Allyn Tobey
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> The regex compiles, and runs in java, but it doesn't exclude the jar files. I
> am doing an or so i was able to use wild card characters and it is working
> but wanted to let you know my regex didn't work. Is there something wrong
> with my regex?
> {code}%regex[WEB-INF/lib/[email\\-library\\-|web\\-services\\-library\\-].*\\.jar]{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJDEPS-3) Can't handle long classpath
[ https://issues.apache.org/jira/browse/MJDEPS-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790793#comment-16790793 ] Robert Scholte commented on MJDEPS-3: - This issue is still waiting for a committer or contributor to be picked up. If you want to give it a try, we can guide you. > Can't handle long classpath > --- > > Key: MJDEPS-3 > URL: https://issues.apache.org/jira/browse/MJDEPS-3 > Project: Maven JDeps Plugin > Issue Type: Bug > Environment: Java version: 1.8.0_131, vendor: Oracle Corporation > Java home: C:\java\jdk8\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" >Reporter: Clas Forsberg >Priority: Critical > Attachments: error.txt > > > When running I got this error > Cannot run program "C:\java\jdk8\jre\..\bin\jdeps.exe": CreateProcess > error=206, The filename or extension is too long > Mavan debug log attached -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [maven-checkstyle-plugin] helt commented on issue #1: MCHECKSTYLE-344 Fix category resolution when reporting violation
helt commented on issue #1: MCHECKSTYLE-344 Fix category resolution when reporting violation URL: https://github.com/apache/maven-checkstyle-plugin/pull/1#issuecomment-472129146 However, if it is no effort, a release would be awesome if it addresses this issue. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-compiler-plugin] sormuras closed pull request #10: [WIP] Show-casing junit-platform-maven-plugin [DONT MERGE]
sormuras closed pull request #10: [WIP] Show-casing junit-platform-maven-plugin [DONT MERGE] URL: https://github.com/apache/maven-compiler-plugin/pull/10 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-compiler-plugin] sormuras opened a new pull request #13: Emit a warning instead of throwing an exception
sormuras opened a new pull request #13: Emit a warning instead of throwing an exception URL: https://github.com/apache/maven-compiler-plugin/pull/13 Prior this commit, an UnsupportedOperationException was thrown when a test module descriptor is present and a main module descriptor is absent. Now only a warning is emitted informing the user to either fix the modular setup or to allow users ignoring the warning. They might want to test that specific setup after all. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-compiler-plugin] sormuras opened a new pull request #14: Use junit-platform-maven-plugin w/o isolating test runtime jars
sormuras opened a new pull request #14: Use junit-platform-maven-plugin w/o isolating test runtime jars URL: https://github.com/apache/maven-compiler-plugin/pull/14 # Note _This is just a "proof-of-concept" and always "work-in-progress" PR to show-case what the junit-platform-maven-plugin looks like. It's also much easier to attach notes to source code here than in JIRA._ ## Overview Launching the JUnit Platform "in-process" *without* isolating test and main path sets. ```xml de.sormuras.junit junit-platform-maven-plugin 1.0.0-Mx true DIRECT MERGED ``` ### Summary ``` Test run finished after 2820 ms [ 2 containers found ] [ 0 containers skipped] [ 2 containers started] [ 0 containers aborted] [ 2 containers successful ] [ 0 containers failed ] [12 tests found ] [ 0 tests skipped ] [12 tests started ] [ 0 tests aborted ] [12 tests successful ] [ 0 tests failed ] ``` ### Using `MERGED` ...the jars are isolated as follows: ``` merged(test+main) test-classes maven-aether-provider-3.0.jar plexus-compiler-javac-2.8.4.jar maven-plugin-testing-harness-2.1.jar plexus-archiver-2.2.jar plexus-container-default-1.0-alpha-9-stable-1.jar classworlds-1.1-alpha-2.jar plexus-io-2.0.4.jar maven-compat-3.0.jar wagon-provider-api-1.0-beta-6.jar mockito-core-1.9.5.jar hamcrest-core-1.1.jar objenesis-1.0.jar junit-4.12.jar classes maven-plugin-annotations-3.5.2.jar maven-plugin-api-3.0.jar maven-model-3.0.jar sisu-inject-plexus-1.4.2.jar sisu-inject-bean-1.4.2.jar sisu-guice-2.1.7-noaop.jar maven-artifact-3.0.jar plexus-utils-2.0.4.jar maven-core-3.0.jar maven-settings-3.0.jar maven-settings-builder-3.0.jar maven-repository-metadata-3.0.jar maven-model-builder-3.0.jar aether-impl-1.7.jar aether-spi-1.7.jar aether-api-1.7.jar aether-util-1.7.jar plexus-interpolation-1.14.jar plexus-classworlds-2.2.3.jar plexus-component-annotations-1.7.1.jar plexus-sec-dispatcher-1.3.jar plexus-cipher-1.4.jar maven-shared-utils-3.2.1.jar commons-io-2.5.jar maven-shared-incremental-1.1.jar plexus-java-0.9.10.jar asm-6.2.jar qdox-2.0-M9.jar plexus-compiler-api-2.8.4.jar plexus-compiler-manager-2.8.4.jar launcher junit-platform-launcher-1.3.2.jar apiguardian-api-1.0.0.jar junit-platform-engine-1.3.2.jar junit-platform-commons-1.3.2.jar opentest4j-1.1.1.jar junit-vintage-engine-5.3.2.jar hamcrest-core-1.3.jar isolator junit-platform-isolator-worker-1.0.0-M5.jar junit-platform-isolator-1.0.0-M5.jar ``` ### Using `ABSOLUTE|ALMOST` ...and **no tests** are found by the Vintage engine. I guess, main classes need to access test classes, somehow. Injection? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-compiler-plugin] eolivelli commented on a change in pull request #13: Emit a warning instead of throwing an exception
eolivelli commented on a change in pull request #13: Emit a warning instead of throwing an exception URL: https://github.com/apache/maven-compiler-plugin/pull/13#discussion_r264862715 ## File path: src/main/java/org/apache/maven/plugin/compiler/TestCompilerMojo.java ## @@ -369,9 +369,11 @@ else if ( Double.valueOf( getTarget() ) < Double.valueOf( MODULE_INFO_TARGET ) ) // very odd // Means that main sources must be compiled with -modulesource and -Xmodule: // However, this has a huge impact since you can't simply use it as a classpathEntry -// due to extra folder in between -throw new UnsupportedOperationException( "Can't compile test sources " -+ "when main sources are missing a module descriptor" ); +// due to extra folder in between ... or the user wants to test his main code on the +// classpath used by a named module ... or ... +getLog().warn( "Modular black-box test compilation with no main module?!" ); + +// TODO classpathElements = List.of( mainOutputDirectory ); Review comment: Todo? Can you link a JIRA? In order notbto forget? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-compiler-plugin] sormuras commented on a change in pull request #13: Emit a warning instead of throwing an exception
sormuras commented on a change in pull request #13: Emit a warning instead of throwing an exception URL: https://github.com/apache/maven-compiler-plugin/pull/13#discussion_r264865001 ## File path: src/main/java/org/apache/maven/plugin/compiler/TestCompilerMojo.java ## @@ -369,9 +369,11 @@ else if ( Double.valueOf( getTarget() ) < Double.valueOf( MODULE_INFO_TARGET ) ) // very odd // Means that main sources must be compiled with -modulesource and -Xmodule: // However, this has a huge impact since you can't simply use it as a classpathEntry -// due to extra folder in between -throw new UnsupportedOperationException( "Can't compile test sources " -+ "when main sources are missing a module descriptor" ); +// due to extra folder in between ... or the user wants to test his main code on the +// classpath used by a named module ... or ... +getLog().warn( "Modular black-box test compilation with no main module?!" ); + +// TODO classpathElements = List.of( mainOutputDirectory ); Review comment: > "In order not to forget" This. I'm not sure what to do here, actually. That's why I implemented the `throws` variant first. Now, a warning is emitted, and any subsequent "mis-configuration" will lead to an error. Presumably when calling `javac`... but, as stated in the comment, this "main=classic + test=module" case is rare and not well understood. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-compiler-plugin] sormuras commented on issue #13: Emit a warning instead of throwing an exception
sormuras commented on issue #13: Emit a warning instead of throwing an exception URL: https://github.com/apache/maven-compiler-plugin/pull/13#issuecomment-472163859 > So you want to compile your codebase in classpath mode and run tests as a module which is consuming an unnamed module (classpath based)? Exactly. Similar to this setup https://github.com/micromata/sawdust/tree/master/modular-blackbox-mono -- but with a "classic" `src/main/java` directory. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MJAVADOC-583) javadoc: error - The code being documented uses modules but the packages defined in {URL} are in the unnamed module
[
https://issues.apache.org/jira/browse/MJAVADOC-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790992#comment-16790992
]
Robert Scholte commented on MJAVADOC-583:
-
Not sure you're hit by this , but I see there's an issue when your code is Java
9 compatible. The reason is that it uses
https://docs.oracle.com/javase/9/docs/api/package-list and not like 10 and
above https://docs.oracle.com/javase/10/docs/api/element-list
On the other hand: it seems like the javadoc is generated, even though there's
an error.
> javadoc: error - The code being documented uses modules but the packages
> defined in {URL} are in the unnamed module
> ---
>
> Key: MJAVADOC-583
> URL: https://issues.apache.org/jira/browse/MJAVADOC-583
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.1.0
> Environment: Travis CI, toolchain with openjdk 11.0.2
>Reporter: Sjoerd Talsma
>Priority: Major
> Attachments:
> context-propagation-dependabot-maven-org.apache.maven.plugins-maven-javadoc-plugin-3.1.0.zip,
> packages-3.0.1, packages-3.1.0
>
>
> My project build with toolchains, using both oracle JDK 8 and openjdk 11.0.2
> generating both 'jar' and 'aggregate-jar' documentation.
> This seems to inversely relate to MJAVADOC-555 somehow.
> The following error occurs:
> {quote}Exit code: 1 - javadoc: error - The code being documented uses modules
> but the packages defined in
> [https://javadoc.io/page/nl.talsmasoftware.context/context-propagation-root/1.0.6-SNAPSHOT/]
> are in the unnamed module
> {quote}
> _source:
> [https://travis-ci.org/talsma-ict/context-propagation/builds/501900168]_
> github:
> [https://github.com/talsma-ict/context-propagation/tree/dependabot/maven/org.apache.maven.plugins-maven-javadoc-plugin-3.1.0]
> pull-request: https://github.com/talsma-ict/context-propagation/pull/108
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ARCHETYPE-560) Require Java 7
Robert Scholte created ARCHETYPE-560: Summary: Require Java 7 Key: ARCHETYPE-560 URL: https://issues.apache.org/jira/browse/ARCHETYPE-560 Project: Maven Archetype Issue Type: Improvement Reporter: Robert Scholte Assignee: Robert Scholte -- This message was sent by Atlassian JIRA (v7.6.3#76005)
