date:20120915


 [ 
https://jira.codehaus.org/browse/MJAVADOC-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Herve Boutemy updated MJAVADOC-171:
---

Assignee: (was: Herve Boutemy)

 Modules in multi-module projects are built too often
 --

 Key: MJAVADOC-171
 URL: https://jira.codehaus.org/browse/MJAVADOC-171
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.3
 Environment: Maven 2.0.8, Linux
Reporter: Stefan Seidel
Priority: Critical
 Attachments: 2.2.log, 2.3.log, mjavadoc-171-b.zip, mjavadoc171.patch, 
 mjavadoc-171.zip, mvnexec.zip


 In a multi-module project, all modules are built twice for each module. 
 This leads to huge performance problems when many modules are in a project. 
 In the attached sample project, the xmlbeans plugin is executed 27 times for 
 a project with one parent module and two submodules. 18 of these executions 
 can be attributed to the javadoc plugin. With version 2.2, only 3 invocations 
 (once for each project) are caused by the javadoc plugin.

--
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] (SUREFIRE-908) Surefire fails with StackOverflowError when toolchains are present


 [ 
https://jira.codehaus.org/browse/SUREFIRE-908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold closed SUREFIRE-908.
---

Resolution: Fixed
  Assignee: Kristian Rosenvold

Fixed in r1385045,  thanks for the bug report !

We've been struggling with test coverage for the toolchain stuff, but I finally 
think I managed to find a nice unit test.



 Surefire fails with StackOverflowError when toolchains are present
 --

 Key: SUREFIRE-908
 URL: https://jira.codehaus.org/browse/SUREFIRE-908
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.12.3
Reporter: Sergei Ivanov
Assignee: Kristian Rosenvold
Priority: Blocker
 Fix For: 2.13


 All our builds failed after an upgrade from 2.12.2 to 2.12.3 with the 
 following stack trace. Looking at the trunk version of 
 {{AbstractSurefireMojo.java}}, there's indeed an infinite recursion between 
 the two methods. The recursion only happens when a toolchain is defined in 
 the project.
 {noformat}
 [INFO] --- maven-surefire-plugin:2.12.3:test (default-test) @ config-server 
 ---
 [INFO] Toolchain in surefire-plugin: 
 JDK[/opt/app//tools/jdk/64/jdk1.6.0_15]
 java.lang.reflect.InvocationTargetException
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
   at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
   at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
   at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
   at hudson.remoting.UserRequest.perform(UserRequest.java:118)
   at hudson.remoting.UserRequest.perform(UserRequest.java:48)
   at hudson.remoting.Request$2.run(Request.java:287)
   at 
 hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   at java.lang.Thread.run(Thread.java:662)
 Caused by: java.lang.StackOverflowError
   at 
 org.apache.maven.plugin.surefire.AbstractSurefireMojo.getEffectiveForkMode(AbstractSurefireMojo.java:890)
   at 
 org.apache.maven.plugin.surefire.AbstractSurefireMojo.isForkModeNever(AbstractSurefireMojo.java:880)
   at 
 org.apache.maven.plugin.surefire.AbstractSurefireMojo.getEffectiveForkMode(AbstractSurefireMojo.java:892)
   at 
 org.apache.maven.plugin.surefire.AbstractSurefireMojo.isForkModeNever(AbstractSurefireMojo.java:880)
   at 
 org.apache.maven.plugin.surefire.AbstractSurefireMojo.getEffectiveForkMode(AbstractSurefireMojo.java:892)
   at 
 org.apache.maven.plugin.surefire.AbstractSurefireMojo.isForkModeNever(AbstractSurefireMojo.java:880)
 ...
 {noformat}

--
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] (SUREFIRE-831) Lexical error in surefire-plugin (TestNGExecutor.applyGroupMatching()) if the groupName of an excludedGroup contains a '-' sign


 [ 
https://jira.codehaus.org/browse/SUREFIRE-831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold closed SUREFIRE-831.
---

Resolution: Fixed
  Assignee: Kristian Rosenvold

Fixed in r1385046, thanks for the bug report !

Updated IT to cover -

 Lexical error in surefire-plugin (TestNGExecutor.applyGroupMatching()) if the 
 groupName of an excludedGroup contains a '-' sign
 ---

 Key: SUREFIRE-831
 URL: https://jira.codehaus.org/browse/SUREFIRE-831
 Project: Maven Surefire
  Issue Type: Bug
  Components: TestNG support
Affects Versions: 2.11, 2.12
 Environment: Tested with maven-surefire-plugin-2.13-20120207.212404-8
Reporter: Andreas Kuhtz
Assignee: Kristian Rosenvold
 Fix For: 2.13


 This occurs even with the current SNAPSHOT release. The issue might be 
 related to SUREFIRE-828.
 {code:title=pom.xml}
 plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
configuration
   excludedGroupsui-test/excludedGroups
/configuration
 /plugin
 {code}
 {code}
 Running TestSuite
 org.apache.maven.surefire.util.SurefireReflectionException: 
 java.lang.reflect.InvocationTargetException; nested exceptio
 n is java.lang.reflect.InvocationTargetException: null
 java.lang.reflect.InvocationTargetException
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at 
 org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
 at 
 org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
 at 
 org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
 at 
 org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
 at 
 org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
 Caused by: org.apache.maven.surefire.testset.TestSetFailedException: null; 
 nested exception is java.lang.reflect.Invocat
 ionTargetException: null
 at 
 org.apache.maven.surefire.testng.TestNGExecutor.applyGroupMatching(TestNGExecutor.java:164)
 at 
 org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:65)
 at 
 org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeMulti(TestNGDirectoryTestSuite.java:161)
 at 
 org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:101)
 at 
 org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:115)
 ... 9 more
 Caused by: java.lang.reflect.InvocationTargetException
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at 
 org.apache.maven.surefire.testng.TestNGExecutor.applyGroupMatching(TestNGExecutor.java:140)
 ... 13 more
 Caused by: org.apache.maven.surefire.group.parse.TokenMgrError: Lexical error 
 at line 1, column 3.  Encountered: - (45
 ), after : 
 at 
 org.apache.maven.surefire.group.parse.GroupMatcherParserTokenManager.getNextToken(GroupMatcherParserTokenMana
 ger.java:468)
 at 
 org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_scan_token(GroupMatcherParser.java:527)
 at 
 org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_3_7(GroupMatcherParser.java:274)
 at 
 org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_3R_3(GroupMatcherParser.java:287)
 at 
 org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_3_3(GroupMatcherParser.java:279)
 at 
 org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_3R_1(GroupMatcherParser.java:320)
 at 
 org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_3_1(GroupMatcherParser.java:335)
 at 
 org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_2_1(GroupMatcherParser.java:179)
 at 
 org.apache.maven.surefire.group.parse.GroupMatcherParser.expr(GroupMatcherParser.java:63)
 at 
 org.apache.maven.surefire.group.parse.GroupMatcherParser.parse(GroupMatcherParser.java:56)
 at

[jira] (MRELEASE-734) When releaseVersion and developmentVersion are passed in command-line but are empty should be treated as not-defined

