incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <Janne.Jalka...@ecyrd.com>
Subject Re: WikiPlugins and 3.0, was -> RE: Idea? Auto-update (Ecplise-like) mechanism for JSPWiki plugins.
Date Tue, 11 Nov 2008 06:14:15 GMT

Yes, plugins can be changed (everything is broken anyway) but nobody  
has been interested in providing any comments or design so far.  If  
you want to lead the discussion, go ahead!

(My hope is though that we can survive with rather a minimal set of  
changes as to encourage people to port their plugins to 3.0. Our  
plugin system is fairly stable and easy to understand - if there was  
anything I would change it would be that I would change the way  
parameters are transmitted.  A Map prevents for example multiple  
parameters of the same name, which is a bit painful.  But you guys do  
plugins more, so please start the discussion!)

Mediawiki (which is about 90% of the world's wiki installations) does  
not give a list of backlinks when clicking on the title.  Neither  
does TWiki, which probably accounts for a majority of the rest.   
Therefore the assertion about every other wiki engine is flat out  
wrong, and just shows that there is a bias towards a particular  
selection from the beginning.  (In fact, I think it is a clunky idea  
at best.  Our ReferringPagesPlugin is superior, since it can be  
embedded in the LeftMenu.)

Our default template could look better, I agree (and I am not too hot  
on the other skins on it either).  Unfortunately, we don't have any  
graphic designers in the team...  If a company out there would like  
to help JSPWiki, getting someone with a very good eye for loan for a  
while might be very nice... ;-)

/Janne

On 11 Nov 2008, at 03:22, Volkar, John M. wrote:

> Agreed Murray.
>
> I've not been following closely but it appears with 3.0 just around  
> the
> corner compatibility breaking changes are now possible.  For instance,
> plugins in general can be broken and changed.  For example, WikiPlugin
> could spout new *required* methods and have signature changes.
>
> Things like generics and annotations are now possible in 3.0 so  
> perhaps
> the time is ripe for significant change.
>
> Of course wholesale change just for change sake isn't a good idea, but
> really an opportunity for change like this doesn't happen very  
> often in
> a project's lifecycle (after all, I haven't heard anyone say anything
> about 4.0 ... yet <grin/>).
>
> Let me think on this some more and pull the code from svn (and get  
> back
> up to speed with svn, eclipse, etc... It's been too long.).  I'll  
> browse
> around and see about writing out some sort of proposal regarding  
> plugins
> and 3.0.  This should be given some thought by plugin developers and a
> wish list should be discussed.
>
> ----
> Unless of course current committer thinking is that this is an area
> where change isn't desired in 3.0?
>
> I see lots of talk about storage backends, UI front ends and other
> plumbing, but nothing systematic regarding plugins.  Is this viewed  
> as a
> fully satisfied niche of JSPWiki?  This seems ashamed because plugins
> represent a fairly simple way of bolting new functionality into  
> JSPWiki
> as a platform and the existing framework could be strengthened to make
> plugin development easier and more regular.  But then again, if it  
> ain't
> broke don't fix it is a good rule-of-thumb too.
>
> ----
> <aside>
> I'm ashamed to admit it, but I've had a recent experience where a  
> group
> of wiki users choose UseMod over JSPWiki because the JSPWiki UI was
> too-cluttered and complicated (quote: "and *why* doesn't the page  
> title
> give a list of backlinks like every other wiki in existence?").
> <head-shaking/> Just shows that not everyone can be happy; they  
> detested
> the default template, tried installing other templates and threw up
> their hands in disgust.  Anyway it just goes to show that there are
> different folks in the world.
> </aside>
>
>
>
> Regards,
> John Volkar
>
>
>
>
> -----Original Message-----
> From: Murray Altheim [mailto:murray07@altheim.com]
> Sent: Monday, November 10, 2008 4:58 PM
> To: jspwiki-dev@incubator.apache.org
> Subject: Re: Idea? Auto-update (Ecplise-like) mechanism for JSPWiki
> plugins.
>
> Volkar, John M. wrote:
>> Anyone give any thought to how sanctioned plugins could be hosted and
>> have a means for live running sites to auto-download and install
>> updates to them?
>>
>> If there were someway to do this, the annotations which are being
>> discussed could be used to query a plugin about its needs,
>> dependencies, etc.  This would have to be seriously thought thru, but
>> could be quite cool.
>
> Hi John,
>
>  From someone with a *lot* of plugins to deal with, the current system
> using jspwiki_module.xml is rather broken. It's too complicated,  
> and if
> one misses a file, or misses a plugin alias (i.e., a class used to
> shorten a name or move a plugin into a parent package), or includes in
> the XML configuration a plugin that isn't actually available, the  
> whole
> shebang comes apart. I've ended up removing all the XML files from my
> jar files since I couldn't get everything to reliably work.
>
> My feeling is that annotations might work fine if they permit each
> plugin and any of its aliases to function independently and not be  
> bound
> to packaging restraints; this is not to speak of actual code
> dependencies. I am wary of further complications though. If, for
> example, someone has available to them dozens of plugins, and has
> several sites using different combinations of plugins, whatever  
> approach
> is taken would hopefully be pretty seamless and not require  
> complicated
> combinations of configuration files or machinations in ant build  
> scripts
> as I've had to try, such as copying from a pool of jspwiki_module.xml
> files depending on configuration. A mess.
>
> I'm currently dealing with installs that include three or four jar
> files, sometimes with code dependencies across jars, and as I've
> mentioned before it's unclear about the order and priority of  
> processing
> when there are multiple XML configuration files.
>
> Murray
>
> ...................................................................... 
> ..
> ...
> Murray Altheim <murray07 at altheim.com>                           ===
> = =
> http://www.altheim.com/murray/                                     = =
> ===
> SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk               = =
> = =
>
>        Boundless wind and moon - the eye within eyes,
>        Inexhaustible heaven and earth - the light beyond light,
>        The willow dark, the flower bright - ten thousand houses,
>        Knock at any door - there's one who will respond.
>                                        -- The Blue Cliff Record


Mime
View raw message