Subproject A is dependant on subproject B, but cannot find the build classes of B (SOLVED)

[chjan]

The rootproject contains 3 subprojects, placed side by side as folders in the Windows folder of the rootproject.

B clean&build = OK. The classes from B may also be imported into A, however sometimes after manual reload of project B.

The problem arise when compiling A, as the compiler claims the classes of B do not exist (despite import ok).

Have tried all sorts of NB restart, cache delete, etc, but in vain. I have tried to look into all files without finding any clues for this malfunction. It is probably a blunder on my part, but what?

What could be the possible causes of A not recognising B during compiletime?

Note: I am moving to Gradle for NB due to long time use of Gradle in Android Studio.

[kelemen]

I would guess that you put settings.gradle files into the folders of your subprojects but I can't tell without seeing your project (I don't need the actual Java source files).

[chjan]

RxDNSSD_java for Kelemen.zip

No big secret since I am porting an existing Android project here on GitHub to pure Java, but sources removed anyway.

Hope you can spot something. (could be some of the files are Android remnants)

[kelemen]

Thanks, I'll be able to have a look at it on monday evening.

[chjan]

I found what causes this error, not related to this plugin at all: It is the jar {...} of the subproject :library that puts some native JNILIBs files into the Jar. Without this section, the error is gone.

This was the wrong choice of command as the Jar command is not the right one for adding native files. I am still struggling to find a proper way to do that. There is a gradle native plugin, but not working, and Gradle itself seems to be not as prepared for pure Java projects as it is for Android. There is no obvious way to load dll via build.gradle files. Bummer! Seems like the only option is to put the dll files (in this case) in the right folder, which if true is a cumbersome solution.

[kelemen]

I'm not exactly sure what happened for you because putting dlls into the jar should break compilation.

As for the native dependency: It is not a Gradle issue, you just have to make Java be able to locate your dlls (e.g.: by setting the PATH variable). However, you will need to manually create a run task and set it up properly to be able to run your application.

[chjan]

It did break the compilation, confirmative. IOW it was the wrong approach.

FYI, I am able now to load dlls. I tried the gradle natives plugin available on GitHub, but in vain, because it is abandoned. Thus, I simply put the dlls in the classpath.

Your plugin is working fine. Thanks for your efforts. I prefer gradle and will use this library in forthcoming projects. I hope you will be offered a tighter integration to NetBeans (as a default option).

[kelemen]

The current plan is to add this plugin to be part of the official NB package. Some problem needs to be solved to do that but it should be part soonish.

[chjan]

Excellent! One idea: What if you took a quick look at the Gradle native plugin here on GitHub? Perhaps it is a small job for you to make it work? Why? Because the use of JNI native layers are "commodity" in the pure Java world, and because Gradle does not provide that feature in their own Java plugin. I suppose the reason is that Gradle so far has been focusing on Android. In the Gradle Android plugin, this feature is working well. For your consideration.

[kelemen]

Which plugin exactly? (this: https://github.com/cjstehno/gradle-natives?) Also, what do you mean by "make it work"? What support do you expect exactly? If you want some features to be added to this plugin, so that it recognizes something, can you open another issue?

[chjan]

I mean that project, yes, i.e. that you could enhance your own plugin by including this native add-on, since "native" is lacking in the normal Gradle Java plugin.

That gradle-natives plugin was recently abandoned by the developer. It doesn't work properly at the moment, but my guess is that there is not much work to do. I have no idea whether it will be possible, so it was just a loose suggestion on the fly.

[kelemen]

Can you open a new issue explaining what is happening now and what exactly do you expect to happen? Because I have no intention to analyze that plugin as I do not currently have any project with native dependencies (I used to years ago but I have manually coded the support in our build).

[chjan]

I am sorry, no time to involve further. It was just a loose suggestion to possibly enhance your own project. Not a need I have at the moment.