incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olaf Kock <ok...@abstrakt.de>
Subject Re: package names (was Re: PLEASE READ: package names, trademarks and legal advice)
Date Thu, 24 Jan 2008 12:27:08 GMT
Janne Jalkanen schrieb:
>> Given that the plugin path has to be specified in jspwiki.properties,
>> *in theory* the existing plugins could still function if their earlier
>> (i.e., current) paths were added to the list. That's a reasonable interim
> 
> Nope, since even WikiContext would no longer be in com.ecyrd.jspwiki 
> -package, so the WikiPlugin.execute() signature would be incorrect.  So 
> it would be a total breakage.

Hi,

It's been a long time since I laid my hands on JSPWiki Code, so I don't 
know how viable this is. (Provided one really cares for compatibility of 
old plugins without much work on behalf of the plugin authors):

What about providing a "compatibility" layer, e.g. moving WikiContext to 
org.apache.*, together with all code and then provide an empty subclass 
that plugins can rely on. If not subclass, maybe some org.jspwiki.* 
classes that are solely delegating to org.apache.* classes could 
suffice? This would not provide 100% backwards compatibility but may 
ease transition (e.g. instantiating object instances could reveal some 
problems).

As Terry said, too much breakage would reveal some amount of 
frustration. Though I believe the frustration is among developers, not 
users, and developers should be able to handle this better than users - 
adapting to the ever changing world is part of my daily business at least.

Another thought would be a somehow aided migration path: Provide old 
(empty) API classes (in source code) that simply inherit from 
org.apache.* classes (as said above). These are copied into the 3rd 
party plugin dev environment. Then use your favorite IDE to replace 
usage of the org.jspwiki.* class with it's subclass and delete the 
org.jspwiki classes just added to the project. This would have to be 
done in the context (and dev environment) of all plugins that are 
upgrading to org.apache.* code.

Does this communicate the idea?

Of course all this would ease the work of 3rd party plugin developers at 
the cost of JSPWiki core developers. If only few (3rd party) authors 
care for this, I'd rather help them port their plugins one by one...

Please comment,
Cheers,
Olaf

Mime
View raw message