[jira] (MSITE-443) add a reportingManagement section
[
https://jira.codehaus.org/browse/MSITE-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MSITE-443.
---
Resolution: Fixed
Fix Version/s: 3.0
this is fixed in Maven 3 + maven-site-plugin-3
see
[explanations|http://maven.apache.org/plugins/maven-site-plugin/maven-3.html#Version_Resolution]
> add a reportingManagement section
> -
>
> Key: MSITE-443
> URL: https://jira.codehaus.org/browse/MSITE-443
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Environment: maven-site-plugin 2.0-beta-3-SNAPSHOT
>Reporter: Indrajit Raychaudhuri
> Fix For: 3.0
>
>
> Consider the following POM:
> {code:xml}
>
>
>
>
>
> org.apache.maven.plugins
> maven-javadoc-plugin
>
> false
>
>
>
>
>
>
>
>
>
> org.apache.maven.plugins
> maven-javadoc-plugin
>
>
>
>
> {code}
> {{mvn site:site}} doesn't honor the javadoc configuration specified in the
> {{}} section.
> However, {{mvn javadoc:javadoc}} honors them.
> This is true not just for javadoc but other plugins like checkstyle as well.
> I guess, the {{}} section doesn't use the {{}}
> section at all.
--
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-653) Wrong report set inherited from super POM
[
https://jira.codehaus.org/browse/MSITE-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MSITE-653.
---
Resolution: Duplicate
Assignee: Herve Boutemy
duplicate of MSITE-484
explanations have been improved in MSITE-647: just don't use the new
reportPlugins format for the moment, since it is less flexible than usual
reporting section (yes, in this case, "new" != "better")
> Wrong report set inherited from super POM
> -
>
> Key: MSITE-653
> URL: https://jira.codehaus.org/browse/MSITE-653
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
>Affects Versions: 3.1
> Environment: JDK 7u7, Windows Vista
>Reporter: Christian Schlichtherle
>Assignee: Herve Boutemy
>
> I have a parent POM with the coordinates:
> {code}net.java.truecommons:truecommons-parent:13{code}
> In it's project/build/pluginManagement/plugins element, I effectively have:
> {code}
>
> maven-site-plugin
> 3.1
>
>
>
>
> maven-project-info-reports-plugin
>
>
> maven-javadoc-plugin
>
> aggregate
> javadoc
>
>
>
> maven-jxr-plugin
>
> aggregate
> jxr
>
>
>
> org.codehaus.mojo
> findbugs-maven-plugin
>
>
> org.codehaus.mojo
> jdepend-maven-plugin
>
>
>
>
> {code}
> Now I inherit from this parent POM. In the
> project/build/pluginManagement/plugins element of my child POM I have:
> {code}
>
> maven-site-plugin
>
>
>
>
> maven-project-info-reports-plugin
>
>
> org.codehaus.mojo
> findbugs-maven-plugin
>
>
> org.codehaus.mojo
> jdepend-maven-plugin
>
>
>
>
> {code}
> However, when running help:effective-pom I get:
> {code}
>
> maven-site-plugin
> 3.1
>
>
>
> maven-project-info-reports-plugin
>
>
> org.codehaus.mojo
> findbugs-maven-plugin
>
> aggregate
> javadoc
>
>
>
> org.codehaus.mojo
> jdepend-maven-plugin
>
> aggregate
> jxr
>
>
>
>
>
> {code}
> Note the reports elements! Apparently they have been inherited from the
> javadoc and jxr report plugins of the parent POM. However, they do not belong
> into the findbugs and jdepend report plugins of the child POM.
--
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-453) Add new lifecylce mapping "maven-skin"
[ https://jira.codehaus.org/browse/MSITE-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308638#comment-308638 ] Herve Boutemy commented on MSITE-453: - shouldn't we consider doing [like archetype|http://maven.apache.org/archetype/maven-archetype-plugin/] which has a plugin with jar/integration-test goals and [dedicated packaging|http://maven.apache.org/archetype/archetype-packaging/] (outside core, since we don't want any reporting feature in Maven 3 core)? > Add new lifecylce mapping "maven-skin" > -- > > Key: MSITE-453 > URL: https://jira.codehaus.org/browse/MSITE-453 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: New Feature >Reporter: Benjamin Bentmann >Priority: Minor > Fix For: backlog > > Attachments: new-lifecycle-mappings.patch > > > Currently, creating a custom skin for Maven is done by a project with > packaging "jar". The attached patch intents to introduce an individual > lifecycle mapping named "maven-skin" for this purpose. > Why that? I consider the re-usage of the "jar" packaging an abuse for the > case of building a Maven skin. On the one hand, the "jar" packaging does too > much. Skins usually do not get compiled or unit-tested, do they? Since any > unused plugin invocation is an unnecessary risk of a build failure (sorry to > say), I would appreciate a lifecycle mapping that is not overdressed. On the > other hand, I could image that skins required some additional processing some > day like a check whether all required images are present in the skin or > whether the CSS references unknown IDs/names. Having a distinct lifecylcle > mapping in the Maven Core would allow for a central definition of the build > steps instead of requiring all users to extend the "jar" packaging. > Especially for the first reason, i.e. having a packaging that does not more > than required, the patch also defines a "resources" packaging. Such a > packaging is intended for JARs that just contain resources one wants to share > with other projects like rulesets for PMD, Checkstyle, etc. The lifecylcle > mappings "resources" and "maven-skin" are identiical (now) but I consider it > a bad practice to merge different use-cases just because they happen to be > equal by coindicence. -- 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-453) Add new lifecylce mapping "maven-skin"
[ https://jira.codehaus.org/browse/MSITE-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MSITE-453: Fix Version/s: backlog > Add new lifecylce mapping "maven-skin" > -- > > Key: MSITE-453 > URL: https://jira.codehaus.org/browse/MSITE-453 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: New Feature >Reporter: Benjamin Bentmann >Priority: Minor > Fix For: backlog > > Attachments: new-lifecycle-mappings.patch > > > Currently, creating a custom skin for Maven is done by a project with > packaging "jar". The attached patch intents to introduce an individual > lifecycle mapping named "maven-skin" for this purpose. > Why that? I consider the re-usage of the "jar" packaging an abuse for the > case of building a Maven skin. On the one hand, the "jar" packaging does too > much. Skins usually do not get compiled or unit-tested, do they? Since any > unused plugin invocation is an unnecessary risk of a build failure (sorry to > say), I would appreciate a lifecycle mapping that is not overdressed. On the > other hand, I could image that skins required some additional processing some > day like a check whether all required images are present in the skin or > whether the CSS references unknown IDs/names. Having a distinct lifecylcle > mapping in the Maven Core would allow for a central definition of the build > steps instead of requiring all users to extend the "jar" packaging. > Especially for the first reason, i.e. having a packaging that does not more > than required, the patch also defines a "resources" packaging. Such a > packaging is intended for JARs that just contain resources one wants to share > with other projects like rulesets for PMD, Checkstyle, etc. The lifecylcle > mappings "resources" and "maven-skin" are identiical (now) but I consider it > a bad practice to merge different use-cases just because they happen to be > equal by coindicence. -- 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-121) Generated html files contain inconsistent new lines
[ https://jira.codehaus.org/browse/MSITE-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MSITE-121: Fix Version/s: backlog > Generated html files contain inconsistent new lines > --- > > Key: MSITE-121 > URL: https://jira.codehaus.org/browse/MSITE-121 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 >Reporter: Carlos Sanchez > Fix For: backlog > > -- 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-234) Maven skin / version as plugin parameters
[
https://jira.codehaus.org/browse/MSITE-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MSITE-234.
---
Resolution: Fixed
Assignee: Herve Boutemy
just use ${project.version} in your site.xml
FYI, this is actually used by skins to generate their site with their actual
build result: see [maven-fluido-skin's
site.xml|http://svn.apache.org/viewvc/maven/skins/tags/maven-fluido-skin-1.3.0/src/site/site.xml?view=markup]
for example
> Maven skin / version as plugin parameters
> -
>
> Key: MSITE-234
> URL: https://jira.codehaus.org/browse/MSITE-234
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Improvement
>Affects Versions: 2.0-beta-5
>Reporter: Stefano Bagnara
>Assignee: Herve Boutemy
>
> I have an m2 reactor project where one of the modules is the skin used
> by one of the other modules (and every of its children).
> {noformat}
> root
> |- maven-skin
> '- module1 (using maven-skin)
> {noformat}
> The problem is that module1 declare the skin in its site.xml file and
> this way the version is not updated when I use the release:prepare to
> update my poms.
> So I checked the site plugin searching for a way to declare the skin in
> the plugin configuration instead of the site.xml descriptor but there is
> no such option.
> I think that a good solution would be to use something like the remote
> resource plugin (used for LICENSE/NOTICE) also for the skin declaration.
--
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-650) Problem with multiple executions of surefire within site plugin 3.0
[ https://jira.codehaus.org/browse/MSITE-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308641#comment-308641 ] Herve Boutemy commented on MSITE-650: - this one seems to be related to MJAVADOC-171 > Problem with multiple executions of surefire within site plugin 3.0 > --- > > Key: MSITE-650 > URL: https://jira.codehaus.org/browse/MSITE-650 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Kristian Rosenvold > > There is a test project attached to SUREFIRE-905 that has a total of 4 > executions of surefire, with different configuration for each. > When running "mvn clean install" inside this project, surefire gets executed > 4 times as expected. When running "mvn site" only the first execution gets > run, the last three get stopped by the configuration-checksum in surefire, > indicating they get executed with the *same* configuration as the default > execution. (Surefire creates a SHA1 hash of all the mojo parameters to avoid > re-running the same configuration, which is why I conclude the three > executions get the same configuration as the default config) -- 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] (MPLUGIN-223) HelpMojo is not extracted when using java-annotations extractor
[
https://jira.codehaus.org/browse/MPLUGIN-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308642#comment-308642
]
Anthony Whitford commented on MPLUGIN-223:
--
I too would like the option to go with the Java5 Annotations. Presently, I see
3 issues:
# The @Property annotations are commented out.
# The @Mojo annotation is missing.
# The legacy Javadoc style annotations should be removed (Java 5 or legacy, not
both).
> HelpMojo is not extracted when using java-annotations extractor
> ---
>
> Key: MPLUGIN-223
> URL: https://jira.codehaus.org/browse/MPLUGIN-223
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Martin Ellis
>
> The generated HelpMojo uses javadoc tags rather than Java annotations.
> If the plugin is only configured to use only the java-annotations extractor,
> then it does not recognise the HelpMojo as a valid mojo:
> {noformat}
>
> java-annotations
>
> {noformat}
> In this case, the plugin will silently fail to include the 'help' goal in the
> plugin descriptor.
--
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-5346) update maven-plugin-plugin:descriptor default binding from generate-resources phase to process-classes
Herve Boutemy created MNG-5346:
--
Summary: update maven-plugin-plugin:descriptor default binding
from generate-resources phase to process-classes
Key: MNG-5346
URL: https://jira.codehaus.org/browse/MNG-5346
Project: Maven 2 & 3
Issue Type: Wish
Reporter: Herve Boutemy
with Java annotations support added in Maven Plugin Tools 3.0, descriptor
cannot be generated before compilation
actually, to use annotations, users need to add extra configuration to avoid
failure and to bind the goal to proper phase:
{code:xml}
true
mojo-descriptor
descriptor
{code}
changing the default lifecycle binding will enable removal of this extra
configuration
notice that removing the configuration from pom will require to check newer
Maven version is used to build the 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] (MSKINS-69) REGRESSION: reporting section titles are not enough visible (was better in previous version)
Herve Boutemy created MSKINS-69: --- Summary: REGRESSION: reporting section titles are not enough visible (was better in previous version) Key: MSKINS-69 URL: https://jira.codehaus.org/browse/MSKINS-69 Project: Maven Skins Issue Type: Bug Components: Stylus Skin Affects Versions: fluido-1.3.0 Reporter: Herve Boutemy Attachments: fluido-1.2.png, fluido-1.3.0.png see attachements to compare Fluido 1.2 and Fluido 1.3.0 -- 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] (MSKINS-69) REGRESSION: reporting section titles are not enough visible (was better in previous version)
[ https://jira.codehaus.org/browse/MSKINS-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MSKINS-69: Priority: Critical (was: Major) Fix Version/s: fluido-1.3.1 > REGRESSION: reporting section titles are not enough visible (was better in > previous version) > > > Key: MSKINS-69 > URL: https://jira.codehaus.org/browse/MSKINS-69 > Project: Maven Skins > Issue Type: Bug > Components: Stylus Skin >Affects Versions: fluido-1.3.0 >Reporter: Herve Boutemy >Priority: Critical > Fix For: fluido-1.3.1 > > Attachments: fluido-1.2.png, fluido-1.3.0.png > > > see attachements to compare Fluido 1.2 and Fluido 1.3.0 -- 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-tabpanel&focusedCommentId=308643#comment-308643
]
Geoffrey De Smet commented on MJAVADOC-340:
---
Which version did you test? Please set it as fix version.
> 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}
>
> true
>
> org.jbpm:*
>
>
> {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}
>
> org.apache.felix
> org.osgi.core
> provided
>
>
> org.apache.felix
> org.osgi.compendium
> provided
>
> {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] (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-tabpanel&focusedCommentId=308644#comment-308644
]
Jackie Noi commented on WAGON-374:
--
This is what I just a moment ago used to deploy my maven project to the github
pages with maven 3.0.4:
{code:xml}
org.apache.maven.wagon
wagon-scm
2.2
org.apache.maven.scm
maven-scm-manager-plexus
1.8
org.apache.maven.scm
maven-scm-provider-gitexe
1.8
gh.pages
scm:git:ssh://g...@github.com/lhw/duckduckgo.git
{code}
With the following settings:
{code:xml}
gh.pages
git
branch
gh-pages
{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
[
https://jira.codehaus.org/browse/WAGON-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308644#comment-308644
]
Jackie Noi edited comment on WAGON-374 at 9/16/12 12:42 PM:
This is what I just a moment ago used to deploy my maven project to the github
pages with maven 3.0.4. No _workarounds_ needed as far as I am concerned:
{code:xml}
org.apache.maven.wagon
wagon-scm
2.2
org.apache.maven.scm
maven-scm-manager-plexus
1.8
org.apache.maven.scm
maven-scm-provider-gitexe
1.8
gh.pages
scm:git:ssh://g...@github.com/lhw/duckduckgo.git
{code}
With the following settings:
{code:xml}
gh.pages
git
branch
gh-pages
{code}
was (Author: jackienoi):
This is what I just a moment ago used to deploy my maven project to the
github pages with maven 3.0.4:
{code:xml}
org.apache.maven.wagon
wagon-scm
2.2
org.apache.maven.scm
maven-scm-manager-plexus
1.8
org.apache.maven.scm
maven-scm-provider-gitexe
1.8
gh.pages
scm:git:ssh://g...@github.com/lhw/duckduckgo.git
{code}
With the following settings:
{code:xml}
gh.pages
git
branch
gh-pages
{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] (MDOCCK-26) When using Java 5 Annotations, docck incorrectly warns of no mojo descriptors found
Anthony Whitford created MDOCCK-26:
--
Summary: When using Java 5 Annotations, docck incorrectly warns of
no mojo descriptors found
Key: MDOCCK-26
URL: https://jira.codehaus.org/browse/MDOCCK-26
Project: Maven 2.x Documentation Checker Plugin
Issue Type: Bug
Affects Versions: 1.0
Reporter: Anthony Whitford
I have a Maven Plugin that uses [Java 5
annotations|http://maven.apache.org/plugin-tools/maven-plugin-tools-annotations/].
The [descriptor is being
generated|http://maven.apache.org/ref/3.0.4/maven-plugin-api/plugin.html], yet
the docck plugin erroneously emits a warning:
{noformat}
[WARNING] ***
[WARNING] Deprecation Alert:
[WARNING] No mojo descriptors were found in this project which has a packaging
type of maven-plugin.
[WARNING] In future versions of the plugin tools, this will fail the build.
[WARNING] If this project is an archetype, change the packaging type from
maven-plugin to maven-archetype.
[WARNING]
{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] (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 updated MJAVADOC-340:
--
Fix Version/s: 2.9
> 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
> Fix For: 2.9
>
>
> Using this configuration in jbpm-distribution:
> {code}
>
> true
>
> org.jbpm:*
>
>
> {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}
>
> org.apache.felix
> org.osgi.core
> provided
>
>
> org.apache.felix
> org.osgi.compendium
> provided
>
> {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-tabpanel&focusedCommentId=308646#comment-308646
]
Benson Margulies commented on MJAVADOC-340:
---
I tested the trunk, which will be 2.9, and I set the fix version to 2.9 as a
result just now.
> 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
> Fix For: 2.9
>
>
> Using this configuration in jbpm-distribution:
> {code}
>
> true
>
> org.jbpm:*
>
>
> {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}
>
> org.apache.felix
> org.osgi.core
> provided
>
>
> org.apache.felix
> org.osgi.compendium
> provided
>
> {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] (MNG-3283) Plugins that require dependency resolution in early phases cause dependency resolution issue
[ https://jira.codehaus.org/browse/MNG-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MNG-3283: -- Assignee: (was: Brian Fox) > Plugins that require dependency resolution in early phases cause dependency > resolution issue > > > Key: MNG-3283 > URL: https://jira.codehaus.org/browse/MNG-3283 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies, Plugins and Lifecycle, Reactor and > workspace >Affects Versions: 2.0.7 >Reporter: Alfie Kirkpatrick > Fix For: Issues to be reviewed for 3.x > > Attachments: maven-dependency-bug.zip > > > What we're seeing is that some multi-project configurations succeed on > 'mvn package' but fail on 'mvn generate-sources'. They are failing when > one project in the reactor references another project in the reactor > which is not installed in the local repo. It seems that the referenced > project has not quite "made it" into the reactor this early in the phase > lifecycle. But it does work correctly if you target a later phase at the > outset which is really confusing. > The problem only occurs when a plugin binds itself to the > generate-sources phase and has @requiresDependencyResolution, presumably > because this is what triggers resolution of the referenced dependency > too early in the lifecycle, and hence the error. > We are seeing this problem when trying to run 'mvn eclipse:eclipse' > because this only executes the generate-sources phase by default and we > have other mojos which genuinely do generate source, such as java2wsdl. > A workaround we're using is to run 'mvn process-classes eclipse:eclipse'. > Attached is a really simple project that exhibits this problem. -- 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] (MPLUGIN-226) Plugin documentation suggests an incorrect goal for generating descriptor
Anthony Whitford created MPLUGIN-226:
Summary: Plugin documentation suggests an incorrect goal for
generating descriptor
Key: MPLUGIN-226
URL: https://jira.codehaus.org/browse/MPLUGIN-226
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Affects Versions: 3.1
Reporter: Anthony Whitford
Priority: Minor
On this
[page|http://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/generate-descriptor.html],
the goal says {{plugin}} instead of {{descriptor}}.
--
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-tabpanel&focusedCommentId=308650#comment-308650 ] Martin Pecka commented on MJAVADOC-333: --- Where can I access the snapshot? 2.8-SNAPSHOT and 2.9-SNAPSHOT don't exist. 2.8.1-SNAPSHOT seems to work, but no files are downloaded during the build - I thought this is what the snapshot versions should do... So I tested it with 2.8.1 and the same error (the bug was reported for 2.8). > 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] (MASSEMBLY-343) add symbolic links managment
[
https://jira.codehaus.org/browse/MASSEMBLY-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308651#comment-308651
]
Ahmed El-Madhoun commented on MASSEMBLY-343:
Hi Zuhayr,
I was able to get the proper revisions of the maven plugins and plexus
components (as listed above), however, I am having trouble building the
assembly plugin. All code patches fine, except that I run into this issue:
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/home/aelmadho/ASSEMBLY/maven/plugins/maven-assembly-plugin-2.2.1/target/generated-sources/modello/org/apache/maven/plugin/assembly/model/io/xpp3/AssemblyXpp3Writer.java:[291,119]
error: unclosed string literal
[ERROR]
/home/aelmadho/ASSEMBLY/maven/plugins/maven-assembly-plugin-2.2.1/target/generated-sources/modello/org/apache/maven/plugin/assembly/model/io/xpp3/AssemblyXpp3Writer.java:[292,10]
error: unclosed string lite
The file in context (AssemblyXpp3Writer) looks like this at line 291-292:
if ( ( dependencySet.getOutputFileNameMapping() != null ) &&
!dependencySet.getOutputFileNameMapping().equals( "${artifact.artifactId}
${artifact.version}${dashClassifier?}.${artifact.extension}
" ) )
{
serializer.startTag( NAMESPACE, "outputFileNameMapping" ).text(
dependencySet.getOutputFileNameMapping() ).endTag( NAMESPACE,
"outputFileNameMapping" );
}
There seems to be a "\n" character at the end of the logical comparison that
the parser fails. I am not very familiar with Xpp3, I need to do some more
reading there, but I was hoping to try and generate maven artifacts including
symlinks using the solution you have proposed.
Any idea on how I can proceed?
Thanks a bunch.
> add symbolic links managment
>
>
> Key: MASSEMBLY-343
> URL: https://jira.codehaus.org/browse/MASSEMBLY-343
> Project: Maven 2.x Assembly Plugin
> Issue Type: Wish
>Affects Versions: 2.2-beta-2
> Environment: linux, ubuntu
>Reporter: Godet Gilles
> Attachments: MASSEMBLY-343_maven-assembly-plugin.patch
>
>
> i need to buid archives ( tar for example ) with symbolic links
> the plugin build an archive with a file containing the destination of the
> link, not the link itself
> => the plugin need an option to know if deferencement of links is needed
> this is just like -h option of tar
> -h, --dereference
> don't dump symlinks; dump the files they point to
> actually, if you do an archive of /lib, for example, many file will be in
> double with différent names. extract of archive will not be the exactly the
> same as the source of the archive. => this is a test !
--
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-tabpanel&focusedCommentId=308652#comment-308652
]
Rob Elliot commented on WAGON-374:
--
I have to confess that at the moment I'm baffled - what command are you using
to do the deployment? Whether I use
{noformat}
mvn site-deploy
{noformat}
or
{noformat}
mvn site:deploy
{noformat}
in both cases with your config mvn fails saying:
{noformat}
Missing site information in the distribution management of the project
{noformat}
This is true - your example, and the real pom at
https://github.com/lhw/duckduckgo/blob/master/pom.xml, both have no site in the
distributionManagement section, only a repository.
I've gone so far as to clone your project to
https://github.com/Mahoney/duckduckgo - I still get the same error. If I switch
the element in distributionManagement from "repository" to "site" then I'm back
to failing with error "Error uploading site" caused by "Error interacting with
SCM: No such provider: 'git'.".
> 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
[ https://jira.codehaus.org/browse/WAGON-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308653#comment-308653 ] Rob Elliot commented on WAGON-374: -- Looking at your gh-pages site (http://lhw.github.com/duckduckgo/) it doesn't look like it's a maven generated site at all. This JIRA issue is about deploying a Maven site (one created with "mvn site" or "mvn site:site") and deploying that site to gh-pages using "mvn site-deploy" or "mvn site:deploy". It is not about deploying artifacts (poms, jars etc.) to an existing gh-pages site. > 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-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-tabpanel&focusedCommentId=308654#comment-308654 ] Herve Boutemy commented on MJAVADOC-333: you need to build it yourself from source, it's not complex, just checkout http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-javadoc-plugin/ > 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-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-tabpanel&focusedCommentId=308658#comment-308658 ] Martin Pecka commented on MJAVADOC-333: --- ok, tried with home-built 2.9-SNAPSHOT - without a change... :( > 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-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-tabpanel&focusedCommentId=308667#comment-308667 ] wiwnsdfk commented on MJAVADOC-333: --- ONLINE STORE : http://Mlink.in/6H n2012 comes, in order to thank everyone, characteristic, novel style, varieties, low price and good quality, and the low sale price. Thank everyone free shipping competitive price any size available accept the paypal jordan shoes $32 nike shox $32 Christan Audigier bikini $23 Ed Hardy Bikini $23 Smful short_t-shirt_woman $15 ed hardy short_tank_woman $16 Sandal $32 christian louboutin $80 Sunglass $15 COACH_Necklace $27 handbag $33 AF tank woman $17 puma slipper woman $30 http://Mlink.in/6H > 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] (MRESOURCES-132) Copying of files with permissions broken
[
https://jira.codehaus.org/browse/MRESOURCES-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308672#comment-308672
]
Rajesh Gowda commented on MRESOURCES-132:
-
Hi,
Is the fix delivered in the latest version of maven-resources-plugin (v2.6) ??
BR,
Rajesh
> Copying of files with permissions broken
>
>
> Key: MRESOURCES-132
> URL: https://jira.codehaus.org/browse/MRESOURCES-132
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Components: copy
>Affects Versions: 2.4.3
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 22:16:01+0300)
> Java version: 1.6.0_19
> Java home: /java/jdk1.6.0_19/jre
> Default locale: en_US, platform encoding: ISO-8859-1
> OS name: "linux" version: "2.6.28.5" arch: "i386" Family: "unix"
>Reporter: Martin Todorov
>
> Files with permissions are not copied with the permissions as illustrated
> below:
> {noformat}
> root@carlspring:/java/opensource/build-force/zipper-plugin# ls -al `find .
> -name *perm*`
> -rwxr--r-- 1 root root 8 2010-12-09 20:48
> ./src/test/resources/zip/file.with.permission.sh*
> -rw-r--r-- 1 root root 8 2010-12-09 22:56
> ./target/test-classes/zip/file.with.permission.sh
> {noformat}
> Notice the 'x' permission missing from the copied file.
--
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:all-tabpanel ] Herve Boutemy updated MJAVADOC-333: --- Comment: was deleted (was: ONLINE STORE : http://Mlink.in/6H n2012 comes, in order to thank everyone, characteristic, novel style, varieties, low price and good quality, and the low sale price. Thank everyone free shipping competitive price any size available accept the paypal jordan shoes $32 nike shox $32 Christan Audigier bikini $23 Ed Hardy Bikini $23 Smful short_t-shirt_woman $15 ed hardy short_tank_woman $16 Sandal $32 christian louboutin $80 Sunglass $15 COACH_Necklace $27 handbag $33 AF tank woman $17 puma slipper woman $30 http://Mlink.in/6H ) > 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
