[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 > 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
[jira] Updated: (MJAVADOC-28) [EMAIL PROTECTED] foo} doesn't work when "foo" is a package name
[ http://jira.codehaus.org/browse/MJAVADOC-28?page=all ] Martin Desruisseaux updated MJAVADOC-28: Attachment: test.zip > [EMAIL PROTECTED] foo} doesn't work when "foo" is a package name > - > > Key: MJAVADOC-28 > URL: http://jira.codehaus.org/browse/MJAVADOC-28 > Project: Maven 2.x Javadoc Plugin > Type: Bug > Environment: Windows XP > Reporter: Martin Desruisseaux > Assignee: Maria Odea Ching > Priority: Minor > Fix For: 2.0-beta-4 > Attachments: test.zip > > Time Spent: 1 hour, 30 minutes >Remaining: 0 minutes > > See or link tags of the kind [EMAIL PROTECTED] org.mypackage} doesn't work > with maven-javadoc-plugin (we get a "Tag @link: reference not found: > org.mypackage" warning), while it work when using the javadoc tool from the > command line or from an Ant script. I suspect that this is related to the way > maven-javadoc-plugin work, which provides a list of source files as a @files > argument. > A possible workaround is to provide a way to use the maven-javadoc-plugin > through the javadoc's -subpackages option, instead of letting > maven-javadoc-plugin creates a @files. It would gives more control to the > user, would allows the current parameter to work (this > parameter is currently useless since it is ignored when the files to process > are provided in @files), and would solve the problem reported in this JIRA > issue. -- 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] Created: (MPJAVADOC-77) allow only one 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 {{}} 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 {{}} 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 {{}} 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 {{}} 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: (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:
>
>
>
> org.apache.maven.plugins
> maven-javadoc-plugin
>
>
>
> 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:
>
> true
>
> 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] 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 {{>}}. For example the Geotools
project tried the following configuration:
{code:xml}
gt-${artifactId}-${version}
{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
Manifest classpath ignores the "real" JAR filenames specified in
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 {{}}. For example the Geotools project tried the
following configuration:
{code:xml}
gt-${artifactId}-${version}
{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] 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: (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-tabpanel&focusedCommentId=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 {{}}
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-tabpanel&focusedCommentId=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] (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] [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 Atlassia
[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&focusedCommentId=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] (MNG-5437) Do not load plugins from snapshot JARs
[
https://jira.codehaus.org/browse/MNG-5437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 inside element
Martin Desruisseaux created MNG-5246:
Summary: Allow inside 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 {{}} elements by specifying the {{}},
{{}} and {{}} elements. However the {{}}
element is currently not legal for a plugin. I would like {{}} 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] (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-tabpanel&focusedCommentId=345103#comment-345103
]
Martin Desruisseaux commented on MJAVADOC-368:
--
This is also a problem for the new JDK8 {{-Xdoclint}} option. For example:
{noformat}
-Xdoclint:syntax,missing,accessibility
{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
> {{-header 'A,B'}}
> 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
> {{-header 'A,B'}}
> 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-tabpanel&focusedCommentId=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)