2012-09-15 Thread Robert Scholte (JIRA)


 [ 
https://jira.codehaus.org/browse/MRELEASE-734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte closed MRELEASE-734.
---

Resolution: Fixed

Fixed in [r1385048|http://svn.apache.org/viewvc?rev=1385048view=rev]

 When releaseVersion and developmentVersion are passed in command-line but are 
 empty should be treated as not-defined
 

 Key: MRELEASE-734
 URL: https://jira.codehaus.org/browse/MRELEASE-734
 Project: Maven 2.x Release Plugin
  Issue Type: Improvement
  Components: prepare
Affects Versions: 2.2.2
Reporter: Dmitry Katsubo
Assignee: Robert Scholte
 Fix For: 2.4


 In my case I would like to pass {{releaseVersion}} and {{developmentVersion}} 
 taken from user input, e.g. from [Hudson Release 
 Plugin|http://wiki.hudson-ci.org/display/HUDSON/Release+Plugin]:
 {code}
 release:prepare release:perform -DreleaseVersion=${RELEASE_VERSION} 
 -DdevelopmentVersion=${DEVELOPMENT_VERSION}
 {code}
 however if user leaves input fields empty it would be nice if 
 maven-release-plugin would treat empty values as non-defined and fallback to 
 default behaviour: inherit the next version from pom. Currently it breaks 
 down with message 'Unable to parse the version string '.

--
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] (MRELEASE-760) updateWorkingCopyVersions=false still bumps up pom versions to next development version

2012-09-15 Thread Robert Scholte (JIRA)

[
https://jira.codehaus.org/browse/MRELEASE-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Robert Scholte closed MRELEASE-760.
---

Resolution: Fixed

Joeri, I'll close this, since the original issue was fixed.
Concerning your wish to keep development versions locked on the release
version, there are a few reasons why I think this is not good practice:
- This would mean that the same version could be build + deployed multiple
times, so in fact it is a new artifact. For this reason most
repository-managers won't allow you to deploy the same artifact twice by
default.
- Best practice is to base your project structure on a release-cycle: projects
which must be released at once are part of a multi-module tree. So in our case
seperate implementation from API modules.
- Versions are cheap and is much easier to manage modules with the same
version, even if there's no code change. At least with non-bugfix releases it
would probably be better if all versions are in sync, so the user knows for
sure all artifacts are part of the same delivery/shipment.
- No codechange doesn't mean that the build-result will still be the same.
Recently we've discovered usecases which confirms this. Mark Struberg is
working on a new strategy called 'incremental builds' which should solve such
issues.

If you still think there's enough reason to implement your wish, please create
new issue.

updateWorkingCopyVersions=false still bumps up pom versions to next
development version
---

Key: MRELEASE-760
URL: https://jira.codehaus.org/browse/MRELEASE-760
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.3
Reporter: Joeri Leemans
Assignee: Robert Scholte
Fix For: 2.3.2

Attachments: maven-release-plugin-testcase.zip, mrelease760-patch.diff

The flag updateWorkingCopyVersions (more specifically with value false) is
not handled correctly.
Attached project is a simple Maven project with version 1.0-SNAPSHOT,
depending on version 2.3 of the release plugin. It is configured with
dryRun=true and updateWorkingCopyVersions=false.
When running mvn:prepare (and accepting the versions that are proposed),
you'll see that pom.xml.next file contains 1.1-SNAPSHOT (the next development
version) instead of 1.0 (the tagged version).

--
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-328) docletpath parameter not working from command line


 [ 
https://jira.codehaus.org/browse/MJAVADOC-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Herve Boutemy closed MJAVADOC-328.
--

Resolution: Not A Bug

 docletpath parameter not working from command line
 --

 Key: MJAVADOC-328
 URL: https://jira.codehaus.org/browse/MJAVADOC-328
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.8
 Environment: MacOS 10.6, Java 6
Reporter: Guy Rixon

 The command-line parameter -Ddocletpath is being ignored. Maven says: 
 [WARNING] No docletpath option was found. Please review docletpath/ or 
 docletArtifact/ or doclets/ and then fails to find the doclet. The 
 parameter -Ddoclet is working.

--
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-331) DEFAULT_JAVA_API_LINKS values to be held in properties file


 [ 
https://jira.codehaus.org/browse/MJAVADOC-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Herve Boutemy closed MJAVADOC-331.
--

Resolution: Won't Fix

thanks for the suggestion
but avoiding some compilation is not of any value here

 DEFAULT_JAVA_API_LINKS values to be held in properties file
 ---

 Key: MJAVADOC-331
 URL: https://jira.codehaus.org/browse/MJAVADOC-331
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Improvement
Reporter: Luke Robertson

 Currently DEFAULT_JAVA_API_LINKS values are held in static fields under 
 /maven-javadoc-plugin-2.8/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java
  
 Suggest that moving these out to a properties file would mean that should an 
 issue similar to http://jira.codehaus.org/browse/MJAVADOC-301 occur again 
 this would not require the plugin to be recompiled.

--
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-332) outputDirectory is not honored as it should, but valuated to destDir.


 [ 
https://jira.codehaus.org/browse/MJAVADOC-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Herve Boutemy closed MJAVADOC-332.
--

Resolution: Not A Bug
  Assignee: Herve Boutemy

when deploying the site, you'll get what you expect
it's normal that the site has this problem at build time

 outputDirectory is not honored as it should, but valuated to destDir.
 -

 Key: MJAVADOC-332
 URL: https://jira.codehaus.org/browse/MJAVADOC-332
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.8
 Environment: WXP SP3 JDK 1.6.0_26 Maven 3.0
Reporter: zosrothko
Assignee: Herve Boutemy

 Hi
 The outputDirectory is referencing ${destDir} instead of ${outputDirectory} 
 as per following snippet extracted from AbstractJavadocMojo.java
 /**
  * Specifies the destination directory where javadoc saves the generated 
 HTML files.
  * br/
  * See a 
 href=http://download.oracle.com/javase/1.4.2/docs/tooldocs/windows/javadoc.html#d;d/a.
  * br/
  *
  * @parameter expression=${destDir} alias=destDir 
 default-alue=${project.build.directory}/apidocs
  * @required
  */
 protected File outputDirectory;

--
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-348) Update javaApiLinks links


[ 
https://jira.codehaus.org/browse/MJAVADOC-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308586#comment-308586
 ] 

Herve Boutemy commented on MJAVADOC-348:


docs update in [r1385123|http://svn.apache.org/viewvc?rev=1385123view=rev]

 Update javaApiLinks links
 ---

 Key: MJAVADOC-348
 URL: https://jira.codehaus.org/browse/MJAVADOC-348
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Improvement
Reporter: Paul Benedict
Assignee: Benson Margulies
Priority: Minor
 Fix For: 2.9


 Oracle has moved their API documentation from download.oracle.com to 
 docs.oracle.com

--
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] (SUREFIRE-841) Incorrect Test Run Count

[
https://jira.codehaus.org/browse/SUREFIRE-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308587#comment-308587
]

Kristian Rosenvold commented on SUREFIRE-841:
-

The behaviour you expect is compliant with a JUnit3 runner (and TestNG, which
up until just recently was only JUnit3 compliant). Surefire's behaviour is
consistent with JUnit4.

Ant is a JUnit3 based test-runner.

I'm still trying to figure out what to do with this issue:
A) Close it as wontfix.
B) Make surefire report JUnit3/TestNG style when using these libraries and
JUnit4 style when using junit4.

The problem with B is that surefire will appear to behave inconsistently when
users upgrade from 3.x to 4.x.

For those wishing to experiment with this, there is an IT project at:

https://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-integration-tests/src/test/resources/failure-result-counting

This verifies all the different modes of reporting.

Incorrect Test Run Count

Key: SUREFIRE-841
URL: https://jira.codehaus.org/browse/SUREFIRE-841
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Reporter: karthik kandasamy
Fix For: 2.13

When a simple Junit test with errors in the @Before() and @After() method are
run directly with java or ant's junit task, it reports correctly that the
Tests Run = 1 and Errors = 2.
But when the same is run through maven surefire plugin, it reports it as
Tests Run = 2 and Errors = 2.
Its the same test in which 2 errors are encountered, so the Tests Run should
be 1.
I traced the issue to the org.apache.maven.surefire.report.TestSetRunListener
Class - testError() method, where the completed count is also incremented
along with the error count irrespective of whether its in the same test the
error is encountered.

[jira] (SUREFIRE-841) Incorrect Test Run Count

[
https://jira.codehaus.org/browse/SUREFIRE-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308587#comment-308587
]

Kristian Rosenvold edited comment on SUREFIRE-841 at 9/15/12 12:05 PM:
---

The behaviour you expect is compliant with a JUnit3 runner (and TestNG, which
up until just recently was only JUnit3 compliant). Surefire's behaviour is
consistent with JUnit4. (I am not sure how TestNG behaves when running JUnit4
tests)

Ant is a JUnit3 based test-runner.

I'm still trying to figure out what to do with this issue:
A) Close it as wontfix.
B) Make surefire report JUnit3/TestNG style when using these libraries and
JUnit4 style when using junit4.

The problem with B is that surefire will appear to behave inconsistently when
users upgrade from 3.x to 4.x.

For those wishing to experiment with this, there is an IT project at:

https://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-integration-tests/src/test/resources/failure-result-counting

This verifies all the different modes of reporting.

was (Author: krosenvold):
The behaviour you expect is compliant with a JUnit3 runner (and TestNG,
which up until just recently was only JUnit3 compliant). Surefire's behaviour
is consistent with JUnit4.

Ant is a JUnit3 based test-runner.

I'm still trying to figure out what to do with this issue:
A) Close it as wontfix.
B) Make surefire report JUnit3/TestNG style when using these libraries and
JUnit4 style when using junit4.

