On 18 Mar 07, at 7:06 PM 18 Mar 07, Brett Porter wrote:
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.
We extracted it out and then put it back in? It was done in a
different way that actually worked for single pages in the original
code. The original code had aggregators, but not like we've done
where you can't actually render a single xhtml page.
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.
No user is exposed to doxia directly yet. All they will see is the
site plugin right now.
Do you agree with the level of modularity in that list, and how do
you see these things being bundled up?
I don't know about the last one, it's kind of vague but I definitely
agree with separate units of deployment for the first three.
I definitely would like to keep:
http://svn.apache.org/repos/asf/maven/doxia/trunk/
The book stuff is in the sandbox but is definitely a separate project.
The site stuff is definitely a separate project but I bundled it with
with site plugin. I've fine putting the site stuff in a separate
project itself but it doesn't work by itself as half the logic is in
the site plugin itself.
But I'm happy to do 1, 2, 3 and that clearly dilineates the
functionality. So I can make spots for the site stuff under doxia and
put those back under there. I don't care where it is per se as long
as it's marked as site tools and isn't in doxia's core or distributed
with it.
Jason.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
