incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "van Dalen, Andre" <andre.van.da...@atos.net>
Subject RE: Throw away 3.0 Re: JSPWiki & Apache Incubation?
Date Mon, 16 Jan 2012 09:25:51 GMT
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:harry.metske@gmail.com] 
Sent: donderdag 12 januari 2012 20:00
To: jspwiki-dev@incubator.apache.org
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 <juanpablo.santos@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 <frank@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<florian@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
> >
>
Mime
View raw message