Closed arsi-apli closed 3 months ago
The default behaviour should be the same. Which version of JDK 8?
does this happen with all versions of the maven plugin or is this a regression?
Am I missing something here? Compare https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java#L466 to https://github.com/openjdk/jdk/blob/master/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystemProvider.java#L274 -> https://github.com/openjdk/jdk/blob/master/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java#L808 The default options are never accounted for??
It might be better to use explicit options? In which case, are we expecting truncate?
Ah, missed a step - https://github.com/openjdk/jdk/blob/master/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java#L895 Looks like it was fixed in https://github.com/openjdk/jdk8u/commit/bc2f17678c9607becb67f453c8b692c96d0e8bba
The default behaviour should be the same. Which version of JDK 8?
Java: 1.8.0_191; Java HotSpot(TM) 64-Bit Server VM 25.191-b12 Tomorrow I'll try a newer version.. Previously I was using nbm-maven-plugin 4.2 and it was OK..
Java: 1.8.0_191
RELEASE126
Previously I was using nbm-maven-plugin 4.2 and it was OK..
You can't update one dependency and expect that everything keeps working. NB 12.6 is EOL since 11 releases, JDK 8 is at update 422. It would be a coincidence if this would still work since nobody tests this range of EOL libs.
This should be fixed in JDK 8u252 or later, which is more than 4 years old. I agree with @mbien about the range of EOL dependencies at play here, so closing.
When compiling from RELEASE126 modules with JDK8 on newer plugin versions I get the exception Could not overwrite manifest entry: META-INF/MANIFEST.MF The same problem has been reported here: https://issues.apache.org/jira/browse/NETBEANSINFRA-274
The solution is to change line CreateNetBeansFileStructure:299
= new BufferedOutputStream(Files.newOutputStream(fs.getPath(JarFile.MANIFEST_NAME)))) {
to= new BufferedOutputStream(Files.newOutputStream(fs.getPath(JarFile.MANIFEST_NAME), StandardOpenOption.CREATE))) {
I didn't look into that why. But if it works on higher versions of java, then probably the default behavior has changed StandardOpenOption.CREATE vs StandardOpenOption.CREATE_NEW
If this change is OK, I can do a pull request..