Organizing plugins, utility classes and jars

[BenTupper]

Hi,

I have been (finally) getting to the point in ImageJ where I have  
collected suites of utility classes and plugins. Suppose that I have  
in the /plugins folder (a) folder of a menu-based plugin plus  
supporting utility classes, (b) a folder of utility classes, (c) a  
folder of a menu-based plugin than wants to use utilities from A and  
B, and (d) a folder called jars.


/plugins
        /pluginA (a plugin plus supporting classes)
                PluginA_.class (the plugin to ImageJ)
                UtilityA1.class
                UtilityA2.class
        /utilityB (utility classes)
                UtilityB1.class
                UtilityB2.class
        /pluginC
                PluginC_.class (wants to use utilities in A and B)
        /jars


My habit at this point is to create jars of the utilities within A and  
B, place them in the /jars folder, and finally remove the original  
code and classes so ImageJ finds only the jars.  Creating the jar in A  
is a little tricky because I don't want to place the menu-based plugin  
"PluginA_.class" in the jar.  It seems a little clunky (and perhaps  
risky) to move the code in and out of the ImageJ/plugins directory.  
It certainly is a pesky process when developing in directory C  
requires modifying the code in A or B.

Is there a conventional way to manage this process that requires less  
effort and risk on my part?

Thanks!
Ben

Ben Tupper

[Michael Schmid]

Hi Ben,

two remarks:

In your approach, there is no need to remove the .java files from the  
plugins subdirectories; it is enough to remove the .class files that  
are now in a .jar
ImageJ won't compile .java files unless they are needed for  
'Compile&Run'

--
My usual approach for editing a larger package is copying the  
directory with the sources as a whole into the plugins folder, moving  
the jar somewhere else (actually, I name it .zip; ImageJ accepts  
also .zip in place of .jar; the advantage is that one can more easily  
add/replace files in a .zip, at least under Windows).
Then I do the changes until everything works; and I copy the  
new .class files into the zip (jar) and I move the new sources back  
to my home directory. Finally, I delete the remaining class files and  
put the zip (jar) file back into place.

You can have a plugins.config file in the jar to specify which  
plugins should appear in the menu and where.
   http://rsb.info.nih.gov/ij/plugins/jar-demo.html

I have this plugins.config file together with the sources, so I can  
also create a new zip from the whole subdirectory of the plugins (and  
remove the sources afterwards if desired)
I have a flat folder, no hierarchy, however; possibly this won't work  
with subfolders.


Michael
________________________________________________________________

On 27 Aug 2009, at 02:52, Ben Tupper wrote:

> Hi,
>
> I have been (finally) getting to the point in ImageJ where I have  
> collected suites of utility classes and plugins. Suppose that I  
> have in the /plugins folder (a) folder of a menu-based plugin plus  
> supporting utility classes, (b) a folder of utility classes, (c) a  
> folder of a menu-based plugin than wants to use utilities from A  
> and B, and (d) a folder called jars.
>
>
> /plugins
> /pluginA (a plugin plus supporting classes)
> PluginA_.class (the plugin to ImageJ)
> UtilityA1.class
> UtilityA2.class
> /utilityB (utility classes)
> UtilityB1.class
> UtilityB2.class
> /pluginC
> PluginC_.class (wants to use utilities in A and B)
> /jars
>
>
> My habit at this point is to create jars of the utilities within A  
> and B, place them in the /jars folder, and finally remove the  
> original code and classes so ImageJ finds only the jars.  Creating  
> the jar in A is a little tricky because I don't want to place the  
> menu-based plugin "PluginA_.class" in the jar.  It seems a little  
> clunky (and perhaps risky) to move the code in and out of the  
> ImageJ/plugins directory.  It certainly is a pesky process when  
> developing in directory C requires modifying the code in A or B.
>
> Is there a conventional way to manage this process that requires  
> less effort and risk on my part?
>
> Thanks!
> Ben
>
> Ben Tupper

[dscho]

Hi,

On Thu, 27 Aug 2009, Michael Schmid wrote:

> two remarks:

I only see one.

> In your approach, there is no need to remove the .java files from the
> plugins subdirectories; it is enough to remove the .class files that are
> now in a .jar ImageJ won't compile .java files unless they are needed
> for 'Compile&Run'

Note that this is not true in Fiji: as we ship a Java compiler, we
integrated transparent support for .java files.  Just drop the .java files
anywhere in plugins/ and Fiji will show them in the appropriate place in
the Plugins menu.

Leaving the .java files in plugins/ if you do not need/want them would be
sloppy anyway.

Ciao,
Dscho

[BenTupper]

Thanks to you each for the answers.

I would like to keep the source files in place if I can.  Ours is a  
very small shop - so to speak - and it feels better to keep all of the  
important papers in the same shoebox (with regular backups to another  
shoebox of course!)  But it occurs to me that when making a jar I  
should perhaps do it in two steps...

(1) jar cvfM BenUtility.jar *.class

(2) rm *.class

I can then leave the jar and the source code (along with special test  
images, the html api, etc)  in the subdirectory.  Then when I need to  
distribute plugins/utilities to my lab-mates I can simply send the jar  
- with reduced risk from moving things in-and-out.  If I can just  
remember to not do "rm *.java"...

Cheers,
Ben



On Aug 27, 2009, at 6:16 AM, Michael Schmid wrote:

> Hi Ben,
>
> two remarks:
>
> In your approach, there is no need to remove the .java files from  
> the plugins subdirectories; it is enough to remove the .class files  
> that are now in a .jar
> ImageJ won't compile .java files unless they are needed for  
> 'Compile&Run'
>
> --
> My usual approach for editing a larger package is copying the  
> directory with the sources as a whole into the plugins folder,  
> moving the jar somewhere else (actually, I name it .zip; ImageJ  
> accepts also .zip in place of .jar; the advantage is that one can  
> more easily add/replace files in a .zip, at least under Windows).
> Then I do the changes until everything works; and I copy the  
> new .class files into the zip (jar) and I move the new sources back  
> to my home directory. Finally, I delete the remaining class files  
> and put the zip (jar) file back into place.
>
> You can have a plugins.config file in the jar to specify which  
> plugins should appear in the menu and where.
>  http://rsb.info.nih.gov/ij/plugins/jar-demo.html
>
> I have this plugins.config file together with the sources, so I can  
> also create a new zip from the whole subdirectory of the plugins  
> (and remove the sources afterwards if desired)
> I have a flat folder, no hierarchy, however; possibly this won't  
> work with subfolders.

On Aug 27, 2009, at 7:50 AM, Johannes Schindelin wrote:
>
> Leaving the .java files in plugins/ if you do not need/want them  
> would be
> sloppy anyway.
>



Ben Tupper

[dscho]

Hi,

On Thu, 27 Aug 2009, Ben Tupper wrote:

> I would like to keep the source files in place if I can.  Ours is a very
> small shop - so to speak - and it feels better to keep all of the
> important papers in the same shoebox (with regular backups to another
> shoebox of course!)  But it occurs to me that when making a jar I should
> perhaps do it in two steps...
>
> (1) jar cvfM BenUtility.jar *.class

Why not simply

        jar cvf ../plugins/BenUtility.jar *.class plugins.config

?

But hey, if you insist...

Ciao,
Dscho