Re: JEX

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

Re: JEX

Curtis Rueden
Hi Jay & Erwin,

> Erwin and I are exploring the idea of a new version of JEX that would
> itself be a plugin of ImageJ.

That would be fantastic.
 
> 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.

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:

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.

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.

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.

Further, in the Fiji project, each module is now what we call an "external plugin" that lives in its own repository, either in the github.com/fiji namespace, or in some cases [2, 3] in the plugin developer's personal space (doesn't matter that much).

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.

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:


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:


Very happy to answer any questions our issues you have on your journey. :-)

Regards,
Curtis



On Thu, Apr 17, 2014 at 9:41 AM, Jay Warrick <[hidden email]> wrote:
Sorry to clog your inbox. Evidently this didn't send last night and it got sent without closing the email... 

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 :-)

I look forward to hearing from you. Thanks,

Jay (and Erwin)


Begin forwarded message:

From: Jay Warrick <[hidden email]>
Subject: JEX
Date: April 17, 2014 at 9:35:04 AM CDT
To: Curtis Rueden <[hidden email]>

Hi Curtis,

Erwin and I are exploring the idea of a new version of JEX that would itself be a plugin of ImageJ.

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).





_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: JEX

Jay Warrick
Hi Curtis,

So, I took a crack at getting a Maven project setup for the "JEX plugin" with a "hello world" run method. I think it is working so far (mostly). I think I likely need to add more dependancies because when I run and show ImageJ so that I may select JEX from the menu, I find that some of the other menu commands work and others give an error message (I think I at least need to add the ij-options project). However, I figure this is a point to get feedback on what I've done to set it up so far...

1) The maven project template was very helpful. Thanks. Although I really don't have much of an idea of what I should tweak from here. I figure mainly the name of the project and dependancies. Also, the template is based on ImageJ 1.x but I'm doing ImageJ2... I will be showing all the Command.class plugins within the JEX plugin as batchable commands within JEX and I don't know what all of those may depend on. So probably I should add all the ij projects as dependancies, right? If you have any other key words to search regarding maven project properties to search the web for to learn more about... I'm willing.

2) I tried to set up dependancies with my forked ImageJ2 maven projects in my eclipse workspace. Not sure how this will affect things downstream or if the magic of Maven will find jars if there are no projects when others clone this new project's repository to contribute. Advice?

3) Right now, the versions of the dependencies are fixed instead of flexible (e.g., using ${project.version} parameters) I have no idea what I'm doing :-) but when I changed the dependancy version to ${project.version} as done in the poms of the other ij projects, it gave an error. Mainly I just wanted this to point to the newest versions. Maybe fixed version is better / less prone to random new bugs as other things get updated so I should leave it as is for now and update version numbers manually moving forward?

4) If I make JEX a Command.class plugin, will the JEX plugin act like a modal window, blocking interaction with the main IJ2 UI while "running". If so, is there an alternative that won't block? I was hoping they could be open, operating, and interacting at the same time. Is there a more appropriate plugin class to do this?

5) Can you pass the singular ImageJ context/gateway as a parameter to the plugin or only services and whatnot? i.e., can I do the following?

@Parameter
private ImageJ ij;

6) I figure once things look a bit more reasonable as far as project readiness, I'll do the update site thing :-) Thanks for the tips and website. The instructions seem fairly straight forward.

Thanks in advance, for any help you can provide. The github repo for what I've done is here... (https://github.com/jaywarrick/JEX_IJ2) I've added you as a collaborator. I imagine this repo is what Erwin and I will build up, pulling JEX code in and cleaning/converting things as we do so.

Cheers,

Jay

On Apr 17, 2014, at 10:32 AM, Curtis Rueden <[hidden email]> wrote:

Hi Jay & Erwin,

> Erwin and I are exploring the idea of a new version of JEX that would
> itself be a plugin of ImageJ.

That would be fantastic.
 
> 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.

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:

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.

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.

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.

Further, in the Fiji project, each module is now what we call an "external plugin" that lives in its own repository, either in the github.com/fiji namespace, or in some cases [2, 3] in the plugin developer's personal space (doesn't matter that much).

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.

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:


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:


Very happy to answer any questions our issues you have on your journey. :-)

Regards,
Curtis



On Thu, Apr 17, 2014 at 9:41 AM, Jay Warrick <[hidden email]> wrote:
Sorry to clog your inbox. Evidently this didn't send last night and it got sent without closing the email... 

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 :-)

I look forward to hearing from you. Thanks,

Jay (and Erwin)


Begin forwarded message:

From: Jay Warrick <[hidden email]>
Subject: JEX
Date: April 17, 2014 at 9:35:04 AM CDT
To: Curtis Rueden <[hidden email]>

Hi Curtis,

Erwin and I are exploring the idea of a new version of JEX that would itself be a plugin of ImageJ.

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).






_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: JEX

Kevin W Eliceiri
In reply to this post by Curtis Rueden
this is great guys, glad to seek

On 04/17/14, Curtis Rueden  wrote:

