incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Svante Schubert <svante.schub...@gmail.com>
Subject Re: Source code checked in, what next?
Date Tue, 20 Sep 2011 09:58:30 GMT
Am 20.09.2011 02:02, schrieb Rob Weir:
> On Mon, Sep 19, 2011 at 6:53 PM, Svante Schubert
> <svante.schubert@gmail.com> wrote:
>
> <snip>
>
>
>  * xslt-runner
>    XSLT-Runner and Task might be both dropped completely when it is
>    guaranteed that ODFDOM is supporting the same feature set.
>  * xslt-runner-task
> I think the XSLT Runner code is useful because it targets a user with
> a different skill set.  The person who is productive with an XSLT
> transform might not be a Java programmer.  So even if we had similar
> functionality in ODFDOM, we'd still want an XSLT interface.
>
> Or are you suggesting something like a xlst-transform() method in the Java API?
The XSLT runner is just a command line call to a Java program, with the
XSLT as its parameter.
http://odftoolkit.org/projects/conformancetools/pages/ODFXSLTRunner

Instead of the XSLT runner, ODFDOM package should be callable giving the
same results with some little tweaks and additional tests.

And an extension for ANT to used it
http://odftoolkit.org/projects/conformancetools/pages/ODFXSLTRunnerTask

But than why is only the XSLT being supported and not the validator?
I would either drop ANT support in general or extend it to support the
validator and ODFDOM in general.
I would tend to support ANT and switch to ODFDOM and Validator support
dropping the XSLT-extension

>>    A ANT task to trigger XSLT-Runner. If XSLT-Runner becomes obsolete
>>    the same is valid for this project.
>>
>> If every directory is its own project, using Maven and delivering a
>> Maven artifact with a version number, accessing the others via
>> dependencies of their pom.xml, I see yet no benefit for an umbrella
>> pom.xml and when in doubt I tend to keep things as simple as possible.
>>
> I'm making a distinction between a component in a release.  I agree
> that we should have fine -rained components for independent layers of
> functionality.  Each component might have its own POM, its own
> directory, its own JAR.
>
> But since we are a single Apache project we should be aiming for a
> single release, the thing that is called "Apache ODF Toolkit" (or
> "Apache ODF" as you were suggesting) This would be two tarballs, one
> witth source, and another tarball for the binaries.  I believe we
> could still publish the individual JARs to Maven Central, but that
> would come after we approve a release.  And the Apache view of an
> "official" is the source (and optionally binary) tarballs.
>
> My question was how we want to manage building that combined release.
>
Sorry, I misunderstood your question and it makes perfectly sense.
We should investigate if it is possible to provide an umbrella pom.xml
to bundle various sources, binaries and / or JavaDoc.

That reminds me of an old idea and I am back to the naming question, why
not calling it the "Apache ODF SDK".
There is yet some glue code/documentation missing, but it would be a
stretch goal to work toward.

Especially the generated documentation
http://odftoolkit.org/downloads/odfdom/OpenDocument-v1.2-draft/OdfReference.html
would make perfectly sense to be integrated after it had been improved.
If there would be a Backus-Naur-Form for the occurrence of sibling, some
layout improvements and perhaps even a generated picture of the parent
with possible children it would be a great orientation for new ODF
developers.

Regards,
Svante

Mime
View raw message