On Mon, Jan 16, 2012 at 4:02 PM, Dave Fisher <[email protected]> wrote: > > On Jan 16, 2012, at 11:54 AM, Rob Weir wrote: > >> On Mon, Jan 16, 2012 at 8:12 AM, Devin Han <[email protected]> wrote: >>> Hi all, >>> >>> Thanks you for the contribution of the the first release! Now the plan of >>> the next release is on the desktop. >>> I summary some todo items and wish to get your guys' feedback. >>> >>> (1) Clear crypto process with Apache. >>> (2) Commit encryption/decryption code to the master repository. >> >> These two need to be done together, at the same time. >> >>> (3) Update package name from "org.odftoolkit.*" to >>> "org.apache.odftoolkit.*". >>> (4) Remove ODFDOM Doc API which has been marked as deprecated in the first >>> release. >> >> These two are "breaking changes" So we will want to do them together, >> IMHO. Better to pull the bandage off quickly and get the pain over >> with, I think. >> >> Another change we should make at the same time: >> >> 5) Update ODF schema to the final ODF 1.2 schemas, which were >> published last week: >> >> http://lists.oasis-open.org/archives/tc-announce/201201/msg00001.html >> >>> (5) bug fix. >>> >> >> Always ;-) >> >> >> I wonder, also: >> >> (6) We have the demo applications build using the ODF Toolkit Simple API: >> >> http://incubator.apache.org/odftoolkit/simple/demo/index.html >> >> These are very good demos, I think. But we make it hard for the >> project to update or improve them, since the source code is in ZIP >> files on the website. So they will break when we do the package >> rename. Maybe we want to move these samples into SVN, in a "demo" or >> "samples" directory, with their own POM, maybe an assembly if we want >> to build each one individually and then bundle them together into a >> "samples" release package. > > I think that a "samples", "demo" or "examples" tree is a good idea. One could > argue that it is a graduation requirement. > > In Apache POI the maven artifact id is - poi-examples and it one of the jar > files in the binary distribution and part of the source distribution. > > Having a page or folder in the website with the examples is a good idea. >
We have the website with the examples. Two kinds: 1) A "cookbook" with what some would call "snippets". So not full programs but enough code to demonstrate some common patterns of use: http://incubator.apache.org/odftoolkit/simple/document/cookbook/Manipulate%20TextSearch.html Since these are not complete classes (or even functions) they won't compile and probably should not be in a normal project with a POM and everything. This is the bane of every tech publisher -- how to verify that these code fragments are correct, and how to ensure they stay updated as our libraries evolve. Devin -- I thought you had some magic that helped here? Is that something we can contribute to Apache? 2) The "demos", These are full programs that demonstrates the use of the ODF Toolkit in context. http://incubator.apache.org/odftoolkit/simple/demo/index.html The issue here is the demos are each made available as their own ZIP, and they have not gone through the release process. I like the idea of unzipping them into SVN and build a "examples" package from them, for inclusion in a future release. And since any package refactoring will require that we update the demos at the same time, it makes sense to do them both for the next release. > Regards, > Dave > > >> >> (7) Many of the bugs we get reported are related to >> multithreading/concurrent use of the API. It would be great if we >> could find some automated way of testing this. All our unit tests are >> single threaded. Ditto for our samples. So we're not effectively >> testing this aspect of the code. Maybe they do something interesting >> with POI? >> >> Anyone have any other ideas for features for the next release? >> >>> -- >>> -Devin >
