If I understand what you're saying "2.10.x would be the place for that", that means you're in agreement with Ichiro, it's just you would like to postpone this change until 2.10.x, correct? Perhaps the additional time to make sure the change is well thought through would be good anyway.

JSPWiki already has a build requirement of JDK 5.0 (http://incubator.apache.org/jspwiki/development/building.html) so I'm not sure a need to support pre-5.0 versions (i.e., no generics) is all that important. OTOH, with the proposed change, would that mean all/most of these plugins: http://www.jspwiki.org/wiki/ContributedPlugins would have to be rewritten? (Or is that already the case due to the classnames being changed to org.apache.xxx?)

Glen


On 11/04/2012 04:19 PM, Juan Pablo Santos Rodríguez wrote:
Hi Ichiro,

com.ecyrd.jspwiki namespace is also a default valid plugin namespace for
2.9.x, it is
translated into org.apache.jspwiki at
org.apache.wiki.utilClassUtil#findClass (this was
part of https://issues.apache.org/jira/browse/JSPWIKI-719).

The <K,V> is just to ensure that older, ungenerified, plugins can remain
compatible with
current trunk, while also allowing something like:

MyPlugin implements WikiPlugin<String, Object>

and therefore getting the typed Map at execute(..). I'm not very fond of
introducing the
<String, Object> change b/c of the compatibility issue, (in 2.9.x, 2.10.x
would be
the place for that) but maybe I'm being over-conservative here. So, other
thoughts from
anyone else (specially plugin devs)?


cheers,
jp


On Sun, Nov 4, 2012 at 9:39 PM, Ichiro Furusato
<[email protected]>wrote:

Hi Juan Pablo,

Given that the package name of all plugins is required to change from
com.ecyrd.jspwiki
to org.apache.wiki, anyone with existing plugins is going to have to
fix and recompile them
for compatibility anyway, so it's a good time to force generics into the
API.

I'm not sure why you'd suggest

    public String execute( WikiContext context, Map<K,V> params )
          throws PluginException;

as the method signature, as I believe we'd want to constrain K to
String and V to any
Object, so I'd advocate for Map<String,Object> myself (and all of my
plugins would
conform with that simple change). Perhaps you have a reasons I don't
understand.

I've taken over the CeryleWikiPlugin set and while I'm not going to
commit to upgrading
the entire set, I'm willing to release most of them, depending on my
time constraints.
Some of rather obscure, but a number are pretty handy (such as the user
tagging
system).

Cheers,

Ichiro

On Mon, Nov 5, 2012 at 8:31 AM, Juan Pablo Santos Rodríguez
<[email protected]> wrote:
Hi Ichiro,

in fact, PluginManager#parseArgs builds a HashMap<String, Object> but
returns an
ungenerified Map, most probably because this way binary compatibility
with
older,
ungenerified plugins is ensured. Besides, as the plugin system hasn't had
any issues
since a long long time, the focus had been put elsewhere.

But yes, aside from the compatibility issue, constraining to <String,
Object> makes
sense to me, as most probably this is how the Map is used by everyone
(anyone not
doing this way please correct me).

hmm right now I'm thinking that WikiPlugin's signature could be changed
to
something like:

public interface WikiPlugin <K, V> {
     public String execute( WikiContext context, Map<K,V> params ) throws
PluginException;
}

so you could override the Map types on your plugins. Makes sense?


br,
juan pablo

On Sat, Nov 3, 2012 at 10:23 AM, Ichiro Furusato
<[email protected]>wrote:

Hi,

In looking at the 2.9.0 code I note that it doesn't use generics in a
number of
rather key places, such as WikiPlugin.execute(), so I'm guessing it
hasn't
been updated in a few years (at least in that regard), perhaps due to
the
somewhat longstanding status of the project going into Apache, or for
legacy-
compatibility reasons.

Could someone please fill me in as to any particular reason why the Map
argument couldn't be constrained to <String,String> or <String,Object>?
I've
got quite a few plugins that are now incompatible with a generics-less
WikiPlugin API, i.e.,

         public String execute( WikiContext context, Map<String,Object>
params ) throws PluginException;

...and rather than remove all my generics I'm wondering if it'd be
possible
to update the API. Yes, I know that is a brash assumption.

Thanks much,

Ichiro

Reply via email to