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.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> 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> > 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> 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.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 >>> http://imagej.net/mailman/listinfo/imagej-devel >>> >> >> >> >> _______________________________________________ >> ImageJ-devel mailing list >> ImageJ-devel@imagej.net >> http://imagej.net/mailman/listinfo/imagej-devel >> >> > > > _______________________________________________ > ImageJ-devel mailing list > ImageJ-devel@imagej.net > http://imagej.net/mailman/listinfo/imagej-devel > >
_______________________________________________ ImageJ-devel mailing list ImageJ-devel@imagej.net http://imagej.net/mailman/listinfo/imagej-devel
