: RE File type on Mac

[Albert Cardona]

>> For some time I have been thinking that it would be ideal to have a
>> ImageJ live CD. But for this one needs to carefully choose what to put
>> in and then maintain it! It is certainly not a job to do alone.
>>    
>
> Heh, you are certainly not the only one thinking about such a thing.  Stay
> tuned; I think it'll take about 3-4 weeks until we announce something.
>
> (Yes, this is meant to make you curious...)
>
> Ciao,
> Dscho
>  

Now, who in the world could be involved in something like that!


--
Albert Cardona
http://www.mcdb.ucla.edu/Research/Hartenstein/acardona

[dscho]

Hi,

On Mon, 21 Jan 2008, Albert Cardona wrote:

> > > For some time I have been thinking that it would be ideal to have a
> > > ImageJ live CD. But for this one needs to carefully choose what to
> > > put in and then maintain it! It is certainly not a job to do alone.
> >
> > Heh, you are certainly not the only one thinking about such a thing.  
> > Stay tuned; I think it'll take about 3-4 weeks until we announce
> > something.
> >
> > (Yes, this is meant to make you curious...)
>
> Now, who in the world could be involved in something like that!

Hey, don't give your participation away!

Actually, I should be honest.  All of this was Albert's idea.  But it is
not finished yet.  So please, stay tuned.

Ciao,
Dscho

[J H-4]

Hi
      The key to changing and reloading a plugin without closing ImageJ is:
            the plugin absolutely CANNOT be loaded by the system classloader
when ImageJ starts up.

The technical explanation is that the Java JVM uses an object called a
ClassLoader to load all the compiled classes into memory when the
application starts (actually it uses several ClassLoaders).  Now, if your
plugin is loaded by the system ClassLoader, it's pretty much etched in stone
and cannot be changed.  However, ImageJ uses its own special
ij.io.PluginClassLoader for loading plugins.  Plugins that are loaded by the
ImageJ ClassLoader but NOT the system ClassLoader CAN be changed during
runtime.  So the trick is to make sure that our plugins are NOT loaded by
the system ClassLoader.  The easiest way is to keep the plugin classes out
of the CLASSPATH when we run ImageJ. Here's how:

1) for NetBeans, download and install ImageJ source as described in
http://rsb.info.nih.gov/ij/developer/NBTutorial.html

Method #1:

2)  Undo step 1) in the guide, i.e. line 12 of source/build.xml should be
uncommented  <exclude name="plugins/**"/>
3) select Build->Clean and build Main Project
4) Manually right click on each of your plugins in the project window and
select "Compile File", the class files should be put in the plugins
directory, not in the build directory.
5) select Run-> Debug Main project

You should see your plugin in the ImageJ plugin menu and be able to run it.

To change the plugin and reload it into a running ImageJ
6) With ImageJ still running, make changes to your plugin code
7) Repeat step 4) and wait for it to finish compiling
8) In the running ImageJ instance, hold down the ALT key and select your
plugin from the ImageJ plugin menu (***VERY IMPORTANT to hold ALT while
clicking your plugin***)

The newly altered plugin should run.

What holding down the ALT key does is make ImageJ dump it's old plugin
ClassLoader and create a new ClassLoader.  If you do not hold down the ALT
key, then the old ClassLoader reuses the old Class without loading your new
one. See IJ.java runPlugIn() line ~124.

If you have a lot of plugins that change, or you don't want to manually
compile each plugin, you can automate this a little using the ant script as
follows.

Method #2

In build.xml in the "compile" target
2) comment out the line 12 i.e. change it to   <!-- <exclude
name="plugins/**"/> -->
3) After the </javac> tag line 13, add:

  <move todir="plugins">
      <fileset dir="build">
        <include name="*.class"/>
        <exclude name="ij"/>
        <exclude name="macros"/>
        <exclude name="about.jpg"/>
        <exclude name="IJ_Props.txt"/>
        <exclude name="microscope.gif"/>
      </fileset>
    </move>

4) select Build->Clean and Build Main Project
5) select Run-> Debug Main project

After you edit plugin code while ImageJ is running, then simply click
Build->Build Main Project (not Clean and Build) to re-compile all the plugin
classes at once. Then repeat step 8) above.

NOTES:
-Any breakpoints you set in your plugin will stop the debugger and give you
full control in the IDE.
-If your plugin does not show up, you may need to change the .plugins.dir to
point to the plugins folder
-This same concept should work in any IDE

For any of you that do not use and IDE, it is completely worth taking the
time to learn.

PS, quick tidbit, if you want to debug from the class files instead of the
jar file (sometimes the breakpoints in the IJ core code work better)
1) in the Files window, open the file ide-targets.xml in the nbproject
folder
2) change
      <java fork="yes" jar="ij.jar" maxmemory="256m">
to
      <java fork="yes" classpath="build" classname="ij.ImageJ"
maxmemory="512m">





             Joachim Wesner
             <joachim.wesner@L
             EICA-MICROSYSTEMS                                          To
             .COM>                     [hidden email]
             Sent by: ImageJ                                            cc
             Interest Group
             <[hidden email].                                     Subject
             GOV>                      ImageJ plugin development using
                                       (external) debugger

             01/21/2008 08:27
             AM


             Please respond to
              ImageJ Interest
                   Group
             <[hidden email].
                   GOV>






Hi there,

I know this has been already been discussed in this list, but I do notseem
to find the info I´m interested in, resp. maybe what I want to acchieve is
simply not possible....

Up to now, I have exclusively used the built in Editor and compiler
mechanism of ImageJ to develop small to medium size plugins, which works
quite well. However, for more complex plugins,
having at hand a more complex IDE and debugger would be great. There are
quite a lot of HOWTOs to use Eclipse for this, I also managed to compile
and run ImageJ with JCreator, for example. So far so good.

