Hi Mike & everyone,<div><br></div><div>Johannes wrote:</div><div>> Ideally, however, you would really provide the very same .jar file (and<br>> likewise have really just one project) for both the IJ1 and IJ2 plugin. If<br>
> you wrap the ImagePlus into an ImgLib2 structure in the IJ1-specific part,<br>> you should be able to use the exact same code to perform the actual<br>> computation from both IJ1 and IJ2.<br><br>One downside to this approach is that by using ImageJ1's ImagePlus as your primary data structure, you will limit yourself to data types supported by ImageJ1. The other way round would be to use an ImageJ2 Dataset, which can be converted to an ImagePlus on the fly in IJ2's legacy layer.<br>
<br>I agree with Johannes that it is great to avoid duplicating code, but there may also be merit in maintaining a clean IJ2 version of the plugin. We will continue actively working on the IJ2 legacy layer to make this sort of code sharing easier.<br>
<br>Regards,<br>Curtis</div><div><br><br><div class="gmail_quote">On Mon, Jul 30, 2012 at 12:35 PM, Johannes Schindelin <span dir="ltr"><<a href="mailto:Johannes.Schindelin@gmx.de" target="_blank">Johannes.Schindelin@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Michael,<br>
<div class="im"><br>
On Sun, 29 Jul 2012, Michael Doube wrote:<br>
<br>
> In a new thread because it's a broad but different issue than the<br>
> others: How to move an active ImageJ1 plugin project to an ImageJ2<br>
> project?<br>
><br>
> The scenario:<br>
> I have an active ImageJ1 plugin project, which I want to move to Image2.<br>
> The old plugin needs to stay active with bugfixes and for archival<br>
> reasons. Currently, releases are tracked on the master branch of a Git<br>
> repository, the IDE is Eclipse and Ant is the builder. I'd like to keep<br>
> the whole project (IJ1 and IJ2 plugins) in the same Git repository.<br>
><br>
> The plan at the moment is to:<br>
> Keep releasing the old plugin on the master branch<br>
> Work on the new plugin on a version branch<br>
> When the new plugin is stable, send the old plugin to a legacy branch<br>
> and merge the new plugin to master<br>
<br>
</div>Personally, I would actually develop them in the same branch, in different<br>
subdirectories, for the time being. And if at all possible, I would try to<br>
re-use code all the time.<br>
<br>
Ideally, however, you would really provide the very same .jar file (and<br>
likewise have really just one project) for both the IJ1 and IJ2 plugin. If<br>
you wrap the ImagePlus into an ImgLib2 structure in the IJ1-specific part,<br>
you should be able to use the exact same code to perform the actual<br>
computation from both IJ1 and IJ2.<br>
<div class="im"><br>
> Because the two plugins use different build systems, I've set them up as<br>
> two separate Eclipse projects, one with the old style (Ant,<br>
> plugins.config) and one with the new style (Maven, annotations). The two<br>
> projects work on different branches of the same Git repository, so I can<br>
> work on both of them simultaneously in the same instance of Eclipse.<br>
<br>
</div>If you have a look at, say,<br>
<a href="https://github.com/fiji/fiji/tree/master/src-plugins/Arrow_" target="_blank">https://github.com/fiji/fiji/tree/master/src-plugins/Arrow_</a> you will see<br>
that it is quite doable to use Maven to build IJ1 plugins without any<br>
hassle.<br>
<div class="im"><br>
> To do that I branched the new plugin off, cloned it locally into a new<br>
> Eclipse project (Import...) then 'Mavenized' the new project. The<br>
> pom.xml-related chatter from me lately has been a result of this<br>
> process. The new branch has the old directory structure:<br>
> workspace/src/org/bonej/MyPlugin.java but Maven expects something else<br>
> by convention.<br>
<br>
</div>Yep, that is right, the convention is that your sources live in the<br>
src/main/java/ sub-directory of your project root directory. In your case,<br>
it would be:<br>
<br>
BoneJ/src/main/java/org/bonej/MyPlugin.java<br>
<br>
Also, I would strongly advise to keep the sources outside of the Eclipse<br>
workspace. We had a lot of "fun" with Eclipse that was solved simply by<br>
moving the project files outside of the workspace.<br>
<div class="im"><br>
> The big question is, is this going to work at all or should I start<br>
> again in a different way?<br>
<br>
</div>I'll not suggest to throw away all your hard work. If you want to follow<br>
my advice above, you can do that without re-starting the whole thing.<br>
<br>
For example, to get the IJ1 and IJ2 plugin reconciled into one branch, you<br>
could first change things in the IJ1 branch to use ImgLib2 and to use<br>
Maven, and then you could simply merge the IJ2 branch.<br>
<div class="im"><br>
> I am asking all this because processing of annotations doesn't work in<br>
> my setup, so the new plugin's menu items aren't added to ImageJ2<br>
> (solution is to use the Ant build.xml and Sun javac to do the release<br>
> build, as we developed at the last Fiji Hackathon).<br>
<br>
</div>Yes, the annotation processing is a little hairy. Our solution in ImageJ2<br>
is to force certain settings by tracking the .factorypath and<br>
.settings/org.eclipse.jdt.apt.core.prefs as part of our source code. This<br>
tells Eclipse to adher to the standard mandated by the Java specifications<br>
which demand that annotation processors present in the classpath when<br>
compiling Java sources be run.<br>
<br>
I have ticket in the ImageJ2 ticket system to make it easier to start<br>
developing a plugin in Eclipse, by providing a File>New Plugin (Eclipse)<br>
menu entry. I fully intend to write out the two files mentioned above<br>
together with a pom.xml file from there.<br>
<br>
Also note that starting with ImageJ2 beta3, Eclipse setups should be<br>
supported much better even when the annotation processors failed to be<br>
called: if you start ImageJ2 from within Eclipse, it should now detect<br>
that situation and run the annotation processors manually.<br>
<div class="im"><br>
> Do you see any disasters looming, or propose another streamlined<br>
> approach that will work? Maven is impressive so far, so I'd like to<br>
> continue with it, I just have to organise things so that it behaves<br>
> correctly.<br>
<br>
</div>Right, the problem is however not so much Maven as Eclipse's Maven<br>
emulation. One other thing I would strongly suggest to do is to make the<br>
scijava pom.xml the parent of your top-level pom.xml. That way, you not<br>
only get the ImageJ2 versions for free, but you also get some settings<br>
fixing issues in particular with Eclipse that at least yours truly<br>
struggled with for extended amounts of time. Just as an example: at some<br>
stage, Eclipse's Maven emulation stopped running the buildnumber plugin<br>
(which embeds the current commit into your .jar file's manifest,<br>
super-useful). After hours of research I finally found how to force it<br>
back to normal.<br>
<br>
And yes, you probably guessed it, the pom.xml which File>New Plugin<br>
(Eclipse) will write out will have the scijava pom as parent.<br>
<br>
Ciao,<br>
Dscho<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
ImageJ-devel mailing list<br>
<a href="mailto:ImageJ-devel@imagej.net">ImageJ-devel@imagej.net</a><br>
<a href="http://imagej.net/mailman/listinfo/imagej-devel" target="_blank">http://imagej.net/mailman/listinfo/imagej-devel</a><br>
</div></div></blockquote></div><br></div>