Support for getting / injecting shared Maven components in JibMavenPluginExtension

[stefanocke]

I would like to achieve the following in an extension plugin (maybe as a pull request for jib-layer-filter-extension-maven):

• determine the dependencies (including transitive) that come from the parent pom
• put them into one or more separate layers

The idea is that the parent pom defines the "company / project standard" which rarely changes.
While the existing jib-layer-filter-extension-maven is already quite useful, it would be still quite cumbersome to write globs for all direct and transitive dependencies.
For example, think about having some Spring Boot starters in the parent pom for all your microservice, but some other Spring Boot starters are optional and only used by specific microservices. You not only would need quite exact globs for the Spring Boot starters then, but also for their manyfold transitive dependencies.

So far the introduction...

Now my proposal / request:

For doing advanced tasks like "determine the dependencies (including transitive) that come from the parent pom" in an extension, I need shared Maven components like ProjectDependenciesResolver.

In a Mojo, one would get it like this

    @Component
    ProjectDependenciesResolver resolver;

But the JibMavenPluginExtension is no Mojo, so I can't do that.

So far, the following works, but the lookup() method is already deprecated and will be removed in Maven 4:

      ProjectDependenciesResolver resolver = (ProjectDependenciesResolver) mavenData.getMavenSession()
          .lookup(org.apache.maven.project.ProjectDependenciesResolver.class.getName());

So do you see any chance to perform dependency injection on the loaded extensions or to provide some other (compatible) way to get shared Maven components?

You can see a first working draft of my approach here stefanocke/jib-extensions@d9652b5

The deprecated lookup() method is used here stefanocke/jib-extensions@d9652b5#diff-1cf0b87bb4b940a4278b65d96c8da263fc6457a431798f0b1fb7fd2f648c17e6R200

[chanseokoh]

Hi @stefanocke,

I think this is a very interesting idea.

It's just that we are unsure what would be the best architecture to enable this with enough flexibility and expandability. Should Jib just pass ProjectDependenciesResolver as another argument in tandem with MavenProject? That's the simplest solution, but what if the users want other Maven components as well later? It doesn't feel right to just keep adding components. It'd be nice if the extension framework could somehow inject components (as Maven does with @Component as you said), but I don't know if that's technically possible? (We don't have much expertise with implementing dependency injection with annotations.)

What's your thoughts? Any detailed design proposal?

BTW, I think we have to leave this as a low priority. Not that we think this is not important, but our resources are very limited at the moment. We also welcome contributions.

[stefanocke]

Thanks for your feedback, @chanseokoh. I agree with you that just passing in ProjectDependenciesResolver is not a good solution.
Regarding Depedency injection in Maven I only know that it was "Plexus container" in former times and it moved to Guice. See https://maven.apache.org/maven-jsr330.html

However, I don't know enough yet, whether there is any way to apply this DI to our own (non-Mojo) components.

Some hint from someone who is deeper into Maven internals would be helpful. But of course, the solution should be based on some public API of Maven.

If I find out some more details by myself, I will come back here...

[stefanocke]

Okay, so approximately my plan would be to make the extension a Sisu / Guice / JSR-330 component and to inject it into the jib plugin instead of creating it by using the service loader.

Pretty much as the Jsr330Component in the example on https://maven.apache.org/maven-jsr330.html

I am not sure yet, if jib has completely move from plexus to Sisu / Guice / JSR-330 then or if it is possible to mix.
Even a complete migration should not be a to big deal, since as I understand it it mainly about replacing the two or three existing @Component annotations in the Mojo by @Inject.

Sisu / Guice / JSR-330 needs at least Maven 3.1.0. So, jib would not work for older Maven versions. Would this be an issue, @chanseokoh?

[chanseokoh]

Thanks for looking into it! I think I am not following all the technical stuff you said (😅 hopefully it's easy to implement and doesn't incur a lot of changes). However, At least I can say requiring 3.1.0+ is OK. I see 3.1.0 was released in 2015.

[stefanocke]

@chanseokoh , I have implemented the approach in the commit stefanocke@0c122a1.
It is IMHO completely compatible and optional and quite lean, too. If the extension is not injected, the plugin still uses the existing JDK service loader approach to create it.

Basically the solution comes down to inject the extensions into the MOJO like this:

public abstract class JibPluginConfiguration extends AbstractMojo {
  ...
  @Inject
  private Set<JibMavenPluginExtension<?>> injectedPluginExtensions = Collections.emptySet();

The extension just needs to declare itsfelf as a JSR-330 / Sisu Component by adding the following annotations:

@Named
@Singleton
public class JibLayerFilterExtension implements JibMavenPluginExtension<Configuration> {
...

And finally, some index is required in META-INF/sisu/javax.inject.Named of the extension:

com.google.cloud.tools.jib.maven.extension.layerfilter.JibLayerFilterExtension

Under the hoods, Sisu will discover the so declared component and apply dependency injection to it, which allows me to accomplish my original goal to inject shared Maven components into the extension like this:

@Named
@Singleton
public class JibLayerFilterExtension implements JibMavenPluginExtension<Configuration> {
  ...
  @Inject
  private ProjectDependenciesResolver dependencyResolver;

Could you please have a look? If this approach is okay with you, I would add some integration test and create a pull request.

[chanseokoh]

Thanks a lot for doing this! We'll get back to this as soon as we have time, but please be patient until then.

[stefanocke]

It needed some polishing, but now everything should be ready in the pull request.

[chanseokoh]

Fixed by #3062. This new approach to load Jib extensions (which enables injecting Maven components) will be documented in the jib-extensions README.

[chanseokoh]

@stefanocke thanks for your great contribution! This was really a cool idea, and we were very happy to get help from an expert on this subject.

We released Jib 3.0, and you should be able to start using the feature. (I know I am lazy to update the Jib extensions doc.)