external plugins

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

external plugins

Jay Warrick-2
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
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: external plugins

Mark Hiner
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

On Wed, Mar 18, 2015 at 6:42 PM, Jay Warrick <[hidden email]> 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
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: external plugins

Jay Warrick-2
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 <[hidden email]> 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

On Wed, Mar 18, 2015 at 6:42 PM, Jay Warrick <[hidden email]> 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
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel



_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: external plugins

Curtis Rueden
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 <[hidden email]> 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 <[hidden email]> 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

On Wed, Mar 18, 2015 at 6:42 PM, Jay Warrick <[hidden email]> 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
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel



_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel



_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: external plugins

Jay Warrick-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

On Wed, Mar 18, 2015 at 6:42 PM, Jay Warrick <[hidden email]> 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
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel



_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel




_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: external plugins

Curtis Rueden
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


On Thu, Mar 19, 2015 at 12:50 PM, Jay Warrick <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

On Wed, Mar 18, 2015 at 6:42 PM, Jay Warrick <[hidden email]> 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
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel



_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel




_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel



_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: external plugins

Jay Warrick-2
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 <[hidden email]> 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


On Thu, Mar 19, 2015 at 12:50 PM, Jay Warrick <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

On Wed, Mar 18, 2015 at 6:42 PM, Jay Warrick <[hidden email]> 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
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel



_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel




_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: external plugins

Jay Warrick-2
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 <[hidden email]> 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 <[hidden email]> 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


On Thu, Mar 19, 2015 at 12:50 PM, Jay Warrick <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

On Wed, Mar 18, 2015 at 6:42 PM, Jay Warrick <[hidden email]> 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
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel



_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel




_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel

_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: external plugins

Curtis Rueden
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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


On Thu, Mar 19, 2015 at 12:50 PM, Jay Warrick <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

On Wed, Mar 18, 2015 at 6:42 PM, Jay Warrick <[hidden email]> 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
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel



_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel




_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel

_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel



_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: external plugins

Jay Warrick-2
Agree. Thanks.

On Mar 19, 2015, at 3:38 PM, Curtis Rueden <[hidden email]> wrote:

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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


On Thu, Mar 19, 2015 at 12:50 PM, Jay Warrick <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

On Wed, Mar 18, 2015 at 6:42 PM, Jay Warrick <[hidden email]> 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
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel



_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel




_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel

_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel




_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel