Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Abandoned
-
None
-
None
-
None
-
None
Description
Use of OSGi Bundles and OSGi core framework to control dependencies and code base evolution.
Common components between a Service and its download client jar need to be packaged separately, such that both the Service and client depend on this package, forming an indirect dependency link between the client and service. The common component also needs to be downloadable.
Attachments
Issue Links
- blocks
-
RIVER-72 Outrigger keeps local attributes in marshalled form, prevents codebase evolution
- Open
-
RIVER-79 Mahalo stores local attributes in marshalled form, prevents codebase evolution
- Open
-
RIVER-80 Mercury stores local attributes in marshalled form, prevents codebase evolution
- Open
-
RIVER-190 Fiddler stores local attributes in marshalled form, prevents codebase evolution
- Open
- incorporates
-
RIVER-316 RFC Library, Application & Class Versioning, Dynamically Mobile Codebases and Classloading enhancements
- Open
- is related to
-
RIVER-150 Reggie codebase evolution problematic for persisted local objects
- Open
- relates to
-
RIVER-48 Lookup service type matching semantics are unclear or difficult to implement
- Open
-
RIVER-125 Norm stores local attributes in marshalled form, prevents codebase evolution
- Open
-
RIVER-238 Serialized form of MarshalledInstance needs some more specification
- Open
-
RIVER-149 net.jini.export.ServerContext spec shouldn't rely on the system classloader
- Resolved
-
RIVER-315 "Translation layer" from OSGi components and River services and back again
- Resolved
-
RIVER-317 Deploy Apache River artifacts to Maven repositories (both release and snapshot)
- Resolved