You are viewing a plain text version of this content. The canonical link for it is here.
Posted to doxia-commits@maven.apache.org by jv...@apache.org on 2007/03/18 19:54:21 UTC
svn commit: r519667 - in /maven/doxia/trunk: doxia-decoration-model/
doxia-doc-renderer/ doxia-site-renderer/ pom.xml
Author: jvanzyl
Date: Sun Mar 18 11:54:20 2007
New Revision: 519667
URL: http://svn.apache.org/viewvc?view=rev&rev=519667
Log:
o site specific modules moved to sitetools
Removed:
maven/doxia/trunk/doxia-decoration-model/
maven/doxia/trunk/doxia-doc-renderer/
maven/doxia/trunk/doxia-site-renderer/
Modified:
maven/doxia/trunk/pom.xml
Modified: maven/doxia/trunk/pom.xml
URL: http://svn.apache.org/viewvc/maven/doxia/trunk/pom.xml?view=diff&rev=519667&r1=519666&r2=519667
==============================================================================
--- maven/doxia/trunk/pom.xml (original)
+++ maven/doxia/trunk/pom.xml Sun Mar 18 11:54:20 2007
@@ -146,9 +146,6 @@
<modules>
<module>doxia-core</module>
<module>doxia-sink-api</module>
- <module>doxia-site-renderer</module>
- <module>doxia-decoration-model</module>
<module>doxia-modules</module>
- <module>doxia-doc-renderer</module>
</modules>
</project>
Re: svn commit: r519667 - in /maven/doxia/trunk: doxia-decoration-model/
doxia-doc-renderer/ doxia-site-renderer/ pom.xml
Posted by Trygve Laugstøl <tr...@apache.org>.
Jason van Zyl wrote:
>
> On 20 Mar 07, at 7:57 AM 20 Mar 07, Trygve Laugstøl wrote:
>
>> Brett Porter wrote:
>>> On 19/03/2007, at 11:27 AM, Jason van Zyl wrote:
>>>> 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)
>>> These sound fine to me.
>>
>> Me too. What is the most important aspect of Doxia given how many
>> plugins you can write for it is the external APIs and how you use
>> Doxia in an embedded fashion.
>>
>
> Agreed. The core should be free of any site/book stuff for the 1.0.
>
> Trygve do you see anything that can move out. Like the indexing stuff?
> That is probably most pertinent to books and sites, any thoughts to
> where that should live?
Can't think of an obvious place right now.
To me the design of Doxia is not very useful if you want to produce
books and/or sites useful for anyone other than developers so I haven't
put much work into Doxia after my book work last year. I have some big
plans somewhere for Doxia 2 but that won't happen sometime soon.
--
Trygve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r519667 - in /maven/doxia/trunk: doxia-decoration-model/ doxia-doc-renderer/ doxia-site-renderer/ pom.xml
Posted by Jason van Zyl <ja...@maven.org>.
On 20 Mar 07, at 7:57 AM 20 Mar 07, Trygve Laugstøl wrote:
> Brett Porter wrote:
>> On 19/03/2007, at 11:27 AM, Jason van Zyl wrote:
>>> 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)
>> These sound fine to me.
>
> Me too. What is the most important aspect of Doxia given how many
> plugins you can write for it is the external APIs and how you use
> Doxia in an embedded fashion.
>
Agreed. The core should be free of any site/book stuff for the 1.0.
Trygve do you see anything that can move out. Like the indexing
stuff? That is probably most pertinent to books and sites, any
thoughts to where that should live?
Jason.
> [snip]
>
> --
> Trygve
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r519667 - in /maven/doxia/trunk: doxia-decoration-model/
doxia-doc-renderer/ doxia-site-renderer/ pom.xml
Posted by Trygve Laugstøl <tr...@apache.org>.
Brett Porter wrote:
>
> On 19/03/2007, at 11:27 AM, Jason van Zyl wrote:
>
>> 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)
>
> These sound fine to me.
Me too. What is the most important aspect of Doxia given how many
plugins you can write for it is the external APIs and how you use Doxia
in an embedded fashion.
[snip]
--
Trygve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r519667 - in /maven/doxia/trunk: doxia-decoration-model/ doxia-doc-renderer/ doxia-site-renderer/ pom.xml
Posted by Brett Porter <br...@apache.org>.
On 19/03/2007, at 11:27 AM, Jason van Zyl wrote:
> 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)
These sound fine to me.
>
>> - 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.
Can't agree more :)
I think a key part of this, even if we're not able to meet those
sorts of timelines, is at least always having an up-to-date list of
what is going into the next release, when the next milestone is, etc.
It at least gives a good indication of progress, and should highlight
the things that need the most help. I'm happy to help put those
together.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r519667 - in /maven/doxia/trunk: doxia-decoration-model/ doxia-doc-renderer/ doxia-site-renderer/ pom.xml
Posted by Jason van Zyl <ja...@maven.org>.
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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r519667 - in /maven/doxia/trunk: doxia-decoration-model/ doxia-doc-renderer/ doxia-site-renderer/ pom.xml
Posted by Brett Porter <br...@apache.org>.
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.
>
>>
>> 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.
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 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.
- 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.
WDYT?
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r519667 - in /maven/doxia/trunk: doxia-decoration-model/ doxia-doc-renderer/ doxia-site-renderer/ pom.xml
Posted by Jason van Zyl <ja...@maven.org>.
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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r519667 - in /maven/doxia/trunk: doxia-decoration-model/ doxia-doc-renderer/ doxia-site-renderer/ pom.xml
Posted by Brett Porter <br...@apache.org>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r519667 - in /maven/doxia/trunk: doxia-decoration-model/ doxia-doc-renderer/ doxia-site-renderer/ pom.xml
Posted by Jason van Zyl <ja...@maven.org>.
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.
Jason.
> I have no objection to splitting the site plugin into some maven
> site related tools, but I don't think these belong in there.
>
> - Brett
>
> On 19/03/2007, at 5:54 AM, jvanzyl@apache.org wrote:
>
>> Author: jvanzyl
>> Date: Sun Mar 18 11:54:20 2007
>> New Revision: 519667
>>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=519667
>> Log:
>> o site specific modules moved to sitetools
>>
>> Removed:
>> maven/doxia/trunk/doxia-decoration-model/
>> maven/doxia/trunk/doxia-doc-renderer/
>> maven/doxia/trunk/doxia-site-renderer/
>> Modified:
>> maven/doxia/trunk/pom.xml
>>
>> Modified: maven/doxia/trunk/pom.xml
>> URL: http://svn.apache.org/viewvc/maven/doxia/trunk/pom.xml?
>> view=diff&rev=519667&r1=519666&r2=519667
>> =====================================================================
>> =========
>> --- maven/doxia/trunk/pom.xml (original)
>> +++ maven/doxia/trunk/pom.xml Sun Mar 18 11:54:20 2007
>> @@ -146,9 +146,6 @@
>> <modules>
>> <module>doxia-core</module>
>> <module>doxia-sink-api</module>
>> - <module>doxia-site-renderer</module>
>> - <module>doxia-decoration-model</module>
>> <module>doxia-modules</module>
>> - <module>doxia-doc-renderer</module>
>> </modules>
>> </project>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r519667 - in /maven/doxia/trunk: doxia-decoration-model/ doxia-doc-renderer/ doxia-site-renderer/ pom.xml
Posted by Jason van Zyl <ja...@maven.org>.
On 18 Mar 07, at 5:52 PM 18 Mar 07, Brett Porter wrote:
> -1 on this change.
> I apologise - I was sure I responsed to your mail saying you were
> going to do this yesterday saying that I objected, but it never
> made it to the list.
> I can't see any reason to remove these 2 modules from Doxia - I
> believe Doxia should be capable of generating a fully decorated
> site on it's own.
I think that should be relegated to another layer as explained below.
> They are not presently coupled to Maven at all, and moving them
> into a Maven site tools project obviously does.
The still won't be coupled to Maven they will be for generating
sites. They will not be coupled to Maven and in fact sitetools could
be a standard site toolkit.
>
> What was your justification for removing them?
That Doxia is a content framework consisting of parsers, and sinks
and that's it. Small, with a clear purpose and very limited API.
Anything else can be layered on top of that. What's there now is very
small and easier managed without tangling concerns of books or sites.
So standard separation of concerns was my impetus. A small API for
Doxia, site capabilities in another layer, book capabilities in
another layer. The site and book functionality in Doxia are whole
different tool sets. If I make changes to the site, or book
capabilities I am then forced to release Doxia to publish those
changes. I see no downside in modularizing the site and book
functionality. Do they not seem to be separate concerns to you?
The whole point of our tooling mechanism to the transitive
dependencies, the sitetool can generate a site easily and to date no
one has ever used Doxia itself to generate a site so now seems a
perfect opportunity to decouple the concerns.
Please reconsider, I feel tangling the book and site capabilities in
Doxia make it far harder to manage the change and evolution of Doxia
itself.
Jason.
>
> I have no objection to splitting the site plugin into some maven
> site related tools, but I don't think these belong in there.
>
> - Brett
>
> On 19/03/2007, at 5:54 AM, jvanzyl@apache.org wrote:
>
>> Author: jvanzyl
>> Date: Sun Mar 18 11:54:20 2007
>> New Revision: 519667
>>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=519667
>> Log:
>> o site specific modules moved to sitetools
>>
>> Removed:
>> maven/doxia/trunk/doxia-decoration-model/
>> maven/doxia/trunk/doxia-doc-renderer/
>> maven/doxia/trunk/doxia-site-renderer/
>> Modified:
>> maven/doxia/trunk/pom.xml
>>
>> Modified: maven/doxia/trunk/pom.xml
>> URL: http://svn.apache.org/viewvc/maven/doxia/trunk/pom.xml?
>> view=diff&rev=519667&r1=519666&r2=519667
>> =====================================================================
>> =========
>> --- maven/doxia/trunk/pom.xml (original)
>> +++ maven/doxia/trunk/pom.xml Sun Mar 18 11:54:20 2007
>> @@ -146,9 +146,6 @@
>> <modules>
>> <module>doxia-core</module>
>> <module>doxia-sink-api</module>
>> - <module>doxia-site-renderer</module>
>> - <module>doxia-decoration-model</module>
>> <module>doxia-modules</module>
>> - <module>doxia-doc-renderer</module>
>> </modules>
>> </project>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r519667 - in /maven/doxia/trunk: doxia-decoration-model/ doxia-doc-renderer/ doxia-site-renderer/ pom.xml
Posted by Brett Porter <br...@apache.org>.
-1 on this change.
I apologise - I was sure I responsed to your mail saying you were
going to do this yesterday saying that I objected, but it never made
it to the list.
I can't see any reason to remove these 2 modules from Doxia - I
believe Doxia should be capable of generating a fully decorated site
on it's own. They are not presently coupled to Maven at all, and
moving them into a Maven site tools project obviously does.
What was your justification for removing them?
I have no objection to splitting the site plugin into some maven site
related tools, but I don't think these belong in there.
- Brett
On 19/03/2007, at 5:54 AM, jvanzyl@apache.org wrote:
> Author: jvanzyl
> Date: Sun Mar 18 11:54:20 2007
> New Revision: 519667
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=519667
> Log:
> o site specific modules moved to sitetools
>
> Removed:
> maven/doxia/trunk/doxia-decoration-model/
> maven/doxia/trunk/doxia-doc-renderer/
> maven/doxia/trunk/doxia-site-renderer/
> Modified:
> maven/doxia/trunk/pom.xml
>
> Modified: maven/doxia/trunk/pom.xml
> URL: http://svn.apache.org/viewvc/maven/doxia/trunk/pom.xml?
> view=diff&rev=519667&r1=519666&r2=519667
> ======================================================================
> ========
> --- maven/doxia/trunk/pom.xml (original)
> +++ maven/doxia/trunk/pom.xml Sun Mar 18 11:54:20 2007
> @@ -146,9 +146,6 @@
> <modules>
> <module>doxia-core</module>
> <module>doxia-sink-api</module>
> - <module>doxia-site-renderer</module>
> - <module>doxia-decoration-model</module>
> <module>doxia-modules</module>
> - <module>doxia-doc-renderer</module>
> </modules>
> </project>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org