incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Holeczek <>
Subject Re: Vote requested: package renaming
Date Tue, 30 Dec 2008 18:02:00 GMT
Hi all,

> ITEM 1.
> Immediate renaming of all packages from com.ecyrd.jspwiki to
> org.apache.jspwiki, so that we can move to release an early alpha
> Apache build.

> Details: This would cause all packages currently named
> com.ecyrd.jspwiki to be renamed to org.apache.jspwiki

At the moment. I thought there was a consensus on waiting until
Stripes as well as JCR branches are merged with the trunk.

> ITEM 2.
> Refactoring concrete classes (e.g., WikiEngine) into interfaces
> whenever possible, and supplementing them with factory interfaces if
> warranted (e.g., interface WikiEngineFactory).

> Details: For those of you who use Eclipse, this is similar to an
> "Extract interface" refactoring step, where concrete classes like
> WikiEngine are turned into interfaces that are meant to be stable. The
> concrete class WikiEngine would be renamed to something like
> DefaultWikiEngine.

This may be useful in some situations (and then should be done of
course), but isn't a solution for the API problem IMO.

> ITEM 3.
> Creation of the .api package/package tree, and creation of various
> types in this package/package tree (e.g., WikiEngine, WikiPage) for
> stable interfaces.

> Details: The org.apache.jspwiki.api package has been proposed by Janne
> (and partially implemented) as a dedicated package tree where stable
> interfaces would live, separate from the existing com.ecyrd.jspwiki
> and future org.apache.jspwiki package trees. See the debate at
> for details. This is
> essentially a retroactive vote: majority approval would commit us to
> this direction; majority disapproval would cause contents of the .api
> package to be reincorporated into the existing tree.

I think this is a good approach and even don't see any problems in the
depth of org.apache.jspwiki.api. Normally, one does import it once per
class and then continues using the class/interface names.


View raw message