the Cargo and Cactus builds showed that doxia-site-renderer 1.0 was
incompatible with Velocity trunk - in fact doxia-site-renderer's trunk
still is, see
I turned to the Velocity dev list and was told the Velocity template
used by doxia-site-renderer wouldn't work with any version of Velocity,
it probably just failed silently with older versions - see
<http://jira.codehaus.org/browse/DOXIA-400> for the JIRA issue I opened.
Optimistically I started adding doxia to Gump so if the issue I opened
would get fixed, Gump'd pick up the fixes and things should work.
A bit too optimistic, obviously.
Doxia has released several 1.1.x releases and decided to break the 1.0
API in several ways. For one the doxia-sink-api module used to contain
some sort of logging api that has been broken out - this was fixable
with a custom POM. But they've also moved a class from
doxia-modules-xhtml into a different module and Java package, a class
that seems to be used by several Maven plugins including the RAT and
Gump can not force a project to use a different Maven plugin version
than it specifies since mvn verifies that the version given inside the
POM matches a plugin descriptor contained inside the jar itself. Right
now I don't feel like re-writing the plugin descriptor inside the mvn
This means projects that use the Javadoc plugin can't use Doxia 1.1+,
even if there was a version of the Javadoc plugin that supported it
(there isn't, even the trunk is stuck at Doxia 1.0).
I don't see a way to resolve this given our tools at hand and I don't
really know how we could improve the current Gump ideas to deal with
this situation. To solve this and similar problems we'd need a way in
Gump to say "this time, really provide the version the project asks for"
but I don't find a hook where this could be added.
Unless anybody can come up with a better idea I'll change the groupId
for the doxia module so Doxia gets built, but nobody will ever use the
trunk version. I may even go so far and remove the doxia build again
since it isn't worth much if downstream users must not use it.
I don't have any idea how to resolve the Cactus/Cargo case either.
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org