Potential updates to ImageJ + a question

[Rasband, Wayne (NIH/NIMH) [E]]

On Feb 17, 2015, at 7:01 AM, Peter Haub <[hidden email]> wrote:
>
> Hi Michael,
>
> yes, that's the way I understood your info.
>
> I have removed a jar file which is necessary to run a certain plugin.
> When I started the plugin I got the message "Plugin or class not found" where the plugin itself is reported instead of the missing class file.
> For me, the situation has not changed.

The latest ImageJ daily build (1.49p15) should provide a better error message when you attempt to run a plugin and a needed class file is missing.

Best regards,

-wayne

> On 17.02.2015 10:37, Michael Schmid wrote:
>> Hi Peter,
>>
>> sorry, I did not write it clearly enough:
>> In the old versions, the "Plugin or class not found" did not report the class that is actually missing but erroneously a class that is not missing, with the beginning of its name (up to the first dot) stripped off.
>>
>> Since 1.49o, ImageJ should report the class that is really missing in "Plugin or class not found".
>>
>> You may also get a "Plugin or class not found" error if the file is not in the ImageJ/plugins directory or an immediate subdirectory thereof.
>> E.g. ImageJ/plugins/subdir/subsubdir/ThePlugIn.class won't work.
>>
>> Michael
>> ________________________________________________________________
>> On Feb 17, 2015, at 06:54, Peter Haub wrote:
>>
>>> Hi Michael,
>>>
>>> Thanks for your answer.
>>>
>>> I tested the version 1.49p13 (latest daily build) and I still got the misleading "Plugin or class not found" error message.
>>>
>>> By the way, if it would have been fixed would it be display the name of the missing jar file or only the name of the missing class and one has to find the jar file containing the class manually?
>>>
>>> Thanks and regards,
>>> Peter
>>>
>>> On 16.02.2015 18:22, Michael Schmid wrote:
>>>> Hi Peter,
>>>>
>>>> just a hint for using plugins that use additional packages/jars:
>>>> Make sure you have Image version 1.49o (or later). In this version, the misleading "Plugin or class not found" error messages are fixed, and it tells you which class is actually missing. With this information one can usually identify the package that is actually missing.
>>>>
>>>> Michael
>>>> ________________________________________________________________
>>>> On Feb 16, 2015, at 16:58, Peter Haub wrote:
>>>>
>>>>> Hi Mark,
>>>>>
>>>>> Thanks for your feedback. Let me give some comments ..
>>>>>
>>>>> On 16.02.2015 14:53, Mark Hiner wrote:
>>>>>> It depends on the plugin. In the case of Stitching, for example, there is
>>>>>> an ImageJ 1.x download[1] provided by the author.
>>>>> Yes, but this is not the latest version.
>>>>>> But yes as a general rule a you need to consider any dependencies. All the
>>>>>> Fiji plugins are Mavenized for dependency management[2].
>>>>>> Also, the ImageJ updater (Help > Update...) that ships with Fiji will show
>>>>>> you the dependencies it knows of for any library if you go to Advanced Mode.
>>>>> This is a very helpful function. Thanks for the information!
>>>>>
>>>>> So I started to check the necessary libs for the stitching plugin and copied them to ImageJ. Then I started ImageJ, tested the stitching command and got the error message mentioned before. I went back and check the dependencies of all libs I had copied in the first round. I copied all additional libs to ImageJ, started ImageJ, tested the stitching command and got the error message. Then I repeated the procedure a third time ... ...
>>>>>
>>>>> As a consequence this type of plugin will never be usable in ImageJ for 'standard users'. For non-experts this looks like an incompatibility.
>>>>>
>>>>> Here in my case this is not a big issue. I can deal with it.
>>>>> But I thought I will use the chance to give some feedback to the development team by describing how 'standard users' face the situation. I am often asked what the relation respectively the difference between ImageJ and Fiji is. The answer is not such easy as putting batteries in a flashlight. The nice aspect with ImageJ is that its complexity allows even beginners to dig into the complete source and get an overview and a feeling for an efficient and useful image processing software. Also very nice is its flexibility to extend the functionality by plugins. This is - I thought - wath Fiji is doing. So Fiji is just ImageJ .... But in fact the IJ/Fiji question can not be answered in this way. Using ImageJ means deciding not to use a bundle of very helpful plugins (as we saw above). Using Fiji means losing the 'backward' compatibility and the manageable complexity of ImageJ. So the decision between ImageJ and Fiji is not just a personal preference but leads at the end to different software tools. Ermm, ...
>>>>>
>>>>> Mark, do you have an idea how complex it is to develop a function which could list all dependencies of a plugin such as Stitching_.jar recursively. This would help at least in the situation above. And more perfect would be if all the listed libs could be copied to some location.
>>>>>
>>>>> Hopefully I will find the time to familiarize with with the details of Fiji, with Maven, with ImgLib2 and all the other nice and very powerful and advanced capabilities of Fiji.
>>>>>
>>>>> Regards,
>>>>> Peter
>>>>>
>>>>>> Best,
>>>>>> Mark
>>>>>>
>>>>>> [1] http://fiji.sc/Image_Stitching#Download_for_ImageJ_.26_Acknowledgements
>>>>>> [2] https://github.com/fiji/Stitching/blob/master/pom.xml#L42-121
>>>>>>
>>>>>> On Mon, Feb 16, 2015 at 2:02 AM, Peter Haub <[hidden email]> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>> I have to correct my statement.
>>>>>>>
>>>>>>> After writing a SSCCE I found that ImageJ and Fiji both do access plugins
>>>>>>> located in subdirectories of jar archives in the same way.
>>>>>>>
>>>>>>> After all - my problem  arises because of missing libraries when using the
>>>>>>> original plugin jar in ImageJ.
>>>>>>>
>>>>>>> The message
>>>>>>>     Plugin or class not found: "Stitching Grid"
>>>>>>>     (java.lang.ClassNotFoundException: Stitching_Grid)
>>>>>>> was misleading.
>>>>>>> There is no problem in the class file and no problem in the class handling
>>>>>>> in ImageJ/Fiji.
>>>>>>>
>>>>>>> The question I still have is if plugins written in the Fiji environment
>>>>>>> are thought to be (easily) available as ImageJ plugins too or if - because
>>>>>>> of the complex library dependencies - this compatibility is achievable only
>>>>>>> with time and expert knowhow?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Peter
>>>>>>>
>>>>>>>
>>>>>>> On 14.02.2015 21:13, Peter Haub wrote:
>>>>>>>
>>>>>>>> Dear list,
>>>>>>>>
>>>>>>>> I thought that Fiji is just ImageJ.
>>>>>>>> It seems as if there are slight differences in the way plugins (packed in
>>>>>>>> jar archives) are treated.
>>>>>>>> Maybe someone can point to a place where I can find some information
>>>>>>>> regarding the necessary structure of plugin jar archives - for ImageJ and
>>>>>>>> for Fiji.
>>>>>>>>
>>>>>>>> My problem:
>>>>>>>> I would like to use a Fiji plugin in an ImageJ installation (Stitching
>>>>>>>> plugin, S. Preibisch).
>>>>>>>> The plugin is encapsulated in a jar archive.
>>>>>>>> The main classes to be accessed as plugin are located in a subdirectory
>>>>>>>> (\pluin) inside the jar file.
>>>>>>>> The classes are made available to Fiji/ImageJ by a plugin.config file.
>>>>>>>> I can run this (jar packed) plugin in Fiji without problems.
>>>>>>>> In ImageJ the plugin command is available and the plugin user interface
>>>>>>>> (UI) can be started. But when the UI is closed with OK an error is shown:
>>>>>>>> Plugin or class not found: "Stitching Grid"
>>>>>>>> (java.lang.ClassNotFoundException: Stitching_Grid)
>>>>>>>>
>>>>>>>> There is no conflict with additional libraries or wrong configurations.
>>>>>>>>
>>>>>>>> If I recompile the source code by placing the relevant class files in the
>>>>>>>> default package instead of the plugin package the relevant class files are
>>>>>>>> located in the root of the jar archive. This recompiled plugin packed as
>>>>>>>> jar archive can be executed without error message in ImageJ.
>>>>>>>>
>>>>>>>> My questions are:
>>>>>>>> Is there a difference in the handling of plugin jar archives in ImageJ
>>>>>>>> and Fiji?
>>>>>>>> Should it be possible to us plugin jar archives from Fiji without changes
>>>>>>>> in ImageJ?
>>>>>>>> Do I miss something in my specific case?
>>>>>>>> Or do I have to recompile the classes in the way described above?
>>>>>>>>
>>>>>>>> A personal comment:
>>>>>>>> These kinds of differences of complex dependencies are confusing and are
>>>>>>>> challenging the close connection of the two project streams.
>>>>>>>>
>>>>>>>> I would be happy for any hint.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Peter
>>>>>>>>
>>>>>>>> --
>>>>>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>>>>>
>>>>>> --
>>>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>>> --
>>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>> --
>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>>
>>>>
>>> --
>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html