Re: Using Doxia 1.1 with Maven 2.0.x and more (WAS: svn commit: r740732 - in /maven/doxia: doxia/trunk/doxia-maven-plugin/pom.xml site/pom.xml)

[Brett Porter <br...@apache.org>]

On 05/02/2009, at 12:39 AM, Vincent Siveton wrote:

> Hi guys,
>
> The good news is that using the shade plugin, I was able to run a the
> latest Doxia plugin (using Doxia 1.1) with mvn 2.0.9 and 2.1.0.M2 and
> site-plugin 2.0-beta-7.
> The bad news, I don't know what are the potential side effects.

For what you are trying to do, there'll be no negative side effects to  
this or the PDF plugin.

Think of it this way, you are "self containing" the plugins' doxia  
dependencies - they won't interact with Maven or other plugins. That's  
fine here - these are standard mojos that get executed that way  
anyway. But if you try it on project-info-reports, you get this:

[INFO] Error configuring: org.apache.maven.plugins:maven-project-info- 
reports-plugin. Reason: java.lang.LinkageError: Class org/codehaus/ 
doxia/sink/Sink violates loader constraints

This is because it is trying to pass the "self contained" sink through  
to the site plugin as if it were a "core" sink, and they no longer  
match up (even if they were to be the same). I'll take a closer look  
at whether we can get this reference out easily.

- Brett

--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Using Doxia 1.1 with Maven 2.0.x and more (WAS: svn commit: r740732 - in /maven/doxia: doxia/trunk/doxia-maven-plugin/pom.xml site/pom.xml)

[Brett Porter <br...@apache.org>]

On 20/02/2009, at 1:38 AM, Brett Porter wrote:

>
> On 05/02/2009, at 12:39 AM, Vincent Siveton wrote:
>
>> Hi guys,
>>
>> The good news is that using the shade plugin, I was able to run a the
>> latest Doxia plugin (using Doxia 1.1) with mvn 2.0.9 and 2.1.0.M2 and
>> site-plugin 2.0-beta-7.
>> The bad news, I don't know what are the potential side effects.
>
> For what you are trying to do, there'll be no negative side effects  
> to this or the PDF plugin.
>
> Think of it this way, you are "self containing" the plugins' doxia  
> dependencies - they won't interact with Maven or other plugins.  
> That's fine here - these are standard mojos that get executed that  
> way anyway. But if you try it on project-info-reports, you get this:
>
> [INFO] Error configuring: org.apache.maven.plugins:maven-project- 
> info-reports-plugin. Reason: java.lang.LinkageError: Class org/ 
> codehaus/doxia/sink/Sink violates loader constraints
>
> This is because it is trying to pass the "self contained" sink  
> through to the site plugin as if it were a "core" sink, and they no  
> longer match up (even if they were to be the same). I'll take a  
> closer look at whether we can get this reference out easily.

This didn't go so well.

The way this works is that the site plugin relies on getting a  
consistent report and sink interface from every reporting plugin  
loaded by Maven. The only way they get a common denominator is by  
Maven dictating this. So any type of filtering out or cherrypicking  
classes is going to cause some confusion because at the end you need  
site and report operating on the same classes. I tried every  
combination I could think of to see if I could discover something in  
the current structure that would decouple it without much success.

So I tried a straight upgrade to doxia 1.1-SNAPSHOT and tried running  
the old site plugin. This seemed to work but dropped the skinning  
altogether. But I have a feeling there could be potential problems  
here - if you are getting the new sink, then a report operates on the  
old sink-api, but you grab a new site plugin, then the report will  
fail because it doesn't declare all the new sink api methods.

My recommendation for 2.1.0 is to get 1.0 in there so it's at least on  
that final strand, and run site 2.0 off of that.

For Doxia 1.1+, a hard look needs to be taken at how all these pieces  
fit together. It can be used just fine for PDF, etc. where they don't  
use the reporting links into the site. I think that is the model to go  
for with the reports being as self contained as possible and the site  
being able to link them together in some other way without actually  
referring to or calling the report plugins (we can just use the site  
lifecycle in the build to do the execution). That is probably a better  
opportunity to look at separating the data gathering (in the reports)  
from the rendering (in the site). This would leave the other  
infrastructure in Maven for the old versions of the site plugin until  
support is removed.

WDYT?

Cheers,
Brett

--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org