incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: Source code checked in, what next?
Date Tue, 20 Sep 2011 00:02:48 GMT
On Mon, Sep 19, 2011 at 6:53 PM, Svante Schubert
<> wrote:


> Again, not to switch JDK to a newer version means higher efforts for the
> developers.
> If IBM is willing to put extra efforts in supporting JDK 5, which is
> outdated since 22 months this is fine for me, but I am not interested in
> spending extra time on JDK5 support.

I'm only talking about the initial release.  We already know that
Devin's encryption will require Java 6 when that is integrated.  I
assume our code works fine with Java 6 already, right?  So we're
really just talking about when we drop Java 5 support.  Maybe we can
announce the intent to drop Java 5 in the release notes of our first
release, and then actually drop support in the following release?

>> What are the Maven implications for combining the projects?  Do we
>> want to enable Maven for the XSLT-Runner/Task and the
>> Validator/Servlet?  Do we want to combine to a single POM for the
>> entire toolkit?  Or have separate components, as well as a high level
>> task to combine them all into a tar/zip for release?
> Going through our root source directories
> <> in alphabetic order:
>  * generator
>    Our ODFDOM source code generator.
>    Based on two open source tools
>     1. Multi Schema Validator (MSV) - to read arbitrary XML schema into
>        a common model &
>     2. Apache Velocity - template engine to allow to fill arbitrary
>        templates from the schema date.
>    For instance the project might be used to create HTML based
>    documentation about the schema, see prototype
>    <>.
>    When we have enhanced the project a little more, to be not so ODF
>    centric, we might be able to move it to a more general XML project,
>    perhaps Apache XML Commons.
>    Imagine to have this tool to put in any arbitrary schema, and a
>    documentation and typed DOM tree will be generated. We could use it
>    to generate SVG and MathML support for ODFDOM.
>  * legal
>    Why do we need a directory? Are not those both files LICENSE and
>    NOTICE usually in the root directory?
>    I would suggest to neglect the directory, moving those file a level
>    higher.
>  * odfdom
>    The long-term goal ist to split up the existing odfdom project into
>    a ODF package project and ODF XML project similar to the ODF 1.2
>    specification.
>    This should happen, because not every user of the ODF Package will
>    be in need of the ODF XML. The split up will ease the propagation of
>    the ODF package as a technology independent of the XML.
>    The XML part of the ODFDOM project on the other hand should be again
>    split up into the low-level XML part and the high-level component
>    part (e.g. ODFDOM DOC API package or Simple API).  It should be
>    possible to switch from a high-level to the low-level part and
>    vice-versa, even if it is costly.
>  * old-generator
>    No need for nostalgia here, we should remove it from our trunc.
>  * simple
>    Will be merged with ODFDOM (see above).
>  * taglets (part of JDK, see Taglet Overview
>    <>)
>    A JavaDoc helper of ODFDOM. Being used to provide references to the
>    ODF specification from the OFDDOM JavaDoc. As it only belongs to
>    ODFDOM, I would love to move it beyond it, but I have not figured
>    out any way to do this in Maven.
>    Any help appreciated.
>  * validator
>    Should be kept as it is for now, on long term replaced by ODFDOM.
>    Was updated to use Maven, yesterday. See feature mail
>    <>.
>  * 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?

>    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.


> Regards,
> Svante

View raw message