Use newer gentyref dependency

[ghisvail]

The code for gentyref was moved to GitHub and the organisation was changed accordingly, from com.googlecode.gentyref to com.coekie.gentyref. Please consider updating scijava-common to use the newer version, which will improve its packageability by Linux distributions.

Unfortunately, the eventbus dependency is a trickier one to deal with. Does anyone know where the source code repository is?

Cheers,

[imagejan]

@ghisvail wrote:

Unfortunately, the eventbus dependency is a trickier one to deal with. Does anyone know where the source code repository is?

It seems like at least a fork of this project is here:

https://github.com/wumpz/eventbus

[ghisvail]

@imagejan Thanks for the pointers. Just found the official version:

https://github.com/michaelbushe/EventBus

[ctrueden]

Regarding GenTyRef, SciJava Common will stop depending on it soon; see the generic-types branch (6be1858 specifically). I'll close this issue when that branch merges to master.

If it would help with packageability, we could do something similar with EventBus, since it is also a small library, and does not seem to be actively developed anymore. Please let us know if so, and I can investigate; otherwise, I'll assume you are able to package eventbus successfully.

[ghisvail]

Regarding GenTyRef, SciJava Common will stop depending on it soon

Ok, so I'd probably wait then. Right now, I have parsington and imglib2 ready for submission and was walking down the dependency tree for ImageJ2, which lead me to scijava-common.

If it would help with packageability, we could do something similar with EventBus

If both the gentyref and eventbus dependencies can be dropped, then that would make scijava-common easier to package once parsington is accepted. So, yes please :-)

[ctrueden]

So, yes please :-)

Great, I filed issue #282 to remind me to do that. It will likely be a few weeks, due to other priorities, but I think merging the eventbus code into SJC is a good move regardless.

Regarding parsington, we are considering separating that dependency as well into a scijava-script component, so that SJC proper does not depend on it. Have not settled on doing that for sure, though. It wouldn't help you a lot, probably, because scijava-script would certainly then be a dependency of downstream things like imagej-scripting. I don't want to pull the rug out from under you while you're working through the components, so we can certainly wait on such changes for the time being.

I'm excited that you are working on this. Did you make a forum post yet about what you are trying to achieve? If so, could you point me to it? If not, could you start a quick thread on http://forum.imagej.net/ describing your goals? It would be awesome for the community to be aware of which distros you are targeting, etc., and possibly even help, since there are quite a few people who are anxiously awaiting (presumably some flavor(s) of Linux) packages for the ImageJ2 components!

[ctrueden]

One other thing: there are enough Java components that it would be really good to have an automated way of wrapping them as packages as new versions are released. Otherwise, the packages will quickly fall out of date, and you will be exhausted as a maintainer.

Relatedly, have you seen imagej/ImageJ#162? That discussion is with respect to Gentoo, but there have also been major efforts at packaging Fiji for Debian in the past by @mhl, which I can point you at if desired. He put some effort into automation, but at the time, the licensing of individual Fiji components was too hairy in some cases. We have since made great strides in purging incompatibly licensed components from Fiji, so it should in theory be possible to fully package Fiji now. Just a lot of work to do manually, since there are hundreds of JAR files.

[ghisvail]

Regarding parsington, we are considering separating that dependency as well into a scijava-script component

But parsington would still exist and be needed for the ImageJ2 stack, right?

Did you make a forum post yet about what you are trying to achieve?

I have not, since my effort is still in its infancy. Right now, I am trying to get to know the stack, whilst engaging with leaf dependencies like parsington and imglib2.

Relatedly, have you seen imagej/ImageJ#162? That discussion is with respect to Gentoo...

What applies to Gentoo will generally apply to other distros, so their advice is worth taking into account.

there have also been major efforts at packaging Fiji for Debian

The focus is on ImageJ2 for now, which will already be quite a task.

[ctrueden]

But parsington would still exist and be needed for the ImageJ2 stack, right?

Yes, that library is very stable and will remain a dependency. So efforts to package it are worthwhile. I just meant that it may not remain a dependency of scijava-common specifically. In general, we want scijava-common to have minimal dependencies.

Right now, I am trying to get to know the stack, whilst engaging with leaf dependencies like parsington and imglib2.

Sounds good.

What applies to Gentoo will generally apply to other distros, so their advice is worth taking into account.

Which distros are you personally looking at / interested in?

The focus is on ImageJ2 for now, which will already be quite a task.

Indeed. As part of that, we are willing/happy to discuss paring down the "core ImageJ2" dependencies to make this easier. For example, the imagej-scripting component exists to bring together all of the SciJava script language components under one roof for consumption by ImageJ2. But we do not necessarily need for it to be a required dependency of net.imagej:imagej. It would vastly reduce the dependency tree of ImageJ2 if we made that optional. My dream long-term is for ImageJ to detect when a feature is being used which is not currently on the classpath, and prompt the user to install the needed JAR file(s) in order to continue. This would let the actual net.imagej:imagej component have a much smaller footprint, although I realize it brings certain problems with package managers—in particular, such add-ons would always need to be installed in user space (e.g., under ~/.imagej/plugins) rather than system wide. Otherwise you end up with a bad situation like Eclipse, which plays horribly with Linux package managers.

[ghisvail]

Which distros are you personally looking at / interested in?

Debian

It would vastly reduce the dependency tree of ImageJ2 if we made that optional.

Which is a good thing as far as modularity is concerned too.

in particular, such add-ons would always need to be installed in user space (e.g., under ~/.imagej/plugins) rather than system wide

I have seen such pattern used in the Python stack too. This way, you can have support for both system-wide / packaged plugins and user specific ones.

Otherwise you end up with a bad situation like Eclipse, which plays horribly with Linux package managers.

Hence why Debian gave up on it.

[ghisvail]

@ctrueden Could you let me know what other leaf packages could be dealt with now, besides parsington and imglib2? Cheers,

[ctrueden]

what other leaf packages could be dealt with now, besides parsington
and imglib2?

Including third party packages? Or only SciJava ones?

Some third party ones which will probably not disappear any time soon:

• com.jcraft:jsch
• com.miglayout:miglayout
• org.jfree:jfreechart (though not a leaf; it depends on org.jfree:jcommon)
• com.fifesoft:rsyntaxtextarea

And it is likely we'll have a dependency on com.google.guava:guava in the future too.

Other third party leaf components which are not likely to disappear, but could be made to disappear if absolutely necessary:

• edu.mines:mines-jtk
• gov.nist.math:jama
• net.sf.trove4j:trove4j
• edu.ucar:udunits

At a quick glance, I didn't see any other leaf dependencies in the ImageJ software stack specifically.

And apologies if any of the above are not actually leaves; I just did a quick glance at mvn dependency:tree which is known to do some pruning of redundant dependencies.

[ghisvail]

And it is likely we'll have a dependency on com.google.guava:guava in the future too.

That's quite a big one :S

[ctrueden]

Yes Guava is big, but... no dependencies! 😛

[ghisvail]

Already packaged in Debian:

com.jcraft:jsch
com.miglayout:miglayout
org.jfree:jfreechart
com.fifesoft:rsyntaxtextarea
gov.nist.math:jama

Packaged but not at its latest major version:

net.sf.trove4j:trove4j

Version 2.x, latest is 3.x.

Not packaged yet:

edu.mines:mines-jtk
edu.ucar:udunits
com.google.guava:guava