org.xtext.builder issue: generateXtext > java.util.zip.ZipException: zip END header not found

xtext / xtext-gradle-plugin

Gradle plugins for using Xtext and Xtend

Eclipse Public License 1.0

48 stars 18 forks source link

org.xtext.builder issue: generateXtext > java.util.zip.ZipException: zip END header not found #216

Closed shaertel-rok closed 1 month ago

shaertel-rok commented 1 month ago

Hi,

I have a project with dependencies that are not all jar files, e.g. BOM POMs, TXT files, etc. If these dependencies are present, generateXtext tries to read all of these as if they were jar files resulting in a "java.util.zip.ZipException: zip END header not found". PFA projects_x.zip which illustrates the issue.

gradle_generateXtext.log contains the log with stacktrace
.m2/*/ is an extract of my local Maven repo containing the 2 dependencies used (1 BOM POM + 1 TXT file which is defined in the BOM POM)

As a workaround, I have to overload the dependencies in a derived task. IMHO this should not be necessary.

Best regards, Stephan

cdietrich commented 1 month ago

can you please provide a complete reproducer?

shaertel-rok commented 1 month ago

The zip contains all you need, only that you have to create your own 2 dependencies similar to the ones I have packed under .m2/*/ as these are not accessible on any public repo. Hope this helps.

cdietrich commented 1 month ago

not really as i have no time to set something up. can you provide the file that ends up the in. PathTraverser.findAllResourceUris what file is it.

cdietrich commented 1 month ago

is it compileOnly enforcedPlatform("ccccc:all-yyyy-dependency-management:11.1.0.HF5.1-SNAPSHOT") compileOnly "x:y:11.1.0.HF5.1-SNAPSHOT:@txt" that puts the bom file there?

should these go into resources?

i also wonder how we should distinguish these from broken jar files

cdietrich commented 1 month ago

@oehme are you still out there?

shaertel-rok commented 1 month ago

compileOnly enforcedPlatform("ccccc:all-yyyy-dependency-management:11.1.0.HF5.1-SNAPSHOT")

Correct, this is a generated BOM POM. It defines a lot of dependencies (check in the zip), most of them are jars, but not all.

compileOnly "x:y:11.1.0.HF5.1-SNAPSHOT:@txt"

This is one of the TXT dependencies defined in the above BOM POM. In this combination, Gradle feeds both files into the classpath.

oehme commented 1 month ago

@cdietrich Yes, I am. I was the one who asked Stephan to open this issue and give me an example. I got this from here, thanks.

@shaertel-rok I'll have time to dig deeper into your example this weekend. In the meantime, did the fix I linked you to via email work? If so, I'll make a PR for that and we can have a quick patch release.

shaertel-rok commented 1 month ago

Hi @oehme, all,

I have meanwhile overloaded the dependencies. This corresponds to the classpathElements attribute we used on the original Maven task before migrating to Gradle. I believe this is a valid approach, so I am currently no longer affected by this issue.

Nevertheless IHMO

having dependencies that are not zipped is a valid usecase. (Note we have .jar, .zip and proprietary .dsx files which essentially are all zips + a large number of file types that are not, including BOM POMs, property files, TXT, etc..)
the error handling should at least print out the failing dependency. The existing error message did not help and it took me ~2 MD before I found how I could debug the xtext-gradle-plugin (using Eclipse + Xtext/Xtend plugins) just to diagnose the issue.

Thank you so much for supplying xtext-gradle-plugin! Best regards, Stephan

oehme commented 1 month ago

Alright, I've managed to trim the example down to something that shows the issue. Here's what I think:

The error reporting is already fixed in recent Xtext versions. I used 2.36.0 and the error message now reads Error traversing archive projects_x/.m2/repository/com/rockwell/delivery/ps/all-pharmasuite-dsx-digest/11.1.0.HF5.1-SNAPSHOT/all-pharmasuite-dsx-digest-11.1.0.HF5.1-SNAPSHOT.txt
As you already found out, you can customize XtextGenerate.classpath if the default behavior of using sourceSet.compileClasspath doesn't work for you. So no new features in the Gradle plugin are necessary to work around a situation like this.
I don't know why there are .txt files on your compile classpath. Neither Javac nor Xtext will be able to make use of those. I don't have more details on your project, so I can only guess that this is some kind of runtime metadata. In that case, declaring them as runtimeOnly dependencies would be appropriate.