> Hi Jay & Erwin,
>
> > Erwin and I are exploring the idea of a new version of JEX that would
> > itself be a plugin of ImageJ.
>
>
> That would be fantastic.
>
> > 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.
>
>
>
> 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:
>
>
> 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.
>
>
> 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.
>
>
> 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.
>
>
> Further, in the Fiji project, each module is now what we call an "external plugin" that lives in its own repository, either in the github.com/fiji(http://github.com/fiji) namespace, or in some cases [2, 3] in the plugin developer&#39;s personal space (doesn&#39;t matter that much).
>
>
> 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.
>
>
> 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:
>
>
> http://fiji.sc/How_to_set_up_and_populate_an_update_site
>
>
>
> 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:
>
>
> https://github.com/imagej/minimal-ij1-plugin
>
>
> Very happy to answer any questions our issues you have on your journey. :-)
>
>
> Regards,
> Curtis
>
>
> [1] https://github.com/fiji
> [2] https://github.com/tferr/ASA
>
> [3] git://repo.or.cz/trakem2.git(http://repo.or.cz/trakem2.git)
> [4] http://fiji.sc/Update_Sites
> [5] http://update.imagej.net/
> [6] http://fiji.sc/update/
> [7] http://fiji.sc/List_of_update_sites
>
>
>
> On Thu, Apr 17, 2014 at 9:41 AM, Jay Warrick <[hidden email](javascript:main.compose()> wrote:
>
> > Sorry to clog your inbox. Evidently this didn&#39;t send last night and it got sent without closing the email... 
> >
> > 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&#39;t want to bring the project down by being less professional in our coding abilities and practices. We&#39;ll do our best but I&#39;m not sure we&#39;ll ever be able to be on par with the rest of you guys :-)
> >
> >
> > I look forward to hearing from you. Thanks,
> >
> >
> > Jay (and Erwin)
> >
> >
> > Begin forwarded message:
> >
> >
> > > From: Jay Warrick <[hidden email](javascript:main.compose()>
> > >
> > > Subject: JEX
> > >
> > > Date: April 17, 2014 at 9:35:04 AM CDT
> > >
> > > To: Curtis Rueden <[hidden email](javascript:main.compose()>
> > >
> > >
> > > Hi Curtis,
> > >
> > > Erwin and I are exploring the idea of a new version of JEX that would itself be a plugin of ImageJ.
> > >
> > >
> > > 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&#39;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).
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >

--
Kevin W. Eliceiri
Director, Laboratory for Optical and Computational Instrumentation (LOCI)
Departments Cell and Molecular Biology and Biomedical Engineering
Affiliate Principal Investigator, Morgridge Institute for Research (MIR)
Room 271 Animal Sciences, 1675 Observatory Drive, Madison, WI 53706
Phone: 608-263-6288

_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: JEX

Fabrice de Chaumont
Hi !

Thank you again for this conference !!
It was a great event, I was amazed by the quality of the talks !
And the keynotes of Curtis were super-cool ! (I can't beleive you made each of them in less than 1 day !!) very efficient !

We've been around Madison, the place is extra !

I wish you a very productive hackathon !

Best and hope to see you soon !

Fabrice


2014-04-22 14:41 GMT+02:00 Kevin W Eliceiri <[hidden email]>:
this is great guys, glad to seek

On 04/17/14, Curtis Rueden  wrote:
> Hi Jay & Erwin,
>
> > Erwin and I are exploring the idea of a new version of JEX that would
> > itself be a plugin of ImageJ.
>
>
> That would be fantastic.
>
> > 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.
>
>
>
> 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:
>
>
> 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.
>
>
> 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.
>
>
> 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.
>
>
> Further, in the Fiji project, each module is now what we call an "external plugin" that lives in its own repository, either in the github.com/fiji(http://github.com/fiji) namespace, or in some cases [2, 3] in the plugin developer&#39;s personal space (doesn&#39;t matter that much).
>
>
> 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.
>
>
> 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:
>
>
> http://fiji.sc/How_to_set_up_and_populate_an_update_site
>
>
>
> 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:
>
>
> https://github.com/imagej/minimal-ij1-plugin
>
>
> Very happy to answer any questions our issues you have on your journey. :-)
>
>
> Regards,
> Curtis
>
>
> [1] https://github.com/fiji
> [2] https://github.com/tferr/ASA
>
> [3] git://repo.or.cz/trakem2.git(http://repo.or.cz/trakem2.git)
> [4] http://fiji.sc/Update_Sites
> [5] http://update.imagej.net/
> [6] http://fiji.sc/update/
> [7] http://fiji.sc/List_of_update_sites
>
>
>
> On Thu, Apr 17, 2014 at 9:41 AM, Jay Warrick <[hidden email](javascript:main.compose()> wrote:
>
> > Sorry to clog your inbox. Evidently this didn&#39;t send last night and it got sent without closing the email... 
> >
> > 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&#39;t want to bring the project down by being less professional in our coding abilities and practices. We&#39;ll do our best but I&#39;m not sure we&#39;ll ever be able to be on par with the rest of you guys :-)
> >
> >
> > I look forward to hearing from you. Thanks,
> >
> >
> > Jay (and Erwin)
> >
> >
> > Begin forwarded message:
> >
> >
> > > From: Jay Warrick <[hidden email](javascript:main.compose()>
> > >
> > > Subject: JEX
> > >
> > > Date: April 17, 2014 at 9:35:04 AM CDT
> > >
> > > To: Curtis Rueden <[hidden email](javascript:main.compose()>
> > >
> > >
> > > Hi Curtis,
> > >
> > > Erwin and I are exploring the idea of a new version of JEX that would itself be a plugin of ImageJ.
> > >
> > >
> > > 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&#39;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).
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >

--
Kevin W. Eliceiri
Director, Laboratory for Optical and Computational Instrumentation (LOCI)
Departments Cell and Molecular Biology and Biomedical Engineering
Affiliate Principal Investigator, Morgridge Institute for Research (MIR)
Room 271 Animal Sciences, 1675 Observatory Drive, Madison, WI 53706
Phone: <a href="tel:608-263-6288" value="+16082636288">608-263-6288

_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel



--
Fabrice de Chaumont
Institut Pasteur
Bioimage Analysis Unit
http://icy.bioimageanalysis.org/
CNRS UMR 3691
25, rue du docteur Roux - 75724 Paris Cedex 15 - France

Tél: +33 (0)1 45 68 86 90
Fax: +33 (0)1 40 61 33 30

_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel