http://imagej.273.s1.nabble.com/Potential-updates-to-ImageJ-a-question-tp5011598p5011626.html
I have tested the git clone / mvn command you have suggested.
It runs without any problem. Thanks for this recommendation.
I got 121 jar files in the dependency folder. The file list looks very
similar to the list of files in the Fiji\jars folder. Nearly all jar
files from Fiji\jars have been downloaded with the maven command.
are not needed to run the stitching plugin.
only the really relevant jar files.
instead of using Maven.
> 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>
>