On 19/03/2007, at 9:42 AM, Jason van Zyl wrote:
On 18 Mar 07, at 5:52 PM 18 Mar 07, Brett Porter wrote:
What was your justification for removing them?
Actually, as a follow up to show why what we have currently as not
being ideal is the XhtmlSink. This is something I started and was a
mistake in the form that I did it because I did merge in the
concept of site. What we ended up with is a coupling in the
RenderingContext about physical locations of sites. The XhtmlSink
should purely render out Xhtml so that it would work in a system
producing dynamic content where something like sitemesh would do
the decorating. The XhtmlSink could have easily been subclassed to
allow for site capabilities, but the coupling happened because the
concerns of pure output were not separated from the site concept.
Yeah, but at the time the site concept was embedded right into doxia-
core. I did a fair bit of work extracting it out, though I'm sure
there are still some leftovers too which we can clean up.
At a technical level I agree with you, I see the separation in this way:
- main doxia rendering framework and modules
- site rendering tools
- book rendering tools
- executors: maven plugin, jetty runner (and site:run mojo), ant tasks
- maven-reporting integration (basically need to inject MavenProject
and extra renderers into the maven plugin and site:run executors.
This would be the maven-reporting-impl library)
We have a ways to go to get to this type of abstraction, especially
with the reporting and executors.
However, how these get bundled as subprojects, from a managability
standpoint, is a different matter. Having mapped this out, I feel
like the first 4 are the doxia subproject (with a large amount of the
executor functionality in a shared piece of code in the maven plugin
is actually just a simple rendering doxia-maven-plugin). I think the
second one is a reporting project and includes the maven-site-plugin
which uses the existing executors and extends them to add reports
(and can later become more advanced as the reporting infrastructure
does).
I'm all for modularity, but I worry about the managability of
creating too many subprojects - both from a release standpoint and a
users-getting-confused standpoint.
Do you agree with the level of modularity in that list, and how do
you see these things being bundled up?
Might be good to ping Trygve too since I think he was main book
proponent?
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