The problem with B is that surefire will appear to behave inconsistently when
users upgrade from 3.x to 4.x.

For those wishing to experiment with this, there is an IT project at:

https://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-integration-tests/src/test/resources/failure-result-counting

This verifies all the different modes of reporting.

Incorrect Test Run Count

Key: SUREFIRE-841
URL: https://jira.codehaus.org/browse/SUREFIRE-841
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Reporter: karthik kandasamy
Fix For: 2.13

[jira] (SUREFIRE-841) Incorrect Test Run Count

2012-09-15 Thread Baptiste MATHUS (JIRA)

[
https://jira.codehaus.org/browse/SUREFIRE-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308588#comment-308588
]

Baptiste MATHUS commented on SUREFIRE-841:
--

I would go with being consistent with the underlying test engine in use. So I
guess it's B).
Ant Runner should be fixed for the cases when it runs JUnit 4 or JUnit 3.
By the way, maybe the problem is larger than just Surefire: maybe TestNg team
and Junit one should try align their way of thinking if possible. If already
done, then we're back to B.

Incorrect Test Run Count

Key: SUREFIRE-841
URL: https://jira.codehaus.org/browse/SUREFIRE-841
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Reporter: karthik kandasamy
Fix For: 2.13

[jira] (SUREFIRE-841) Incorrect Test Run Count


[ 
https://jira.codehaus.org/browse/SUREFIRE-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308589#comment-308589
 ] 

Kristian Rosenvold commented on SUREFIRE-841:
-

The ant runner has basically been un-maintained for several years, so I'm not 
really sure they're anything to go by. 

As for who's who in the testing business, JUnit usually defines the standard 
and the others follow suite. AFIK JUnit is still almost 10x the users of 
TestNG. So I really have no problem with us folowing JUnit4 only ;) Although it 
would be real easy to adapt to the underlying framework, I'm afraid of the 
potential for creating confusion

 Incorrect Test Run Count
 

 Key: SUREFIRE-841
 URL: https://jira.codehaus.org/browse/SUREFIRE-841
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Reporter: karthik kandasamy
 Fix For: 2.13


 When a simple Junit test with errors in the @Before() and @After() method are 
 run directly with java or ant's junit task, it reports correctly that the 
 Tests Run = 1  and  Errors = 2.
 But when the same is run through maven surefire plugin, it reports it as 
 Tests Run = 2  and Errors = 2.
 Its the same test in which 2 errors are encountered, so the Tests Run should 
 be 1.
 I traced the issue to the org.apache.maven.surefire.report.TestSetRunListener 
 Class - testError() method, where the completed count is also incremented 
 along with the error count irrespective of whether its in the same test the 
 error is encountered.

--
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] (SUREFIRE-841) Incorrect Test Run Count

2012-09-15 Thread Baptiste MATHUS (JIRA)


[ 
https://jira.codehaus.org/browse/SUREFIRE-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308590#comment-308590
 ] 

Baptiste MATHUS commented on SUREFIRE-841:
--

I agree about being cautious about creating confusion. But still, surefire 
didn't create that confusion, from what I see JUnit did by changing its 
behaviour, isn't it?

I think only a small warning in the doc would prevent many users from being 
surprised. And if some get surprised, well that's a JUnit-side issue in the 
first place...

 Incorrect Test Run Count
 

 Key: SUREFIRE-841
 URL: https://jira.codehaus.org/browse/SUREFIRE-841
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Reporter: karthik kandasamy
 Fix For: 2.13


 When a simple Junit test with errors in the @Before() and @After() method are 
 run directly with java or ant's junit task, it reports correctly that the 
 Tests Run = 1  and  Errors = 2.
 But when the same is run through maven surefire plugin, it reports it as 
 Tests Run = 2  and Errors = 2.
 Its the same test in which 2 errors are encountered, so the Tests Run should 
 be 1.
 I traced the issue to the org.apache.maven.surefire.report.TestSetRunListener 
 Class - testError() method, where the completed count is also incremented 
 along with the error count irrespective of whether its in the same test the 
 error is encountered.

--
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-345) Javadoc-aggregate fail


[ 
https://jira.codehaus.org/browse/MJAVADOC-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308591#comment-308591
 ] 

Herve Boutemy commented on MJAVADOC-345:


can you attach a sample project?

 Javadoc-aggregate fail
 --

 Key: MJAVADOC-345
 URL: https://jira.codehaus.org/browse/MJAVADOC-345
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.8.1
Reporter: Lefebvre JF

 The javadoc-aggregate fail if there is a goal configured to execute on the 
 initialize phase of a war project (but works with parameter aggregate=true)
 To reproduce
 - create a multi-project with a child war project
 - on the war project, define execution of a plugin on the initialize phase 
 (example ant just do a hello world)
 - Launch javadoc-aggregate on the parent project
 Tanks 

--
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-253) Http proxy does not work any more


 [ 
https://jira.codehaus.org/browse/MJAVADOC-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benson Margulies updated MJAVADOC-253:
--

Priority: Major  (was: Critical)

 Http proxy does not work any more
 -

 Key: MJAVADOC-253
 URL: https://jira.codehaus.org/browse/MJAVADOC-253
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.6, 2.7
 Environment: Maven 2.0.9
 JDK5 (Sun)
Reporter: Mohan K

 It appears the update of Wagon Provider in 2.6 is not compatible with Maven 
 2.0.x. Here is the
 email snippet as posted to maven users group (no responses)
 I am using Maven 2.0.9 and maven-javadoc-plugin 2.6. I have the links 
 configured in my
 plugin config. Now all resolution of external links fail (we are behind a 
 proxy *not* NTLM)
 with this:
 Aug 12, 2009 12:02:31 AM 
 org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme
 INFO: ntlm authentication scheme selected
 Aug 12, 2009 12:02:31 AM org.apache.commons.httpclient.HttpMethodDirector 
 authenticate
 The wagon provider appears to have been upgraded to 1.0-beta-6 in the 
 maven-javadoc-plugin 2.6
 (as opposed to 1.0-beta-2 in 2.5). I seem to remember that (maybe it is 
 wrong) that wagon 1.0-beta-6
 requires Maven 2.1.x and above? If that is the case, I don't understand how 
 the plugin was released with
 prerequisite of 2.0.9? 
 Is there a workaround to disable the default ntlm auth scheme via a magical 
 system property? TIA 

--
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-171) Modules in multi-module projects are built too often


 [ 
https://jira.codehaus.org/browse/MJAVADOC-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benson Margulies updated MJAVADOC-171:
--

Priority: Major  (was: Critical)

 Modules in multi-module projects are built too often
 --

 Key: MJAVADOC-171
 URL: https://jira.codehaus.org/browse/MJAVADOC-171
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.3
 Environment: Maven 2.0.8, Linux
Reporter: Stefan Seidel
 Attachments: 2.2.log, 2.3.log, mjavadoc-171-b.zip, mjavadoc171.patch, 
 mjavadoc-171.zip, mvnexec.zip


 In a multi-module project, all modules are built twice for each module. 
 This leads to huge performance problems when many modules are in a project. 
 In the attached sample project, the xmlbeans plugin is executed 27 times for 
 a project with one parent module and two submodules. 18 of these executions 
 can be attributed to the javadoc plugin. With version 2.2, only 3 invocations 
 (once for each project) are caused by the javadoc plugin.

--
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-324) Dependency sources support appears to require javadoc-resources


 [ 
https://jira.codehaus.org/browse/MJAVADOC-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benson Margulies updated MJAVADOC-324:
--

Priority: Major  (was: Critical)

 Dependency sources support appears to require javadoc-resources
 ---

 Key: MJAVADOC-324
 URL: https://jira.codehaus.org/browse/MJAVADOC-324
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.8
 Environment: Win 7
Reporter: Brian Albers

 I cannot seem to get the includeDependencySources support to work. Although 
 I have scoped the dependencies down using various combinations of 
 dependencySourceIncludes and dependencySourcesExcludes, as well as 
 setting includeTransitiveDependencySources to false, no iteration ever 
 succeeds.
 Instead, the javadoc:jar goal complains of being unable to find the 
 javadoc-resources for a whole slew of dependencies.
 None of my projects or dependencies use javadoc-resources. They are all very 
 basic Javascript JARs with minimal configuration.
 I noticed that part of the 2.7 release (revision 933380) added support for 
 javadoc-resource bundle aggregation, as well. Is the javadoc-resources search 
 not scoped to the include/exclude list?

--
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-253) Http proxy does not work any more

