http://imagej.273.s1.nabble.com/Potential-updates-to-ImageJ-a-question-tp5011598p5011616.html
> Hi Peter,
>
>> Yes, you can use Fiji plugins in a vanilla ImageJ 1.x installation
> I added a FAQ entry on it:
>
>
http://imagej.net/Frequently_Asked_Questions#How_do_I_install_a_Fiji_plugin_into_vanilla_ImageJ_1.x.3F>
> There are several downsides to doing things this way, which I explain
> further there. In particular, it places the burden of dependency version
> management on the end user, which is something Fiji was specifically
> created to avoid doing.
>
> Regards,
> Curtis
>
> On Mon, Feb 16, 2015 at 8:40 AM, Curtis Rueden <
[hidden email]> wrote:
>
>> Hi Peter,
>>
>>> 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?
>> Yes, you can use Fiji plugins in a vanilla ImageJ 1.x installation, as
>> long as you copy all its dependencies with it.
>>
>> You can do this easily as follows:
>>
>> git clone git://github.com/fiji/Stitching
>> cd Stitching
>> mvn dependency:copy-dependencies
>>
>> Then copy target/dependency/*.jar into your ImageJ directory.
>>
>> You will need Git and Maven installed for this to work.
>>
>> That said, note that Fiji plugin authors test their plugins in Fiji, not
>> vanilla ImageJ 1.x, so you might save yourself some pain by using Fiji
>> instead.
>>
>> Regards,
>> Curtis
>>
>>
>> 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>
>