Error with mvn.CMD and newly created pom.xml

Hi all,

This is something of an extension from a series of problems I posted late last week about getting imagej working in python. I was getting an error trying to call autoclass(ij.ImagePlus) in pyimagej to the tune of JavaException: Class not found b'ij/ImagePlus'.

Since init('sc.fiji:fiji') is the only command that works for me I thought perhaps switcing over to a local fiji installation from imagej might work, but I’m running into another problem with maven & imglyb.

In the process of imagej.init(), I receive an error:

ij = imagej.init('C:\\Users\\msout\\Desktop\\Fiji.app',headless=False)

CalledProcessError: 
Command '('C:\\Users\\msout\\Anaconda2\\envs\\pyimagej\\Library\\bin\\mvn.CMD', '-B', '-f', 'C:\\Users\\msout\\Desktop\\ImageJ\\RELEASE+net.imglib-imglib2-imglyb-0.3.0+net.imglib-imglib2-imglyb-0.3.0\\pom.xml', 'dependency:resolve')' returned non-zero exit status 1.

In the process, it seems that 3 entirely new folders were created in \Fiji.app

C:\Users\msout\Desktop\Fiji.app\RELEASE+C-
C:\Users\msout\Desktop\Fiji.app\RELEASE+net.imglib-imglib2-imglyb-0.3.0
C:\Users\msout\Desktop\Fiji.app\RELEASE+net.imglib-imglib2-imglyb-0.3.0+net.imglib-imglib2-imglyb-0.3.0

Each one of these folders contains their own pom.xml.

This one is an error that is somewhat beyond me. If anyone can help with this error or any of the others from my other post I would be extremely grateful.

1 Like

Posting this development here as well as my original thread since this thread is really the one that approaches this problem specifically. It’s not much at the moment, but I’ll try to keep further developments on this issue limited to this thread so as to not clutter both discussions.

I’ve followed the error prompt from this post to the _init_jvm_options() function from the __init__.py found in the imglyb folder of my virtual environment. I will investigate further when I have a moment. Given the format of the created directories mentioned in the linked post, I feel as though there’s a formatting bug hiding somewhere (perhaps hiding within a loop). As with many things, that could be a misguided thought, but we’ll see.

Whoa, weird. At first glance, it looks like it’s not detecting your path as a local folder, and instead trying to bootstrap some Maven artifacts. Did you try with forward slash / instead of backslashes?

In the meantime, I’ll boot up my Windows VM and see if I can reproduce.

I cannot reproduce on my Windows VM. It works with either forward slash or backslash:

Wrapping an existing Fiji.app folder
(pyimagej) PS>python
Python 3.7.3 | packaged by conda-forge | (default, Jul  1 2019, 22:01:29) [MSC v.1900 64 bit (AMD64)] :: Anaconda, Inc. on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import imagej
>>> ij = imagej.init('C:/Users/curtis/Programs/Fiji.app')
Added 387 JARs to the Java classpath.
Oct 29, 2019 10:33:21 AM java.util.prefs.WindowsPreferences <init>
WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5.
>>> ij.getVersion()
'2.0.0-rc-69/1.52p'
>>> ^Z

(pyimagej) PS>python
Python 3.7.3 | packaged by conda-forge | (default, Jul  1 2019, 22:01:29) [MSC v.1900 64 bit (AMD64)] :: Anaconda, Inc. on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import imagej
>>> ij = imagej.init('C:\\Users\\curtis\\Programs\\Fiji.app')
Added 387 JARs to the Java classpath.
Oct 29, 2019 10:34:07 AM java.util.prefs.WindowsPreferences <init>
WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5.
>>> ij.getVersion()
'2.0.0-rc-69/1.52p'

(The Could not open/create prefs error can be safely ignored.)

Edit: I can reproduce by passing a non-existent directory:

(pyimagej) PS>python
Python 3.7.3 | packaged by conda-forge | (default, Jul  1 2019, 22:01:29) [MSC v.1900 64 bit (AMD64)] :: Anaconda, Inc. on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import imagej
>>> ij = imagej.init('C:\\Users\\curtis\\Programs\\Foo')

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\tools\miniconda3\envs\pyimagej\lib\site-packages\imagej\imagej.py", line 104, in init
    import imglyb
  File "C:\tools\miniconda3\envs\pyimagej\lib\site-packages\imglyb\__init__.py", line 38, in <module>
    config, _ = _init_jvm_options()
  File "C:\tools\miniconda3\envs\pyimagej\lib\site-packages\imglyb\__init__.py", line 33, in _init_jvm_options
    import scyjava
  File "C:\tools\miniconda3\envs\pyimagej\lib\site-packages\scyjava\__init__.py", line 139, in <module>
    jnius = _init_jvm()
  File "C:\tools\miniconda3\envs\pyimagej\lib\site-packages\scyjava\__init__.py", line 125, in _init_jvm
    verbose=scyjava_config.get_verbose()
  File "C:\tools\miniconda3\envs\pyimagej\lib\site-packages\jgo\jgo.py", line 458, in resolve_dependencies
    raise e
  File "C:\tools\miniconda3\envs\pyimagej\lib\site-packages\jgo\jgo.py", line 449, in resolve_dependencies
    mvn_out = run_and_combine_outputs(mvn, *mvn_args)
  File "C:\tools\miniconda3\envs\pyimagej\lib\site-packages\jgo\jgo.py", line 200, in run_and_combine_outputs
    return subprocess.check_output((command,) + args, stderr=subprocess.STDOUT)
  File "C:\tools\miniconda3\envs\pyimagej\lib\subprocess.py", line 395, in check_output
    **kwargs).stdout
  File "C:\tools\miniconda3\envs\pyimagej\lib\subprocess.py", line 487, in run
    output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '('C:\\tools\\miniconda3\\envs\\pyimagej\\Library\\bin\\mvn.CMD', '-B', '-f', 'C:\\Users\\curtis\\Programs\\Foo\\RELEASE+net.imglib-imglib2-imglyb-0.3.0\\pom.xml', 'dependency:resolve')' returned non-zero exit status 1.
>>>

Are you sure the path C:\Users\msout\Desktop\Fiji.app is correct, and contains a local installation of Fiji?

Edit: I pushed a commit to proactively check if a directory-like string was specified, but that directory does not actually exist:

2 Likes

@ctrueden
I can confirm that I was referencing a file that does exist. The local installation call works fine after a fresh install. :+1:

I don’t think the culprit was my endpoint hack, as I was using it for some time before this issue popped up, but whatever the issue was was certainly my fault.

1 Like