[
https://jira.codehaus.org/browse/MJAVADOC-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308592#comment-308592
]

Benson Margulies commented on MJAVADOC-253:
---

I don't think that there is anyone prepared to do work to improve the behavior
of this plugin with maven 2.0.x. Barring other commentary, I'll close this as
wont-fix.

Http proxy does not work any more
-

Key: MJAVADOC-253
URL: https://jira.codehaus.org/browse/MJAVADOC-253
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.6, 2.7
Environment: Maven 2.0.9
JDK5 (Sun)
Reporter: Mohan K

It appears the update of Wagon Provider in 2.6 is not compatible with Maven
2.0.x. Here is the
email snippet as posted to maven users group (no responses)
I am using Maven 2.0.9 and maven-javadoc-plugin 2.6. I have the links
configured in my
plugin config. Now all resolution of external links fail (we are behind a
proxy *not* NTLM)
with this:
Aug 12, 2009 12:02:31 AM
org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme
INFO: ntlm authentication scheme selected
Aug 12, 2009 12:02:31 AM org.apache.commons.httpclient.HttpMethodDirector
authenticate
The wagon provider appears to have been upgraded to 1.0-beta-6 in the
maven-javadoc-plugin 2.6
(as opposed to 1.0-beta-2 in 2.5). I seem to remember that (maybe it is
wrong) that wagon 1.0-beta-6
requires Maven 2.1.x and above? If that is the case, I don't understand how
the plugin was released with
prerequisite of 2.0.9?
Is there a workaround to disable the default ntlm auth scheme via a magical
system property? TIA

[jira] (MJAVADOC-333) Diacritics (accents) in project path prevent the plugin from working on Windows.


 [ 
https://jira.codehaus.org/browse/MJAVADOC-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benson Margulies updated MJAVADOC-333:
--

Description: 
My project is located in E:\ProgramovÃ¡nÃ\Java\beam-3D-data-viewer. Notice 
the diacritics in the path.

When launching the javadoc:javadoc goal, the build fails:
.
.
.
[ERROR] javadoc: warning - No source files for package org.esa.beam.util
[ERROR] javadoc: error - No public or protected classes found to document.

I looked on the generated options file, and that's the problem. Windows 
apparentely don't have their filenames encoded in UTF8 when passing them to the 
command line, but the options file is saved in UTF8. That's the reason why the 
plugin cannot find the source files. When I manually edit the file and save it 
in cp1250 encoding, running javadoc.bat works perfectly.

This should obviously be fixed, but is there a quick workaround? Eg. a way to 
alter the generated javadoc.bat to prepend a call to iconv or something else.

Now I can use the generated files, manually edit the options file, and run the 
task, but if I want to run the jar goal, this bug makes it impossible.

Thanks for cooperation!

  was:
My project is located in E:\Programování\Java\beam-3D-data-viewer. Notice the 
diacritics in the path.

When launching the javadoc:javadoc goal, the build fails:
.
.
.
[ERROR] javadoc: warning - No source files for package org.esa.beam.util
[ERROR] javadoc: error - No public or protected classes found to document.

I looked on the generated options file, and that's the problem. Windows 
apparentely don't have their filenames encoded in UTF8 when passing them to the 
command line, but the options file is saved in UTF8. That's the reason why the 
plugin cannot find the source files. When I manually edit the file and save it 
in cp1250 encoding, running javadoc.bat works perfectly.

This should obviously be fixed, but is there a quick workaround? Eg. a way to 
alter the generated javadoc.bat to prepend a call to iconv or something else.

Now I can use the generated files, manually edit the options file, and run the 
task, but if I want to run the jar goal, this bug makes it impossible.

Thanks for cooperation!

   Priority: Major  (was: Critical)

 Diacritics (accents) in project path prevent the plugin from working on 
 Windows.
 

 Key: MJAVADOC-333
 URL: https://jira.codehaus.org/browse/MJAVADOC-333
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.7, 2.8
 Environment: Win7
Reporter: Martin Pecka

 My project is located in E:\ProgramovÃ¡nÃ\Java\beam-3D-data-viewer. Notice 
 the diacritics in the path.
 When launching the javadoc:javadoc goal, the build fails:
 .
 .
 .
 [ERROR] javadoc: warning - No source files for package org.esa.beam.util
 [ERROR] javadoc: error - No public or protected classes found to document.
 I looked on the generated options file, and that's the problem. Windows 
 apparentely don't have their filenames encoded in UTF8 when passing them to 
 the command line, but the options file is saved in UTF8. That's the reason 
 why the plugin cannot find the source files. When I manually edit the file 
 and save it in cp1250 encoding, running javadoc.bat works perfectly.
 This should obviously be fixed, but is there a quick workaround? Eg. a way to 
 alter the generated javadoc.bat to prepend a call to iconv or something else.
 Now I can use the generated files, manually edit the options file, and run 
 the task, but if I want to run the jar goal, this bug makes it impossible.
 Thanks for cooperation!

--
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-324) Dependency sources support appears to require javadoc-resources

[
https://jira.codehaus.org/browse/MJAVADOC-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308593#comment-308593
]

Benson Margulies commented on MJAVADOC-324:
---

A testcase would be helpful here.

Dependency sources support appears to require javadoc-resources
---

Key: MJAVADOC-324
URL: https://jira.codehaus.org/browse/MJAVADOC-324
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.8
Environment: Win 7
Reporter: Brian Albers

I cannot seem to get the includeDependencySources support to work. Although
I have scoped the dependencies down using various combinations of
dependencySourceIncludes and dependencySourcesExcludes, as well as
setting includeTransitiveDependencySources to false, no iteration ever
succeeds.
Instead, the javadoc:jar goal complains of being unable to find the
javadoc-resources for a whole slew of dependencies.
None of my projects or dependencies use javadoc-resources. They are all very
basic Javascript JARs with minimal configuration.
I noticed that part of the 2.7 release (revision 933380) added support for
javadoc-resource bundle aggregation, as well. Is the javadoc-resources search
not scoped to the include/exclude list?

[jira] (MJAVADOC-341) The javadoc.bat file created in the apidocs directory by using debugtrue/debug causes site deployment to fail


[ 
https://jira.codehaus.org/browse/MJAVADOC-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308594#comment-308594
 ] 

Herve Boutemy commented on MJAVADOC-341:


commands are really launched from target/site/apidocs: creating the script 
outside would mean the script would not represent really what is running
so bad idea

you should disable debug if this causes trouble with your target deploy

 The javadoc.bat file created in the apidocs directory by using 
 debugtrue/debug causes site deployment to fail
 -

 Key: MJAVADOC-341
 URL: https://jira.codehaus.org/browse/MJAVADOC-341
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.8.1
Reporter: Adrián Boimvaser

 I'm deploying to MS Sharepoint via WevDAV with wagon-webdav-jackrabit.
 mvn site-deploy fails while trying to upload javadoc.bat with HTTP error 414.
 Maybe javadoc.{bat,sh} should be created outside target/site?

