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 -1 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. +0 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 > https://issues.apache.org/jira/browse/JSPWIKI-38 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. +1 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. Regards Florian
smime.p7s
Description: S/MIME Cryptographic Signature
