[jira] [Commented] (MNG-8015) Control the type of path where each dependency can be placed
[
https://issues.apache.org/jira/browse/MNG-8015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806293#comment-17806293
]
Martin Desruisseaux commented on MNG-8015:
--
Pull request: https://github.com/apache/maven/pull/1378
> Control the type of path where each dependency can be placed
>
>
> Key: MNG-8015
> URL: https://issues.apache.org/jira/browse/MNG-8015
> Project: Maven
> Issue Type: Improvement
> Components: Core
>Affects Versions: 4.0.0-alpha-12
>Reporter: Martin Desruisseaux
>Priority: Major
>
> Make possible to declare where each dependency can be placed: on the
> module-path, class-path, agent path, doclet path, taglet path, annotation
> processing path, _etc._ The proposed improvement consists in adding a new
> {{PATH_TYPES}} property that can be associated to dependencies. The property
> value is an array of {{PathType}}, a new enumeration-like class with values
> such as {{CLASSES}}, {{MODULES}}, {{DOCLET}}, _etc._ Contrarily to real Java
> enumerations, this enumeration-like class is extensible: plugins can add
> their own enumeration values. This is required at least for the
> {{--patch-module}} option, where a new {{PathType}} enumeration value need to
> be created for each module to patch.
> Users can control indirectly the {{PathType}} of a dependency by specifying
> the dependency type. Note that there is no direct mapping between the
> dependency type and where the dependency will be placed, but only an indirect
> mapping caused by the fact that using a dependency type implies implicit
> values of some properties such as classifier, and (with this proposal) path
> types:
> * {{jar}} implies {{PathType.CLASSES}} and {{PathType.MODULES}}.
> * {{modular-jar}} implies {{PathType.MODULES}} only.
> * {{classpath-jar}} implies {{PathType.CLASSES}} only.
> * _etc._
> When a plugin requests the paths of dependencies, the plugin specifies the
> types of path it is interested in. For example, a Java compiler plugin can
> specify that it is interested in {{PathType.CLASSES}} and
> {{PathType.MODULES}}, but not {{PathType.DOCLET}}. If a dependency declared
> that it can be placed on the class-path or the doclet-path, only the
> class-path is left after intersection with plugin's request. This is
> important for the next step.
> If, after all filtering such as above paragraph are applied, a dependency has
> only one {{PathType}} left, then there is no ambiguity and we are done.
> Combined with above-cited dependency types like {{modular-jar}} or
> {{classpath-jar}}, this rule allows users to control where the dependency
> will be placed. But if there are two or more {{PathType}} left after
> filtering, then a choice needs to be done. For example if there are both
> {{PathType.CLASSES}} and {{PathType.MODULES}} (which may happen when
> {{jar}} is used), then an heuristic rule similar to Maven 3 can
> be applied: check if a {{module-info.class}} file or an {{Automatic-Name}}
> manifest attribute is present, and base the decision on that.
> This proposal aims to fix MNG-7855.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8015) Control the type of path where each dependency can be placed
Martin Desruisseaux created MNG-8015:
Summary: Control the type of path where each dependency can be
placed
Key: MNG-8015
URL: https://issues.apache.org/jira/browse/MNG-8015
Project: Maven
Issue Type: Improvement
Components: Core
Affects Versions: 4.0.0-alpha-12
Reporter: Martin Desruisseaux
Make possible to declare where each dependency can be placed: on the
module-path, class-path, agent path, doclet path, taglet path, annotation
processing path, _etc._ The proposed improvement consists in adding a new
{{PATH_TYPES}} property that can be associated to dependencies. The property
value is an array of {{PathType}}, a new enumeration-like class with values
such as {{CLASSES}}, {{MODULES}}, {{DOCLET}}, _etc._ Contrarily to real Java
enumerations, this enumeration-like class is extensible: plugins can add their
own enumeration values. This is required at least for the {{--patch-module}}
option, where a new {{PathType}} enumeration value need to be created for each
module to patch.
Users can control indirectly the {{PathType}} of a dependency by specifying the
dependency type. Note that there is no direct mapping between the dependency
type and where the dependency will be placed, but only an indirect mapping
caused by the fact that using a dependency type implies implicit values of some
properties such as classifier, and (with this proposal) path types:
* {{jar}} implies {{PathType.CLASSES}} and {{PathType.MODULES}}.
* {{modular-jar}} implies {{PathType.MODULES}} only.
* {{classpath-jar}} implies {{PathType.CLASSES}} only.
* _etc._
When a plugin requests the paths of dependencies, the plugin specifies the
types of path it is interested in. For example, a Java compiler plugin can
specify that it is interested in {{PathType.CLASSES}} and {{PathType.MODULES}},
but not {{PathType.DOCLET}}. If a dependency declared that it can be placed on
the class-path or the doclet-path, only the class-path is left after
intersection with plugin's request. This is important for the next step.
If, after all filtering such as above paragraph are applied, a dependency has
only one {{PathType}} left, then there is no ambiguity and we are done.
Combined with above-cited dependency types like {{modular-jar}} or
{{classpath-jar}}, this rule allows users to control where the dependency will
be placed. But if there are two or more {{PathType}} left after filtering, then
a choice needs to be done. For example if there are both {{PathType.CLASSES}}
and {{PathType.MODULES}} (which may happen when {{jar}} is used),
then an heuristic rule similar to Maven 3 can be applied: check if a
{{module-info.class}} file or an {{Automatic-Name}} manifest attribute is
present, and base the decision on that.
This proposal aims to fix MNG-7855.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7855) Dependencies wrongly put on class-path rather than module-path
[
https://issues.apache.org/jira/browse/MNG-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759233#comment-17759233
]
Martin Desruisseaux commented on MNG-7855:
--
Another area where being on the class-path versus module-path makes a big
difference is when loading other JAR files dynamically (after JVM startup). In
a class-path world, we use {{URLClassLoader}}. In a module-path world,
{{URLClassLoader}} does not work anymore and we have to use {{ModuleLayer}}
instead. The two approaches are very different.
For making {{ServiceLoader}} compatible with both class-path and module-path,
duplicating the {{module-info}} information into {{META-INF/services/}} is
problematic but still sometime doable (not always, because the two approaches
are not fully equivalent). However duplicating a dynamic JAR loading capability
with one framework based on {{ModuleLayer}} and another framework based on
{{ClassLoader}} is much more difficult.
For avoiding such bug prone situations, it is critical to be able to put a
library on the module-path no matter if the client application is modularized
or not.
> Dependencies wrongly put on class-path rather than module-path
> --
>
> Key: MNG-7855
> URL: https://issues.apache.org/jira/browse/MNG-7855
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.8.6, 4.0.0-alpha-7
>Reporter: Martin Desruisseaux
>Priority: Blocker
> Attachments: MavenModulepathBug.zip
>
>
> When invoking Java tools such as {{java}} or {{javac}}, the project
> dependencies can be declared either in a {{\--class-path}} or
> {{\--module-path}} option. Maven choose automatically the module-path if all
> the following conditions are true:
> # the dependency is modularized (i.e. contains a {{module-info.class}} file
> or an {{Automatic-Module-Name}} attribute in {{MANIFEST.MF}}), and
> # the project using the dependency is itself modularized.
> Condition #1 is fine, but #2 is problematic. The fact that a dependency is
> declared on the class-path rather than the module-path changes the way that
> {{java.util.ServiceLoader}} discovers the provided services.
> * If the dependency is on the class-path, {{ServiceLoader}} scans the content
> of {{META-INF/services}} directory.
> * If the dependency is on the module-path, {{ServiceLoader}} uses the
> declarations in {{module-info.class}}.
> Even if condition #2 is false (i.e. a project is not modularized),
> modularized dependencies still need to be declared on the module-path _for
> allowing the dependency to discover its own services, or the services of a
> transitive modularized dependency_. If a modularized dependency is put on the
> class-path instead, it has consequence not only for the project using that
> dependency, *but also for the dependency itself, which become unable to use
> its own {{module-info.class}}*.
> h1. Demonstration
> The attached test case contains two Maven modules, named {{service}} and
> {{client}}. The first Maven module declares a dummy services with 4
> providers, named A, B, C and D. Providers A and D are declared in
> {{module-info}}. Providers B and C are declared in {{META-INF/services}}. A
> {{ShowMyServices}} class lists the services discovered by
> {{java.util.ServiceLoader}}.
> The second Maven module has only a main method invoking {{ShowMyServices}}.
> This second module intentionally has no {{module-info.java}} file. The use
> case is a big module that we cannot modularize immediately (because
> modularization brings stronger encapsulation, which requires significant
> changes in the project to modularize), but still want to use modularized
> dependencies. The test case can be run with {{mvn install}}. During test
> execution, the following is printed:
> {noformat}
> Running test.client.MainTest
> Start searching for services...
> Provider B declared in META-INF.
> Provider C declared in META-INF.
> Done.
> The dependency has been loaded as an unnamed module.
> Consequently its `module-info` file has been ignored,
> and the `META-INF/services` directory is used instead.
> {noformat}
> The above test demonstrates that {{module-info}} has been ignored in the
> context of JUnit test execution. The same behaviour happens also with {{mvn
> exec:java}} executed in the {{client}} sub-directory.
> h2. Expected behaviour
> The Maven behaviour can be reproduced on the command-line as below (Linux
> convention). This command put everything on the class-path:
> {code:bash}
> java --class-path service/target/service-1.0.jar:client/target/client-1.0.jar
> test.client.Main
> {code}
> The expected behaviour can be reproduced with the following command-line.
> This command put the modularized dependency on the module-path while keeping
>
[jira] [Comment Edited] (MNG-7855) Dependencies wrongly put on class-path rather than module-path
[
https://issues.apache.org/jira/browse/MNG-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748556#comment-17748556
]
Martin Desruisseaux edited comment on MNG-7855 at 7/28/23 11:30 AM:
Java code for generating workarounds has been added in the [test case GitHub
repository|https://github.com/Geomatys/MavenModulepathBug], in the
{{workaround}} sub-directory. That code parses de {{module-info.class}} entries
of all specified JAR files and generates a {{META-INF/services/}} directory
with all service providers found. If a service provider declares a public
static {{provider()}} method, then the program also generates a {{java}}
sub-directory with Java code for wrappers. Those wrappers redirect all methods
of the service interface to the same methods of the provider obtained by a call
to the {{provider()}} static method.
Note that this workaround does not fix the real issue, which is that
dependencies are loaded as unnamed modules when they should not. The workaround
allows libraries and application to find some service providers despite this
problem, sometime not in the way that the providers should be (because of
wrappers). But any other features that depend on named modules are still broken.
was (Author: desruisseaux):
Java code for generating workarounds has been added in the [test case GitHub
repository|https://github.com/Geomatys/MavenModulepathBug], in the
{{workaround}} sub-directory. That code parses de {{module-info.class}} entries
of all specified JAR files and generates a {{META-INF/services/}} directory
with all service providers found. If a service provider declares a public
static {{provider()}} method, then the program also generates a {{java}}
sub-directory with Java code for wrappers. Those wrappers redirect all methods
of the service interface to the same methods of the provider obtained by a call
to the {{provider()}} static method.
This workaround is of course unsatisfying, especially the wrappers which will
not work in all cases.
> Dependencies wrongly put on class-path rather than module-path
> --
>
> Key: MNG-7855
> URL: https://issues.apache.org/jira/browse/MNG-7855
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.8.6, 4.0.0-alpha-7
>Reporter: Martin Desruisseaux
>Priority: Blocker
> Attachments: MavenModulepathBug.zip
>
>
> When invoking Java tools such as {{java}} or {{javac}}, the project
> dependencies can be declared either in a {{\--class-path}} or
> {{\--module-path}} option. Maven choose automatically the module-path if all
> the following conditions are true:
> # the dependency is modularized (i.e. contains a {{module-info.class}} file
> or an {{Automatic-Module-Name}} attribute in {{MANIFEST.MF}}), and
> # the project using the dependency is itself modularized.
> Condition #1 is fine, but #2 is problematic. The fact that a dependency is
> declared on the class-path rather than the module-path changes the way that
> {{java.util.ServiceLoader}} discovers the provided services.
> * If the dependency is on the class-path, {{ServiceLoader}} scans the content
> of {{META-INF/services}} directory.
> * If the dependency is on the module-path, {{ServiceLoader}} uses the
> declarations in {{module-info.class}}.
> Even if condition #2 is false (i.e. a project is not modularized),
> modularized dependencies still need to be declared on the module-path _for
> allowing the dependency to discover its own services, or the services of a
> transitive modularized dependency_. If a modularized dependency is put on the
> class-path instead, it has consequence not only for the project using that
> dependency, *but also for the dependency itself, which become unable to use
> its own {{module-info.class}}*.
> h1. Demonstration
> The attached test case contains two Maven modules, named {{service}} and
> {{client}}. The first Maven module declares a dummy services with 4
> providers, named A, B, C and D. Providers A and D are declared in
> {{module-info}}. Providers B and C are declared in {{META-INF/services}}. A
> {{ShowMyServices}} class lists the services discovered by
> {{java.util.ServiceLoader}}.
> The second Maven module has only a main method invoking {{ShowMyServices}}.
> This second module intentionally has no {{module-info.java}} file. The use
> case is a big module that we cannot modularize immediately (because
> modularization brings stronger encapsulation, which requires significant
> changes in the project to modularize), but still want to use modularized
> dependencies. The test case can be run with {{mvn install}}. During test
> execution, the following is printed:
> {noformat}
> Running test.client.MainTest
> Start searching for
[jira] [Commented] (MNG-7855) Dependencies wrongly put on class-path rather than module-path
[
https://issues.apache.org/jira/browse/MNG-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748556#comment-17748556
]
Martin Desruisseaux commented on MNG-7855:
--
Java code for generating workarounds has been added in the [test case GitHub
repository|https://github.com/Geomatys/MavenModulepathBug], in the
{{workaround}} sub-directory. That code parses de {{module-info.class}} entries
of all specified JAR files and generates a {{META-INF/services/}} directory
with all service providers found. If a service provider declares a public
static {{provider()}} method, then the program also generates a {{java}}
sub-directory with Java code for wrappers. Those wrappers redirect all methods
of the service interface to the same methods of the provider obtained by a call
to the {{provider()}} static method.
This workaround is of course unsatisfying, especially the wrappers which will
not work in all cases.
> Dependencies wrongly put on class-path rather than module-path
> --
>
> Key: MNG-7855
> URL: https://issues.apache.org/jira/browse/MNG-7855
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.8.6, 4.0.0-alpha-7
>Reporter: Martin Desruisseaux
>Priority: Blocker
> Attachments: MavenModulepathBug.zip
>
>
> When invoking Java tools such as {{java}} or {{javac}}, the project
> dependencies can be declared either in a {{\--class-path}} or
> {{\--module-path}} option. Maven choose automatically the module-path if all
> the following conditions are true:
> # the dependency is modularized (i.e. contains a {{module-info.class}} file
> or an {{Automatic-Module-Name}} attribute in {{MANIFEST.MF}}), and
> # the project using the dependency is itself modularized.
> Condition #1 is fine, but #2 is problematic. The fact that a dependency is
> declared on the class-path rather than the module-path changes the way that
> {{java.util.ServiceLoader}} discovers the provided services.
> * If the dependency is on the class-path, {{ServiceLoader}} scans the content
> of {{META-INF/services}} directory.
> * If the dependency is on the module-path, {{ServiceLoader}} uses the
> declarations in {{module-info.class}}.
> Even if condition #2 is false (i.e. a project is not modularized),
> modularized dependencies still need to be declared on the module-path _for
> allowing the dependency to discover its own services, or the services of a
> transitive modularized dependency_. If a modularized dependency is put on the
> class-path instead, it has consequence not only for the project using that
> dependency, *but also for the dependency itself, which become unable to use
> its own {{module-info.class}}*.
> h1. Demonstration
> The attached test case contains two Maven modules, named {{service}} and
> {{client}}. The first Maven module declares a dummy services with 4
> providers, named A, B, C and D. Providers A and D are declared in
> {{module-info}}. Providers B and C are declared in {{META-INF/services}}. A
> {{ShowMyServices}} class lists the services discovered by
> {{java.util.ServiceLoader}}.
> The second Maven module has only a main method invoking {{ShowMyServices}}.
> This second module intentionally has no {{module-info.java}} file. The use
> case is a big module that we cannot modularize immediately (because
> modularization brings stronger encapsulation, which requires significant
> changes in the project to modularize), but still want to use modularized
> dependencies. The test case can be run with {{mvn install}}. During test
> execution, the following is printed:
> {noformat}
> Running test.client.MainTest
> Start searching for services...
> Provider B declared in META-INF.
> Provider C declared in META-INF.
> Done.
> The dependency has been loaded as an unnamed module.
> Consequently its `module-info` file has been ignored,
> and the `META-INF/services` directory is used instead.
> {noformat}
> The above test demonstrates that {{module-info}} has been ignored in the
> context of JUnit test execution. The same behaviour happens also with {{mvn
> exec:java}} executed in the {{client}} sub-directory.
> h2. Expected behaviour
> The Maven behaviour can be reproduced on the command-line as below (Linux
> convention). This command put everything on the class-path:
> {code:bash}
> java --class-path service/target/service-1.0.jar:client/target/client-1.0.jar
> test.client.Main
> {code}
> The expected behaviour can be reproduced with the following command-line.
> This command put the modularized dependency on the module-path while keeping
> the non-modularized client on the class-path:
> {code:bash}
> java --module-path service/target/service-1.0.jar --class-path
> client/target/client-1.0.jar --add-modules ALL-MODULE-PATH
[jira] [Commented] (SUREFIRE-2097) More configuration for surefire JPMS
[
https://issues.apache.org/jira/browse/SUREFIRE-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748544#comment-17748544
]
Martin Desruisseaux commented on SUREFIRE-2097:
---
Thanks for the reply! Does it means that MNG-7855 issue is actually a
{{plexus-languages}} issue? In that case, do you know if there is anyway to
tell plexus to put dependencies on the module-path rather than class-path?
> More configuration for surefire JPMS
>
>
> Key: SUREFIRE-2097
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2097
> Project: Maven Surefire
> Issue Type: Improvement
>Affects Versions: 3.0.0-M7
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
>
> Currently surefire manages the build of module path and classpath graph with
> almost not configurable option.
> Due to long time between M5 and M6 releases while in the meantime plexus-java
> has incorporated a lot changes (for compiler, javadoc), those release has
> created some backward incompatible changes which are affecting some users
> such:
> - https://issues.apache.org/jira/browse/SUREFIRE-2057
> - comments here [https://github.com/eclipse/jetty.project/pull/8129]
> So we need few more options to be able to configure some of the assumptions
> which has been made and changed in plexus-java.
> Because the current configuration is hardcoded:
> {code:java}
> ResolvePathsRequest req = ResolvePathsRequest.ofStrings(
> testClasspath.getClassPath() )
> .setIncludeAllProviders( true )
> .setJdkHome( javaHome )
> .setIncludeStatic( true )
> .setModuleDescriptor( javaModuleDescriptor );
> {code}
> We must give users some options to override the black magic made by
> plexus-java.
> Options to configure:
> - force all test/provided scope to be in classpath or not
> - do not add automatically providers to the module path
> - a possible list per groupId/artifactId to force module path or classpath
> - etc...
> The idea here is too collect what users need.
> Remember we will try to avoid too much complicated options :)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2097) More configuration for surefire JPMS
[
https://issues.apache.org/jira/browse/SUREFIRE-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748204#comment-17748204
]
Martin Desruisseaux commented on SUREFIRE-2097:
---
This issue seems related to MNG-7855 (dependencies wrongly put on class-path
rather than module-path). I think that in those two issues, the problem is that
the developer has no way (as far as I know) to overwrite Maven black magic by
the developer's intend. When the black magic is wrong, the developer is blocked
from using JPMS in the context of a Maven project, unless "polluting" the
libraries with a bit risky workaround.
> More configuration for surefire JPMS
>
>
> Key: SUREFIRE-2097
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2097
> Project: Maven Surefire
> Issue Type: Improvement
>Affects Versions: 3.0.0-M7
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
>
> Currently surefire manages the build of module path and classpath graph with
> almost not configurable option.
> Due to long time between M5 and M6 releases while in the meantime plexus-java
> has incorporated a lot changes (for compiler, javadoc), those release has
> created some backward incompatible changes which are affecting some users
> such:
> - https://issues.apache.org/jira/browse/SUREFIRE-2057
> - comments here [https://github.com/eclipse/jetty.project/pull/8129]
> So we need few more options to be able to configure some of the assumptions
> which has been made and changed in plexus-java.
> Because the current configuration is hardcoded:
> {code:java}
> ResolvePathsRequest req = ResolvePathsRequest.ofStrings(
> testClasspath.getClassPath() )
> .setIncludeAllProviders( true )
> .setJdkHome( javaHome )
> .setIncludeStatic( true )
> .setModuleDescriptor( javaModuleDescriptor );
> {code}
> We must give users some options to override the black magic made by
> plexus-java.
> Options to configure:
> - force all test/provided scope to be in classpath or not
> - do not add automatically providers to the module path
> - a possible list per groupId/artifactId to force module path or classpath
> - etc...
> The idea here is too collect what users need.
> Remember we will try to avoid too much complicated options :)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7855) Dependencies wrongly put on class-path rather than module-path
Martin Desruisseaux created MNG-7855:
Summary: Dependencies wrongly put on class-path rather than
module-path
Key: MNG-7855
URL: https://issues.apache.org/jira/browse/MNG-7855
Project: Maven
Issue Type: Bug
Components: Dependencies
Affects Versions: 4.0.0-alpha-7, 3.8.6
Reporter: Martin Desruisseaux
Attachments: MavenModulepathBug.zip
When invoking Java tools such as {{java}} or {{javac}}, the project
dependencies can be declared either in a {{\--class-path}} or
{{\--module-path}} option. Maven choose automatically the module-path if all
the following conditions are true:
# the dependency is modularized (i.e. contains a {{module-info.class}} file or
an {{Automatic-Module-Name}} attribute in {{MANIFEST.MF}}), and
# the project using the dependency is itself modularized.
Condition #1 is fine, but #2 is problematic. The fact that a dependency is
declared on the class-path rather than the module-path changes the way that
{{java.util.ServiceLoader}} discovers the provided services.
* If the dependency is on the class-path, {{ServiceLoader}} scans the content
of {{META-INF/services}} directory.
* If the dependency is on the module-path, {{ServiceLoader}} uses the
declarations in {{module-info.class}}.
Even if condition #2 is false (i.e. a project is not modularized), modularized
dependencies still need to be declared on the module-path _for allowing the
dependency to discover its own services, or the services of a transitive
modularized dependency_. If a modularized dependency is put on the class-path
instead, it has consequence not only for the project using that dependency,
*but also for the dependency itself, which become unable to use its own
{{module-info.class}}*.
h1. Demonstration
The attached test case contains two Maven modules, named {{service}} and
{{client}}. The first Maven module declares a dummy services with 4 providers,
named A, B, C and D. Providers A and D are declared in {{module-info}}.
Providers B and C are declared in {{META-INF/services}}. A {{ShowMyServices}}
class lists the services discovered by {{java.util.ServiceLoader}}.
The second Maven module has only a main method invoking {{ShowMyServices}}.
This second module intentionally has no {{module-info.java}} file. The use case
is a big module that we cannot modularize immediately (because modularization
brings stronger encapsulation, which requires significant changes in the
project to modularize), but still want to use modularized dependencies. The
test case can be run with {{mvn install}}. During test execution, the following
is printed:
{noformat}
Running test.client.MainTest
Start searching for services...
Provider B declared in META-INF.
Provider C declared in META-INF.
Done.
The dependency has been loaded as an unnamed module.
Consequently its `module-info` file has been ignored,
and the `META-INF/services` directory is used instead.
{noformat}
The above test demonstrates that {{module-info}} has been ignored in the
context of JUnit test execution. The same behaviour happens also with {{mvn
exec:java}} executed in the {{client}} sub-directory.
h2. Expected behaviour
The Maven behaviour can be reproduced on the command-line as below (Linux
convention). This command put everything on the class-path:
{code:bash}
java --class-path service/target/service-1.0.jar:client/target/client-1.0.jar
test.client.Main
{code}
The expected behaviour can be reproduced with the following command-line. This
command put the modularized dependency on the module-path while keeping the
non-modularized client on the class-path:
{code:bash}
java --module-path service/target/service-1.0.jar --class-path
client/target/client-1.0.jar --add-modules ALL-MODULE-PATH test.client.Main
{code}
The latter command produces the following output:
{noformat}
Start searching for services...
Provider A declared in module-info.
Provider D declared in module-info.
Done.
The dependency has been loaded as named module. Great!
This is what we need for the `module-info` to be used.
{noformat}
h1. Discussion
Unless Maven provides configuration options that we did not see, the way that
Maven decides what to put on {{\--class-path}} and what to put on
{{\--module-path}} is a blocker issue for gradual modularisation of large
projects. This is because Maven choices break usages of
{{java.util.ServiceLoader}} in the dependencies themselves, which developers
may not control. The workaround for library developers is to declare all
service providers in both {{module-info}} and {{META-INF/services}}, with the
risk of inconsistencies. This workaround forces developers to renounce to the
usage of {{provider()}} static methods (which was making possible to use
singleton provider instances), because {{provider()}} static method works only
for providers declared in {{module-info}}. If the
[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior
[
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418698#comment-17418698
]
Martin Desruisseaux commented on MRESOURCES-237:
Yes, but it may be cause I do not apply any filtering. I only copy a
{{LICENSE}} file verbatim. I saw the alternative proposed in earlier comment
(to put the license in a separated module and use the
{{maven-remote-resources-plugin}}), but it seems an overkill for me for what
should be a very simple task.
> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the
> {{maven-resources-plugin}} has changed in version 3.0.x. I'm submitting a
> JIRA because it breaks the previous behavior and I have not been able to find
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project. We have a custom log4j2
> configuration file we use during testing. Instead of maintaining this file
> in multiple {{src/test/resources}} directories, we instead maintain a single
> copy of the file at the project's root level and create symbolic links from
> each module's {{src/test/resources}} directory to the file using relative
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim.
> The symlink's relative path results in the symlink pointing to the wrong
> file location. The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document
> the change and provide a configuration parameter to allow the legacy behavior.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior
[
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418686#comment-17418686
]
Martin Desruisseaux commented on MRESOURCES-237:
I had to dowgrade to version 2.7 for the same reason.
> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the
> {{maven-resources-plugin}} has changed in version 3.0.x. I'm submitting a
> JIRA because it breaks the previous behavior and I have not been able to find
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project. We have a custom log4j2
> configuration file we use during testing. Instead of maintaining this file
> in multiple {{src/test/resources}} directories, we instead maintain a single
> copy of the file at the project's root level and create symbolic links from
> each module's {{src/test/resources}} directory to the file using relative
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim.
> The symlink's relative path results in the symlink pointing to the wrong
> file location. The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document
> the change and provide a configuration parameter to allow the legacy behavior.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MJAVADOC-329) Allow generation of empty javadoc JARs
[
https://issues.apache.org/jira/browse/MJAVADOC-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16705956#comment-16705956
]
Martin Desruisseaux commented on MJAVADOC-329:
--
Well, bug 4492654 is marked "won't fix" because… already fixed (according the
evaluation).
About this issue, not sure it would make any difference, but have you tried
with {{javac}} option {{-Xpkginfo:always}}? (Javadoc uses the generated
{{.class}} files, but I'm not sure what it is doing with them).
> Allow generation of empty javadoc JARs
> --
>
> Key: MJAVADOC-329
> URL: https://issues.apache.org/jira/browse/MJAVADOC-329
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Vincent Massol
>Assignee: Robert Scholte
>Priority: Major
>
> Here's my use case:
> * I want to be able to deploy my artifacts to Maven Central. There's a
> requirement that a javadoc jar exists for the arifact to deploy
> * However I have some maven modules of type packaging = jar that have java
> files but these files are located in an "internal" package (internal api that
> we don't expose to end users since it's not part of our public API contract)
> which we exclude from the javadoc generation
> The problem is that the javadoc plugin doesn't generate any JAR if there are
> no java files matching (even if I have other files such as a package.html
> file in my src/main/javadoc/* directories).
> I'd like it to be possible to generate an "empty" javadoc JAR containing only
> a package.html file for example.
> Thanks a lot
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-449) javadoc:aggregate fails with JDK 9
[
https://issues.apache.org/jira/browse/MJAVADOC-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16599627#comment-16599627
]
Martin Desruisseaux commented on MJAVADOC-449:
--
I think that the issue is deeper than aggregated javadoc only. In order to
generate aggregated javadoc with a front page listing modules, we need to use
the {{\--module-path}} and {{\--module-source-path}} options of JDK tools (if
there is another way, I did not found it yet). But those options require a
directory having the exact module name. Current Maven standard directory layout
is incompatible with this requirement. This problem impacts no only javadoc,
but all JDK tools working with modules (at least {{javadoc}}, {{javac}} and
{{jlink}}). For example when used with {{javac}}, "aggregated compilation"
allows to run Annotation Processing Tools on all modules in one pass (useful if
the processing tools want to combine information from all modules).
If we need to revisit directory layout in order to support aggregated javadoc,
then we could expand the scope for fixing also other issues (in my opinion) in
supporting multi-language projects, for example in projects using Java, Python
and C/C++ together. A new directory layout [has been proposed on the Maven
developer mailing
list|https://mail-archives.apache.org/mod_mbox/maven-dev/201808.mbox/%3C91eb6c15-9fc6-6d2a-56c9-962c2be4c227%40geomatys.com%3E].
But [implementing and
experimenting|https://github.com/Geomatys/maven-plugins/wiki] it would require
volunteer time, maybe outside the current Maven maintainers team, until the
value of such proposal is demonstrated (or not).
> javadoc:aggregate fails with JDK 9
> --
>
> Key: MJAVADOC-449
> URL: https://issues.apache.org/jira/browse/MJAVADOC-449
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.10.3
>Reporter: Hervé Boutemy
>Assignee: Robert Scholte
>Priority: Major
> Attachments: 20180618-MJAVADOC449.zip,
> maven-javadoc-plugin-aggregate-test.zip
>
>
> trying {{mvn -Preporting site}} with Maven core and maven-javadoc-plugin
> upgraded to 2.10.4-SNAPSHOT to benefit from already JDK 9 related fixed
> issues shows another one
> {noformat}[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project
> maven: Error generating maven-javadoc-plugin:2.10.4-SNAPSHOT:aggregate:
> Unable to resolve artifact:groupId = 'org.apache.maven.plugin-tools'
> [ERROR] artifactId = 'maven-plugin-tools-javadoc'
> [ERROR] version = '3.4': Missing:
> [ERROR] --
> [ERROR] 1) com.sun:tools:jar:1.4.2
> [ERROR]
> [ERROR] Try downloading the file manually from the project website.
> [ERROR]
> [ERROR] Then, install it using the command:
> [ERROR] mvn install:install-file -DgroupId=com.sun -DartifactId=tools
> -Dversion=1.4.2 -Dpackaging=jar -Dfile=/path/to/file
> [ERROR]
> [ERROR] Alternatively, if you host your own repository you can deploy the
> file there:
> [ERROR] mvn deploy:deploy-file -DgroupId=com.sun -DartifactId=tools
> -Dversion=1.4.2 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url]
> -DrepositoryId=[id]
> [ERROR]
> [ERROR] Path to dependency:
> [ERROR] 1) org.apache.maven.plugin-tools:maven-plugin-tools-javadoc:jar:3.4
> [ERROR] 2) com.sun:tools:jar:1.4.2
> [ERROR]
> [ERROR] --
> [ERROR] 1 required artifact is missing.
> [ERROR]
> [ERROR] for artifact:
> [ERROR] org.apache.maven.plugin-tools:maven-plugin-tools-javadoc:jar:3.4
> [ERROR]
> [ERROR] from the specified remote repositories:
> [ERROR] apache.snapshots (http://repository.apache.org/snapshots,
> releases=false, snapshots=true),
> [ERROR] central (https://repo.maven.apache.org/maven2, releases=true,
> snapshots=false)
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MCOMPILER-336) Dependency that should be on modulepath sometime put on classpath
Martin Desruisseaux created MCOMPILER-336:
-
Summary: Dependency that should be on modulepath sometime put on
classpath
Key: MCOMPILER-336
URL: https://issues.apache.org/jira/browse/MCOMPILER-336
Project: Maven Compiler Plugin
Issue Type: Task
Affects Versions: 3.7.0
Reporter: Martin Desruisseaux
Attachments: module-vs-classpath.zip
{{maven-compiler-plugin}} sometime puts modularized dependencies on the
{{javac}} {{-classpath}} option instead than {{-modulepath}}, which cause
compilation failure. A test case is attached. Step to reproduce:
{noformat}
cd module-vs-classpath
cd a
mvn install
cd ../b
mvn clean install
mvn install
{noformat}
The last command fail with the following error message:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile (default-compile)
on project b: Compilation failure
[ERROR] module not found: test.a
{noformat}
Execution with the {{-X}} option shows that the {{test.a}} dependency is
correctly declared in {{-modulepath}} when executing {{mvn clean install}}, but
is wrongly declared in {{-classpath}} when executing {{mvn install}}.
A workaround is to remove the
{{false}} option in the
{{pom.xml}} files, or to execute {{touch src/main/java/module-info.java}}
before {{mvn install}}. However the same error message occurs when attempting
to execute {{mvn site}}, for which case I have found no workaround yet (note:
the {{mvn site}} problem is not reproduced by the attached
{{module-vs-classpath.zip}} file).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MJAVADOC-494) javadoc:aggregate ignores repositories declared in sub-modules
[
https://issues.apache.org/jira/browse/MJAVADOC-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated MJAVADOC-494:
-
Description:
Given a multi-modules project with:
* A {{… URL A …}} element in the root {{pom.xml}}.
* Another {{… URL B …}} element in the {{pom.xml}} of
a module, for downloading a JAR file used only by that specific module (we do
that in order to depend only on Maven central for all modules except one).
Then:
* {{mvn install}} works: it download all JAR files as expected.
* {{mvn javadoc:javadoc}} also work with both Maven Javadoc plugin 2.10.4 and
3.0.0-M1.
* {{mvn javadoc:aggregate}} with Maven Javadoc plugin 2.10.4 works.
* {{mvn javadoc:aggregate}} with Maven Javadoc plugin 3.0.0-M1 fails.
Maven Javadoc plugin 3.0.0-M1 execution produces the following logs (simplified
for brevity):
{noformat}
Downloading: URL A/.../MyArtifact.jar
Downloading: https://repo.maven.apache.org/maven2/.../MyArtifact.jar
{noformat}
No download attempt from URL B is reported, despite the {{}}
declaration in a sub-module. Note that the JAR is present in my
{{.m2/repository}} directory but is apparently ignored.
Downgrading Maven Javadoc plugin to 2.10.4 with everything else identical
allows successful aggregated Javadoc generation.
*Note:* another user apparently has [the same issue on stack
overflow|https://stackoverflow.com/questions/46034250/maven-javadocaggregate-artifacts-could-not-be-resolved].
was:
Given a multi-modules project with:
* A {{… URL A …}} element in the root {{pom.xml}}.
* Another {{… URL B …}} element in the {{pom.xml}} of
a module, for downloading a JAR file used only by that specific module (we do
that in order to depend only on Maven central for all modules except one).
Then:
* {{mvn install}} works: it download all JAR files as expected.
* {{mvn javadoc:javadoc}} also work with both Maven Javadoc plugin 2.10.4 and
3.0.0-M1.
* {{mvn javadoc:aggregate}} with Maven Javadoc plugin 2.10.4 works.
* {{mvn javadoc:aggregate}} with Maven Javadoc plugin 3.0.0-M1 fails
(regression).
Maven Javadoc plugin 3.0.0-M1 execution produces the following logs (simplified
in this issue for brevity):
{noformat}
Downloading: URL A/.../MyArtifact.jar
Downloading: https://repo.maven.apache.org/maven2/.../MyArtifact.jar
{noformat}
No download attempt from URL B is found; its {{}} declaration (in a
sub-module) is apparently ignored. Note that the JAR is present in my
{{.m2/repository}} directory but is apparently ignored too.
Downgrading Maven Javadoc plugin to 2.10.4 with everything else identical
allows successful aggregated Javadoc generation.
*Note:* another user apparently has [the same issue on stack
overflow|https://stackoverflow.com/questions/46034250/maven-javadocaggregate-artifacts-could-not-be-resolved].
Summary: javadoc:aggregate ignores repositories declared in sub-modules
(was: [REGRESSION] javadoc:aggregate ignores repositories declared in
sub-modules)
> javadoc:aggregate ignores repositories declared in sub-modules
> --
>
> Key: MJAVADOC-494
> URL: https://issues.apache.org/jira/browse/MJAVADOC-494
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.0.0-M1
> Environment: Maven Javadoc plugin 3.0.0-M1
> Apache Maven 3.5.0
> Java version 1.8.0_144
>Reporter: Martin Desruisseaux
> Labels: regression
>
> Given a multi-modules project with:
> * A {{… URL A …}} element in the root {{pom.xml}}.
> * Another {{… URL B …}} element in the {{pom.xml}}
> of a module, for downloading a JAR file used only by that specific module (we
> do that in order to depend only on Maven central for all modules except one).
> Then:
> * {{mvn install}} works: it download all JAR files as expected.
> * {{mvn javadoc:javadoc}} also work with both Maven Javadoc plugin 2.10.4 and
> 3.0.0-M1.
> * {{mvn javadoc:aggregate}} with Maven Javadoc plugin 2.10.4 works.
> * {{mvn javadoc:aggregate}} with Maven Javadoc plugin 3.0.0-M1 fails.
> Maven Javadoc plugin 3.0.0-M1 execution produces the following logs
> (simplified for brevity):
> {noformat}
> Downloading: URL A/.../MyArtifact.jar
> Downloading: https://repo.maven.apache.org/maven2/.../MyArtifact.jar
> {noformat}
> No download attempt from URL B is reported, despite the {{}}
> declaration in a sub-module. Note that the JAR is present in my
> {{.m2/repository}} directory but is apparently ignored.
> Downgrading Maven Javadoc plugin to 2.10.4 with everything else identical
> allows successful aggregated Javadoc generation.
> *Note:* another user apparently has [the same issue on stack
> overflow|https://stackoverflow.com/questions/46034250/maven-javadocaggregate-artifacts-could-not-be-resolved].
--
This message was sent by
[jira] [Created] (MJAVADOC-494) [REGRESSION] javadoc:aggregate ignores repositories declared in sub-modules
Martin Desruisseaux created MJAVADOC-494:
Summary: [REGRESSION] javadoc:aggregate ignores repositories
declared in sub-modules
Key: MJAVADOC-494
URL: https://issues.apache.org/jira/browse/MJAVADOC-494
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: javadoc
Affects Versions: 3.0.0-M1
Environment: Maven Javadoc plugin 3.0.0-M1
Apache Maven 3.5.0
Java version 1.8.0_144
Reporter: Martin Desruisseaux
Given a multi-modules project with:
* A {{… URL A …}} element in the root {{pom.xml}}.
* Another {{… URL B …}} element in the {{pom.xml}} of
a module, for downloading a JAR file used only by that specific module (we do
that in order to depend only on Maven central for all modules except one).
Then:
* {{mvn install}} works: it download all JAR files as expected.
* {{mvn javadoc:javadoc}} also work with both Maven Javadoc plugin 2.10.4 and
3.0.0-M1.
* {{mvn javadoc:aggregate}} with Maven Javadoc plugin 2.10.4 works.
* {{mvn javadoc:aggregate}} with Maven Javadoc plugin 3.0.0-M1 fails
(regression).
Maven Javadoc plugin 3.0.0-M1 execution produces the following logs (simplified
in this issue for brevity):
{noformat}
Downloading: URL A/.../MyArtifact.jar
Downloading: https://repo.maven.apache.org/maven2/.../MyArtifact.jar
{noformat}
No download attempt from URL B is found; its {{}} declaration (in a
sub-module) is apparently ignored. Note that the JAR is present in my
{{.m2/repository}} directory but is apparently ignored too.
Downgrading Maven Javadoc plugin to 2.10.4 with everything else identical
allows successful aggregated Javadoc generation.
*Note:* another user apparently has [the same issue on stack
overflow|https://stackoverflow.com/questions/46034250/maven-javadocaggregate-artifacts-could-not-be-resolved].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MJAR-223) classpathLayoutType is not taken into account when building the classpath attribute in the manifest
[ https://issues.apache.org/jira/browse/MJAR-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15318942#comment-15318942 ] Martin Desruisseaux commented on MJAR-223: -- Same issue for me. I downgraded to version 2.6 in the meantime. > classpathLayoutType is not taken into account when building the classpath > attribute in the manifest > --- > > Key: MJAR-223 > URL: https://issues.apache.org/jira/browse/MJAR-223 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Tomer Cohen > Attachments: jar-test.zip > > > After upgrading to version 3.0.0 of the jar plugin, the "classpathLayoutType" > is not taken into account and is always of type "repository" even if set > differently (e.g. "simple). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] (MJAVADOC-368) Can not use a comma (,) in option additionalparam
[
https://jira.codehaus.org/browse/MJAVADOC-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=345103#comment-345103
]
Martin Desruisseaux commented on MJAVADOC-368:
--
This is also a problem for the new JDK8 {{-Xdoclint}} option. For example:
{noformat}
additionalparam-Xdoclint:syntax,missing,accessibility/additionalparam
{noformat}
produces the given lines in the {{options}} file generated by Maven:
{noformat}
-Xdoclint:syntax
missing
accessibility
{noformat}
It seems that Maven replaced the coma by line separator. Adding quote does not
prevent that. This behavior is not documented in the [plugin
goal|http://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-mojo.html#additionalparam].
Can not use a comma (,) in option additionalparam
-
Key: MJAVADOC-368
URL: https://jira.codehaus.org/browse/MJAVADOC-368
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.9
Reporter: Andy Schönemann
I would like to set an additional parameter for javadoc like
{{additionalparam-header apos;A,Bapos;/additionalparam}}
But this is not possible! Every comma here separates the string into
different parameters. So I'm not able to set parameters including commas.
Furthermore, the options name is {{additionalparam}} and NOT
{{additionalparamS}}. So it should not be possible to set multiple parameters
here.
I also tried
{{additionalparam-header apos;A#44;Bapos;/additionalparam}}
but this doesn't work either.
[Plugin
documentation|http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#additionalparam]
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-387) Handle JDK8 -Xdoclint
[
https://jira.codehaus.org/browse/MJAVADOC-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=345104#comment-345104
]
Martin Desruisseaux commented on MJAVADOC-387:
--
A support for {{-Xdoclint}} would be appreciated. However I disagree that Maven
should take {{-Xdoclint:none}} as the default. I realize that the JDK 8
behavior (all checks enabled by default) will break lot of Javadoc generation.
But I think that it is preferable to force developers to explicitly disable the
checks if they need too, otherwise many developers will probably not even
realize that their Javadoc has problems. Especially since when using
{{-Xdoclint:none}}, the errors are not replaced by warnings - they just
disappear.
Handle JDK8 -Xdoclint
-
Key: MJAVADOC-387
URL: https://jira.codehaus.org/browse/MJAVADOC-387
Project: Maven Javadoc Plugin
Issue Type: Improvement
Reporter: Stephen Colebourne
The Oracle team have added the doclint tool to JDK 8. The tool validates
Javadoc as part of a standard Javadoc run. Unfortunately, with the default
settings, it rejects many HTML elements that are perfectly acceptable to
browsers, and all invalid Javadoc references (@links). This is likely to
prove very unpopular with developers.
Action needed:
1) Provide a maven-javadoc-plugin configuration item and property that can
control the doclint tool (currently this requires using additionalparam
AFAICT).
2) Apply the {{-Xdoclint:none}} option by default, so that doclint is opt-in,
not opt-out (ie. fix Oracle's messed up default). This will also make it much
easier for developers to handle migration to JDK 8.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5437) Do not load plugins from snapshot JARs
[
https://jira.codehaus.org/browse/MNG-5437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=320112#comment-320112
]
Martin Desruisseaux commented on MNG-5437:
--
The proposed patch may help in making Maven build more robust when running
builds in parallel, thanks a lot for proposing it. But I wonder if this is a
common cases? In the particular case of the JVM crash reported in the SIS
project, there is no parallel build, and I don't see which process could be
cobbling the JAR file at the time of the JVM crash... So it is quite possible
that the JVM crash has another cause. One think we could do first would be to
upgrade JDK7 on the Jenkins server (which is 18 months old), then see if the
crashes are still there.
Do not load plugins from snapshot JARs
--
Key: MNG-5437
URL: https://jira.codehaus.org/browse/MNG-5437
Project: Maven 2 3
Issue Type: Bug
Components: Class Loading
Affects Versions: 3.0.4
Environment: Solaris 10, JDK 1.7.0
Reporter: Jesse Glick
Priority: Minor
See [mailing list
discussion|http://mail-archives.apache.org/mod_mbox/www-builds/201302.mbox/browser]
for background. When a reactor build creates a plugin JAR and then loads
classes from it, a JVM crash is a possibility:
{code:none}
[INFO] Installing
/export/home/hudson/hudson-slave/workspace/sis-jdk7/sis-build-helper/target/sis-build-helper-0.3-jdk7-SNAPSHOT.jar
to
/export/home/hudson/hudson-slave/maven-repositories/0/org/apache/sis/sis-build-helper/0.3-jdk7-SNAPSHOT/sis-build-helper-0.3-jdk7-SNAPSHOT.jar
...moving on to another project in the reactor...
[INFO] --- sis-build-helper:0.3-jdk7-SNAPSHOT:collect-jars (default) @
sis-utility ---
#
# A fatal error has been detected by the Java Runtime Environment:
{code}
This could happen for example if two people were running the same build
concurrently; if one Maven process is trying to load classes from the JAR at
the same time as another is rebuilding that JAR, there will be a problem. On
Windows, one of the processes will simply fail with an I/O error due to
mandatory file locks. On Unix, the OS will not stop the clash in this way,
but there will be a worse issue: {{libzip.so}} will be trying to load a ZIP
entry based on a stale copy of the ZIP index, so it loads bogus data, and
(being not very robustly written) crashes, taking the whole JVM with it.
Since this class of problem is most likely to occur when loading classes from
{{SNAPSHOT}} JARs in the local repository, I would suggest Maven simply not
do this. Instead, use {{File.createTempFile}} to make a new {{/tmp/*.jar}};
use {{deleteOnExit}} to clean it up at process end (or if possible delete it
sooner, e.g. upon conclusion of the reactor build, or at any time when it can
be determined that mojo execution from this JAR must have ceased); copy the
snapshot JAR from the local repo to this temp location; and load from there.
This means that problems will be limited to the much less likely event that
someone is rebuilding the JAR during the very short period during which the
file copy happens. And on Unix, the result might be a corrupted JAR file (and
thus class loading errors which fail the build somehow), but not a mysterious
JVM crash.
If this proposal sounds good, let me know and I can try to write a patch.
(GitHub pull request would be easiest; I am an Apache committer.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5246) Allow classifier inside plugin element
Martin Desruisseaux created MNG-5246:
Summary: Allow classifier inside plugin element
Key: MNG-5246
URL: https://jira.codehaus.org/browse/MNG-5246
Project: Maven 2 3
Issue Type: Improvement
Components: Plugins and Lifecycle
Affects Versions: 3.0.4
Environment: All
Reporter: Martin Desruisseaux
Priority: Minor
In the current Maven project descriptor
(http://maven.apache.org/ref/3.0.4/maven-model/maven.html), plugins are
declared inside {{build}} elements by specifying the {{groupId}},
{{artifactId}} and {{version}} elements. However the {{classifier}}
element is currently not legal for a plugin. I would like {{classifier}} to
be legal for plugins, like any other dependencies.
*Use case:* I maintain two branches for my project: a development branch on
JDK7, and a branch ported to JDK6. I use custom Maven plugins for my build
process. However the JDK7 doclet API seems to have some incompatible changes
compared to the JDK6 doclet API. In addition some APT (Annotation Processing
Tools) API are being removed from JDK8, since they are now merged with the
javac API. For various reasons (may also be reasons specific to my projects), I
wish slightly different Maven plugins depending if I'm building my JDK6 branch
or my JDK7 branch. I would like to simply use my custom Maven plugins with the
same classifier than the project I'm building, but this is currently not
possible.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-145) If Javadoc is set to aggregate, the build fails inside a Maven plugin module
[
http://jira.codehaus.org/browse/MJAVADOC-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=184118#action_184118
]
Martin Desruisseaux commented on MJAVADOC-145:
--
Is this bug really fixed? I'm using Maven 2.1 with {{maven-javadoc-plugin}} 2.5
in a project having a few Maven plugins, and still get _Error extracting
plugin descriptor: Goal already exists in the plugin descriptor_ when running
{{mvn clean install site}}. The same command without the {{site}} goal works
fine. Removing the aggregated javadoc configuration from the {{reporting}}
section in the root {{pom.xml}} fixes the build as well.
If Javadoc is set to aggregate, the build fails inside a Maven plugin module
Key: MJAVADOC-145
URL: http://jira.codehaus.org/browse/MJAVADOC-145
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.3
Reporter: Howard M. Lewis Ship
Assignee: Vincent Siveton
Priority: Critical
Fix For: 2.4
Attachments: ComponentReport.java, maven.out, pom.xml, pom.xml
If your project contains a Maven plugin, then it is impossible to build
aggregated Javadoc.
As the output (attached) shows, Maven seems to recusively build (what's with
all those skipping messages?). When it reaches the plugin:
[INFO] Error during page generation
Embedded error: Error rendering Maven report: Error extracting plugin
descriptor: 'Goal: component-report already exists in the plugin descriptor
for prefix: tapestry-component-report
Existing implementation is: org.apache.tapestry.mojo.ComponentReport
Conflicting implementation is: org.apache.tapestry.mojo.ComponentReport'
I can get by this with the -fn (fail never) option.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-134) Support aggregated reports at each level in the multi-module hierarchy
[ http://jira.codehaus.org/browse/MJAVADOC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=184119#action_184119 ] Martin Desruisseaux commented on MJAVADOC-134: -- Actually I'm interrested in a variant of this request, where the javadoc is aggregated only starting from the submodule which ask for it. Such feature could (maybe) help to workaround MJAVADOC-145 (closed, but the issue reported in that task still occurs in my project and I have not yet found a workaround), if we can avoid the aggregation of javadoc for Maven plugins. Support aggregated reports at each level in the multi-module hierarchy -- Key: MJAVADOC-134 URL: http://jira.codehaus.org/browse/MJAVADOC-134 Project: Maven 2.x Javadoc Plugin Issue Type: New Feature Affects Versions: 2.2 Reporter: John Allen The current system makes the assumption that if one wants aggregated reports one does not want further javadoc reports (aggregated ones) down the hierarchy. We do require this functionality and in fact do the same for all our reports (PMD, Checkstyle, Clover, JXR, Surefire, etc): A-B-C-D1 (JAR) A-B-C-D2 (JAR) A-B-E(JAR) A-F (JAR) A - javadoc for D1,D2,E,F B - javadoc for D1,D2,E C - javadoc for D1,D2 D1 - javadoc for D1 D2 - javadoc for D2 E - javadoc for E F - javadoc for F This way there is the required info at the appropriate level throughout the hierarchy. And nope we dont care about space or generation times:) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-251) Allows prefixing of eclipse project name
Allows prefixing of eclipse project name
Key: MECLIPSE-251
URL: http://jira.codehaus.org/browse/MECLIPSE-251
Project: Maven 2.x Eclipse Plugin
Issue Type: New Feature
Components: multiproject
Affects Versions: 2.4
Reporter: Martin Desruisseaux
This issue is related to MECLIPSE-44, MECLIPSE-119 and MECLIPSE-161. They were
closed as fixed by MECLIPSE-189, but the later doesn't adress fully our issue
(or works only if we are lucky).
We have two Maven projects (namely _Geotools_ and _Geoserver_) made of many
modules. Some Geoserver modules may (by accident) have the same name than
Geotools modules. For example both Geotools and Geoserver have a module named
_main_. We need to import those two projects in Eclipse, because they are
closely related and share the same pool of developpers. Before MECLIPSE-189, it
was not possible with those names, because of module name clash like _main_.
Since MECLIPSE-189, it is possible if we are lucky enough to have different
Geotools and Geoserver version numbers.
We would like a way to prefix every Eclipse module names. For example we would
like a way to add {{gt-}} in front of every Geotools modules imported in
Eclipse. I realize that the common practice in Maven projects seems to be long
module names (for example {{maven-eclipse-plugin}}), but such practice seems
quite redundant with group name. We would like to keep module names that match
SVN directory names or Maven report directory names (otherwise we often get
broken links in generated HTML pages), and we would like to keep the path names
simple and intelligible (long module names don't bring much compared to full
path names, which should already be unique).
The ability to add some prefix before Eclipse project names would help. If this
is not possible, something like {{addGroupNameToProjectName}} property (similar
to {{addVersionToProjectName}} defined in MECLIPSE-189) could be a fallback.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-28) Using the jar plugin with addClasspath and snapshots can create manifest classpath with incorrect jar versions
[ http://jira.codehaus.org/browse/MJAR-28?page=comments#action_78430 ]
Martin Desruisseaux commented on MJAR-28:
-
Maybe related to this issue: the manifest classpath generated by Maven ignores
the real JAR name as specified in {{finalName}}. For example the Geotools
project tried the following configuration:
{code:xml}
build
finalNamegt-${artifactId}-${version}/finalName
{code}
but the manifest classpath generated by Maven contains only
{{${artifactId}-${version}.jar}} entries, which are non-existent JARs.
*Note:* this problem happen only when the JAR dependencis come from the
repository. The manifest classpath is correct if all dependencies were compiled
in the same {{mvn install}} cycle.
Using the jar plugin with addClasspath and snapshots can create manifest
classpath with incorrect jar versions
--
Key: MJAR-28
URL: http://jira.codehaus.org/browse/MJAR-28
Project: Maven 2.x Jar Plugin
Issue Type: Bug
Affects Versions: 2.0
Reporter: Mark J. Titorenko
Attachments: MJAR-28-patch.txt
When the POM contains dependencies to snapshot versions of jars, and snapshot
versions of those jars are downloaded from a remote repository, the name of
the jar contained in the classpath added to the manifest, of the form
artifactID-X.X-SNAPSHOT.jar, does not match the actual name of the jar
downloaded, which contains version information of the form
artifactID-X.X-MMDD.HHmmss-V.jar.
This does not affect snapshot versions which have been directly installed
into a local repository and have no uploaded version within the remote
repository, as these jars are named using the artifactID-X.X-SNAPSHOT.jar
form.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAR-61) Manifest classpath ignores the real JAR filenames specified in finalName
Manifest classpath ignores the real JAR filenames specified in finalName
Key: MJAR-61
URL: http://jira.codehaus.org/browse/MJAR-61
Project: Maven 2.x Jar Plugin
Issue Type: Bug
Affects Versions: 2.1
Reporter: Martin Desruisseaux
The manifest classpath generated by Maven ignores the real JAR name as
specified in {{finalName}}. For example the Geotools project tried the
following configuration:
{code:xml}
build
finalNamegt-${artifactId}-${version}/finalName
{code}
but the manifest classpath generated by Maven contains only
{{${artifactId}-${version}.jar}} entries, which are non-existent JARs.
*Note:* this problem happen only when the JAR dependencis come from the
repository. The manifest classpath is correct if all dependencies were compiled
in the same {{mvn install}} cycle. However this workaround is applicable only
to Geotools developpers (in our case), because users of the Geotools library
usually download the dependencies from a repository.
This bug may be related to MJAR-28.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-66) Aggregated Javadoc does not use module-level dependencies
[ http://jira.codehaus.org/browse/MJAVADOC-66?page=comments#action_76148 ]
Martin Desruisseaux commented on MJAVADOC-66:
-
Is this bug really fixed in {{maven-javadoc-plugin}} version 2.0? Aggregated
javadoc still fail to find module-level dependencies when building the Geotools
project for example.
Aggregated Javadoc does not use module-level dependencies
-
Key: MJAVADOC-66
URL: http://jira.codehaus.org/browse/MJAVADOC-66
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.0
Environment: WinXP, Maven 2.0.4, maven-javadoc-plugin from source
Reporter: Wendy Smoak
Assigned To: Jesse McConnell
Fix For: 2.0
Attachments: mjavadoc66.patch
The 'mvn javadoc:javadoc' command works fine with the latest plugin built
from source and this in struts/action/trunk/pom.xml:
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
/plugin
/plugins
/reporting
It drops into each module and builds the javadoc there. However, if I add
configuration and try to get aggregated Javadoc at the top level:
configuration
aggregatetrue/aggregate
/configuration
It seems to build the aggregated Javadoc okay, but then when starts
descending into each module it fails complaining Cannot find
symbol... about things like commons-logging and the Servlet api. These are
declared as dependencies at the module level.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPJAVADOC-77) taglet allow only one taglet
taglet allow only one taglet
--
Key: MPJAVADOC-77
URL: http://jira.codehaus.org/browse/MPJAVADOC-77
Project: maven-javadoc-plugin
Issue Type: Bug
Reporter: Martin Desruisseaux
The {{taglet}} configuration element in the javadoc plugin allows for only
one taglet, or doesn't document how to add more than one taglet.
* I tried to put one than one {{taglet}} element in the {{pom.xml}} file, but
the last one seems to override all the previous ones.
* I tried space, coma, : and ; as separator, without success.
It should be possible to add an arbitrary amount of {{taglet}} elements, and
each of them should register a new taglet (through a new occurence of
{{-taglet}} argument given to the {{javadoc}} command line I guess). I tested
that multiple occurence of {{taglet}} works as expected with Ant.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSUREFIRE-43) Surefire fails to start when the local repository and the project (pom.xml) lives in different window drives
[ http://jira.codehaus.org/browse/MSUREFIRE-43?page=comments#action_65543 ]
Martin Desruisseaux commented on MSUREFIRE-43:
--
I can confirm that the bug is fixed with Maven 2.0.4 and maven-surefire-plugin
2.1.3. Thanks for yours work!
Surefire fails to start when the local repository and the project (pom.xml)
lives in different window drives
Key: MSUREFIRE-43
URL: http://jira.codehaus.org/browse/MSUREFIRE-43
Project: Maven 2.x Surefire Plugin
Type: Bug
Versions: 2.1.2
Environment: Windows XP
Java 1.5.0_06
Maven 2.0.1
Surefire fork mode: once
Reporter: Martin Desruisseaux
We have the following situation:
- Local repository in {{C:\Documents and Settings\user\.m2}}
- A Maven 2 project in {{P:\MyProject}}.
- Surefire fork mode set to once.
In this configuration, surefire fails with this (somewhat misleading) error
message:
{quote}
Setting reports dir: {{P:\MyProject\target/surefire-reports}}
BUILD ERROR
There are some test failure.
{quote}
This message is misleading because it suggests that some user's tests failed,
while actually Surefile didn't executed a single one. It even failed before
to create the {{surefire-reports}} directory! So we have no indication about
the cause, and printing the stack trace with the {{-e}} option doesn't help
much (I suspect that this is because the stack trace was actually produced by
a different virtual machine instance, and was not passed to the JVM running
Maven). Running Maven with the {{-X}} option provides more hints however. We
can see that Maven try to executes the following command:
{{java -Xmx512M -enableassertions -classpath
C:\...snip...\.m2\repository\org\apache\maven\surefire\surefire-booter\1.5.2\surefire-booter-1.5.2.jar;
C:\Java\Apache\Maven2\bin\..\core\plexus-utils-1.0.5.jar
org.apache.maven.surefire.SurefireBooter P:\MyProject}}
Running this command manually gives the following output:
{code}
ClassLoader: typeclass sun.misc.Launcher$ExtClassLoader, value=...snip...
: file:/C:/Java/1.5/jre/lib/ext/sunjce_provider.jar
: file:/C:/Java/1.5/jre/lib/ext/sunpkcs11.jar
(...snip...)
ClassLoader: typeclass sun.misc.Launcher$AppClassLoader, value=...snip...
: file:/C:/Documents ...snip... /.m2/repository/ ...snip..
./surefire-booter-1.5.2.jar
: file:/C:/Java/Apache/Maven2/core/plexus-utils-1.0.5.jar
ClassLoader: typeclass org.apache.maven.surefire.IsolatedClassLoader,
value=...snip...
: file:/P:/MyProjects/
(...snip...)
: file:/P:/Documents and
Settings/user/.m2/repository/...snip.../surefire-1.5.2.jar
Exception in thread main java.lang.ClassNotFoundException:
org.apache.maven.surefire.Surefire
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
(...snip...)
{code}
As you can see, the path for {{surefire-1.5.2.jar}} wrongly refer to the
drive letter {{P:}}. It should be {{C:}} instead.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-36) Would like a way to get default javadoc behavior
[ http://jira.codehaus.org/browse/MJAVADOC-36?page=comments#action_60526 ] Martin Desruisseaux commented on MJAVADOC-36: - Thanks for doing all this javadoc work. Would like a way to get default javadoc behavior Key: MJAVADOC-36 URL: http://jira.codehaus.org/browse/MJAVADOC-36 Project: Maven 2.x Javadoc Plugin Type: Wish Environment: Windows XP Reporter: Martin Desruisseaux Assignee: Maria Odea Ching Priority: Minor Fix For: 2.0-beta-4 Attachments: MJAVADOC-36-maven-javadoc-plugin.patch, no_default_stylesheet.diff Time Spent: 2 hours, 30 minutes Remaining: 0 minutes The javadoc plugin overrides some Sun's javadoc default options with its own default. This is quite nice for options like -bottom, since Maven has informations that Sun's javadoc doesn't have. The -package option (which default to 'true' in maven-javadoc-plugin, while the default was 'false' in Sun's javadoc) sound a little bit more surprising to me, since it lead us to a situation where we have two set of default values to keep in mind: the Sun's ones, and the Maven ones. It is not a real problem for options like -package and -use. It is a little bit more disturbing for -stylesheet, since it seems hard to tell to Maven to not use the Maven's stylesheet, but to keep the Sun's default stylesheet instead. I understand that we can provide our own stylesheet with the stylesheet parameter, but in this case I have no file to point; I would just like to keep Sun's default stylesheet. I would like a way to disable completly the -stylesheet option in the javadoc plugin. Or alternatively, the plugin may use the Maven's stylesheet only when explicitly required. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