--
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-318) detectLinks should work together with links, or allow overrides for docs it can't locate


 [ 
https://jira.codehaus.org/browse/MJAVADOC-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Herve Boutemy closed MJAVADOC-318.
--

Resolution: Cannot Reproduce
  Assignee: Herve Boutemy

AFAIK, manually defined links are added to detected dependencies links

I really don't understand what is missing to you

Without any explanation, I can't do anything more than close the report as 
Cannot Reproduce

 detectLinks should work together with links, or allow overrides for docs it 
 can't locate
 

 Key: MJAVADOC-318
 URL: https://jira.codehaus.org/browse/MJAVADOC-318
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Improvement
Reporter: Jenni Syed
Assignee: Herve Boutemy

 When detectLinks is true, it tends to find the correct javadoc link for 80%+ 
 of the referenced classes. If I add the few locations that are not able to be 
 detected to the links section, these will be ignored. Ideally, detectLinks 
 would find whatever it could automatically, but work in conjuction with an 
 override that can be provided for the locations you know it won't be able to 
 find.

--
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-350) Allow include/exclude at the class level


 [ 
https://jira.codehaus.org/browse/MJAVADOC-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Herve Boutemy updated MJAVADOC-350:
---

Comment: was deleted

(was: ONLINE STORE : 

+++ http://l2y.eu/dddqh ++


Best online store

Best quality, Best reputation , Best services

--- NHL Jersey Woman $ 40 --- NFL Jersey $ 35

--- NBA Jersey $ 34 --- MLB Jersey $ 35

--- Jordan Six Ring_m $ 36 --- Air Yeezy_m $ 45

--- T-Shirt_m $ 25 --- Jacket_m $ 36

--- Hoody_m $ 50 --- Manicure Set $ 20

--- handbag $ 37 --- ugg boot $ 43 ---

--- sunglass $ 16 --- bult $ 17 ---

+++ http://l2y.eu/dddqh ++)

 Allow include/exclude at the class level
 

 Key: MJAVADOC-350
 URL: https://jira.codehaus.org/browse/MJAVADOC-350
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Improvement
Affects Versions: 2.8.1
Reporter: Benson Margulies
Assignee: Benson Margulies
 Fix For: 2.9


 Javadoc itself (and the ant task, for purposes of comparison) allows 
 controlling the source files that are processed, one at a time. I suggest the 
 creation of a standard maven include/exclude setup to give class-at-a-time 
 control.

--
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-330) Ability to exclude specific classes


 [ 
https://jira.codehaus.org/browse/MJAVADOC-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Herve Boutemy closed MJAVADOC-330.
--

   Resolution: Duplicate
Fix Version/s: 2.9

AFAIK done in MJAVADOC-350

 Ability to exclude specific classes
 ---

 Key: MJAVADOC-330
 URL: https://jira.codehaus.org/browse/MJAVADOC-330
 Project: Maven 2.x Javadoc Plugin
  Issue Type: New Feature
Affects Versions: 2.8
Reporter: Gili
 Fix For: 2.9


 I'd like to be able to specify specific classes to include or exclude in a 
 project's Javadoc. See 
 http://stackoverflow.com/questions/1195647/maven-javadoc-plugin-how-can-i-include-only-certain-classes
  for a related discussion (this was posted by another user).
 I am only personally interested in the ability to exclude specific classes in 
 a package but allowing others.

--
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-335) In Maven 3 it is impossible to generate several JavaDoc reports at once


 [ 
https://jira.codehaus.org/browse/MJAVADOC-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Herve Boutemy updated MJAVADOC-335:
---

Description: 
When I try to generate several JavaDoc reports using mvn site(see pom.xml 
fragment below), only last one is actually created.
It works perfectly in Maven 2.2.1 and looks broken in Maven 3.0.3. I tried to 
change pom.xml to Maven 3 style (use Maven Site Plugin reportPlugins section 
instead of reporting) but it didn't help.


Workaround: use Maven 2.2.1 for site generation.

{code:xml}reporting
plugins

plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
version2.8/version
reportSets

reportSet
idreport-1/id
configuration
   destDirdocs1/destDir
...
/configuration
reports
reportjavadoc/report
/reports
/reportSet
reportSet
idreport-2/id
configuration
   destDirdocs2/destDir
   ...
/configuration
reports
reportjavadoc/report
/reports
/reportSet
/reportSets
/plugin

/plugins
/reporting
{code}


  was:
When I try to generate several JavaDoc reports using mvn site(see pom.xml 
fragment below), only last one is actually created.
It works perfectly in Maven 2.2.1 and looks broken in Maven 3.0.3. I tried to 
change pom.xml to Maven 3 style (use Maven Site Plugin reportPlugins section 
instead of reporting) but it didn't help.


Workaround: use Maven 2.2.1 for site generation.

reporting
plugins

plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
version2.8/version
reportSets

reportSet
idreport-1/id
configuration
   destDirdocs1/destDir
...
/configuration
reports
reportjavadoc/report
/reports
/reportSet
reportSet
idreport-2/id
configuration
   destDirdocs2/destDir
   ...
/configuration
reports
reportjavadoc/report
/reports
/reportSet
/reportSets
/plugin

/plugins
/reporting




 In Maven 3 it is impossible to generate several JavaDoc reports at once
 ---

 Key: MJAVADOC-335
 URL: https://jira.codehaus.org/browse/MJAVADOC-335
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.8
 Environment: Maven 3.0.3
Reporter: Anton Nikitin

 When I try to generate several JavaDoc reports using mvn site(see pom.xml 
 fragment below), only last one is actually created.
 It works perfectly in Maven 2.2.1 and looks broken in Maven 3.0.3. I tried to 
 change pom.xml to Maven 3 style (use Maven Site Plugin reportPlugins 
 section instead of reporting) but it didn't help.
 Workaround: use Maven 2.2.1 for site generation.
 {code:xml}reporting
 plugins
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-javadoc-plugin/artifactId
 version2.8/version
 reportSets
 reportSet
 idreport-1/id
 configuration
destDirdocs1/destDir
 ...
 /configuration
 reports
 reportjavadoc/report
 /reports
 /reportSet
 reportSet
 idreport-2/id
 configuration
destDirdocs2/destDir
...
 /configuration
 reports
 reportjavadoc/report
 /reports
 /reportSet
 /reportSets

[jira] (MJAVADOC-274) Regression in 2.6.1 - modules with no sources cause an error


 [ 
https://jira.codehaus.org/browse/MJAVADOC-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Herve Boutemy closed MJAVADOC-274.
--

Resolution: Not A Bug

 Regression in 2.6.1 - modules with no sources cause an error
 

 Key: MJAVADOC-274
 URL: https://jira.codehaus.org/browse/MJAVADOC-274
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.6.1
Reporter: Andrey Razumovsky
Assignee: John Casey
 Attachments: MJAVADOC-274.zip


 After upgrading from 2.6 to 2.6.1 our Apache Cayenne builds got broken. The 
 problem is in module with no public or protected sources (there's only a 
 package-private class). Now, after infamous message 
 'org.apache.maven.plugins:maven-javadoc-plugin:2.6:javadoc' has not be
 previously called for the project ... build fails and creates an error 
 report. In the report:
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] An error has occurred in JavaDocs report generation:
 Exit code: 1 - javadoc: error - No public or protected classes found to 
 document.
 Command line was: C:\Progra~1\Java\jdk1.6.0_13\jre\..\bin\javadoc.exe 
 @options @packages
 Refer to the generated Javadoc files in 
 'C:\Project\cayenne-parent\framework\cayenne-jdk1.6-unpublished\target\site\apidocs'
  dir.

--
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-333) Diacritics (accents) in project path prevent the plugin from working on Windows.


[ 
https://jira.codehaus.org/browse/MJAVADOC-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308599#comment-308599
 ] 

Herve Boutemy commented on MJAVADOC-333:


there were little improvements lately
can you check if the problem is still here with latest snapshot, please?

 Diacritics (accents) in project path prevent the plugin from working on 
 Windows.
 

 Key: MJAVADOC-333
 URL: https://jira.codehaus.org/browse/MJAVADOC-333
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.7, 2.8
 Environment: Win7
Reporter: Martin Pecka

 My project is located in E:\ProgramovÃ¡nÃ\Java\beam-3D-data-viewer. Notice 
 the diacritics in the path.
 When launching the javadoc:javadoc goal, the build fails:
 .
 .
 .
 [ERROR] javadoc: warning - No source files for package org.esa.beam.util
 [ERROR] javadoc: error - No public or protected classes found to document.
 I looked on the generated options file, and that's the problem. Windows 
 apparentely don't have their filenames encoded in UTF8 when passing them to 
 the command line, but the options file is saved in UTF8. That's the reason 
 why the plugin cannot find the source files. When I manually edit the file 
 and save it in cp1250 encoding, running javadoc.bat works perfectly.
 This should obviously be fixed, but is there a quick workaround? Eg. a way to 
 alter the generated javadoc.bat to prepend a call to iconv or something else.
 Now I can use the generated files, manually edit the options file, and run 
 the task, but if I want to run the jar goal, this bug makes it impossible.
 Thanks for cooperation!

--
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] (WAGON-374) Deploying your Maven site to GitHub's gh-pages


[ 
https://jira.codehaus.org/browse/WAGON-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308601#comment-308601
 ] 

Rob Elliot commented on WAGON-374:
--

This is my experience also. When I try it I have the following issues:

1) The versions are wrong - maven-scm-manager-plexus is currently at 1.8, as is 
maven-scm-provider-gitexe. In the example on the page they are both at 2.2. 
Easy to fix, but the documentation as it stands is wrong.

