On 18 Mar 07, at 8:10 PM 18 Mar 07, Brett Porter wrote:
On 19/03/2007, at 10:37 AM, Jason van Zyl wrote:
We extracted it out and then put it back in?
I'm not really sure what you mean here. All I was saying was the
the site stuff was already wound in, I pulled most out to a
separate module, but there are probably still things that could be
improved to get the core back to rendering a single page as you
said. I think we're in clear agreement on what's needed there, it's
just a question of packaging.
No user is exposed to doxia directly yet. All they will see is the
site plugin right now.
I know, but I'd like to understand where we are trying to
eventually get to - I assume you want this as an independently
usable framework.
Aside from our site plugin, not sure. In it's current form it could
not be used for a dynamic site as it would be far too slow. Once it
fully streamed you might be able to do something but I imagine it
being used only from our site plugin.
Do you agree with the level of modularity in that list, and how
do you see these things being bundled up?
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.
I started pushing that into the site renderer, but there is more
work to do, for sure.
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.
It really comes down to the last 3 words :)
We're in full agreement the site stuff and book stuff should be
separated from the core - it's just a matter of where it resides,
how it's versioned and released. The core/api should always be
usable (say, embedded in a wiki) on it's own.
The question is whether the book/site stuff should be usable
outside the context of the site plugin. I believe it should. Given
that, it either is it's own subproject(s), or it's part of the
doxia subproject. From a managability standpoint, I prefer the latter.
Sure, under Doxia is fine as subprojects. That's fine with me.
This is really becoming a broader question of how we deal with
these framework subprojects - we haven't actually made a production
release of the frameworks we've built that are being used outside
of Maven (to my knowledge), but we're about to make a bunch. We're
doing a great job of modularising things, but a poor job of
presenting it as something useful and cohesive to the outside world.
I think stripping doxia down to its guts is the way to present it. As
it is now I think it could be released as a 1.0 barring a couple
nitpicks with a couple of the modules.
I would prefer, for now:
- putting the renderers back, on the understanding that they are a
separate section of the project (maybe they should be in a
subdirectory). This makes things simpler, because we don't have to
muck with artifact IDs and versions and SVN locations for now.
You mean in a separate subproject of doxia. I can change the
directory so how about:
doxia
doxia-site (sub project)
doxia-book (sub project)
- start a new thread on the broader question of how we manage our
subprojects. I think we're all interested in this given the wagon,
scm, surefire, etc releases coming through, and while I think we
have a large amount of common ground it's probably worth coming up
with an agreed template for how we do these things.
Sure, but for the most part it's a matter of just releasing,
releasing, releasing. After EclipseCon I like what their projects do
and especially Mylar where they have frequent dev builds and follow
an every 6 week release schedule. I think following their pattern is
the best I've seen so far and it gives folks some expectation of
what's to come.
I think the template is forming in the tools and much of this is
approaching automation. I think it's more a matter of sheer force of
will and patching and releasing. We're not closing issues is the
problem. The release reporting is almost workable as with the
majority of the releasing toolchain so for the most part closing
issues and invoking the toolchain will be most of the template.
Jason.
WDYT?
- 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]
