[
https://issues.apache.org/jira/browse/JSPWIKI-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12802212#action_12802212
]
Murray Altheim commented on JSPWIKI-628:
----------------------------------------
I hope you can understand that if one considers that the vast majority of
installations are public sites, and even among those that are intranet
installations where security is *less* of a problem, there's still going to be
very few that opt to install this feature. So the concern of the development
group is not whether deployment is easy or awkward but rather possible. For
those who are capable of following directions, of copying jar files to
directories and altering configuration files, so long as there is documentation
and installation wouldn't require modification of and a recompile of the core
code, the status quo would be that core remains less complicated and more
secure. Having core code check for the existence of a specific plugin-related
jar file in order to activate a custom and rarely-used feature is not very
pretty. These are the kinds of hacks that create a lot of fragility in an
application. That kind of functionality should be in the plugin itself, or some
kind of bespoke utility that the plugin uses to manage files.
I've done some very extensive plugin development (e.g., I think over 60 so far,
including several managers that themselves use a dozen or so plugins) and some
have required configuration changes. But the JSPWiki 2.8.* API is significantly
flexible and allows a huge amount of variability in configurations. On those
rare occasions when I couldn't accomplish something, Janne was generous enough
to permit several modifications. The cascading properties feature and the
existing plugin manager provide everything I've needed so far.
Now, if there are changes required to core in order to make use of your plugin
*possible* that would certainly be a reasonable request.
> Load Plugin resources from classpath
> ------------------------------------
>
> Key: JSPWIKI-628
> URL: https://issues.apache.org/jira/browse/JSPWIKI-628
> Project: JSPWiki
> Issue Type: Improvement
> Affects Versions: 2.8.3
> Reporter: Jürgen Weber
>
> Some plugins require the browser to load files. E.g. the FreeMindPlugin needs
> the browser to load the applet's classes, or another plugin might need some
> flash code.
> Currently the solution is to attach these files to a page which has the sole
> purpose of having the attachment. This is kind of awkward.
> JSPWiki should have a mechanism (in JSPFilter?) which would load the file
> from the classpath. So for FreeMind the FreeMindPlugin.jar would additionally
> contain freemindbrowser.jar. The plugin would generate some markup that would
> make the Filter recognize that the parameter is to be loaded from classpath,
> e.g. <wiki:IncludeResource freemindbrowser.jar>
> I guess this could be done with a PageFilter, too, but the idea is to make
> installing plugins easier and having to add a filters.xml would be
> counterproductive, so the mechanism should go into core.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
