incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: JSPWiki API first proposal in SVN
Date Thu, 10 Jul 2008 16:22:34 GMT
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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message