Hi Devin, just my 0.05CHF:
IMO, separating logically different modules promotes cleaner and clearer dependencies. No accidental reference from ODFDOM into Simple API. Both APIs have a different sort of client. Some may not even need Simple at all. Lately doing a lot of OSGi I like smaller OSGi bundles (a bundle is basically a normal JAR with additional metadata). In the end, I think it's only a question of packaging. You could always create a combined JAR that contains both ODFDOM and Simple. Apache Batik, for example, provides both: multiple JARs for each module and a single "All-JAR". However, Batik has only a single, large source tree. That makes keeping dependencies clean a challenge. Apache FOP has a single source tree, too, but contains multiple modules that could easily be used outside the context of XSL-FO. Or an output format called AFP is used only by a minority of all FOP users but it takes up a large portion for fop.jar. Both project would profit from splitting up into modules. It also makes the source code less threatening to newbies, I believe. I believe it should also be possible to create a single Javadoc run for all subprojects. At least other projects I've seen seem to do that. As for naming (your question (1)): you could still have odfdom.jar, simple.jar and add odf-toolkit.jar containing everything. BTW, the ODF Toolkit website needs an overhaul to use the new Simple API. Even the first example on the front page uses deprecated API. BTW, since Simple API is a new API I'm kind of surprised that it doesn't use org.apache.odftoolkit.simple as package name. Since ODF Toolkit has a <1.0 version number, I'd be relatively quick to remove deprecated API. It makes finding your way around a little difficult as a newbie. Or maybe it is possible to move the old simple API to a separate legacy package to clean up ODFOM. HTH On 23.02.2012 09:30:46 Devin Han wrote: > Hi all, > > As you know we will remove the deprecated ODFDOM DOC layer and replace it > with Simple API in the 2nd release. After that, ODFDOM will focus on low > level dom/package layer, while Simple API focus on the high level > convenient API. That would be a good news for users. > > Now, I have a new idea that why not combine ODFDOM and Simple API together? > If we do that, the advantages are: > (1) The user only needs to download a single jar. Include to classpath > easily and no need to care about the version dependency between ODFDOM and > Simple API. > (2) ODFDOM and Simple API javadoc are together, user can find class, method > easily. > (3) People, who only use ODFDOM before, has a chance to use Simple API to > improve the efficiency. The jar of Simple API 0.7 is only 444.8 KB, would > not take too much space. > > The questions are: > (1) We need a new name for ODFDOM&Simple API. > (2) What's the new package name of Simple API? Inherit ODFDOM DOC Layer > name or change nothing? > > -- > -Devin Jeremias Maerki
