On Mon, Sep 19, 2011 at 5:13 PM, Svante Schubert <[email protected]> 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 odftoolkit.org to apache.org. 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? -Rob > Kind regards, > Svante > > >
