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/fijinamespace, 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:
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
[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 <warr...@wisc.edu> 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 <warr...@wisc.edu>
> *Subject: **JEX*
> *Date: *April 17, 2014 at 9:35:04 AM CDT
> *To: *Curtis Rueden <ctrue...@wisc.edu>
>
> 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
ImageJ-devel@imagej.net
http://imagej.net/mailman/listinfo/imagej-devel
