NOTICE! This is a static HTML version of a legacy ImageJ Trac ticket.

The ImageJ project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Ticket #143 (closed task: wontfix)

Opened 2010-07-29T15:59:21-05:00

Last modified 2014-05-01T06:32:27-05:00

Explore use of OSGi

Reported by: curtis Owned by: curtis
Priority: major Milestone: imagej-3.0.0
Component: Plugin Framework Version:
Severity: non-issue Keywords:
Cc: dscho Blocked By:


Once our codebase is unified under Maven (see #96), we can easily tag our JARs with OSGi metadata, as well as explore use of the OSGi-based services architecture.

Relevant articles:

Change History

comment:1 Changed 2010-08-23T12:29:54-05:00 by curtis

  • Milestone changed from biweekly-2010: Aug-23 to Sep-03 to biweekly-2010: Nov-15 to Nov-24

comment:2 Changed 2010-11-29T10:58:28-06:00 by curtis

  • Milestone changed from biweekly-2010: Nov-15 to Nov-24 to biweekly-2011: Feb-28 to Mar-11

comment:3 Changed 2011-02-15T09:41:04-06:00 by curtis

  • Milestone changed from biweekly-2011: Feb-28 to Mar-11 to imagej-3.0

Due to time pressure, long-term exploratory tickets are being moved to the imagej-2.5 milestone or later.

comment:4 Changed 2013-03-26T10:15:19-05:00 by dscho

  • Cc dscho added

I just found out the other day that the Class-Path entry in the manifest is heeded by the URLClassLoader. We therefore might not need to go full-blown OSGi but it might suffice to have a "full" classloader just for sezpoz and a minimal classloader, initialized only with the .jar file in question, for actually loading the plugin.

To support this, MiniMaven has been taught to add the appropriate Class-Path entries, too.

Note: under certain circumstances which I haven't been able to investigate more closely, the Class-Path entry contains elements that resolve -SNAPSHOT versions (i.e. something like ij-core-2.0.0-20130314.040424-969.jar instead of ij-core-2.0.0-SNAPSHOT.jar). These circumstances would need to be identified and prevented if we were to go the proposed route.

comment:5 Changed 2014-05-01T06:32:27-05:00 by curtis

  • Status changed from new to closed
  • Resolution set to wontfix

At this point, dscho has looked at OSGi quite a bit. We even have support in the KNIME Image Processing build system to transparently wrap the SciJava software stack artifacts as OSGi bundles. But I doubt we will go full-blown OSGi with ImageJ any time soon. If there is a specific need or use case for doing that later, we can discuss further then.

Last edited 2014-05-01T06:32:43-05:00 by curtis