incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Svante Schubert <>
Subject Re: Source code checked in, what next?
Date Mon, 19 Sep 2011 22:53:52 GMT
Am 20.09.2011 00:06, schrieb Rob Weir:
> On Mon, Sep 19, 2011 at 5:13 PM, Svante Schubert
> <> wrote:
>> Hi Nick,
>> Am 19.09.2011 22:13, schrieb Nick Burch:
>>> On Mon, 19 Sep 2011, Svante Schubert wrote:
>>>> I would favor to do a quick release without new features. Allowing us
>>>> to focus on adapting the new Apache processes and to setup the
>>>> required documentation.
>>> This is a sensible course of action, get the first release out soon
>>> (so you get the procedures in place and everything setup), then
>>> concentrate on shiny new features :)
>>>> I assume when we do an Apache release we need to change the Java package
>>>> names as well from to What are the Apache
>>>> rules here?
>>> I'd suggest a quick check on general@incubator to see what most others
>>> have done. I know of some who've made the switch ASAP, others who
>>> waited for the next major release (they did a minor release after
>>> starting incubation to get the processes right and the IP stuff
>>> sorted, but without changing APIs). Probably best see what the
>>> majority do.
>> If there is no strict Apache rule to change the package name, I would
>> love to keep it to cause as less distress for existing users as possible.
>>> (My hunch is that the best bet is to do a minor release without the
>>> change, to minimise the work on the first release, then shortly after
>>> do a major release with the change, but it's worth checking what
>>> others have found to work well)
>>>> As we know that we will be using JDK 6 for the next encryption and
>>>> signature update, we should save time by dropping the tests for EOL JDK
>>>> 5, switch now to JDK 6 and adapt the pom.xml(s) accordingly.
>>> FWIW, Tika is still on 1.5, so if ODFToolkit required 1.6 then we
>>> couldn't use it
>>> That said, if the odf community is keen, then ignore Tika and upgrade!
>>> Probably best to roll that into the release which changes the packaging
>> "Never change a running system" comes to my mind, when I hear about the
>> current usage JDK 5.
>> What is Tika's reason to stick with JDK5?
>> The usage can not be related to security as the latest public available
>> security update was 22 months ago and there will be no further update,
>> may the possible security risk be arbitrary high.
>> ODFDOM's reason to use JDK 6 is its need for the ODF package encryption
>> & signature feature and even JDK 7 comes along with improved ZIP access
>> of NIO2, therefore I will from my current point of view I will vote to
>> switch to JDK in July 2012 when JDK 6 is EOL.
> The encryption/digital signature stuff has not been checked in yet.
> So we don't need to go to Java 6 for the initial release.  But no
> objection if we want to.  But we can wait a little longer if we want.
Again, not to switch JDK to a newer version means higher efforts for the
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.
> 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
  * 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
    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
    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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message