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: | |
| Blocking: |
Description
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.