Details
-
New Feature
-
Status: Closed
-
Major
-
Resolution: Won't Fix
-
4.0.0
-
None
-
None
Description
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 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, that allows easy wiring of all these requirements using 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, 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...