[ https://issues.apache.org/jira/browse/DERBY-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571993#action_12571993 ]
Dibyendu Majumdar commented on DERBY-3405: ------------------------------------------ > Why is a bundle needed. These classes are only needed at compile time, not a > runtime. Does OSGi require a bundle even for compiling? I think that it is possible to have a plain old library (jar) and include this in a bundle. But, so far putting reference package in its own bundle seems to be working okay. > Examine the possibility of implementing Derby modules as OSGI bundles > --------------------------------------------------------------------- > > Key: DERBY-3405 > URL: https://issues.apache.org/jira/browse/DERBY-3405 > Project: Derby > Issue Type: New Feature > Reporter: Dibyendu Majumdar > Assignee: Dibyendu Majumdar > > At present, Derby as a whole is offered as an OSGI bundle. > Internally, Derby does not use OSGI for managing modules. Modules and > services (which are collections of modules) are managed using the Monitor > component, which is a custom IoC container, designed specifically for Derby. > Some of the features of the Monitor component, mirror facilities offered by > OSGI. The obvious ones are: > a) Loading modules based upon environment. The features offered by the > Monitor subsystem were described by Dan like this: > The monitor ... selects the module implementation that is suitable for the > given environment by: > - seeing what the current JDK level is and if a module implementation > supports it > - seeing what classes a module implementation requires and if they exist > - if the module implements ModuleSupportable and if so asking the module if > it can support the current environment. > As an example, modules.properties today contains three JDBC implementations, > JSR169, JDBC 3 and JDBC 4, having multiple exist is not an issue, the monitor > selects the correct one. > The ability to load bundles based on environment compatibility is one of OSGI > features. > b) Resolving module interdependencies. > c) Managing life-cycle of services and modules. > A migration from the Monitor component to an OSGI based packaging is not > going to be an easy transition. At this stage, therefore, this is more of an > experiment. > The benefits of using OSGI are: > a) It supports dependencies based upon versions of bundles. > b) It will make it easier to add/remove components, specially at run-time. > However, the use case for this needs defining. > c) It may open up Derby to other possibilities ... > The disadvantages are: > a) Introduces a dependency on OSGI - whereas Derby at present has its own IoC > implementation. > b) Will mean a major change to how Derby is bundled and therefore potentially > impact users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.