-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[MNG-7954] New dependency injection mechanism #1393
Conversation
c046895
to
b4dff3a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No strong issue for me but I'd like we review these points before merging then if it is ok just go:
- do we want to copy all part of guice, guess in maven we just need a subtype
- do we need bindinset notion, guess we can just lookup sets from a type now
- do we need all these flavors of structures (tuple for ex), using a list wouldnt be dramatic for us I think
- do we want all these notions in modules/binders
overall idea is to drop all we dont need from guice if possible to maintain the minimum we need
hope it makes sense
api/maven-api-di/src/main/java/org/apache/maven/api/di/Scope.java
Outdated
Show resolved
Hide resolved
api/maven-api-di/src/main/java/org/apache/maven/api/di/Transient.java
Outdated
Show resolved
Hide resolved
maven-di/src/main/java/org/apache/maven/api/di/ProvidesIntoSet.java
Outdated
Show resolved
Hide resolved
maven-di/src/main/java/org/apache/maven/di/ResourceLocator.java
Outdated
Show resolved
Hide resolved
maven-di/src/main/java/org/apache/maven/di/binding/Bindings.java
Outdated
Show resolved
Hide resolved
maven-di/src/main/java/org/apache/maven/di/impl/AbstractCompiledBinding.java
Outdated
Show resolved
Hide resolved
maven-di/src/main/java/org/apache/maven/di/module/UniqueQualifierImpl.java
Outdated
Show resolved
Hide resolved
There's no guice dependency here.
Agreed. There are a bunch of things that are unneeded to us. That's because the library has been designed with programmatic definition in mind (using the ModuleBuilder DSL) while we need a declarative definition. So I do plan to trim down to what we really need. |
Well some part of the code were highly inspired from Guice, this is what I meant.
Perfect for me. Thanks a lot! |
Am just worried that we end up again as we did with old plexus: was our, but began to rot from one point... I'd be happies if we could simply circumvent this by something like eclipse-sisu/sisu-project#103 |
Feel free to give it a try, but I could not find an easy way without rewriting everything... |
Do we want something like |
Think we should start minimalistic, maven IoC need is actually pretty low - mainly bean definition + overriding - so less we keep better it is in terms of maintenance. |
Yeah, I think I'll even drop support for scopes for now, we don't really need it for plugins. Those are only needed when dealing with extensions or maven-core, as plugins are always bound to the mojo execution. |
Unless, as you mention, is an extension... and we do have quite some of those. |
Yes think extensions are in scope there and don't think scope is the biggest code (maybe guice made it verbose but the CDI way is actually quite light - |
950921f
to
5b10ca5
Compare
5b10ca5
to
e40925e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, nothing to add really
JIRA issue: https://issues.apache.org/jira/browse/MNG-7954
This PR provides a minimalistic dependency injection library (the code is initially based on the ActiveJ project).
This provides
org.apache.maven.api.di
packageorg.apache.maven.di
packageThis is currently plugged into the plugin creation for plugins using the Maven 4 API.
It's currently not used for extensions or for the core maven components. This would require extra support and a plexus compatibility layer (which is kinda what we want to get rid of).