Re: Attempting to modify the ImageJ user interface to create a "mini application"

Posted by Curtis Rueden on Mar 02, 2019; 2:33am
URL: http://imagej.273.s1.nabble.com/Attempting-to-modify-the-ImageJ-user-interface-to-create-a-mini-application-tp5021669p5021864.html

Hi Thomas,

> The Fiji people added the key for their Maven repo, but left the value
> blank (if someone from the Fiji community reads these lines: please
> add an automatic module name for modular applications!).

The SciJava build infrastructure supports Automatic-Module-Name, and many
components already do define it. See this gist:
https://gist.github.com/ctrueden/56d3f4fe2273d4a6437d8d593bf67c9f

However, the net.imagej:ij component did not set the package-name property,
and therefore the Automatic-Module-Name was not assigned accordingly. I
have remedied this with https://github.com/imagej/ImageJA/commit/26e053ee,
so the next ImageJ 1.x release will have the field set in the manifest.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
Have you tried the Image.sc Forum? https://forum.image.sc/

On Tue, Feb 26, 2019 at 3:09 PM Peterbauer Thomas <
[hidden email]> wrote:

> On 26.02.19 19:14, Grayson_Harrington wrote:
> > I was using jdk11* and just downloaded and installed jdk1.8* and then
> set it
> > to be used in the project (see image), but the same error message was
> > thrown.
> >
> > <http://imagej.1557.x6.nabble.com/file/t382212/capture.png>
>
> Check your project setup. Perhaps you are compiling with JDK 8, but
> still running with JDK 11.
>
> The second option is to try to get JDK 11 running. First of all, try to
> get ij.jar on the classpath while launching, not on the modulepath:
>
> java -classpath ij.jar <your-main-package.your-main-class>
>
> Running on the modulepath is more involved. I describe a solution in
> detail, because most likely more people will run into this problem in
> the near future.
>
> Error #1 ("Unable to derive module descriptor for ../ij.jar")
> unambiguously points to a modulepath problem. The most likely cause is a
> missing entry in META-INF\MANIFEST.MF. There should be one with the key
> "Automatic-Module-Name:" followed by a name. It's absent in ij.jar from
> imagej.nih.gov (at least it did when I fetched it two or three weeks
> ago). The Fiji people added the key for their Maven repo, but left the
> value blank (if someone from the Fiji community reads these lines:
> please add an automatic module name for modular applications!). One can
> patch ij.jar by opening it in an archive manager (rename to ij.zip if
> working with 7zip) and adding a name manually (I simply called it "ij").
> Complete MANIFEST.MF:
>
> Manifest-Version: 1.0
> Main-Class: ij.ImageJ
> Automatic-Module-Name: ij
>
> Error #2, "MacAdapter.class found in top level directory (unnamed module
> not allowed in module)": JDK 9+ seems to confuse this class in the root
> of ij.jar with a module-info.class (a class internally describing a JDK
> 9+ module). So far I found no other solution than removing it from
> ij.jar. It's required only for MacOS (should Wayne Rasband happen to
> read these lines: would it be possible to move it into a package?)
>
> I usually compile new versions from source, with a patched MANIFEST.MF
> and omitting the MacAdapter.class in my ant build, and can run ImageJ as
> a library successfully on Windows and Linux, with any of JDK 9 to 12ea.
>
> Good luck,
>
> Thomas
>
>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

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