I was planning to release a RC version tonight, but if you think you can
make improvements in this Doxia two-step we're putting together here, I
think that is more important than a couple of days' time. I'll spend my
time in more productive ways - namely, documenting the release process I
used for 2.0.1, and the pitfalls that I experienced.
More comments are inline below.
Thanks,
John
Brett Porter wrote:
Hi,
One thing I haven't changed yet and don't quite understand is the
inclusion of copies of classes in org.codehaus.doxia in reporting-impl.
John - what was the need for this? I think I might be able to get rid of
the concrete ones, and move the site renderer to doxia-site-renderer,
then do the implements think like with the sink.
I was simply going through the apis available to any report and making
them look exactly as they would have if the package hadn't changed. For
example, the concrete classes became wrappers around the new classes
from org.apache.maven.doxia.* so that anyone who had cast them to the
concrete classes passed back would have the same API to code against...I
know that type of casting is generally a no-no, but I wanted to avoid
breaking compatibility, even at that level.
Admittedly, this compat layer was done in a fairly quick-and-dirty
fashion, so whatever you think needs to go, I have no objections...
Note also that the next release of the site plugin will require maven
2.0.2 (because it requires changes to doxia, which requires updating to
the new packages, which requires 2.0.2 :)
I think this is fine...it's inevitable that some plugin releases won't
be compatible with maven 2.0, since they depend on fixes in the
supporting APIs.
Thoughts?
- Brett
---------------------------------------------------------------------
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]
