incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juan Pablo Santos Rodríguez <>
Subject Re: Throw away 3.0 Re: JSPWiki & Apache Incubation?
Date Tue, 10 Jan 2012 22:59:50 GMT
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 + 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

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.


On Tue, Jan 10, 2012 at 11:22 PM, Frank Fischer <> wrote:

> On 01/10/2012 08:49 PM, Jürgen Weber wrote:
>> On Wed, Jan 4, 2012 at 11:59 AM, Florian Holeczek<>
>>  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
>> 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

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