2) Maven complains that it does not understand the settings.xml:
{noformat}
[WARNING] 
[WARNING] Some problems were encountered while building the effective settings
[WARNING] Unrecognised tag: 'scmVersionType' (position: START_TAG seen 
.../password\n  scmVersionType... @21:23)  @ 
/Users/Robert/.m2/settings.xml, line 21, column 23
[WARNING] 
{noformat}

3) On attempting a site-deploy I get this error:
{noformat}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-site-plugin:3.1:deploy (default-deploy) on 
project sandbox: Error uploading site: Error interacting with SCM: No such 
provider: 'git'. - [Help 1]
{noformat}

Using Maven 3.0.4, maven-site-plugin 3.1.

 Deploying your Maven site to GitHub's gh-pages
 --

 Key: WAGON-374
 URL: https://jira.codehaus.org/browse/WAGON-374
 Project: Maven Wagon
  Issue Type: Bug
  Components: wagon-scm
Affects Versions: 2.2
Reporter: Samuel Santos

 The example at 
 http://maven.apache.org/wagon/wagon-providers/wagon-scm/usage.html for 
 deploying a Maven site to GitHub's pages does not work.

--
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-309) detectLink fails if dependency's POM is not interpolated


 [ 
https://jira.codehaus.org/browse/MJAVADOC-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Herve Boutemy closed MJAVADOC-309.
--

Resolution: Not A Bug
  Assignee: Herve Boutemy

I just checked on commons-io:commons-io:1.0 with Maven 3.0.4 and 2.2.1

help:effective-pom isn't able to interpolate this 
${pom.artifactId.substring(8)} expression

then of course the javadoc plugin can't do anything more

AFAIK, commons stopped these unsupported/not working expressions in their urls

 detectLink fails if dependency's POM is not interpolated
 

 Key: MJAVADOC-309
 URL: https://jira.codehaus.org/browse/MJAVADOC-309
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.7
Reporter: Michael Osipov
Assignee: Herve Boutemy

 Recently while generating my site I saw this in my output:
 {noformat}
 [ERROR] Malformed link: 
 http://commons.apache.org/${pom.artifactId.substring(8)}/apidocs/package-list.
  Ignored it.
 {noformat}
 I checked the deps pom: commons config 1.6
 {noformat}
 urlhttp://commons.apache.org/${pom.artifactId.substring(8)}//url
 {noformat}
 Running help:effetive-pom on this project interpolates the URL correctly.
 So JavaDocs genereation should use effective POMs before extracting 
 information.

--
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] (WAGON-374) Deploying your Maven site to GitHub's gh-pages


[ 
https://jira.codehaus.org/browse/WAGON-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308607#comment-308607
 ] 

Rob Elliot commented on WAGON-374:
--

OK, trial and error leads me to conclude that the extensions mentioned on the 
usage page are now not needed - instead I need to add the following 
dependencies to the site plugin:

{code:xml} 
  build
plugins
  plugin
artifactIdmaven-site-plugin/artifactId
version3.1/version
dependencies
  dependency
groupIdorg.apache.maven.wagon/groupId
artifactIdwagon-scm/artifactId
version2.2/version
  /dependency
  dependency
groupIdorg.apache.maven.scm/groupId
artifactIdmaven-scm-manager-plexus/artifactId
version1.8/version
  /dependency
  dependency
groupIdorg.apache.maven.scm/groupId
artifactIdmaven-scm-provider-gitexe/artifactId
version1.8/version
  /dependency
  dependency
groupIdorg.apache.maven.scm/groupId
artifactIdmaven-scm-api/artifactId
version1.8/version
  /dependency
/dependencies
  /plugin
/plugins
  /build
{code} 

At that point it fails because it tries to run the following command:
{noformat}
git clone ssh://g...@github.com/Mahoney/sandbox.git/
{noformat}
Note the trailing slash - it shouldn't be there. Remove it and the clone works 
fine. My distribution management section looks as follows:
{code:xml}
  distributionManagement
site
  idgh-pages/id
  urlscm:git:ssh://g...@github.com/Mahoney/sandbox.git/url
/site
  /distributionManagement
{code}

 Deploying your Maven site to GitHub's gh-pages
 --

 Key: WAGON-374
 URL: https://jira.codehaus.org/browse/WAGON-374
 Project: Maven Wagon
  Issue Type: Bug
  Components: wagon-scm
Affects Versions: 2.2
Reporter: Samuel Santos

 The example at 
 http://maven.apache.org/wagon/wagon-providers/wagon-scm/usage.html for 
 deploying a Maven site to GitHub's pages does not work.

--
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] (MSITE-654) Appending a Slash to the Repository URL Makes Deploying to Github impossible

Rob Elliot created MSITE-654:


 Summary: Appending a Slash to the Repository URL Makes Deploying 
to Github impossible
 Key: MSITE-654
 URL: https://jira.codehaus.org/browse/MSITE-654
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
  Components: Maven 3, site:deploy
Affects Versions: 3.1
 Environment: Maven 3.0.4
Reporter: Rob Elliot


I am attempting to deploy my site to github as described here:
http://maven.apache.org/wagon/wagon-providers/wagon-scm/usage.html
using the following config:
{code:xml}
  distributionManagement
site
  idgh-pages/id
  urlscm:git:ssh://g...@github.com/Mahoney/sandbox.git/url
/site
  /distributionManagement

  build
plugins
  plugin
artifactIdmaven-site-plugin/artifactId
version3.1/version
dependencies
  dependency
groupIdorg.apache.maven.wagon/groupId
artifactIdwagon-scm/artifactId
version2.2/version
  /dependency
  dependency
groupIdorg.apache.maven.scm/groupId
artifactIdmaven-scm-manager-plexus/artifactId
version1.8/version
  /dependency
  dependency
groupIdorg.apache.maven.scm/groupId
artifactIdmaven-scm-provider-gitexe/artifactId
version1.8/version
  /dependency
  dependency
groupIdorg.apache.maven.scm/groupId
artifactIdmaven-scm-api/artifactId
version1.8/version
  /dependency
/dependencies
  /plugin
/plugins
  /build
{code}

It fails because it tries to run the following command:
{noformat}
git clone ssh://g...@github.com/Mahoney/sandbox.git/
{noformat}
Note the trailing slash - it shouldn't be there. Remove it and the clone works 
fine.

I have tracked this down to the following:

{code:title=AbstractDeployMojo.java}
public void execute()
throws MojoExecutionException
{
if ( skipDeploy )
{
getLog().info( maven.site.deploy.skip = true: Skipping site 
deployment );
return;
}

deployTo( new 
org.apache.maven.plugins.site.wagon.repository.Repository( 
getDeployRepositoryID(), appendSlash(
getDeployRepositoryURL() ) ) );
}

/**
 * Make sure the given url ends with a slash.
 *
 * @param url a String.
 * @return if url already ends with '/' it is returned unchanged,
 * otherwise a '/' character is appended.
 */
protected static String appendSlash( final String url )
{
if ( url.endsWith( / ) )
{
return url;
}
else
{
return url + /;
}
}
{code}

The assumption that the URI to which a site is to be deployed *must* end in a 
slash renders this interaction impossible. It should surely be a matter for 
individual wagon providers to decide what processing needs to be done to the 
provided URI, rather than having the site plugin make a blanket decision with 
no knowledge of the URI formats expected.

--
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] (WAGON-374) Deploying your Maven site to GitHub's gh-pages


[ 
https://jira.codehaus.org/browse/WAGON-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308608#comment-308608
 ] 

Rob Elliot commented on WAGON-374:
--

I have diagnosed the final problem and raised 
http://jira.codehaus.org/browse/MSITE-654 on the maven site to highlight it.

 Deploying your Maven site to GitHub's gh-pages
 --

 Key: WAGON-374
 URL: https://jira.codehaus.org/browse/WAGON-374
 Project: Maven Wagon
  Issue Type: Bug
  Components: wagon-scm
Affects Versions: 2.2
Reporter: Samuel Santos

 The example at 
 http://maven.apache.org/wagon/wagon-providers/wagon-scm/usage.html for 
 deploying a Maven site to GitHub's pages does not work.

--
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] (MSITE-654) Appending a Slash to the Repository URL Makes Deploying to Github impossible


[ 
https://jira.codehaus.org/browse/MSITE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308609#comment-308609
 ] 

Rob Elliot commented on MSITE-654:
--

