Hi,
First of all, thanks Brad for your elaborate answer !
Some more details about your project would probably help.
The mentioned multi-module project is part of a really large system with
more than 100 different modules/projects. We're currently performing a
major POM clean-up / refactoring so dependencies are in a state of flux
right now. One of the major changes to the parent POM is getting rid of
all ${version.MODULEXYZ} properties we've used so far and replacing them
with proper <dependencyManagement/> entries.
Do your missing symbols happen to be related to types created by source
code generation?
No, the missing symbols come from another in-house project. I think the
bug is somehow related to our use of <dependencyManagement/> since it
did not occur until we got rid of the version properties in the parent POM.
module B ----> module A
^ ^
| |
+--------+--------+
|
module C (this is the module that breaks while generating javadocs)
All modules inherit from a common parent POM , versions of dependencies
for modules A / B / C are declared inside the parent's
<dependencyManagement/> section. When running 'mvn release:perform' for
module C the javadoc-plugin fails because some symbol from module B is
missing. I just double-checked the pom.xml of module C , both module A
and module B are properly listed as dependencies there (and obviously
are on the classpath during the 'compile' phase, otherwise the build
would fail earlier).
As a 'work-around' , we've completely removed the javadoc plugin from
the parent POM's <reporting/> section for now ...
Regards,
Tobias
I had run into a similar problem with one of my builds a couple months
ago, so let me share what I found.
I had a multi-module project which used the XMLBeans Maven Plugin to
generate some code from XML Schema files. I had the plugin defined in
the module POM and had it configured to use JDK 1.5, which means amongst
other things, that it creates get*List() methods in addition to
get*Array() methods. The reactor project built fine, and I was able to
successfully run site:site. After successfully running release:prepare,
I tried release:perform, and all of a sudden the build failed with an
error like:
cannot find symbol
symbol : method getPropertyList()
location: interface
I investigated this and found that the problem was that the XMLBeans
Maven Plugin was being run multiple times during a reactor build, and
during the site generation process it was being re-run but without the
proper plugin configuration (specifically javaSource = 1.5 was not set).
As a result, the get*List() versions of the methods were not being
generated and the build failed.
I tried several things to resolve this issue. I found that the only
solution for me was to move the plugin configuration into the
<pluginManagement> section of the root POM to insure that the
configuration was always available, since for some unknown reason it
was sometimes being omitted during a reactor build. This approach
"resolved" the issue for me.
I am not sure if this will help you at all, but I thought I would share
in case you do have a similar configuration, or at least it may give you
some ideas.
I *think* this may be related to
http://jira.codehaus.org/browse/MJAVADOC-179, but I am not sure.
Good luck!
~Brad
-----Original Message-----
From: Tobias Gierke <[EMAIL PROTECTED]>
Reply-To: Maven Users List <[email protected]>
To: Maven Users List <[email protected]>
Subject: javadoc plugin fails during mvn release:perform ?
Date: Mon, 29 Sep 2008 18:13:45 +0200
Hi,
How come the javadoc plugin fails with a 'cannot find symbol XYZ' error
when running 'mvn release:perform' but 'mvn site' works fine ? Since
compilation works I would assume my pom.xml contains all required
dependencies.
Maven version: 2.0.9 (i386 Linux)
JDK version: 1.5 (tested with 1.6 as well, both fail)
maven-release-plugin: 2.0-beta-7
javadoc-plugin: 2.4
My project uses a rather large parent POM , unfortunately I had no time
to try to reproduce this issue with a simpler POM yet. (Plugin) version
numbers are inherited from a parent POM, along with dependency version
numbers (although these are not completely managed using
<dependencyManagement/> , we're currently in a kind of 'transition
phase' and use a mix of version properties and <dependencyManagement> in
our parent POM).
Regards,
Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
