Re: javadoc generation fails only during site generation
A small correction: The @options file does contain the dependencies of the first A module (A1), but misses those of all other A modules (for example A2). We use the following directory layout: A-parent/pom.xml A1/pom.xml A2/pom.xml B/B-parent/pom.xml B/B1/pom.xml B/B2/pom.xml Hope this helps, Holger Holger Brands wrote: > > Hi, > > we get the same exception trace using Maven 2.2.1 and after upgrading > to javadoc plugin 2.6. Now we use the aggregate goal in a report set > instead of the aggregate config parameter. > > We hava a mulit-module build with two layers of aggregation: > > A-parent > - A1 > - A2 > - B-parent > - B1 > - B2 > > In both parents the aggregate javadoc reportset is defined. > When executing "mvn install site" in the top-level parent "A-parent" > the exception occurs. > (Removing the aggregate javadoc report set from B-parent does not help.) > It seems to me that in this case the generated @options file does not > contain > the dependencies of the A1 and A2 modules, but only those of > modules B1 and B2. > > Can somone confirm this behaviour? > Is this the cause of the exception? > > Thanks, > Holger > > > Benoit DECHERF-3 wrote: >> >> Hi, >> >> In my project, when I execute mvn javadoc:javadoc, The javadoc generation >> works. >> >> But It fails when I execute mvn site, it fails: >> --- >> [INFO] Generating "JavaDocs" report. >> Loading source files for package >> com.x.euromarketplace.search.cleaner... >> Constructing Javadoc information... >> Standard Doclet version 1.6.0_16 >> Building tree for all the packages and classes... >> 34 warnings >> [INFO] >> >> [ERROR] BUILD ERROR >> [INFO] >> >> [INFO] Error during page generation >> >> Embedded error: Error rendering Maven report: Exit code: 1 - >> /home/decherfb/tmp/searchCleaner/src/java/com//euromarketplace/search/cleaner/Configuration.java:13: >> package com..processframework.services does not exist >> import com..processframework.services.ServiceException; >> >> >> >> java.lang.NullPointerException >>at com.sun.tools.javadoc.TypeMaker.getType(TypeMaker.java:67) >>at com.sun.tools.javadoc.TypeMaker.getType(TypeMaker.java:29) >>at >> com.sun.tools.javadoc.ClassDocImpl.superclassType(ClassDocImpl.java:441) >> >>at com.sun.tools.javadoc.Main.main(Main.java:31) >> >> Command line was:/usr/java/jdk1.6.0_16/jre/../bin/javadoc @options >> @packages >> >> -- >> the @options doesn't have a correct classpath : the missing class is in >> an >> artifact A1.jar. >> >> In the pom, I have the dependency on A1.jar and A1-script.tgz (In this >> order). >> >> If I inverse the order of these dependencies, the site generation works! >> Do you have an idea on this bug ? >> >> Thanks, >> Benoit >> >> > > -- View this message in context: http://www.nabble.com/javadoc-generation-fails-only-during-site-generation-tp25508297p25641699.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: javadoc generation fails only during site generation
Hi, we get the same exception trace using Maven 2.2.1 and after upgrading to javadoc plugin 2.6. Now we use the aggregate goal in a report set instead of the aggregate config parameter. We hava a mulit-module build with two layers of aggregation: A-parent - A1 - A2 - B-parent - B1 - B2 In both parents the aggregate javadoc reportset is defined. When executing "mvn install site" in the top-level parent "A-parent" the exception occurs. (Removing the aggregate javadoc report set from B-parent does not help.) It seems to me that in this case the generated @options file does not contain the dependencies of the A1 and A2 modules, but only those of modules B1 and B2. Can somone confirm this behaviour? Is this the cause of the exception? Thanks, Holger Benoit DECHERF-3 wrote: > > Hi, > > In my project, when I execute mvn javadoc:javadoc, The javadoc generation > works. > > But It fails when I execute mvn site, it fails: > --- > [INFO] Generating "JavaDocs" report. > Loading source files for package > com.x.euromarketplace.search.cleaner... > Constructing Javadoc information... > Standard Doclet version 1.6.0_16 > Building tree for all the packages and classes... > 34 warnings > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error during page generation > > Embedded error: Error rendering Maven report: Exit code: 1 - > /home/decherfb/tmp/searchCleaner/src/java/com//euromarketplace/search/cleaner/Configuration.java:13: > package com..processframework.services does not exist > import com..processframework.services.ServiceException; > > > > java.lang.NullPointerException >at com.sun.tools.javadoc.TypeMaker.getType(TypeMaker.java:67) >at com.sun.tools.javadoc.TypeMaker.getType(TypeMaker.java:29) >at > com.sun.tools.javadoc.ClassDocImpl.superclassType(ClassDocImpl.java:441) > >at com.sun.tools.javadoc.Main.main(Main.java:31) > > Command line was:/usr/java/jdk1.6.0_16/jre/../bin/javadoc @options > @packages > > -- > the @options doesn't have a correct classpath : the missing class is in an > artifact A1.jar. > > In the pom, I have the dependency on A1.jar and A1-script.tgz (In this > order). > > If I inverse the order of these dependencies, the site generation works! > Do you have an idea on this bug ? > > Thanks, > Benoit > > -- View this message in context: http://www.nabble.com/javadoc-generation-fails-only-during-site-generation-tp25508297p25641690.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: deploy multi-module artifacts with derived artifactIds
Ok, I understand better now.
So, ignoring the issue of needing different dependencies for different JDKs,
I could use classifiers.
In the jdk1.5 profile I would configure the jar plugin to produce jars with
a classifier "jdk1.5". If there are dependencies between modules, I would
have to
redefine the deps in this profile as well using the "classified" artifacts.
Let's assume the module for artifact2 depends on artifact1.
The default profile would define a dependency to artifact1 like this:
...
artifact1
...
The jdk1.5 profile would define it like this:
...
artifact1
...
jdk1.5
Correct?
Still a bit ugly, but it could work...
Thanks,
Holger
Stephen Connolly-2 wrote:
>
> OK, the first idea when Maven 2 was being designed is that you would use
> different classifiers to differentiate between the different JDKs... thus
> you could go
>
>
> com.foo.foo
> bar
> jdk15
>
>
> in order to use the jdk15 version, rather than the default with no
> classifier
>
> Why they did not see the problem at this point is beyond me... which is
> the
> default??? is it the jdk13 version? the jdk16 version?
>
> You'd really need everything to have a classifier and not allow default
> classifiers
>
> Then enter NMaven which points out that you could want multiple
> classifiers...
>
> This could even apply in Java...
>
> On top of all of this, you have that for transitive dependencies,
> everything
> uses the one POM.xml
>
> So if I have a jdk15 and a jdk16 set of artifacts that use JAXB for
> jdk16 I should not list JAXB as a transitive dependency (as it is included
> in jdk16) but I need it for jdk15... the jdk14 stuff needs some other
> stuff
> added as well, and the jdk13 stuff even needs me to swap in a whole lot of
> other stuff to work around JAXB and roll it all myself
>
> i.e. dependencies are a problem when you use classifiers.
>
> That problem has not been solved yet it may have to wait until Maven
> 3.0 (as it might require a schema change)
>
> OK, so you're fine that classifiers cannot be used to solve the problem
> (BTW
> either adding the classifier config or the build helper plugin can be used
> to attach the builds using classifiers... but I suggest that you ignore
> that
> approach)
>
> Now you realize that you cannot do everything from one artifact you
> need
> more than one artifact...
>
> So you create two projects foo-jdk15 and foo-jdk16
>
> in foo-jdk15 you also build the source-jar and attach that to the reactor
>
> in foo-jdk16 you use the dependency plugin to extract
> foo-jdk15-sources-${project.version}.jar into target/generated-sources/jar
> and use the build helper plugin to add this source path...
>
> That should do what you need and allow you to differentiate the
> depenencies
> required for each platform (jdk15 vs jdk16)
>
> 2008/9/25 Holger Brands <[EMAIL PROTECTED]>
>
>>
>> Stephen,
>>
>> I don't quite understand your tip.
>> My main problem is not compiling. I don't need different JREs to link
>> against, I just have to specify a different target compiler option. Just
>> in
>> case I wasn't clear about that.
>> The problem is to tweak the artifactIds to have a suffix. The generated
>> artifacts should reflect the changed names as well as the deploy plugin
>> should respect them in the deployed poms and with regard to the
>> deployment
>> target directory.
>>
>> Thanks,
>> Holger
>>
>>
>> Stephen Connolly-2 wrote:
>> >
>> > I want to say classifiers
>> >
>> > but that only works if the dependencies have not changed.
>> >
>> > Perhaps what you want is a different project that depends on the first
>> one
>> > and unpacks it's -source.jar and does a recompile with the different
>> jdk
>> >
>> > On 25 September 2008 12:00, Holger Brands <[EMAIL PROTECTED]> wrote:
>> >
>> >>
>> >> I've a multi-module build that is compiled with target 1.6 and
>> deployed
>> >> to
>> >> our company repo with artifactIds "artifact1", "artifact2" and so on.
>> >>
>> >> Now, what I want to achieve is the following:
>> >> I want the same multi-module build optionally to be compiled with
>> target
>> >> 1.5
>> >> and deployed to our company repo with artifactIds "artifact1_java15",
>> >> "artifact2_java15" and so on.
>> >>
>> >> So, ideally
>> >> - "mvn deploy" shou
Re: deploy multi-module artifacts with derived artifactIds
Nick,
forget about the ignored finalName profile configuration. I activated the
wrong profile.
But the second question remains open.
I tried the following solution:
I defined a property "suffix" with an empty string as default value in the
parent pom.
In the jdk1.5 build profile a defined the property value to be "_java15".
In the module poms I defined the artifact id to be "artifactId1${suffix}"
"artifactId2${suffix}" and so on.
In addition, I adapted dependencies between the modules accordingly in the
poms.
Now, when calling mvn package with my jdk1.5 build profile activated, the
resulting artifacts are as expected, e.g. artifactId1_java15-1.0.jar.
When calling mvn deploy with the jdk1.5 build profile, these jars get
deployed to the correct target directory respecting the "patched"
artifactId. *But* the poms are deployed as is, e.g. the artifactId stays
"artifactId1${suffix}" in the pom and is not expanded to "artifactId1_java".
That's the only thing that's missing.
Any ideas?
Thanks,
Holger
Holger Brands wrote:
>
> Hi Nick,
>
> I (already) tried to use a profile in the parent pom, but the adapted
> finalName is ignored by the jar plugin, e.g. mvn package creates the jar
> with the default name.
> (I use Maven 2.0.9 with jar plugin version 2.2)
>
> In addition, even if that would work, would the deploy plugin use the
> changed finalName to guess the correct artifactId? I doubt that. I think
> it would still take the artifactId defined in the pom, which would still
> be "artifact1" instead of "artifact1_java15" or am I wrong?
>
> Thanks for your help,
> Holger
>
>
> Nick Stolwijk-4 wrote:
>>
>> You could create a profile which configures the build/finalname and
>> the compiler plugin. This should create the desired artifact.
>>
>> ie:
>>
>>
>>
>>1.5build
>>
>> ${artifactId}-${version}-jdk1.5
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Activate with mvn -P1.5build clean deploy.
>>
>> Hth,
>>
>> Nick Stolwijk
>> ~Java Developer~
>>
>> Iprofs BV.
>> Claus Sluterweg 125
>> 2012 WS Haarlem
>> www.iprofs.nl
>>
>>
>>
>> On Thu, Sep 25, 2008 at 2:40 PM, Stephen Connolly
>> <[EMAIL PROTECTED]> wrote:
>>> I want to say classifiers
>>>
>>> but that only works if the dependencies have not changed.
>>>
>>> Perhaps what you want is a different project that depends on the first
>>> one
>>> and unpacks it's -source.jar and does a recompile with the different jdk
>>>
>>> On 25 September 2008 12:00, Holger Brands <[EMAIL PROTECTED]> wrote:
>>>
>>>>
>>>> I've a multi-module build that is compiled with target 1.6 and deployed
>>>> to
>>>> our company repo with artifactIds "artifact1", "artifact2" and so on.
>>>>
>>>> Now, what I want to achieve is the following:
>>>> I want the same multi-module build optionally to be compiled with
>>>> target
>>>> 1.5
>>>> and deployed to our company repo with artifactIds "artifact1_java15",
>>>> "artifact2_java15" and so on.
>>>>
>>>> So, ideally
>>>> - "mvn deploy" should deploy the default build artifacts compiled with
>>>> target 1.6.
>>>> - "mvn -Djdk=1.5 deploy" should deploy the derived build artifacts
>>>> compiled
>>>> with target 1.5.
>>>>
>>>> I know how to use profiles/properties to set the desired compiler
>>>> options.
>>>> But how to tweak the artifactIds?
>>>>
>>>> Is there an easy way to accomplish this?
>>>> If not, what's the recommended way to deal with this requirement?
>>>>
>>>> I'm using Maven 2.0.9 on Windows XP.
>>>>
>>>> Sorry, if this has been asked before.
>>>>
>>>> Thanks,
>>>> Holger
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/deploy-multi-module-artifacts-with-derived-artifactIds-tp19667309p19667309.html
>>>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>>>
>>>>
>>>> -
>>>> 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]
>>
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/deploy-multi-module-artifacts-with-derived-artifactIds-tp19667309p19675647.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: deploy multi-module artifacts with derived artifactIds
Stephen, I don't quite understand your tip. My main problem is not compiling. I don't need different JREs to link against, I just have to specify a different target compiler option. Just in case I wasn't clear about that. The problem is to tweak the artifactIds to have a suffix. The generated artifacts should reflect the changed names as well as the deploy plugin should respect them in the deployed poms and with regard to the deployment target directory. Thanks, Holger Stephen Connolly-2 wrote: > > I want to say classifiers > > but that only works if the dependencies have not changed. > > Perhaps what you want is a different project that depends on the first one > and unpacks it's -source.jar and does a recompile with the different jdk > > On 25 September 2008 12:00, Holger Brands <[EMAIL PROTECTED]> wrote: > >> >> I've a multi-module build that is compiled with target 1.6 and deployed >> to >> our company repo with artifactIds "artifact1", "artifact2" and so on. >> >> Now, what I want to achieve is the following: >> I want the same multi-module build optionally to be compiled with target >> 1.5 >> and deployed to our company repo with artifactIds "artifact1_java15", >> "artifact2_java15" and so on. >> >> So, ideally >> - "mvn deploy" should deploy the default build artifacts compiled with >> target 1.6. >> - "mvn -Djdk=1.5 deploy" should deploy the derived build artifacts >> compiled >> with target 1.5. >> >> I know how to use profiles/properties to set the desired compiler >> options. >> But how to tweak the artifactIds? >> >> Is there an easy way to accomplish this? >> If not, what's the recommended way to deal with this requirement? >> >> I'm using Maven 2.0.9 on Windows XP. >> >> Sorry, if this has been asked before. >> >> Thanks, >> Holger >> >> -- >> View this message in context: >> http://www.nabble.com/deploy-multi-module-artifacts-with-derived-artifactIds-tp19667309p19667309.html >> Sent from the Maven - Users mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- View this message in context: http://www.nabble.com/deploy-multi-module-artifacts-with-derived-artifactIds-tp19667309p19671027.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: deploy multi-module artifacts with derived artifactIds
Hi Nick,
I (already) tried to use a profile in the parent pom, but the adapted
finalName is ignored by the jar plugin, e.g. mvn package creates the jar
with the default name.
(I use Maven 2.0.9 with jar plugin version 2.2)
In addition, even if that would work, would the deploy plugin use the
changed finalName to guess the correct artifactId? I doubt that. I think it
would still take the artifactId defined in the pom, which would still be
"artifact1" instead of "artifact1_java15" or am I wrong?
Thanks for your help,
Holger
Nick Stolwijk-4 wrote:
>
> You could create a profile which configures the build/finalname and
> the compiler plugin. This should create the desired artifact.
>
> ie:
>
>
>
>1.5build
>
> ${artifactId}-${version}-jdk1.5
>
>
>
>
>
>
>
>
>
> Activate with mvn -P1.5build clean deploy.
>
> Hth,
>
> Nick Stolwijk
> ~Java Developer~
>
> Iprofs BV.
> Claus Sluterweg 125
> 2012 WS Haarlem
> www.iprofs.nl
>
>
>
> On Thu, Sep 25, 2008 at 2:40 PM, Stephen Connolly
> <[EMAIL PROTECTED]> wrote:
>> I want to say classifiers
>>
>> but that only works if the dependencies have not changed.
>>
>> Perhaps what you want is a different project that depends on the first
>> one
>> and unpacks it's -source.jar and does a recompile with the different jdk
>>
>> On 25 September 2008 12:00, Holger Brands <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> I've a multi-module build that is compiled with target 1.6 and deployed
>>> to
>>> our company repo with artifactIds "artifact1", "artifact2" and so on.
>>>
>>> Now, what I want to achieve is the following:
>>> I want the same multi-module build optionally to be compiled with target
>>> 1.5
>>> and deployed to our company repo with artifactIds "artifact1_java15",
>>> "artifact2_java15" and so on.
>>>
>>> So, ideally
>>> - "mvn deploy" should deploy the default build artifacts compiled with
>>> target 1.6.
>>> - "mvn -Djdk=1.5 deploy" should deploy the derived build artifacts
>>> compiled
>>> with target 1.5.
>>>
>>> I know how to use profiles/properties to set the desired compiler
>>> options.
>>> But how to tweak the artifactIds?
>>>
>>> Is there an easy way to accomplish this?
>>> If not, what's the recommended way to deal with this requirement?
>>>
>>> I'm using Maven 2.0.9 on Windows XP.
>>>
>>> Sorry, if this has been asked before.
>>>
>>> Thanks,
>>> Holger
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/deploy-multi-module-artifacts-with-derived-artifactIds-tp19667309p19667309.html
>>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>>
>>>
>>> -
>>> 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]
>
>
>
--
View this message in context:
http://www.nabble.com/deploy-multi-module-artifacts-with-derived-artifactIds-tp19667309p19670654.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
deploy multi-module artifacts with derived artifactIds
I've a multi-module build that is compiled with target 1.6 and deployed to our company repo with artifactIds "artifact1", "artifact2" and so on. Now, what I want to achieve is the following: I want the same multi-module build optionally to be compiled with target 1.5 and deployed to our company repo with artifactIds "artifact1_java15", "artifact2_java15" and so on. So, ideally - "mvn deploy" should deploy the default build artifacts compiled with target 1.6. - "mvn -Djdk=1.5 deploy" should deploy the derived build artifacts compiled with target 1.5. I know how to use profiles/properties to set the desired compiler options. But how to tweak the artifactIds? Is there an easy way to accomplish this? If not, what's the recommended way to deal with this requirement? I'm using Maven 2.0.9 on Windows XP. Sorry, if this has been asked before. Thanks, Holger -- View this message in context: http://www.nabble.com/deploy-multi-module-artifacts-with-derived-artifactIds-tp19667309p19667309.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: codehaus snapshot repo
Hi, > > You should check Bob McWhirter's Blog on http://www.fnokd.com/ for > status updates on the Codehaus server recovery. Additional information > can be found on the temporary Codehaus frontpage http://www.codehaus.org/ > Thanks for these links. But I have not found any info regarding the snapshot repo, in particular: - what state has been recovered: 27. April, 9. Mai ? - how to proceed, e.g. do the plugin maintainers/developers have to restore the missing artifacts themselves or has this been taken care of ? - is there a mirror of http://snapshots.maven.codehaus.org/maven2/ with the correct state ? I'm asking this, because our previous working maven builds are breaking since the snapshot repo is back. Is there a workaround other than manually patching/fixing our local repos and running the builds offline ? Thanks, Holger ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
codehaus snapshot repo
Hi, I noticed, that the codehaus snapshot repo (http://snapshots.maven.codehaus.org/maven2) is available again. But unfortunately, it is not up to date, e.g. deployments from May, 11th are missing (for example new versions of webstart and keytool plugin). Can somebody comment on the state of the codehaus snapshot repo and how do we get to an up to date state ? Thanks, Holger ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
