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 Mon, 19 Sep 2011 22:06:39 GMT
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.

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?


> Kind regards,
> Svante

View raw message