[ImageJ-devel] external plugins

Thu Mar 19 15:38:49 CDT 2015

Hi Jay,

> Likely the more straight forward approach would have been to directly
> use the annotation index in the jar instead of searching jar entries.
> Either way I suppose :-)

Less code, yeah. But also much more performant. Your way not only fully
scans the JAR but also needs to load all the classes so they can be
inspected for @Plugin annotations. The SciJava way (based on the SezPoz
idea) is that you don't have to scan JARs or load classes -- you just read
a single resource file out of each JAR and you have all the information you
need.

-Curtis

On Thu, Mar 19, 2015 at 3:33 PM, Jay Warrick <jay.w.warrick at gmail.com>
wrote:

> After writing this. Likely the more straight forward approach would have
> been to directly use the annotation index in the jar instead of searching
> jar entries. Either way I suppose :-)
>
> On Mar 19, 2015, at 3:30 PM, Jay Warrick <jay.w.warrick at gmail.com> wrote:
>
> Thanks man. It turns out that it isn't too bad to load the class files on
> the fly from a jar, check which jar entries are classes that extend
> JEXPlugin, load them, get the @Plugin annotation, create a PluginInfo, then
> create my JEXPluginInfo from that (something I already had code for) which
> parses the other annotations I made for my plugins. I can then use this
> JEXPluginInfo to instantiate my fully functional JEXCrunchablePlugin (also
> code I already had) that actually does the image processing and can be
> added to my list of plugins available in the software. I only demonstrated
> feasibility today for getting to the functional JEXCrunchablePlugin
> instance and will incorporate more fully soon.
>
> Thanks for pointing out that I should likely just rely on compiled jars
> and pointing out the addPlugin method. It made this process much simpler.
>
> Thanks Curtis and Mark for your help.
>
> Best,
>
> Jay
>
>
> On Mar 19, 2015, at 1:15 PM, Curtis Rueden <ctrueden at wisc.edu> wrote:
>
> Hi Jay,
>
> > What might be the best way to include these compiled jars in my class
> > path upon launching the binary?
>
> Well, one option would be to make JEX into a plugin for ImageJ, with a JEX
> update site. Then JARs in the jars/ and plugins/ directories would
> automatically be on the classpath, thanks to the ImageJ launcher.
>
> Otherwise, deployment of Java applications is a rough issue, man. If you
> don't want to use ImageJ's solution (the Launcher), then you can research
> it yourself and go your own way. There are a million and one ways to do it,
> and they all have their pros and cons. One popular option is launch4j [1].
> Actually, I would love to switch ImageJ to something more industry standard
> like that, but it's quite a lot of effort and surely there would be some
> serious backwards incompatibilities...
>
> Regards,
> Curtis
>
> [1] http://launch4j.sourceforge.net/
>
> On Thu, Mar 19, 2015 at 12:50 PM, Jay Warrick <jay.w.warrick at gmail.com>
> wrote:
>
>> Sweet. Thanks for the clarification. I'm fine with requiring compiled
>> jars. I was prepared to use something like the addPlugins API but certainly
>> see the simplicity of the restart method and will likely try that for now.
>>
>> What might be the best way to include these compiled jars in my class
>> path upon launching the binary? Would one option be to edit the simple
>> launch script for the software by adding a classpath argument to the "java
>> ..." command?
>>
>>
>> On Mar 19, 2015, at 11:36 AM, Curtis Rueden <ctrueden at wisc.edu> wrote:
>>
>> Hi Jay,
>>
>> > Person (A) also downloads the .java/.class file of a just a plugin
>> > that would work within my software from third person (C).
>>
>> This is the scenario we are trying to move away from: distributing bare
>> .java or .class files. As long as plugins are distributed as .jar files
>> which contain the plugin annotation metadata (in
>> META-INF/json/org.scijava.plugin.Plugin), then all is well.
>>
>> > Person (A) wants to run my binary and load/use the plugin from person
>> > (C) at runtime. How would the SciJava plugin framework know how to
>> > automatically discover this plugin?
>>
>> The plugin (as a .jar file) is placed somewhere where it will be included
>> in the classpath at launch time. As long as the new .jar file is on the
>> classpath, it will be discovered at runtime.
>>
>> > I thought that if my program is already compiled and running before I
>> > specify where this "external plugin" resides and load the class, the
>> > PluginService would be unaware of the external plugin.
>>
>> Is it really a requirement that users be able to load additional plugins
>> _after_ your program starts up, without restarting the program? If not,
>> then I wouldn't worry about making this work, as it adds complexity for
>> little gain. Just put the new plugin somewhere on the classpath, start JEX,
>> and all is well.
>>
>> If you really need to be able to load plugins after startup, this _can_
>> be done. But you have to manually add them to the plugin service via the
>> addPlugins API method.
>>
>> Regards,
>> Curtis
>>
>> On Thu, Mar 19, 2015 at 11:32 AM, Jay Warrick <jay.w.warrick at gmail.com>
>> wrote:
>>
>>> Thanks, Mark. I should likely be using this Handler methodology in a few
>>> places in my software, including in this case. However, I'm still concerned
>>> about detection of the plugin given the scenario I'm thinking of. But,
>>> maybe you can help me understand. I have already been able to build my
>>> software project around the SciJava plugin framework and ImageJ's
>>> PluginService to automatically recognize the plugins that are part of my
>>> own software project. The SciJava framework does its job beautifully to
>>> automatically discover the plugins I've developed within my software.
>>> However, what about the following scenario?
>>>
>>> Person (A) downloads the binary of my software from me (B). Person (A)
>>> also downloads the .java/.class file of a just a plugin that would work
>>> within my software from third person (C). Person (A) wants to run my binary
>>> and load/use the plugin from person (C) at runtime. How would the SciJava
>>> plugin framework know how to automatically discover this plugin?
>>>
>>> My recollection is that the list of plugins loaded by the PluginService
>>> are determined from a java annotation index file that is created during
>>> early in the build process. Thus, I thought that if my program is already
>>> compiled and running before I specify where this "external plugin" resides
>>> and load the class, the PluginService would be unaware of the external
>>> plugin. Am I correct? If it can detect it, then it appears I'm home free
>>> and am worrying for nothing, which would be awesome.
>>>
>>> Thanks!
>>>
>>> Jay
>>>
>>>
>>> On Mar 19, 2015, at 8:51 AM, Mark Hiner <hiner at wisc.edu> wrote:
>>>
>>> Hi Jay,
>>>
>>> >One of the main things I can't quite envision is how to process the
>>> annotations of an external .java file at runtime so that I can utilize that
>>> information
>>>
>>> You shouldn't have to do this yourself. By using the SciJava plugin
>>> framework you get discovery of all annotated plugins on your classpath, and
>>> processing/indexing of those plugins, for free.
>>>
>>> I'm assuming the paradigm that would match your needs is a
>>> HandlerService[1]. The service would perform some function (e.g. opening a
>>> path) and the behavior of that function would be extensible via
>>> HandlerPlugins[2] (e.g. a plugin for handling URLs, files on disk, files in
>>> a database, etc...).
>>>
>>> The simplest example of "service chooses a plugin appropriate for the
>>> circumstances" is the AnimalService tutorial[3]. Note that it's not
>>> actually a HandlerService but could easily be converted to one. More
>>> complex examples would be the IOService[4] or SCIFIO's FormatService[5].
>>>
>>> Best,
>>> Mark
>>>
>>> [1]
>>> https://github.com/scijava/scijava-common/blob/scijava-common-2.39.0/src/main/java/org/scijava/plugin/HandlerService.java
>>> [2]
>>> https://github.com/scijava/scijava-common/blob/scijava-common-2.39.0/src/main/java/org/scijava/plugin/HandlerPlugin.java
>>> [3]
>>> https://github.com/imagej/imagej-tutorials/tree/00394f9f5010d1787b9bf584b6e90eed01beec0d/create-a-new-plugin-type/src/main/java
>>> [4]
>>> https://github.com/scijava/scijava-common/blob/scijava-common-2.39.0/src/main/java/org/scijava/io/IOService.java
>>> [5]
>>> https://github.com/scifio/scifio/blob/scifio-0.21.1/src/main/java/io/scif/services/FormatService.java
>>>
>>> On Wed, Mar 18, 2015 at 6:42 PM, Jay Warrick <jay.w.warrick at gmail.com>
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I am using the scijava plugin framework, ImageJ2, and its Plugin
>>>> service. I would like to allow other people to write a plugin for my
>>>> software. I'm open to suggestions but I'd probably like to enable them to
>>>> place their java/jar/class plugin file in a folder, and I could look into
>>>> that folder to load their plugin. I'm thinking along the lines of how how
>>>> old ImageJ did things. Does anyone have suggestions or example code (e.g.,
>>>> in FIJI somewhere) for loading/compiling such plugin files during runtime.
>>>> One of the main things I can't quite envision is how to process the
>>>> annotations of an external .java file at runtime so that I can utilize that
>>>> information (e.g., in conjunction with the PluginService). If there is an
>>>> inherent problem in what I'm hoping to do, please let me know :-) (e.g., if
>>>> I am provided compiled code, I suspect I might need an annotation index to
>>>> go with it if I need that information).
>>>>
>>>> I figured you guys have tackled this problem thoroughly already and
>>>> thus would be a good resource. Thanks in advance!
>>>>
>>>> Regards,
>>>>
>>>> Jay
>>>>
>>>>
>>>> _______________________________________________
>>>> ImageJ-devel mailing list
>>>> ImageJ-devel at imagej.net
>>>> http://imagej.net/mailman/listinfo/imagej-devel
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> ImageJ-devel mailing list
>>> ImageJ-devel at imagej.net
>>> http://imagej.net/mailman/listinfo/imagej-devel
>>>
>>>
>>
>>
>> _______________________________________________
>> ImageJ-devel mailing list
>> ImageJ-devel at imagej.net
>> http://imagej.net/mailman/listinfo/imagej-devel
>>
>>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagej.net
> http://imagej.net/mailman/listinfo/imagej-devel
>
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagej.net
> http://imagej.net/mailman/listinfo/imagej-devel
>
>
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagej.net
> http://imagej.net/mailman/listinfo/imagej-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20150319/1c8ae365/attachment.html>