<div dir="ltr"><div><div><div>Hi !<br><br>Thank you again for this conference !! <br>It was a great event, I was amazed by the quality of the talks ! <br>And the keynotes of Curtis were super-cool ! (I can't beleive you made each of them in less than 1 day !!) very efficient !<br><br></div><div>We've been around Madison, the place is extra !<br></div><div><br></div>I wish you a very productive hackathon !<br><br></div>Best and hope to see you soon !<br><br></div>Fabrice<br><div><div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-04-22 14:41 GMT+02:00 Kevin W Eliceiri <span dir="ltr"><<a href="mailto:eliceiri@wisc.edu" target="_blank">eliceiri@wisc.edu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">this is great guys, glad to seek<br>
<span class=""><br>
On 04/17/14, Curtis Rueden wrote:<br>
> Hi Jay & Erwin,<br>
><br>
> > Erwin and I are exploring the idea of a new version of JEX that would<br>
> > itself be a plugin of ImageJ.<br>
><br>
><br>
> That would be fantastic.<br>
><br>
> > There are a few different ways this could be developed... Either as<br>
> > part of the imagej managed code base (i.e. a package within a current<br>
> > ImageJ2 project or as its own maven project that is updated and<br>
> > managed like the rest of the ImageJ2 suite of projects like ij-app,<br>
> > ij-core, etc.) or as a completely separate project that we jarify and<br>
> > allow users to put into the plugin folder of ImageJ afterward.<br>
><br>
><br>
><br>
> The model we are targeting is "one Git repository per JAR file" with each being a Maven module with its own version. We have already completed this transition with the Fiji project [1], and ImageJ2 will be completely structured that way soon as well. This approach has many advantages:<br>
><br>
><br>
> 1) Stable release version couplings between components, so that if an upstream component changes, downstream components are not affected/broken until they intentionally upgrade to the newer version.<br>
><br>
><br>
> 2) Independent versioning of each component. When a bug is fixed in a particular component, we just release a new version of that component. No need to cut vacuous releases of the entire collection of ImageJ2 JARs.<br>
><br>
><br>
> 3) Easier and less intimidating to contribute to an individual plugin: just fork that one repo, push your changes and file a PR. No need to clone an all-encompassing fiji.git or imagej.git repository.<br>
><br>
><br>
</span>> Further, in the Fiji project, each module is now what we call an "external plugin" that lives in its own repository, either in the <a href="http://github.com/fiji(http://github.com/fiji)" rel="noreferrer" target="_blank">github.com/fiji(http://github.com/fiji)</a> namespace, or in some cases [2, 3] in the plugin developer's personal space (doesn't matter that much).<br>
<span class="">><br>
><br>
> ImageJ2 and Fiji support multiple update sites [4]. There is a core ImageJ2 update site [5], a core Fiji update site [6], and many others as well [7]. JEX would be a perfect fit for its own update site, giving you full control over every aspect of your releases while leveraging the power of ImageJ2 for deployment to your users.<br>
><br>
><br>
> In short: I would suggest creating a personal update site for JEX and serving your releases from there. That way, anyone using ImageJ2 or Fiji can install JEX simply by checking a box. For details, see:<br>
><br>
><br>
> <a href="http://fiji.sc/How_to_set_up_and_populate_an_update_site" rel="noreferrer" target="_blank">http://fiji.sc/How_to_set_up_and_populate_an_update_site</a><br>
><br>
><br>
><br>
> And as you know I would certainly advise structuring JEX as a Maven project, though it is not required. Here is a template you can use as a starting point:<br>
><br>
><br>
> <a href="https://github.com/imagej/minimal-ij1-plugin" rel="noreferrer" target="_blank">https://github.com/imagej/minimal-ij1-plugin</a><br>
><br>
><br>
> Very happy to answer any questions our issues you have on your journey. :-)<br>
><br>
><br>
> Regards,<br>
> Curtis<br>
><br>
><br>
> [1] <a href="https://github.com/fiji" rel="noreferrer" target="_blank">https://github.com/fiji</a><br>
> [2] <a href="https://github.com/tferr/ASA" rel="noreferrer" target="_blank">https://github.com/tferr/ASA</a><br>
><br>
</span>> [3] git://<a href="http://repo.or.cz/trakem2.git(http://repo.or.cz/trakem2.git)" rel="noreferrer" target="_blank">repo.or.cz/trakem2.git(http://repo.or.cz/trakem2.git)</a><br>
<span class="">> [4] <a href="http://fiji.sc/Update_Sites" rel="noreferrer" target="_blank">http://fiji.sc/Update_Sites</a><br>
> [5] <a href="http://update.imagej.net/" rel="noreferrer" target="_blank">http://update.imagej.net/</a><br>
> [6] <a href="http://fiji.sc/update/" rel="noreferrer" target="_blank">http://fiji.sc/update/</a><br>
> [7] <a href="http://fiji.sc/List_of_update_sites" rel="noreferrer" target="_blank">http://fiji.sc/List_of_update_sites</a><br>
><br>
><br>
><br>
</span>> On Thu, Apr 17, 2014 at 9:41 AM, Jay Warrick <<a href="mailto:warrick@wisc.edu">warrick@wisc.edu</a>(javascript:main.compose()> wrote:<br>
><br>
> > Sorry to clog your inbox. Evidently this didn't send last night and it got sent without closing the email... <br>
> ><br>
> > Any ideas or suggestions on a development approach would be welcome. You have sold me/us on your approach to application development. We want to integrate ourselves the best way possible but don't want to bring the project down by being less professional in our coding abilities and practices. We'll do our best but I'm not sure we'll ever be able to be on par with the rest of you guys :-)<br>
<span class="">> ><br>
> ><br>
> > I look forward to hearing from you. Thanks,<br>
> ><br>
> ><br>
> > Jay (and Erwin)<br>
> ><br>
> ><br>
> > Begin forwarded message:<br>
> ><br>
> ><br>
</span>> > > From: Jay Warrick <<a href="mailto:warrick@wisc.edu">warrick@wisc.edu</a>(javascript:main.compose()><br>
<span class="">> > ><br>
> > > Subject: JEX<br>
> > ><br>
> > > Date: April 17, 2014 at 9:35:04 AM CDT<br>
> > ><br>
</span>> > > To: Curtis Rueden <<a href="mailto:ctrueden@wisc.edu">ctrueden@wisc.edu</a>(javascript:main.compose()><br>
<span class="">> > ><br>
> > ><br>
> > > Hi Curtis,<br>
> > ><br>
> > > Erwin and I are exploring the idea of a new version of JEX that would itself be a plugin of ImageJ.<br>
> > ><br>
> > ><br>
</span>> > > There are a few different ways this could be developed... Either as part of the imagej managed code base (i.e. a package within a current ImageJ2 project or as its own maven project that is updated and managed like the rest of the ImageJ2 suite of projects like ij-app, ij-core, etc.) or as a completely separate project that we jarify and allow users to put into the plugin folder of ImageJ afterward. What might you recommend? We don't want to impose or muddy up your architecture but also really like the idea of being well-integrated with your current lifecycle management schemes (i.e. maven dependancies, compiling, versioning, and updating of jars (Jenkins etc).<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
<br>
--<br>
Kevin W. Eliceiri<br>
Director, Laboratory for Optical and Computational Instrumentation (LOCI)<br>
Departments Cell and Molecular Biology and Biomedical Engineering<br>
Affiliate Principal Investigator, Morgridge Institute for Research (MIR)<br>
Room 271 Animal Sciences, 1675 Observatory Drive, Madison, WI 53706<br>
Phone: <a href="tel:608-263-6288" value="+16082636288">608-263-6288</a><br>
<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" rel="noreferrer" target="_blank">http://imagej.net/mailman/listinfo/imagej-devel</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Fabrice de Chaumont<br>Institut Pasteur<br><div>Bioimage Analysis Unit<br></div><a href="http://icy.bioimageanalysis.org/" target="_blank">http://icy.bioimageanalysis.org/</a><br>CNRS UMR 3691<br>25, rue du docteur Roux - 75724 Paris Cedex 15 - France<br><br>Tél: +33 (0)1 45 68 86 90<br>Fax: +33 (0)1 40 61 33 30</div></div></div></div>
</div>