incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christophe Dupriez <>
Subject Re: Vote requested: package renaming
Date Tue, 30 Dec 2008 17:18:13 GMT
Item 1: +1

Item 2: +0 because I cannot agree with interfaces for the sake of interfaces. (You write "whenever
possible": I would prefer "whenever needed").
           May be I am an "oldtimer" but I see more benefits to good subclassing architecture
than interfaces+implementations.

           Interfaces are a "contractual" tool (as I understand what Jane explained) by which
we engage to not change without very strong reason (and to provide upgrade paths!)
           Reason why I approve the idea of separating what is within (you modify at your
own risk, no tears afterward) and what is exposed outside (upgrade paths promised...)
           Except if interfaces for "inside" classes are needed for implementation reason,
I do not see why we would bother to create them.

Item 3: +1 Designing exposed interfaces would allow to clarify JspWiki architecture and make
it always more flexible for integration...
           To package them separately makes clear they are "exposed" for a longer term...
           Subdirectories by "integration mode" are also welcome (plugins for instance).

Good evening!


Andrew Jaquith a écrit :
> Most of you have probably been following the debate on package
> renaming, and the associated creation of a separate .api package --
> with bated breath I'm sure. It's time to get a consensus from the
> group about the direction to proceed.
> I ask the group for three votes:
> 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
> Recommendation: I vote +1 for this item, and recommend the same to the group.
> 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.
> Recommendation: I vote +1 for this item, and recommend the same to the group.
> 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.
> Recommendation: I vote -1 (veto) for this item. I prefer the status
> quo, to keep stable interfaces in the existing package tree.
> Summary of my votes here:
> Item 1: +1
> Item 2: +1
> Item 3: -1

  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message