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
[email protected]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
