search

kelemen / netbeans-gradle-project

This project is a NetBeans plugin able to open Gradle based Java projects. The implementation is based on Geertjan Wielenga's plugin.
172 stars 57 forks source link

Need help with odd Gradle version warnings #371

Open david-hall opened 6 years ago

david-hall commented 6 years ago

I've been using NetBeans 8.2 and Gradle 4.1 with two related Gradle projects for a couple of years with no problem. The main application is in project called vzome-desktop. It depends on the other project called vzome-core. The vzome-desktop project has a couple of subprojects in platform/windows and platform/mac. These are primarily distribution projects. There is no actual project in the intermediate desktop/platform folder.

Recently, we've merged the two projects to a common top level Gradle project called vzome with subprojects called core and desktop, and desktop still having the same two subprojects below it. Here's the new hierarchy:

+-- vzome
    +-- core
    +-- desktop
        +-- platform
            +-- mac
            +-- windows

Since migrating to this unified hierarchy, I have been getting the following warning message every time I build the project, either from NetBeans or from the command line, although I haven't seen it when I run the project in the Eclipse IDE.

The message says:

POM relocation to an other version number is not fully supported in Gradle : xml-apis:xml-apis:2.0.2 relocated to xml-apis:xml-apis:1.0.b2. Please update your dependency to directly use the correct version 'xml-apis:xml-apis:1.0.b2'. Resolution will only pick dependencies of the relocated element. Artifacts and other metadata will be ignored.

I also occasionally see messages about the Gradle daemon starting new instance because of some sort of version incompatibility issue, although I am not able to reproduce that scenario right now to provide the details. I'm sure it will pop up again eventually.

The individual projects (before they were merged) never gave any such warning. I'm not sure what's causing it or what's different in the new unified project which makes it appear. I did discover a hack that I can add to build.gradle in the core subproject which eliminates the warning, but I'd really like to fully understand why it's happening instead of just masking the warning. The hack that makes the message go away can be seen on lines 20-28 of https://github.com/david-hall/vzome/blob/gradleWarningFix/core/build.gradle. I'm not sure why adding it to the core subproject instead of the top level vzome project seems to make it go away.

I noticed in your comments to https://github.com/kelemen/netbeans-gradle-project/issues/341 where you suggest that a single settings.gradle file seems to be the normal configuration, but these projects have always had a separate one in each subproject. Specifically, the one in desktop is used to include the mac subproject only when it's run on a Mac. This was necessary because of some OS dependent libraries that are not available in windows I'm pretty sure that's not related, but I'd be open to any suggestions of a better approach to handling this situation as well.

In addition, the windows subproject has a task named distSfx which I have not been able to run since we merged the two individual projects. It's related to the launch4j tasks in the windows subproject. It appears that it can't find some of the dependencies although they are all present on my local file system in mavenLocal() and work fine in the un-merged projects. I may ask for some help with that issue later, but I'm just mentioning it for now.

You can find the vzome project that exhibits this problem at https://github.com/david-hall/vzome/tree/master. The two original correctly working projects (from before they were combined) can be found at https://github.com/david-hall/vzome-core/tree/master and https://github.com/david-hall/vzome-desktop/tree/master.

I'll appreciate any suggestions you can offer to help me understand and resolve this version warning or the problems with the distSfx task.

Thanks, David

swpalmer commented 6 years ago

On Dec 1, 2017, at 2:51 AM, David Hall notifications@github.com wrote:

…Since migrating to this unified hierarchy, I have been getting the following warning message every time I build the project, either from NetBeans or from the command line, although I haven't seen it when I run the project in the Eclipse IDE.

The message says:

POM relocation to an other version number is not fully supported in Gradle : xml-apis:xml-apis:2.0.2 relocated to xml-apis:xml-apis:1.0.b2. Please update your dependency to directly use the correct version 'xml-apis:xml-apis:1.0.b2'. Resolution will only pick dependencies of the relocated element. Artifacts and other metadata will be ignored.

I have been getting that message for a long time in one of my projects. xml-apis, which is picked up as a transitive dependency seems to have some strange configuration in the artifact repository.

I noticed in your comments to #341 https://github.com/kelemen/netbeans-gradle-project/issues/341 where you suggest that a single settings.gradle file seems to be the normal configuration, but these projects have always had a separate one in each subproject. Specifically, the one in desktop is used to include the mac subproject only when it's run on a Mac. This was necessary because of some OS dependent libraries that are not available in windows I'm pretty sure that's not related, but I'd be open to any suggestions of a better approach to handling this situation as well.

I use multiple nested settings.gradle files like you, without issue.

Regards,

Scott

kelemen commented 6 years ago

I don't know much about the Gradle limitation you described but I guess that some Gradle version says that and some do not. Even the "version incompatibility issue" means that Gradle had to start a new daemon because a different version of Gradle was requested than the already running. In your setup I would bet that different wrapper were specified for your common root project than when one of the subproject is used as a root project (possibly because there is none specified in the directory of such subprojects). I recommend you noting the settings.gradle being used (it is printed) and check if that is the source of different behaviour.

What I would do in your case is try to run the tasks from both context (i.e., from the directory of the common root project and from the directory of the subproject) and see if it makes a difference. If it works in every context from the command line then it is probably either an issue with this plugin or with the Tooling API of Gradle.

If you want it I can implement a feature which prints the actual and requested Gradle version in the output window. I didn't add this yet because it is not exactly free but I guess it could be added as an opt-in feature (possibly enabled in the global settings). Do you think this would help you?

Multiple settings.gradle

I don't recommend having multiple settings.gradle files because it introduces non-determinism. This is because of all the automatism NB does (i.e., you don't import projects). So, the plugin have to somehow autonomously decide which settings.gradle is to be used. There all kinds of rule of thumbs for this decision, of which the most important is that open projects take precendence in being considered as root project (so, if you have multiple root projects, the one opened wins). This doesn't really help in your case because your subprojects are both root projects and simle subprojects (dependening on the context). So as long, as you don't have your common root project open, things should be pretty determinstic. However, as soon as you open your common root project, you will have two equivalent candidate to be a root project and the plugin will pick one of them pretty much randomly.

Anyway, if you have your projects setup so that projects are oblivious to the settings.gradle being used and project properties are set the same for every settings.gradle (the plugin has project properties / root projects currently) you should be fine. However, you should consider the following:

kelemen commented 6 years ago

I have added the possibility to print the actual version of Gradle being used (as reported by Gradle). This feature must be turned on in the global settings (technically this is a project level settings but there is no project level UI for it). So, if you want to check, you can build the plugin from the sources and test your issue with this settings on.