Dennis Lundberg wrote:
On 2012-03-29 09:13, Lukas Theussl wrote:
I agree that they don't belong into core, but I rather thought of moving
them into doxia-tools instead. Not sure what is better.
This was my thought also.
OTOH, neither book nor maven-plugin have been maintained (AFAIK) since
they were moved out of the sandbox, and IMO they don't work too well. In
particular there are problems reported with Maven 3 (DOXIA-438) which I
haven't tested, but I wanted to suggest a long time ago to deprecate and
ultimately remove them.
If agree that they should be moved, let's start with that. If the target
is doxia-tools then let's move them there, prior to the 1.3 release of
Doxia and Doxia Sitetools.
My feeling about Doxia Tools is that their sub projects shouldn't be
released all at the same time. They are individual projects and should
have their own release cycles, much like our shared components or plugins.
I agree for doxia-tools. Doxia and doxia-sitetools are closer coupled
though, I think they should be released together. Maybe the
doxia-maven-plugin should go into sitetools, and the book into tools?
Also I'd like to move maven-doxia-tools from shared over to Doxia. Given
its description
"Assists in using Doxia for site generation and report creation."
Don't know where you got that from, the current pom [1] says "A
collection of tools to help the integration of Doxia in Maven plugins."
I think we also talked about renaming it to 'doxia-integration-tools'
which sounds more descriptive.
[1]
http://svn.apache.org/viewvc/maven/shared/trunk/maven-doxia-tools/pom.xml?revision=1214494&view=markup
I think that Sitetools would be a good home for it.
Sounds reasonable.
Also the doxia-test-docs should move somewhere else.
What are those? They look like they could be the basis of an IT suite.
Perhaps it should be a completely separate project under the Doxia umbrella?
It's not a project actually, just a collection of test resources. They
were originally added to check the correctness of the XSDs, see this
mail thread:
http://mail-archives.apache.org/mod_mbox/maven-doxia-dev/200812.mbox/%3C493D50DF.3040705%40udo.edu%3E
It's currently used by xdoc and fml modules, however, I'm not sure of
the usefulness, see eg my comment in
XdocValidatorTest#testValidateFiles. IMO the validation test would be
useful if it tested either a new xsd against the old test files, or some
new test files (created by a new doxia module) against the existing xsd.
But currently the test takes the old test files (from test-docs) and
validates it with the established xsds (fml-1.0-1, xdoc-2.2), so I don't
see the point.
Just some thoughts, unfortunately I don't have time right now to help
with any 'real' work...
-Lukas
-Lukas
Hervé BOUTEMY wrote:
while working on the relations between components, I finally found why
there
was something I didn't understand for a long time about Doxia suite
structure:
Doxia base contains book support through a plugin, but Doxia base doesn't
contain documents support -- it's Doxia Sitetools.
So we have a circular dependency:
doxia-maven-plugin (from Doxia base) -> maven-doxia-tools ->
Doxia-decoration-
model (from Doxia SiteTools) -> Doxia base (xhtml, fo and itext)
IMHO, doxia-book and doxia-maven-plugin should move to Doxia Sitetools
[1].
This won't change the artifacts coordinate, so won't change anything for
users.
But this should help when explaining Doxia suite structure, which has
been
difficult for a long time, and having a consequence on versioning
decision:
should we keep base and Sitetools version at the same level or not?
Any objection? Did I miss something?
Regards,
Hervé
[1] http://maven.apache.org/doxia/doxia-sitetools/index.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