However, if I understand correctly, using an external IDE like Eclipse for
plugin development effectively mean restarting ImageJ everytime I change my
code, RIGHT? So I am forced to reload any data, stacks, ROis etc,
I need to test my plugin!?

I consider this a BIG minus, one of the advantages of the built-in solution
actually IMHO is that I can leave the windows with my test cases open all
the time.

Is there a way to do this with an external IDE/debugger? Somehow to
"attach" to the already running Imagej process?


Mit freundlichen Grüßen / Best regards

Joachim Wesner
____________________________________________

Leica Microsystems CMS GmbH | GmbH mit Sitz in Wetzlar | Amtsgericht
Wetzlar  HRB 2432
Geschäftsführer:  Dr. Stefan Träger | Dr. Wolf-Otto Reuter | Dr. David Roy
Martyr | Colin Davis


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

[Joachim Wesner]

JH, high,

WOW, this is a very detailed posting and seems to clarify a lot. Didn´t
know about the "Alt"-trick, is it somewhere in the official docs?
If not, it should be included.

 It seems, this behaviour of the internal classloader also might explain
the strange "feature" I discovered a while ago, that after having the
plugins
directory in the ImageJ class path any changes to files in the plugins root
do not seem to be recognized by ImageJ (the changed class is not reloaded
 even when using the internal compile mechnism). I will check what "Alt"
does to this behaviour!

Thanx a lot

Mit freundlichen Grüßen / Best regards

Joachim Wesner

Leica Microsystems CMS GmbH | GmbH mit Sitz in Wetzlar | Amtsgericht
Wetzlar  HRB 2432
Geschäftsführer:  Dr. Stefan Traeger | Dr. Wolf-Otto Reuter | Dr. David Roy
Martyr | Colin Davis

ImageJ Interest Group <[hidden email]> schrieb am 23.01.2008 22:59:05:

> Hi
>       The key to changing and reloading a plugin without closing ImageJ
is:
>             the plugin absolutely CANNOT be loaded by the system
classloader
> when ImageJ starts up.
>
> The technical explanation is that the Java JVM uses an object called a
> ClassLoader to load all the compiled classes into memory when the
> application starts (actually it uses several ClassLoaders).  Now, if your
> plugin is loaded by the system ClassLoader, it's pretty much etched in
stone
> and cannot be changed.  However, ImageJ uses its own special
> ij.io.PluginClassLoader for loading plugins.  Plugins that are loaded by
the
> ImageJ ClassLoader but NOT the system ClassLoader CAN be changed during
> runtime.  So the trick is to make sure that our plugins are NOT loaded by
> the system ClassLoader.  The easiest way is to keep the plugin classes
out

> of the CLASSPATH when we run ImageJ. Here's how:
>
> 1) for NetBeans, download and install ImageJ source as described in
> http://rsb.info.nih.gov/ij/developer/NBTutorial.html
>
> Method #1:
>
> 2)  Undo step 1) in the guide, i.e. line 12 of source/build.xml should be
> uncommented  <exclude name="plugins/**"/>
> 3) select Build->Clean and build Main Project
> 4) Manually right click on each of your plugins in the project window and
> select "Compile File", the class files should be put in the plugins
> directory, not in the build directory.
> 5) select Run-> Debug Main project
>
> You should see your plugin in the ImageJ plugin menu and be able to run

it.

>
> To change the plugin and reload it into a running ImageJ
> 6) With ImageJ still running, make changes to your plugin code
> 7) Repeat step 4) and wait for it to finish compiling
> 8) In the running ImageJ instance, hold down the ALT key and select your
> plugin from the ImageJ plugin menu (***VERY IMPORTANT to hold ALT while
> clicking your plugin***)
>
> The newly altered plugin should run.
>
> What holding down the ALT key does is make ImageJ dump it's old plugin
> ClassLoader and create a new ClassLoader.  If you do not hold down the

ALT
> key, then the old ClassLoader reuses the old Class without loading your
new
> one. See IJ.java runPlugIn() line ~124.
>
> If you have a lot of plugins that change, or you don't want to manually
> compile each plugin, you can automate this a little using the ant script
as

> follows.
>
> Method #2
>
> In build.xml in the "compile" target
> 2) comment out the line 12 i.e. change it to   <!-- <exclude
> name="plugins/**"/> -->
> 3) After the </javac> tag line 13, add:
>
>   <move todir="plugins">
>       <fileset dir="build">
>         <include name="*.class"/>
>         <exclude name="ij"/>
>         <exclude name="macros"/>
>         <exclude name="about.jpg"/>
>         <exclude name="IJ_Props.txt"/>
>         <exclude name="microscope.gif"/>
>       </fileset>
>     </move>
>
> 4) select Build->Clean and Build Main Project
> 5) select Run-> Debug Main project
>
> After you edit plugin code while ImageJ is running, then simply click
> Build->Build Main Project (not Clean and Build) to re-compile all the

plugin
> classes at once. Then repeat step 8) above.
>
> NOTES:
> -Any breakpoints you set in your plugin will stop the debugger and give
you
> full control in the IDE.
> -If your plugin does not show up, you may need to change the .plugins.dir
to
> point to the plugins folder
> -This same concept should work in any IDE
>
> For any of you that do not use and IDE, it is completely worth taking the
> time to learn.
>
> PS, quick tidbit, if you want to debug from the class files instead of
the
> jar file (sometimes the breakpoints in the IJ core code work better)
> 1) in the Files window, open the file ide-targets.xml in the nbproject
> folder
> 2) change
>       <java fork="yes" jar="ij.jar" maxmemory="256m">
> to
>       <java fork="yes" classpath="build" classname="ij.ImageJ"
> maxmemory="512m">
>


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________