Artifact error on Windows XP and Java 8


(Tom Eugelink) #1

On my WXP system the JFXtras 8.0 project builds with the version number in the artifact ID (jfxtras-labs-8.0), but only for Java 8. The same project on Java 7 generates the correct artifact (jfxtras-labs). However, under Windows 7 the 8.0 branch is released correctly, so it seems to be a Windows XP / Java 8 problem. (Using Gradle 1.7)


(Tom Eugelink) #2

I stand corrected; the problem also occurs on W7. So it must be Java 8 that causes it.


(Tom Eugelink) #3

I figured it out: it’s not the enviroment, but Gradle uses the directory name for the artifact id (and I had two versions of the same project checkout out, one contained a version number in the name). Now I need to figure out how to explicitly specify it.


(spencer_allain) #4

Since you were checking it out, and the directory name was variable, I was going to assume that it was a root project and recommend setting the root project name explicitly in a settings.gradle file instead of letting it default to the name of the directory.

Of course, it seems you’ve already found that solution, because I eventually navigated my way to the correct jfxtras repo on github.

For anyone else reading this thread, this is what was placed into the settings.gradle file to ensure a consistent project name, and also end up being the desired consistent artifact id (several names default to the project name).

rootProject.name = 'jfxtras-labs'

Setting archivesBaseName would have also caught most of the artifact names (but some publication items might need to be adjusted as well). Explicitly setting the project name as you’ve done has many more advantages, so since it works in your situation, it is probably the optimal solution at this time.

-Spencer


(Tom Eugelink) #5

Thanks for replying. Yes, this thread is a nice example how one can be searching in the wrong places, and making wrong assumptions. In the end the fix was very simple.

That said, I do have doubts about using a directory name as a project name, it never occurred to me in several months of being aware of the behavior, that that may be the cause of the wrong artifact id. Some defaults are too easily changed, and out of scope of the domain.