Does it make sense to call for an official Apache vote on how to proceed ? And if I summarize all discussed options correctly we would roughly have 3 options :
1) quit Apache incubator and move over to something like GitHub 2) graduate with 2.8 and gradually improve 3) graduate with 3.0 (continue the current 4-year long journey) Right? regards, Harry 2012/1/10 Juan Pablo Santos Rodríguez <juanpablo.san...@gmail.com> > Hello Frank, > > I was just writting pretty much the same thing. It seems that we have two > possible paths towards graduation/development of JSPWiki itself: > > Option A - graduate 2.8 branch: > 1.- 2.8.5: release current 2.8 as 2.8.5, graduate with it > > 2.- 2.8.6: rename packages to org.apache.wiki + fix failing unit tests > > 3.- 2.8.7?: bug fixes > > 4.- 2.9: in parallel with former point; goals: > + improve project documentation > + refactor code in order to ease the initial jump-in, possibly splitting > the code into sub-modules, i.e.: jspwiki-plugins, jspwiki-providers, > jspwiki-filters, jspwiki-workflow, jspwiki-engine and so on. Most probably > means breaking current API, but we would gain simpler, specific APIs > (plugin-api, workflow-api, etc) I have some ideas here, but I think it's > better to discuss this when we reach here. > > 5.- 2.10/3.0: or the new things happen here - retrieve from community what > should we do next > + see how to plug stripes + priha JCR provider work from trunk, at least > as modules that could be plugged in. A lot of work has been made in these > areas in current trunk and I think it's a pity just throwing out them. > Also, both frameworks were chosen because they were meant to simplify the > API, and the pluggability of JSPWiki within other systems.. > + multiwiki support > + enhancements noted by Frank (usb installation, search enhancements) > + the idea is to select a few, develop them, release a new version, > select a few more, etc. > + again, we should discuss this when reaching here > > > pros: seems more community-like, faster graduation, small, incremental > steps > > cons: JSPWIKI-382 (remove posteditor.js as it's license is unclear). > Regarding this point, last week I managed to reach posteditor author, > Daniel Mota, to ask him if he could clarify the license. He didn't knew > about JSPWiki, and he was happy to know that his work was being used, so he > said that as soon as he comes back from his holidays he would explicitly > state the license (MIT-license) at the library page, so we could graduate > and use his library. By the way, one question to our mentors: do we have to > wait this explicit statement in order to graduate? > > > Option B - graduate from current trunk (3.0): > 1.- fix at least JSPWIKI-713 and JSPWIKI-714 (and probably others) in order > to release 3.0.0-alpha > > 2.- graduate from 3.0.0-alpha > > 3.- refactor + improve documentation (same as former point 4) + bug fixes > > 4.- release 3.0.0 > > pros: LOT of work made here > cons: slower pace in order to reach graduation and 3.0.0 final > > Seems that option A is more feasible and will have more community support > but, as always, other opinions? Am I missing something? Let's call for vote > in order to decide which path should we follow to reach graduation. > > > regards, > jp > > > On Tue, Jan 10, 2012 at 11:22 PM, Frank Fischer <fr...@jcpsim.org> wrote: > > > On 01/10/2012 08:49 PM, Jürgen Weber wrote: > > > >> On Wed, Jan 4, 2012 at 11:59 AM, Florian Holeczek<flor...@holeczek.de> > >> wrote: > >> > >> Our community likes the 2.8 series for its stability and simplicity. > >>> Therefore, maintaining the 2.8 branch at least for a longer while is > >>> something that really makes sense. > >>> > >> 2.8 is great. It's a reliable work-horse. I like the file based storage. > >> > >> Why not take the radical step, throw the 3.0 branch away, go on with > >> 2.8 and make it Apache-ready? I never understood, why a wiki, where > >> the wiki engine does the gui, would need a web framework. It should > >> suffice to refactor 2.8 to use a controller servlet. > >> > >> And reread Joel Spolsky: Things You Should Never Do > >> http://www.joelonsoftware.com/**articles/fog0000000069.html< > http://www.joelonsoftware.com/articles/fog0000000069.html> > >> > >> 8-) Juergen > >> > > > > Just my thoughts. 2.8 works great and waiting for 3.0 > > to work was very frustrating. Why not restart with 2.8 > > and let it involve to a better (3.0 like in the end?) system. > > > > What might be done (with not too much effort): > > > > - Provide a (better) interface for data storage > > + that allows for metadata (parent page ...) > > + that decouples the page name from the > > capabilities of the file system (special > > characters, upper/lower case, length) > > A file based data storage should be the default > > connection to that interface > > (simple, easy to debug, no external dependencies, > > the user has access to the data without problems). > > > > What needs to be considered is under which > > 'identifier' (file name) a page should be stored. > > The page name as it is used now can to trouble > > ('Main' and 'main' considered the same under > > Windows, ...). > > > > One solution would be a filtered, human > > readable page name as a (natural) identifier > > (just like the suboptimal one that is in use now - > > xwiki by the way is nor happy at all if there is a > > dot - '.' - in the page name). > > > > Just an idea: > > - a TimeUUID is used as (surrogate) identifier and its string > > representation as file name (disadvantage: the > > user has to search in the metadata for the page > > name to find the file) > > - the file itself is a serialised JSON that contains > > metadata and contents - like: > > { "name":"Main", "author":"me", "contents":"bla bla" ... } > > - there are many ways to represent history and > > attachments with this scenario - not easy to find > > 'the right one'. > > > > - Simplify things / remove unnecessary options > > + is there really a need for other character > > sets as Unicode? > > + . . . > > + . . . > > > > - Many developers have already (and seperately) > > addressed some common needs - but nothing > > has happend to 2.8 because all (including myself) > > did wait for 3.0 to come (whose development was > > too complex for me to follow): > > > > + Provide an option for simple installation > > (on an USB stick). > > > > + Include attachments in the search algorithm. > > > > + Archives - a way to transfer pages and > > attachments from one installation to another. > > > > + Search within attachments (TIKA) > > > > + . . . > > > > All should be doable in small steps. > > > > But i see two big problems: > > > > - The 2.8 API is somewhat chaotic > > (example: try to collect all source code > > fragments that deal with the search > > function). > > Some refactoring in small steps might be > > a (very) good idea but it would continuously > > break the many private addones that have > > been developed. > > > > - Who shall decide what shall be done? > > Janne like most of us does not seem to > > have that much spare time. > > > > A voting system? (an authorised developer > > presents a relevant compatibility breaking > > update and if after one week there are more > > or equal '+1' than '-1' he can do what he wants). > > > > Or GIT-like branching and the developers decide > > every few months what should be merged to > > the trunk? > > > > I have no idea > > (sorry for the long post) > > > > Frank Fischer > > >
