[
https://issues.apache.org/jira/browse/MNG-7518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MNG-7518.
--------------------------------
Resolution: Won't Fix
> Use OSGi to support different libaries in addition to the current class-realms
> ------------------------------------------------------------------------------
>
> Key: MNG-7518
> URL: https://issues.apache.org/jira/browse/MNG-7518
> Project: Maven
> Issue Type: New Feature
> Components: Core
> Affects Versions: 4.0.0
> Reporter: Christoph Läubrich
> Priority: Major
>
> As we recently again seeing issues in a complex maven-plugin builds with
> multiple plugins used in different context (core-extension,
> project-scoped-extension, project-scoped plugin) and also recurring problems
> with "invisible" components, classloader problems and obscure lookup problems
> that are hard to diagnose I'd like to suggest a new feature, that is
> supporting the OSGi-Model for classloader separation and wiring of
> requirements (e.g. Declarative Services) in maven-core.
> OSGi supports a [powerful model of classloader-separation
> |http://docs.osgi.org/specification/osgi.core/8.0.0/framework.module.html]
> that allows defining so called "bundles", each bundle is just a regular jar
> with some meta-data that declares:
> # A name
> # A version
> # packages it want to import (or more generic: a requirement)
> # packages it want to export (or more generic: a capability)
> with these information the OSGi resolver is able to compute a consistent
> classspace for each bundle and thus different libraries in different version
> can co-exits, and it could even be analyzed if something is missing and given
> detailed information about the cause.
> Beside this, OSGi offers a so called "Service-Factory" where a bundle can
> publish or gather services, this is similar to plexus-components but much
> more flexible as advanced filtering is possible and of course the
> class-compatibility is considered as well here.
> Based on this there is a simple but very powerful DI framework available
> called [Declarative
> Services|http://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.component.html],
> that allows easy wiring of all these requirements [using
> annotations|http://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.component.html#service.component-component.annotations].
> Looking at this you will find many concepts shared with Plexus Annotations.
> The advantage of this is, that there is an API to inspect such components and
> give detailed information what is missing why (in contrast to the dreaded "no
> instance of X is bound) and even dynamic service references are possible, for
> example a component might discover while introspecting some object it now
> wants to be notified for a while and can register additional services and
> also dispose them later on.
> *What would be required by Maven?*
> To support integration in existing environments, OSGi supports a so called
> [Framework Connect
> Specification|http://docs.osgi.org/specification/osgi.core/8.0.0/framework.connect.html],
> that allows to export content in a way that connects both worlds and can
> interact with each other, so for maven this would mean:
> # Start a Connect-framework
> # Export what today is "maven-core-realm" as a module to the
> connect-framework so maven can interact with OSGi and OSGi can interact with
> maven
> # Install a ServiceListener in the OSGi world that listen for services and
> provide them on demand if a component requires it by looking it up in the
> plexus-container
> # A way to detect if a maven-plugin wan't to run in the "maven-world" or the
> "OSGi-World" this could be as easy as simply checking if the maven-plugin
> contains an OSGi-Bundle-Header and then not create a classic
> extension/project/plugin class-realm but simply install it and all its
> referenced content into the connect framework
> # Some core-components might need to be adjusted, e.g. a
> MojoExecutionComponent might want to discover Mojos in both worlds, the same
> might apply to thinks like listeners, but this could also implemented as an
> additional component that redirects events/requests.
> This could greatly reduce the complexity of interaction between components in
> the different scenarios (core-extension, project-extensions, plugin) without
> any effort by maven as OSGi takes care, the wiring of modules will be much
> more flexible for such an OSGi-MOJO, and still all current tools and
> techniques could be used. Given that most plugins will require a major
> overhaul for Maven4 it might even be a recommendation to move to the
> OSGi-Mojo as part of the migration.
> If there is interest in this from other Maven developers, I can provide the
> necessary parts for a proof-of-concept. I also target this to Maven4 as there
> is more room for breakages/change of concepts, but of course the same would
> still be applicable to Maven3 so if one find it useful I would happily start
> to introduce this with Maven 3.9.x already...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
