For what it's worth (I am not involved in development of JspWiki 3.0 or 2.8)
I would chose option 2) because I like the fact that is it very simple to use
and setup with
The file based page store and it runs nicely from a thumbdrive under Resin or
Tomcat as a personal
Mobile wiki.
Regards, Andre
-----Original Message-----
From: Harry Metske [mailto:[email protected]]
Sent: donderdag 12 januari 2012 20:00
To: [email protected]
Subject: Re: Throw away 3.0 Re: JSPWiki & Apache Incubation?
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 <[email protected]>
> 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 <[email protected]> wrote:
>
> > On 01/10/2012 08:49 PM, Jürgen Weber wrote:
> >
> >> On Wed, Jan 4, 2012 at 11:59 AM, Florian
> >> Holeczek<[email protected]>
> >> 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
> >
>
