shared java classes?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

shared java classes?

Kenneth Sloan-3
I'm starting to have problems with multiple versions of (usually identical, sometimes not) Java classes used
by installed plugins.  I could use some advice on how to best deal with this.

For example - suppose I have two plugins, both of which use a collection of 5 Java Classes.

My current methodology is to share source code - putting a copy of the shared .java files in both development directories, and the resulting .class files end up in both .jar files (which I then drag&drop to install in FIJI).

This is never a problem, until I upgrade one or more of the same shared classes.   Then, it seems like a crap shoot to determine which class gets used by a particular plugin.

So..what's the best method of using just ONE copy of a shared set of classes?

My development environment is: emacs, ant.  The usual drill is to package up each plugin in it's own .jar file, which is drag&dropped into FIJI.  I almost never get a complaint about duplicates - but I do see cases where the "wrong" version is used in a particular plugin.  My fix at the moment is to un-install all of the old plugins, distribute the latest versions of a helper package to all the plugins that need it, and then re-installing these plugins in FIJI.

--
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
Reply | Threaded
Open this post in threaded view
|

Re: shared java classes?

ctrueden
Replying to this thread for the archives. The discussion happened on a
different thread:

http://imagej.1557.x6.nabble.com/java-plugin-administration-advice-tp5020087.html


On Sun, Feb 4, 2018 at 5:08 PM, Kenneth Sloan <[hidden email]>
wrote:

> I'm starting to have problems with multiple versions of (usually
> identical, sometimes not) Java classes used
> by installed plugins.  I could use some advice on how to best deal with
> this.
>
> For example - suppose I have two plugins, both of which use a collection
> of 5 Java Classes.
>
> My current methodology is to share source code - putting a copy of the
> shared .java files in both development directories, and the resulting
> .class files end up in both .jar files (which I then drag&drop to install
> in FIJI).
>
> This is never a problem, until I upgrade one or more of the same shared
> classes.   Then, it seems like a crap shoot to determine which class gets
> used by a particular plugin.
>
> So..what's the best method of using just ONE copy of a shared set of
> classes?
>
> My development environment is: emacs, ant.  The usual drill is to package
> up each plugin in it's own .jar file, which is drag&dropped into FIJI.  I
> almost never get a complaint about duplicates - but I do see cases where
> the "wrong" version is used in a particular plugin.  My fix at the moment
> is to un-install all of the old plugins, distribute the latest versions of
> a helper package to all the plugins that need it, and then re-installing
> these plugins in FIJI.
>
> --
> 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
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
|

Re: shared java classes?

Kenneth Sloan-3
Thank you to all who replied. I think I will probably use “package” to
create a separate namespace for each plugin. This will lead to some
redundancy, but better independence. It will also help when customers (on a
variety of platforms) need to build updates from source.

This technique was used previously by students working on this project, but
I did not fully appreciate the issues, and abandoned this practice as
“unnecessary”. Live and learn.

If “package” doesn’t work out, I will return to one of the methods proposed
in this thread.

Again - thank you for your time.
On Wed, Feb 14, 2018 at 09:03 Curtis Rueden <[hidden email]> wrote:

> Replying to this thread for the archives. The discussion happened on a
> different thread:
>
>
> http://imagej.1557.x6.nabble.com/java-plugin-administration-advice-tp5020087.html
>
>
> On Sun, Feb 4, 2018 at 5:08 PM, Kenneth Sloan <[hidden email]>
> wrote:
>
> > I'm starting to have problems with multiple versions of (usually
> > identical, sometimes not) Java classes used
> > by installed plugins.  I could use some advice on how to best deal with
> > this.
> >
> > For example - suppose I have two plugins, both of which use a collection
> > of 5 Java Classes.
> >
> > My current methodology is to share source code - putting a copy of the
> > shared .java files in both development directories, and the resulting
> > .class files end up in both .jar files (which I then drag&drop to install
> > in FIJI).
> >
> > This is never a problem, until I upgrade one or more of the same shared
> > classes.   Then, it seems like a crap shoot to determine which class gets
> > used by a particular plugin.
> >
> > So..what's the best method of using just ONE copy of a shared set of
> > classes?
> >
> > My development environment is: emacs, ant.  The usual drill is to package
> > up each plugin in it's own .jar file, which is drag&dropped into FIJI.  I
> > almost never get a complaint about duplicates - but I do see cases where
> > the "wrong" version is used in a particular plugin.  My fix at the moment
> > is to un-install all of the old plugins, distribute the latest versions
> of
> > a helper package to all the plugins that need it, and then re-installing
> > these plugins in FIJI.
> >
> > --
> > 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
> >
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html