Posted by
Kenneth Sloan-2 on
Jun 22, 2020; 9:51pm
URL: http://imagej.273.s1.nabble.com/Compiling-directories-and-jar-files-rules-tp5023539p5023569.html
This discussion is very timely for me.
As always - I do things a bit differently, but am trying to understand the current ImageJ conventions.
I typically compile plugins and create .jar files completely outside of ImageJ (the reasons are complicated, but this is unlikely to change).
Many of my plugins are completely independent of each other, and I try to make the .jar file for each one completely self-contained. This has (predictably) lead to some duplication - which is not really a problem, but I’m trying to use a better structure.
Currently, I install .jar files by dragging&dropping on my FIJI development environment. Clients can download .jar files from my Box account - or (more recently) use my ImageJ update site to download and install. All this works great.
Except…when I upload, I see that my duplications generate automatic dependencies (even circular dependencies) that I have to manually break. This is only a small annoyance, but yet another reason for me to try something new.
So - I’m about to split off a few utility clusters of classes and package each cluster as it’s own .jar file.
Questions:
a) am I correct that these .jar files should be installed in plugins/lib or plugins/jars?
b) is one of these “preferred”?
c) when uploading new versions of the top level plugin, how do I specify the dependency on the subsidiary .jar files?
d) when a client uses the ImageJ update site, what controls WHERE the subsidiary .jar files go? (I’m imagining a scenario where, left to their own devices, a client may put copies in BOTH plugins/lib and plugins/jars - so I’d like this under MY control, if possible).
Right now, I can think of at least 5 clusters that are mature enough to “publish” without fear of serious re-factoring. After that, there are perhaps another 5 small clusters of utilities.
Question:
e) is it reasonable to put EVERYTHING in one .jar file (“MyVeryOwnUtilities.jar”) - or is it better to create separate .jar files for each independent cluster of classes? Does it really matter?
I would appreciate guidance on the best way to proceed - but please, don’t suggest major changes in my development environment. For various reasons, I’m content with, and not likely to change my current tools, which are:
a) Emacs
b) ant
c) javac
Finally, my documentation is decidedly primitive, with virtually all important documentation written into the comments of my (java) code. I flirted with JavaDoc a decade or so ago and found it less than useful. I’m considering adding a few readMe.txt files scattered here and there and wonder - is there some mechanism I should consider? My current plan is to include readMe.txt files in the distributed .jar files. This may extend to .pdf files at some point.
And yet more (so…I lied about “finally”) at the moment, about half of my portfolio of plugins are “mature products” which I intend to be largely unchanged over the next 5 year, and another half are “quick hacks” which are aimed at very specific research projects. Some of these evolve into mature products; some continue to be used as “quick hacks” longer than they should, and some become dormant, even obsolete, until someone remembers one of them and I have to revive it from the ashes. I’m getting better at spotting the “quick hacks” which should be written as quick hacks and those which should be generalized and born as “industrial strength”. I’m constantly trying to balance these considerations - but not always succeeding.
Is it feasible to manage 10 different projects all using the same ImageJ update site? If so, is there any way to structure the update site to keep the several projects separate? Or, is there a better way. Given my initial experience, I hope to never have to establish another WIKI account - once was more than enough. (I’m grateful to those who helped me, but it did NOT go smoothly).
Have pity on an old man - I was distributing image processing packages before the first line of NIH Image was written…
--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html