(Please note - my config does not match that requested by the documentation at 
http://maven.apache.org/wagon/wagon-providers/wagon-scm/usage.html because that 
documentation does not work, as documented here: 
http://jira.codehaus.org/browse/WAGON-374 .)

 Appending a Slash to the Repository URL Makes Deploying to Github impossible
 

 Key: MSITE-654
 URL: https://jira.codehaus.org/browse/MSITE-654
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
  Components: Maven 3, site:deploy
Affects Versions: 3.1
 Environment: Maven 3.0.4
Reporter: Rob Elliot

 I am attempting to deploy my site to github as described here:
 http://maven.apache.org/wagon/wagon-providers/wagon-scm/usage.html
 using the following config:
 {code:xml}
   distributionManagement
 site
   idgh-pages/id
   urlscm:git:ssh://g...@github.com/Mahoney/sandbox.git/url
 /site
   /distributionManagement
   build
 plugins
   plugin
 artifactIdmaven-site-plugin/artifactId
 version3.1/version
 dependencies
   dependency
 groupIdorg.apache.maven.wagon/groupId
 artifactIdwagon-scm/artifactId
 version2.2/version
   /dependency
   dependency
 groupIdorg.apache.maven.scm/groupId
 artifactIdmaven-scm-manager-plexus/artifactId
 version1.8/version
   /dependency
   dependency
 groupIdorg.apache.maven.scm/groupId
 artifactIdmaven-scm-provider-gitexe/artifactId
 version1.8/version
   /dependency
   dependency
 groupIdorg.apache.maven.scm/groupId
 artifactIdmaven-scm-api/artifactId
 version1.8/version
   /dependency
 /dependencies
   /plugin
 /plugins
   /build
 {code}
 It fails because it tries to run the following command:
 {noformat}
 git clone ssh://g...@github.com/Mahoney/sandbox.git/
 {noformat}
 Note the trailing slash - it shouldn't be there. Remove it and the clone 
 works fine.
 I have tracked this down to the following:
 {code:title=AbstractDeployMojo.java}
 public void execute()
 throws MojoExecutionException
 {
 if ( skipDeploy )
 {
 getLog().info( maven.site.deploy.skip = true: Skipping site 
 deployment );
 return;
 }
 deployTo( new 
 org.apache.maven.plugins.site.wagon.repository.Repository( 
 getDeployRepositoryID(), appendSlash(
 getDeployRepositoryURL() ) ) );
 }
 /**
  * Make sure the given url ends with a slash.
  *
  * @param url a String.
  * @return if url already ends with '/' it is returned unchanged,
  * otherwise a '/' character is appended.
  */
 protected static String appendSlash( final String url )
 {
 if ( url.endsWith( / ) )
 {
 return url;
 }
 else
 {
 return url + /;
 }
 }
 {code}
 The assumption that the URI to which a site is to be deployed *must* end in a 
 slash renders this interaction impossible. It should surely be a matter for 
 individual wagon providers to decide what processing needs to be done to the 
 provided URI, rather than having the site plugin make a blanket decision with 
 no knowledge of the URI formats expected.

--
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-340) Javadoc generation with includeDependencySources=true crashes when any of those dependencies have scope=provided dependencies


 [ 
https://jira.codehaus.org/browse/MJAVADOC-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benson Margulies reassigned MJAVADOC-340:
-

Assignee: Benson Margulies

 Javadoc generation with includeDependencySources=true crashes when any of 
 those dependencies have scope=provided dependencies
 -

 Key: MJAVADOC-340
 URL: https://jira.codehaus.org/browse/MJAVADOC-340
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Reporter: Geoffrey De Smet
Assignee: Benson Margulies
Priority: Critical

 Using this configuration in jbpm-distribution:
 {code}
 configuration
   includeDependencySourcestrue/includeDependencySources
   dependencySourceIncludes
 dependencySourceIncludeorg.jbpm:*/dependencySourceInclude
   /dependencySourceIncludes
 /configuration
 {code}
 I got this:
 {code}
 [INFO] 
 
 [INFO] BUILD FAILURE
 [INFO] 
 
 [INFO] Total time: 13.620s
 [INFO] Finished at: Tue Jan 17 15:05:07 CET 2012
 [INFO] Final Memory: 17M/441M
 [INFO] 
 
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-javadoc-plugin:2.8:javadoc (javadoc-javadoc) 
 on project jbpm-distribution: An error has occurred in JavaDocs report 
 generation:
 [ERROR] Exit code: 1 - 
 /home/gdesmet/projects/jboss/droolsjbpm/jbpm/jbpm-distribution/target/distro-javadoc-sources/jbpm-flow-5.3.0-SNAPSHOT-sources/org/jbpm/osgi/flow/core/Activator.java:26:
  package org.osgi.framework does not exist
 [ERROR] import org.osgi.framework.BundleActivator;
 {code}
 Workaround: Explicitly add the provided scope dependencies one by one
 {code}
 dependency
   groupIdorg.apache.felix/groupId
   artifactIdorg.osgi.core/artifactId
   scopeprovided/scope
 /dependency
 dependency
   groupIdorg.apache.felix/groupId
   artifactIdorg.osgi.compendium/artifactId
   scopeprovided/scope
 /dependency
 {code}
 (and if you're doing this in an assembly, make sure your zips don't get to 
 big or to small)

--
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-340) Javadoc generation with includeDependencySources=true crashes when any of those dependencies have scope=provided dependencies


 [ 
https://jira.codehaus.org/browse/MJAVADOC-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benson Margulies closed MJAVADOC-340.
-

Resolution: Cannot Reproduce

Please reopen if you attach a test case.

 Javadoc generation with includeDependencySources=true crashes when any of 
 those dependencies have scope=provided dependencies
 -

 Key: MJAVADOC-340
 URL: https://jira.codehaus.org/browse/MJAVADOC-340
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Reporter: Geoffrey De Smet
Assignee: Benson Margulies
Priority: Critical

 Using this configuration in jbpm-distribution:
 {code}
 configuration
   includeDependencySourcestrue/includeDependencySources
   dependencySourceIncludes
 dependencySourceIncludeorg.jbpm:*/dependencySourceInclude
   /dependencySourceIncludes
 /configuration
 {code}
 I got this:
 {code}
 [INFO] 
 
 [INFO] BUILD FAILURE
 [INFO] 
 
 [INFO] Total time: 13.620s
 [INFO] Finished at: Tue Jan 17 15:05:07 CET 2012
 [INFO] Final Memory: 17M/441M
 [INFO] 
 
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-javadoc-plugin:2.8:javadoc (javadoc-javadoc) 
 on project jbpm-distribution: An error has occurred in JavaDocs report 
 generation:
 [ERROR] Exit code: 1 - 
 /home/gdesmet/projects/jboss/droolsjbpm/jbpm/jbpm-distribution/target/distro-javadoc-sources/jbpm-flow-5.3.0-SNAPSHOT-sources/org/jbpm/osgi/flow/core/Activator.java:26:
  package org.osgi.framework does not exist
 [ERROR] import org.osgi.framework.BundleActivator;
 {code}
 Workaround: Explicitly add the provided scope dependencies one by one
 {code}
 dependency
   groupIdorg.apache.felix/groupId
   artifactIdorg.osgi.core/artifactId
   scopeprovided/scope
 /dependency
 dependency
   groupIdorg.apache.felix/groupId
   artifactIdorg.osgi.compendium/artifactId
   scopeprovided/scope
 /dependency
 {code}
 (and if you're doing this in an assembly, make sure your zips don't get to 
 big or to small)

--
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-340) Javadoc generation with includeDependencySources=true crashes when any of those dependencies have scope=provided dependencies


[ 
https://jira.codehaus.org/browse/MJAVADOC-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308611#comment-308611
 ] 

Benson Margulies commented on MJAVADOC-340:
---

