Hi Janne, I have a meta-comment on the proposal.
It seems that the code currently in trunk is legacy code with the legacy package names now updated with Apache licenses.
Going forward, trunk will presumably become the working set of the implementation using the shiny new org.apache package names.
It might be useful to make a clean break with the past at the point where the package names change. Perhaps by svn move incubator/jspwiki/ trunk to incubator/jspwiki/legacy. And then trunk would be the repository for all things org.apache.
Looking at the api, relative to the implementation, consider whether the api is something that will evolve completely independent of the implementation. If it is independent, perhaps it does deserve to live at the top level of the repository (incubator/jspwiki/api). But if it does evolve, it needs its own trunk, branches, tags, etc. underneath it.
However, if the API is intended to have releases that correspond to the implementation perhaps api should be underneath trunk (incubator/ jspwiki/trunk/api) and parallel to the other sub-projects (incubator/ jspwiki/trunk/engine).
I'm not going to recommend anything or push in a direction, just ask questions to help clarify how to organize things for the future.
Craig P.S. most of the .java files in api are missing a license On Jul 1, 2008, at 12:20 PM, Janne Jalkanen wrote:
Folks,I drafted some Java code for the JSPWiki API. You can check it out from SVN (or browse) at http://svn.apache.org/repos/asf/incubator/jspwiki/api/Feel free to comment and bang at it - it's supposed to be "the stable API".I essentially just took some of the most core extension classes that we have, and created a new api package. I know there's a lot missing, and there's also some extra crud that shouldn't be there. We'll also have to think about the integration to JCR and Stripes - but if possible, I think those dependencies should be kept to a minimum. Currently there are no extra libraries referenced in the API classes, which I think is great - but obviously it would be really nice for a developer to gain access to those classes as well.I also started of with only the most common usecases, and forgot about authentication and URL construction and rendering for a while.This is in NO way final. The design goals are to give an easy, recognizable, easily portable API (hopefully with just a package change when compared to old versions) to JSPWiki with as few external (=non-JDK) dependencies as possible. Especially I would like to hear from guys like Murray who've been poking at the plugin interface far more extensively, what they would like to see, and whether this proposal is going to the right direction./Janne
Craig L Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
