incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Devin Han <>
Subject Re: Let's discussion on the next release
Date Tue, 17 Jan 2012 03:31:57 GMT
2012/1/17 Rob Weir <>

> On Mon, Jan 16, 2012 at 4:02 PM, Dave Fisher <>
> wrote:
> >
> > On Jan 16, 2012, at 11:54 AM, Rob Weir wrote:
> >
> >> On Mon, Jan 16, 2012 at 8:12 AM, Devin Han <> 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:
> >>
> >>
> >>
> >>> (5) bug fix.
> >>>
> >>
> >> Always ;-)
> >>
> >>
> >> I wonder, also:
> >>
> >> (6) We have the demo applications build using the ODF Toolkit Simple
> API:
> >>
> >>
> >>
> >> 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:
> 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?

Rob, you are so generous, even be willing to share our secret weapon
Yes, we can share 3 tools, not only cookbook generator. As your guys may
know, ODF Toolkit is lack of contributor all the time,
so we have to make everything automaticly as soon as possible.

1)cookbook generator
A very simple and cool tool. The editor just need to write java code and
add what you want to explain as javadoc.
  There are some special signals to mark these content. Now, the output
files is html and we have plan to support odf formats.
  see this snippet:
//#page{Manipulate Table}
// This <a href="">Table</a> API supports to manipulate tables in text and
spreadsheet documents. It covers the table definition in <a href="">ODF
Specification 1.2 Committee Draft05</a>
public class CreateTable {
   public void createTableSample() throws Exception {
       //#section{Create Table}
            String filePath="unsatisfied.odt";
       //#para{Let's create an empty table first.By default,the code below
create a table with 5 columns and 2 rows.}
            TextDocument document = TextDocument.newTextDocument();
            Table table1 = Table.newTable(document);
       //#para{If you want to create table with specified column and
row,you can do like this:}
            int row=4;
            int column=3;
            Table table2=Table.newTable(document, row, column);

       //If you want to put some numbers into a table while creating it,
you can use the constructor Table.newTable(document,rowlabels,columnlabels,
       //which you should specify a 2 dimension array as the data and 2
String arrays as table labels,one for row and the other for column.

The output file is here:

2) code compare tool
We always need to supply API change list when announce a new version, just
like this:
This tool is used to generate the draft to avoid omit. Its output looks
like following:
Package : org.odftoolkit.odfdom.pkg
  Class : OdfPackage
    --OdfPackageDocument  loadPackageDocument(String)
    ++OdfPackageDocument  loadDocument(String)

    ++ErrorHandler  getErrorHandler()
    ++void  setErrorHandler(ErrorHandler)

  Class : OdfPackageDocument
    --void  removeEmbeddedDocument(String)
    ++void  removeDocument(String)

  Class : ZipHelper
    --Map  entries()
    ++String  entriesToMap(Map)

 +Class : OdfValidationException
 +Class : ValidationConstraint

"+" means new class is added, while "++" means new method added
"-" means class is removed, while "--" means method removed.

3) downloads sumary tool.
Just like all of the other project, we are care of the downloads count.
When we were in ODF Toolkit union, there was a download page recorded this,
see: But we
have too many versions and not only one subproject, addtionaly we supply
another download source apache extra(
So, very difficult to know the downloads status.
Then we develop this simple tool, access these page automatically, get the
numbers and generate a clear report in odf spreadsheet document. If you
like, you can also get a odf text document report with charts!
Now, I can drink tea while waiting for the tool give me a beautiful report

That's all. Anybody who are interested in these tool, please reply this
mail. I am willing to share more.

> 2) The "demos",  These are full programs that demonstrates the use of
> the ODF Toolkit in context.
> 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
> >


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