I cannot reproduce this. I adapted an integration test to follow the recipe, 
and it worked fine. So unless you can attach a complete failing test case, this 
will be closed.

 Javadoc generation with includeDependencySources=true crashes when any of 
 those dependencies have scope=provided dependencies
 -

 Key: MJAVADOC-340
 URL: https://jira.codehaus.org/browse/MJAVADOC-340
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Reporter: Geoffrey De Smet
Assignee: Benson Margulies
Priority: Critical

 Using this configuration in jbpm-distribution:
 {code}
 configuration
   includeDependencySourcestrue/includeDependencySources
   dependencySourceIncludes
 dependencySourceIncludeorg.jbpm:*/dependencySourceInclude
   /dependencySourceIncludes
 /configuration
 {code}
 I got this:
 {code}
 [INFO] 
 
 [INFO] BUILD FAILURE
 [INFO] 
 
 [INFO] Total time: 13.620s
 [INFO] Finished at: Tue Jan 17 15:05:07 CET 2012
 [INFO] Final Memory: 17M/441M
 [INFO] 
 
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-javadoc-plugin:2.8:javadoc (javadoc-javadoc) 
 on project jbpm-distribution: An error has occurred in JavaDocs report 
 generation:
 [ERROR] Exit code: 1 - 
 /home/gdesmet/projects/jboss/droolsjbpm/jbpm/jbpm-distribution/target/distro-javadoc-sources/jbpm-flow-5.3.0-SNAPSHOT-sources/org/jbpm/osgi/flow/core/Activator.java:26:
  package org.osgi.framework does not exist
 [ERROR] import org.osgi.framework.BundleActivator;
 {code}
 Workaround: Explicitly add the provided scope dependencies one by one
 {code}
 dependency
   groupIdorg.apache.felix/groupId
   artifactIdorg.osgi.core/artifactId
   scopeprovided/scope
 /dependency
 dependency
   groupIdorg.apache.felix/groupId
   artifactIdorg.osgi.compendium/artifactId
   scopeprovided/scope
 /dependency
 {code}
 (and if you're doing this in an assembly, make sure your zips don't get to 
 big or to small)

--
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-342) An incomplete fix for the NPE bugs in AbstractJavadocMojo.java


 [ 
https://jira.codehaus.org/browse/MJAVADOC-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benson Margulies updated MJAVADOC-342:
--

Priority: Major  (was: Critical)

 An incomplete fix for the NPE bugs in AbstractJavadocMojo.java
 --

 Key: MJAVADOC-342
 URL: https://jira.codehaus.org/browse/MJAVADOC-342
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Reporter: Guangtai Liang

 The fix revision 554202 was aimed to remove an NPE bug on the  returned value 
 of  getJavadocDirectory() in the method getSourcePaths  of the file 
 /maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java
  , but it is incomplete. 
 Since the returned value  getJavadocDirectory() could be null during the 
 runtime execution, its value should also be null-checked before being 
 dereferenced in other methods. 
 The buggy code locations the same fix needs to be applied at are as bellows: 
 Line 2401 of the method copyJavadocResources;
 Line 1505 of the method getSourcePaths. 

--
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-342) An incomplete fix for the NPE bugs in AbstractJavadocMojo.java


 [ 
https://jira.codehaus.org/browse/MJAVADOC-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benson Margulies reassigned MJAVADOC-342:
-

Assignee: Benson Margulies

 An incomplete fix for the NPE bugs in AbstractJavadocMojo.java
 --

 Key: MJAVADOC-342
 URL: https://jira.codehaus.org/browse/MJAVADOC-342
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Reporter: Guangtai Liang
Assignee: Benson Margulies

 The fix revision 554202 was aimed to remove an NPE bug on the  returned value 
 of  getJavadocDirectory() in the method getSourcePaths  of the file 
 /maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java
  , but it is incomplete. 
 Since the returned value  getJavadocDirectory() could be null during the 
 runtime execution, its value should also be null-checked before being 
 dereferenced in other methods. 
 The buggy code locations the same fix needs to be applied at are as bellows: 
 Line 2401 of the method copyJavadocResources;
 Line 1505 of the method getSourcePaths. 

--
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-342) An incomplete fix for the NPE bugs in AbstractJavadocMojo.java


 [ 
https://jira.codehaus.org/browse/MJAVADOC-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benson Margulies closed MJAVADOC-342.
-

   Resolution: Fixed
Fix Version/s: 2.9


r1385200 | bimargulies | 2012-09-15 19:22:45 -0400 (Sat, 15 Sep 2012) | 4 lines

MJAVADOC-342: An incomplete fix for the NPE bugs in AbstractJavadocMojo.java
o protect all the calls to getJavadocDirectory
o update to threadsafe version of maven-shade-plugin.

 An incomplete fix for the NPE bugs in AbstractJavadocMojo.java
 --

 Key: MJAVADOC-342
 URL: https://jira.codehaus.org/browse/MJAVADOC-342
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Reporter: Guangtai Liang
Assignee: Benson Margulies
 Fix For: 2.9


 The fix revision 554202 was aimed to remove an NPE bug on the  returned value 
 of  getJavadocDirectory() in the method getSourcePaths  of the file 
 /maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java
  , but it is incomplete. 
 Since the returned value  getJavadocDirectory() could be null during the 
 runtime execution, its value should also be null-checked before being 
 dereferenced in other methods. 
 The buggy code locations the same fix needs to be applied at are as bellows: 
 Line 2401 of the method copyJavadocResources;
 Line 1505 of the method getSourcePaths. 

--
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-314) failOnWarnings option is required


[ 
https://jira.codehaus.org/browse/MJAVADOC-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308614#comment-308614
 ] 

Benson Margulies commented on MJAVADOC-314:
---

Since the javadoc command has no corresponding option, and this plugin does not 
intercept and reprocess any of the commands output, 
this is at least a lot of work and perhaps not practical. If you're not willing 
to make a patch, this isn't very likely to happen.


 failOnWarnings option is required
 -

 Key: MJAVADOC-314
 URL: https://jira.codehaus.org/browse/MJAVADOC-314
 Project: Maven 2.x Javadoc Plugin
  Issue Type: New Feature
Reporter: Yegor Bugayenko

 Would be nice to have failOnWarnings option.

--
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-319) Using groupId and artifactId in dependencySourceInclude results in source not being resolved


[ 
https://jira.codehaus.org/browse/MJAVADOC-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308615#comment-308615
 ] 

Benson Margulies commented on MJAVADOC-319:
---

Without a test case this is unlikely to receive attention.

 Using groupId and artifactId in dependencySourceInclude results in source not 
 being resolved
 

 Key: MJAVADOC-319
 URL: https://jira.codehaus.org/browse/MJAVADOC-319
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.8
 Environment: Maven 3.0.3
Reporter: James Phillpotts

 When using the syntax groupId:* dependencies are resolved fine.
 However, when using syntax groupId:artifactIdFragment* or groupId:artifactId, 
 source dependencies are not resolved.
 I have done some debugging, and find that upon entering 
 ResourceResolver.resolveAndUnpack, the list of Artifacts to be resolved is 
 correct, but on resolution 
 (http://svn.apache.org/viewvc/maven/plugins/tags/maven-javadoc-plugin-2.8/src/main/java/org/apache/maven/plugin/javadoc/resolver/ResourceResolver.java?view=markup
  line 336), the list of artifacts returned in the resolution result is null.
 I don't know whether this is a bug with the javadoc plugin's use of the 
 resolver, or of the resolver which I assume is part of maven core, but I'm 
 raising here as I haven't seen the same problem with filtering anywhere else.

--
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] (WAGON-374) Deploying your Maven site to GitHub's gh-pages


[ 
https://jira.codehaus.org/browse/WAGON-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308616#comment-308616
 ] 

Rob Elliot commented on WAGON-374:
--

I worked around MSITE-654 by hacking GitScmProviderRepository to remove the 
trailing slash, only to find that on a multi-module build each module simply 
over-writes the previous one on the branch. I think I've just about had it with 
trying to persuade the maven site plugin to behave appropriately.

(In the process I found ANOTHER error in the documentation at 
http://maven.apache.org/wagon/wagon-providers/wagon-scm/usage.html - it should 
be:
{code:xml}
server
  idmy.git.server/id
  usernamegit/username
  configuration
scmVersionTypebranch/scmVersionType
scmVersiongh-pages/scmVersion
  /configuration
/server
{code}
not
{code:xml}
server
  idmy.git.server/id
  usernamegit/username
  scmVersionTypebranch/scmVersionType
  scmVersiongh-pages/scmVersion
/server
{code}

 Deploying your Maven site to GitHub's gh-pages
 --

 Key: WAGON-374
 URL: https://jira.codehaus.org/browse/WAGON-374
 Project: Maven Wagon
  Issue Type: Bug
  Components: wagon-scm
Affects Versions: 2.2
Reporter: Samuel Santos

 The example at 
 http://maven.apache.org/wagon/wagon-providers/wagon-scm/usage.html for 
 deploying a Maven site to GitHub's pages does not work.

--
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] (WAGON-374) Deploying your Maven site to GitHub's gh-pages