Make it possible to not apply micromnaut dependencies

[bric3]

Hi while I enjoy micrnaut for bigger applications, sometimes, for very thin command-line applications I don't want to get the micronaut code, injectin, yaml etc, etc.

I know this is somewhat not quite the micronaut direction, so I would understand if this issue was dismissed. Yet the plugin is useful for its nice integration with GraalVM and docker. Thank you in advance for considering this, maye thanks for micronaut as well, I really like it !

---

What I propose is to allow to disable this phase :

• Applies the Micronaut Bill of Materials (BOM)

Currently the above phase adds various micronaut dependencies in various configurations for this dependency declaration:

dependencies {
    annotationProcessor("info.picocli:picocli-codegen:4.6.1")
    compileOnly("org.graalvm.nativeimage:svm")
    implementation("info.picocli:picocli:4.6.1")
    runtimeOnly("ch.qos.logback:logback-classic")
    testImplementation("org.assertj:assertj-core:3.18.1")
    testImplementation("org.junit.jupiter:junit-jupiter-params:5.7.0")
}

annotationProcessor - Annotation processors and their dependencies for source set 'main'.
+--- info.picocli:picocli-codegen:4.6.1
+--- io.micronaut:micronaut-inject-java -> 2.2.3
+--- io.micronaut:micronaut-validation -> 2.2.3 
\--- io.micronaut:micronaut-bom:2.2.3

compileClasspath - Compile classpath for source set 'main'.
+--- org.graalvm.nativeimage:svm -> 20.3.0
+--- io.micronaut:micronaut-bom:2.2.3
+--- info.picocli:picocli:4.6.1
\--- io.micronaut:micronaut-inject -> 2.2.3

runtimeClasspath - Runtime classpath of source set 'main'.
+--- info.picocli:picocli:4.6.1
+--- io.micronaut:micronaut-inject -> 2.2.3
+--- io.micronaut:micronaut-bom:2.2.3
\--- ch.qos.logback:logback-classic -> 1.2.3

[msgilligan]

At the very least, it would be nice to be able to use the Micronaut Gradle Plugin with a lighter set of dependencies from Micronaut. In my case, I'd like to see just micronaut-inject (which in turn depends on micronaut-core.)

Perhaps the way to do that would be with some "lighter" runtimes. For example:

micronaut {
    version = "3.0.0"
    runtime "inject_only"
}

[pbthorste]

It seems like the "io.micronaut:micronaut-inject" dependency always gets added, but it would really help alot if it were not added (unless it was specified), or at the very least there was a config option to disable it.

[graemerocher]

without micronaut-inject nothing will work, in which case it doesn't event make sense to use the plugin

[pbthorste]

Maybe my case more of an exception, but the case where this matters the most for me is in libraries. In my case it would be quite helpful for the library plugin to not include this dependency. For example I have multiple library dependencies with a build.gradle which looks something like this:

plugins {
    id 'io.micronaut.library'
}

dependencies {
    compileOnly "com.google.code.findbugs:jsr305"
    compileOnly "io.micronaut:micronaut-inject"
    compileOnly "io.micronaut:micronaut-http"
    compileOnly "io.micronaut:micronaut-http-server"
    compileOnly "io.micronaut:micronaut-validation"
    compileOnly "io.micronaut.reactor:micronaut-reactor"
    // other dependencies
}

Here I am using the micronaut gradle library plugin to get all of the nice stuff that comes with it. But this is a library, and I dont want it to have any dependencies that might mess with the dependencies of the parent project.

If for example the library project uses micronaut 3.4.0, and the project that consumes the library has 3.3.4, it causes alot of problems - because of the inject dependency.

[melix]

If for example the library project uses micronaut 3.4.0, and the project that consumes the library has 3.3.4, it causes alot of problems - because of the inject dependency.

This sounds more like a backwards compatibility problem. Your library still needs inject. It should IMHO be built with the minimal supported Micronaut version. That is to say if it's supposed to work on Micronaut 3.3.4, build it with 3.3.4, so it will work with both 3.3.4 and 3.4.0 (using regular dependency upgrade mechanisms).

[pbthorste]

@melix yes, that would indeed solve that particular problem, but my intention was just to show an example of one of the many problems that arise because of this dependency.

[melix]

Right but in this case I'd be interested in having a real use case where this causes problems. Moving dependencies to compileOnly to avoid dependency conflicts isn't the right model. Your library should clearly express what it needs. If it requires micronaut-http at compile and runtime, it's either an api or implementation dependency, but clearly not compileOnly.

IMO either you have a Micronaut Library and then you apply the library plugin which does the right thing and adds the proper dependencies, or as Graeme said, you have something else which is not a Micronaut library, and then you don't need to apply the Micronaut plugins: you just apply the regular java-library plugin and add the dependencies you need. But from what I read, you seem to be using compileOnly as a workaround for problems which should be solved by the dependency resolution engine.