Hi!
I didn't much think of the organization, I just needed a place to
share the stuff where it wouldn't mess up the current org.
I think it's a good idea to move the current structure to /legacy/
or /import/ once we get 2.8 out and start working on 3.0 and make the
transition. I would imagine that in that case the .api package would
move under /trunk (with a special ant task to build the jspwiki-
api.jar). Perhaps /trunk/src/api/ or /trunk/src/
Oops, forgot the licenses. Will add them, thanks!
/Janne
On Jul 10, 2008, at 19:22 , Craig L Russell wrote:
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!
