[MNG-7954] New dependency injection mechanism

[gnodet]

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

• our own annotations for the user facing API in org.apache.maven.api.di package
• no dependency (especially ASM)
• a simple programmatic access (not to be exposed, but used to actually populate the bean container) in org.apache.maven.di package
• an index creation using APT

This 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).

[rmannibucau]

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

[gnodet]

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

There's no guice dependency here.

• 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

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.
But that's just a first draft and I need to try and plug this DI engine into plugin loading mechanism and see how it goes. If I can port a few core plugins to this DI engine, I'll then start trimming it down.

[rmannibucau]

There's no guice dependency here.

Well some part of the code were highly inspired from Guice, this is what I meant.

So I do plan to trim down to what we really need.

Perfect for me. Thanks a lot!

[cstamas]

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.inject#103

[gnodet]

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.inject#103

Feel free to give it a try, but I could not find an easy way without rewriting everything...

[cstamas]

Do we want something like @Description is? Or it was added to Sisu only as Plexus XML had "component description"? In fact, am unaware of any use of it, but still...

[rmannibucau]

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.
Rewriting from scratch gives the opportunity to drop guice and sisu at some point too so can be quite promishing if we manage to make plexus-world optional (realm = TCCL) but this is likely mvn 6 or 7 ;).

[gnodet]

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. Rewriting from scratch gives the opportunity to drop guice and sisu at some point too so can be quite promishing if we manage to make plexus-world optional (realm = TCCL) but this is likely mvn 6 or 7 ;).

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.

[cstamas]

Unless, as you mention, is an extension... and we do have quite some of those.

[rmannibucau]

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 - Context usage in subclass proxies which can be done at build time, even if it is just dumping asm one at build time and not using an annot proc or sthg more build oriented). But if we want to split we can maybe start by param injection only.

[cstamas]

LGTM, nothing to add really