[jboss-as7-dev] OSGi subsystem dependencies

[Carlo de Wolf]

On 11/29/2010 07:07 PM, Jason T. Greene wrote:
> This was talked about briefly on the pull request list, but no
> resolution was made.
>
> The issue is that JBAS-8585 and JBAS-8599 both add module dependencies
> from some of the core subsystems on to the osgi subsystem (naming and
> transactions). In addition we already have a module dependency from
> domain to osgi.  So for all intents and purposes, we are moving towards
> AS7 having osgi as a required base level component. Before progressing
> much further in this direction we should evaluate whether this is the
> right thing to do, and how this solution compares to alternative
> approaches. I can think of three approaches right off the bat.
>
> 1. Continue as is, osgi is a core required component
>      Pros: OSGi subsystem module is simpler, no additional subsystems or
> modules needed
>      Cons: AS7 must always have OSGi binaries no matter the configuration
>
> 2. Change the osgi subsystem to use optional dependencies on all of the
> subsystems it maps.
>      Pros: No additional subsystems are needed
>            AS7 no longer requires OSGi binaries
>      Cons: osgi subsystem code will need to do a lot of conditional
> checking for handling different subsystems being available
>
> 3. Create an osgi subsystem per subsystem it wraps (e.g. osgi-naming,
> osgi-transactions, etc)
>       Pros: OSGi subsystem code is simpler
>             AS7 no longer requires OSGi binaries
>       Cons: More subsystems are introduced, almost one per functional
>             subsystem.
>
> Let the debate begin :)
>

http://community.jboss.org/people/wolfc/blog/2010/11/26/strategies-for-separation-of-concern

Right now OSGi is implemented using strategy #1. Not only the module, 
but also the package scope is put on a slider and OSGi is added to it.

At the very least we should have it separated via packages, but this 
does mean not-so vigilant developers will ultimately take short-cuts. In 
itself that could be good or bad, but I think it ultimately just leads 
to a scenario were we bicker over what's considered a hack and what's 
considered functional regression.

Better go for strategy #3, put OSGi into a separate sub-module. This 
will still keep the number of top-level modules to a minimum and allows 
cross-cutting concerns to be implemented into sub-modules.
The same thing will happen once we start integrating transaction and 
security across the board.

Don't take it all the way up to #4, way too much work. ;-)

The important thing is: don't put scopes on a sliding slope. Once we've 
finished up a certain scope, close the book.

Carlo