http://imagej.273.s1.nabble.com/Potential-updates-to-ImageJ-a-question-tp5011598p5011614.html
further there. In particular, it places the burden of dependency version
> 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>>
>
>