How to manage dependencies by myself correctly?

[qtdzz]

Hi John, I have a problem while setting manageDependencies flag to false and provide dependencies by myself.
The problem is actually starting from version 1.2.5. Before that everything was fine.
Here is my example application https://github.com/qtdzz/my-example-application which is broken.
The console looks like this

16:54:42.414 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] Could not determine the dependencies of task ':vaadinCompile'.
16:54:42.414 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] > Could not resolve all dependencies for configuration ':vaadin-client'.
16:54:42.414 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]    > java.lang.NullPointerException (no error message)

Is it anyhow releated to this comment #489 (comment)?

I also have an additional question releated to the --build-cache. When trying with the plugin version 1.2.4, my-example-application works quite well with significant improvements but in our real project (where vaadin application is a submodule), the Build cache key is different on everytime I run vaadinCompile. Do you have any idea why it goes wrong?
Thank you.

[qtdzz]

Hi,
I have had time to investigate the problem by debugging the plugin.
First of all, about the manageDependencies=false, I think there is a concurrency issue while removing all the vaadin- configurations at com/devsoap/plugin/GradleVaadinPlugin.groovy:279.
I was able to reproduce it reliably by steps:

1. Creating a vaadin addon project
2. Set manageDependencies to false
3. Add all the need dependencies in the build.gradle
4. Rebuild the project.
   The build will fail with error

* What went wrong:
Could not determine the dependencies of task ':project:vaadinCompile'.
> Could not resolve all dependencies for configuration ':project:vaadin-client'.
   > java.lang.NullPointerException (no error message)

Sometime, when I debug it slowly, it will complain about vaadin-server configuration instead of vaadin-client.
IMHO, when applying the plugin, we create and add all the dependencies regardless manageDependencies flag, then gradle will resolve them immediately, before finishing the job, it realizes it doesn't need to manageDependencies, then tries to remove the configurations which causes the NPE.
I debugged in gradle 4.0 and gradle 4.7, both give NPE in different places but same symtoms, getting the configuration metadata.
In 4.0, org.gradle.api.internal.artifacts.ivyservice.resolveengine.graph.DependencyGraphBuilder.NodeState#getModuleResolutionFilter
In 4.7, org.gradle.api.internal.artifacts.ivyservice.resolveengine.graph.builder.ComponentState#forEachCapability

I was able to workaround this issue by adding the bellow snippet to com.devsoap.plugin.GradleVaadinPlugin#applyDependencies

if (!project.vaadin.manageDependencies) {
    return
}

My second issue is about the --build-cache. I found that our vaadin project (called project A) depends on other project (called project B) which are rebuilt everytime running the build. That's the reason why they Build cache key is always different.
The situation is exactly the same as the addon and demo subproject in a Vaadin addon project.
Do you have any idea to have build cache in that case?
I was thinking about somehow adding all information (src, resources, compile dependencies) of the project B to inputs of the compile task

Hi, We have the same issue here. Is a fix in planning?

[johndevs]

Hi,

To manage your own dependencies you first have to realize that the configurations which exist there are there for a reason.

The plugin will need different kinds of classpaths when building a Vaadin application depending on what kind of Vaadin application you are building.

For example a server-side only Vaadin application only requires the vaadin-server configuration while a Vaadin application with a custom Widgetset will also require the vaadin-client configuration so it can use that to construct the widgetset compiler classpath. The testbench, spring boot etc. configurations are also there for similar reasons. The way the plugin knows which classpath to apply to which scenario is by using different configurations. So if you want to manage the dependencies yourself you will need to populate the different configurations by yourself, you can't just put everything in compile.

As @qtdzz points out 4.0 will behave differently than 4.7 as the Gradle guys keep changing how the dependencies are resolved. Currently there are only tests up to 4.5 so there might be some breaking changes even in later versions.

The target for 2.0 would be to move toward an dependency API described here https://github.com/devsoap/gradle-vaadin-flow/wiki/Dependency-management. This would allow you to easier select if you want to start from an empty set of dependencies or to autoconfigure them. However, the configurations will need to continue to exist as the classpaths still need to be resolved.

[Arvidas1]

@johndevs Why you do not provide example of correct configuration when "manageDependencies false" is used?

[johndevs]

@Arvidas1 The reason examples for it doesn't exist is that it is a not preferred way of defining dependencies as you need to know the internals of the plugin to understand how to define them correctly.

90% of the use-cases for the plugin should work without manually defining the dependencies, so I'd rather discuss why you need to manually set them. And if you find a use-case where the plugin fails to configure them correctly then I'd rather fix that then having everyone to manually define all their dependencies.

[envas]

One reason could be issue #541 . In my case, I am missing the Vaadin libraries in the exploded war when they are managed by the plugin.