Imagej.net maven repository disappeared?

maven
#1

The Micro-Manager build uses the ImageJ.net maven repository (http://maven.imagej.net/content/groups/public). Posts on the Micro-Manager mailing list suggested issues with this repository, and indeed, the link above now resolves to a http 404 (Not Found) error after redirecting to: https://maven.scijava.org/nexus/content/groups/public/.

Has this repository been moved to another place or is it gone?

3 Likes
#2

Hi @nicost,

I ran into this recently too. @ctrueden migrated to maven.scijava.org as you noticed.

On gitter he says:

Curtis Rueden
@ctrueden
Apr 29 16:40

Everyone, I have updated our Nexus Maven repository, now at https://maven.scijava.org. The old maven.imagej.net has a blanket redirect there. Old builds still seem to work. But if you notice problems, please let me know right away and I will fix it.
I will make a forum post explaining more later.

John

1 Like
#3

So, what is the correct path now? It seems that removing “nexus” from the redirect path gets me somewhere, but not sure yet.

1 Like
#4

The new pom-scijava has

<repositories>
	<repository>
		<id>scijava.public</id>
 		<url>https://maven.scijava.org/content/groups/public</url>
	</repository>
</repositories>

so I’d hope that would do it.

#5

OK, so the redirect is wrong. @ctrueden, can you fix the server setting?

1 Like
#6

@nicost Thanks for the heads up! But I cannot reproduce the wrong redirect:

$ curl -I https://maven.imagej.net/content/groups/public
HTTP/1.1 301 Moved Permanently
Date: Thu, 09 May 2019 14:55:45 GMT
Server: Apache/2.2.22 (Ubuntu)
Location: https://maven.scijava.org/content/groups/public
Vary: Accept-Encoding
Content-Type: text/html; charset=iso-8859-1

Can you give me an example?

#7

@ctrueden When I copy and paste into Firefox:

https://maven.imagej.net/content/groups/public

I am redirected to:

https://maven.scijava.org/nexus/content/groups/public/

And get the 404. Funnily enough, when is use curl, I get the same result you do. No idea what could be causing this, but clearly people building the code run into the same wrong redirect problem, so the ivy fetcher gets the same redirect as Firefox.

2 Likes
#8

Confirming that I observe the same behavior me with Chrome on Linux.

1 Like
#9

And same for me with Chrome on macOS. How bizarre!

I think this is why:

$ curl -I https://maven.scijava.org/content/groups/public
HTTP/1.1 302 Found
Date: Thu, 09 May 2019 19:06:45 GMT
Server: Nexus/2.14.13-01
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Accept-Ranges: bytes
Location: http://maven.scijava.org/nexus/content/groups/public/

But with the trailing slash it’s fine:

$ curl -I https://maven.scijava.org/content/groups/public/
HTTP/1.1 200 OK
Date: Thu, 09 May 2019 19:07:54 GMT
Server: Nexus/2.14.13-01
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Accept-Ranges: bytes
Last-Modified: Thu, 02 May 2019 06:49:48 GMT

I have to figure out why the former returns 302 with bogus Location, and fix it.

For the moment, I added another rule:

RewriteRule ^/nexus(.*)$ %{REQUEST_SCHEME}://maven.scijava.org$1 [L,R=301]

So now we see:

$ curl -IL https://maven.scijava.org/content/groups/public
HTTP/1.1 302 Found
Date: Thu, 09 May 2019 19:11:53 GMT
Server: Nexus/2.14.13-01
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Accept-Ranges: bytes
Location: http://maven.scijava.org/nexus/content/groups/public/

HTTP/1.1 301 Moved Permanently
Date: Thu, 09 May 2019 19:11:53 GMT
Server: Apache/2.4.29 (Ubuntu)
Location: https://maven.scijava.org/nexus/content/groups/public/
Content-Type: text/html; charset=iso-8859-1

HTTP/1.1 301 Moved Permanently
Date: Thu, 09 May 2019 19:11:53 GMT
Server: Apache/2.4.29 (Ubuntu)
Location: https://maven.scijava.org/content/groups/public/
Content-Type: text/html; charset=iso-8859-1

HTTP/1.1 200 OK
Date: Thu, 09 May 2019 19:11:53 GMT
Server: Nexus/2.14.13-01
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Accept-Ranges: bytes
Last-Modified: Thu, 02 May 2019 06:49:48 GMT

Which, while roundabout, gets the job done.

As always, sorry for the hassle.

4 Likes
#10

@ctrueden No worries (I know how hard it is to setup those apache redirect rules)!. Now discovered that ivy also does not like the http to https redirect (fixed that in MM). Current MM repository builds (using the scijava address), I’ll try later with the old address… Bit scared about ivy’s ability to handle redirects. I guess that it is too hard to keep the old address working without redirects?

1 Like
#11

I can make it work without redirects. I would prefer to make HTTP (insecure) work only for certain needed user agents. Can you put a sample non-working project somewhere, so I can try to reproduce for testing things?

#12

@ctrueden You can check out the micro-manager 1.4 repository: svn co https://valelab4.ucsf.edu/svn/micromanager2/trunk/ . Then checkout revision r17023 (svn up r17023), which is the revision just before I changed to the scijava.net from imagej.net. Then:

./autogen.sh
./configure --enable-imagej-plugin=/path/to/ImageJ
make fetchdeps

The latter should list whether or not it succeed downloading dependencies from the various maven update sites. Beware of ivy caches.

Sorry for the heavyweight test. Pulling the essential elements out is quite a bit of work…

#13

Thanks, @nicost. I have migrated the maven.imagej.net virtual host over to the new machine that also hosts maven.scijava.org, and tweaked the configuration so that any user agent with “Ivy” in the name will receive the content directly without redirects. With this change, the Micro-Manager 1.4 build of r17023 now passes again. Please also test it yourself and confirm that it is really fixed.

Note that I had to change maven.imagej.net to point to a new IP address (144.92.48.199), so you should first run host maven.imagej.net and ensure your box reports that IP before you proceed with testing. In particular, if it reports 144.92.48.145 then that is the old IP and the compilation will still fail. It may be a few minutes or hours from time of this writing before the IP change fully propagates.

Using imageJ functions like type conversion and setting pixel size via pyimagej