Agree. Thanks. > On Mar 19, 2015, at 3:38 PM, Curtis Rueden <ctrue...@wisc.edu> 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 <jay.w.warr...@gmail.com > <mailto:jay.w.warr...@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.warr...@gmail.com >> <mailto:jay.w.warr...@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 <ctrue...@wisc.edu >>> <mailto:ctrue...@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/ <http://launch4j.sourceforge.net/> >>> >>> On Thu, Mar 19, 2015 at 12:50 PM, Jay Warrick <jay.w.warr...@gmail.com >>> <mailto:jay.w.warr...@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 <ctrue...@wisc.edu >>>> <mailto:ctrue...@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.warr...@gmail.com >>>> <mailto:jay.w.warr...@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 <hi...@wisc.edu >>>>> <mailto:hi...@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 >>>>> >>>>> <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 >>>>> >>>>> <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 >>>>> >>>>> <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 >>>>> >>>>> <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 >>>>> >>>>> <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.warr...@gmail.com >>>>> <mailto:jay.w.warr...@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@imagej.net <mailto:ImageJ-devel@imagej.net> >>>>> http://imagej.net/mailman/listinfo/imagej-devel >>>>> <http://imagej.net/mailman/listinfo/imagej-devel> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> ImageJ-devel mailing list >>>> ImageJ-devel@imagej.net <mailto:ImageJ-devel@imagej.net> >>>> http://imagej.net/mailman/listinfo/imagej-devel >>>> <http://imagej.net/mailman/listinfo/imagej-devel> >>>> >>>> >>> >>> >>> _______________________________________________ >>> ImageJ-devel mailing list >>> ImageJ-devel@imagej.net <mailto:ImageJ-devel@imagej.net> >>> http://imagej.net/mailman/listinfo/imagej-devel >>> <http://imagej.net/mailman/listinfo/imagej-devel> >>> >>> >>> _______________________________________________ >>> ImageJ-devel mailing list >>> ImageJ-devel@imagej.net <mailto:ImageJ-devel@imagej.net> >>> http://imagej.net/mailman/listinfo/imagej-devel >>> <http://imagej.net/mailman/listinfo/imagej-devel> >> >> _______________________________________________ >> ImageJ-devel mailing list >> ImageJ-devel@imagej.net <mailto:ImageJ-devel@imagej.net> >> http://imagej.net/mailman/listinfo/imagej-devel >> <http://imagej.net/mailman/listinfo/imagej-devel> > > > _______________________________________________ > ImageJ-devel mailing list > ImageJ-devel@imagej.net <mailto:ImageJ-devel@imagej.net> > http://imagej.net/mailman/listinfo/imagej-devel > <http://imagej.net/mailman/listinfo/imagej-devel> > >
_______________________________________________ ImageJ-devel mailing list ImageJ-devel@imagej.net http://imagej.net/mailman/listinfo/imagej-devel
