Fixing NetBeans Gradle Support for OpenJFX

Kevin Rushforth kevin.rushforth at oracle.com
Mon Jul 20 22:16:43 UTC 2020


On 7/20/2020 2:05 PM, Laszlo Kishalmi wrote:
> On 7/20/20 1:15 PM, Kevin Rushforth wrote:
>>>    That could be prevented by removing line 1547: project.version =
>>>    MAVEN_VERSION from the build script.
>>
>> Interesting. That is only used for the maven "publishing" tasks, and 
>> shouldn't affect the main build artifacts. I don't see the generated 
>> version number showing up anywhere in the build output. It would be 
>> easy enough to suppress this for non-production builds, but I'd want 
>> to understand how it is causing problems. Does gradle (and thus the 
>> NetBeans gradle plugin), assign some semantic meaning to the 
>> project.version attribute?
> There is no semantic association. It is just the binding of the 
> sub-projects together. Recent Gradle doesn't generate the jar files of 
> the sub-projects if not asked for that specifically. Though if 
> javafx:base project is asked of it's main output it would be a jar 
> file with a second precision suffix in it's name. Also if you ask for 
> the dependencies of javafx:graphics it will list a dependency on a 
> javafx:base base jar with the second precision suffix in its name. The 
> jar file does not have to be exist, NetBeans still would able to find 
> out the dependency between the two sub-projects, but these jar names 
> shall be the same. So if these two queries happen in different times 
> the jar name would not match.

Got it. We explicitly disable the jar task for each modular project, 
since we don't need them, so we never would have noticed this. If I 
enable them, I can see the jar files with the full version number, 
including the date string.

I'll file a bug to fix it. I'll need to do it in such a way that won't 
disrupt generating maven artifacts for testing (actual maven artifacts 
for uploading won't be affected anyway), but it should be easy to do.

-- Kevin



More information about the openjfx-dev mailing list