Re-triggering is not possible (as there was a bug in the travis config) and uploading the artifacts is a bit intransparent to the users and for us in the future?
What do mean it is intransparent? I thought it is a bit ugly to have a tagged version but no artifacts for it, especially since 5.1 is not broken or anything and the webjar is available on the release page already. So I thought we could just do whatever travis normally does manually (all we need is probably some authentication key and then run mvn deploy or something?). But sure we can also create a new tag 5.2.
What do mean it is intransparent?
The log of that build wouldnāt be public. When using the tagged commit as release trigger there is no way to my knowledge to modify the build process or the jar with e.g. malicious code. Of course we donāt do that, but with a public build log we can even proof that and no one has to trust our words 
I thought it is a bit ugly to have a tagged version but no artifacts for it,
We had this a few times before. Not a big issue IMO.
btw: maybe we should even ask maven to remove the artifacts that contain known security problems?
especially since 5.1 is not broken or anything and the webjar is available on the release page already.
Could we remove this and maybe explain it in 5.2 (?)
all we need is probably some authentication key and then run
mvn deploy
Yes
Ok that makes sense. Will do.
btw: maybe we should even ask maven to remove the artifacts that contain known security problems?
It seems a bit ugly to remove artifacts as someone might use them downstream, and there werenāt any very serious security problems or which artifacts do you mean?
Yes, probably not that nice ā¦ I meant e.g. version 2.0 - 2.3 that have these Navigate endpoint is vulnerable to regex injection that may lead to Denial of Service. Ā· Advisory Ā· graphhopper/graphhopper Ā· GitHub and was fixed in 2.4 and 4.0
I tagged the 5.2 version and the build is āgreenā, but the build log says the builed failed:
There are errors related to the javadoc plugin:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:3.1.1:jar (attach-javadocs) on project graphhopper-core: MavenReportException: Error while generating Javadoc:
[ERROR] Exit code: 1 - /home/travis/build/graphhopper/graphhopper/core/src/main/java/com/graphhopper/GraphHopper.java:162: warning: no @param for precision
[ERROR] public GraphHopper setPreciseIndexResolution(int precision) {
[ERROR] ^
[ERROR] /home/travis/build/graphhopper/graphhopper/core/src/main/java/com/graphhopper/GraphHopper.java:162: warning: no @return
[ERROR] public GraphHopper setPreciseIndexResolution(int precision) {
[ERROR] ^
[ERROR] /home/travis/build/graphhopper/graphhopper/core/src/main/java/com/graphhopper/GraphHopper.java:181: warning: no @return
[ERROR] public GraphHopper setStoreOnFlush(boolean storeOnFlush) {
[ERROR] ^
[ERROR] /home/travis/build/graphhopper/graphhopper/core/src/main/java/com/graphhopper/GraphHopper.java:217: warning: no @param for profiles
[ERROR] public GraphHopper setProfiles(Profile... profiles) {
[ERROR] ^
[ERROR] /home/travis/build/graphhopper/graphhopper/core/src/main/java/com/graphhopper/GraphHopper.java:217: warning: no @return
[ERROR] public GraphHopper setProfiles(Profile... profiles) {
[ERROR] ^
[ERROR] /home/travis/build/graphhopper/graphhopper/core/src/main/java/com/graphhopper/GraphHopper.java:241: warning: no @param for profileName
[ERROR] public Profile getProfile(String profileName) {
[ERROR] ^
I donāt even think this plugin should be enabled as our javadocs are useless anyway. I mean they are not useful to be used as html-only pages (I suppose this is what this plugin is supposed to do).
And can we somehow name the different builds? The build matrix isnāt very informative like this:
I donāt even think this plugin should be enabled as our javadocs are useless anyway.
Uhm, ok. Will have a look what it wants from us
Yes, due to jdk_release_fix there will be only one build left or even this will be removed. But this is currently a bit blocked by a bug of setup-java for 19-ea.
Uhm, ok. Will have a look what it wants from us
Yes, really strange. Why did the build pass when maven failed? And why did maven fail because of the javadoc plugin when normally it does not fail?
Yes, due to jdk_release_fix there will be only one build left or even this will be removed. But this is currently a bit blocked by a bug of setup-java for 19-ea.
If it is blocked by 19-ea, maybe just remove it and put it back later when it is working (and we really need it)?
And why did maven fail because of the javadoc plugin when normally it does not fail?
There was once an error regarding javadoc that let the build fail. But do not remember how we fixed this 
If it is blocked by 19-ea, maybe just remove it and put it back later when it is working (and we really need it)?
Yes, will do. To reduce effort for now I planned to keep building the release from travis on jdk8 - would you find this ok? (having 1 build on travis and the others for every commit on github actions)
I think the problems are these javadoc errors (not the many warnings) and when I run it locally I even get an exception:
[ERROR] Generating /home/peter/Documents/quell/graphhopper/core/target/site/apidocs/com/graphhopper/routing/util/parsers/OSMMtbRatingParser.html...
[ERROR] error: An internal exception has occurred.
[ERROR] (java.lang.IllegalStateException: ERRONEOUS)
[ERROR] Please file a bug against the javadoc tool via the Java bug reporting page
[ERROR] (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com)
[ERROR] for duplicates. Include error messages and the following diagnostic in your report. Thank you.
[ERROR] java.lang.IllegalStateException: ERRONEOUS
[ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDocletWriter.seeTagToContent(HtmlDocletWriter.java:1019)
[ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.TagletWriterImpl.seeTagOutput(TagletWriterImpl.java:318)
[ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.taglets.SeeTaglet.getAllBlockTagOutput(SeeTaglet.java:82)
[ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.taglets.TagletWriter.getBlockTagOutput(TagletWriter.java:288)
[ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDocletWriter.getBlockTagOutput(HtmlDocletWriter.java:365)
[ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDocletWriter.getBlockTagOutput(HtmlDocletWriter.java:351)
[ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDocletWriter.addTagsInfo(HtmlDocletWriter.java:337)
[ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.ClassWriterImpl.addClassTagInfo(ClassWriterImpl.java:224)
[ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.builders.ClassBuilder.buildClassTagInfo(ClassBuilder.java:316)
[ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.builders.ClassBuilder.buildClassInfo(ClassBuilder.java:185)
[ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.builders.ClassBuilder.buildClassDoc(ClassBuilder.java:147)
[ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.builders.ClassBuilder.build(ClassBuilder.java:113)
[ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDoclet.generateClassFiles(HtmlDoclet.java:388)
[ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.AbstractDoclet.generateClassFiles(AbstractDoclet.java:286)
[ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDoclet.generateClassFiles(HtmlDoclet.java:199)
[ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:212)
[ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.AbstractDoclet.run(AbstractDoclet.java:115)
[ERROR] at jdk.javadoc/jdk.javadoc.doclet.StandardDoclet.run(StandardDoclet.java:103)
[ERROR] at jdk.javadoc/jdk.javadoc.internal.tool.Start.parseAndExecute(Start.java:556)
[ERROR] at jdk.javadoc/jdk.javadoc.internal.tool.Start.begin(Start.java:393)
[ERROR] at jdk.javadoc/jdk.javadoc.internal.tool.Start.begin(Start.java:342)
[ERROR] at jdk.javadoc/jdk.javadoc.internal.tool.Main.execute(Main.java:63)
[ERROR] at jdk.javadoc/jdk.javadoc.internal.tool.Main.main(Main.java:52)
[ERROR] 6 errors
For OSMMtbRatingParser as we have an incorrect href in the second link
Yes the ones I pasted above were also errors, not just warnings. It complains about all kinds of things. This probably only fails when we create a tag because otherwise the javadoc plugin does not run. I would just remove the javadoc plugin. I cannot imagine a single person is reading the GraphHopper Java API using the created HTML, and if they do I highly recommend not to do this
I would just remove the javadoc plugin.
Ah, I just fixed all the errors so that this should pass but I donāt care much eitherā¦ have removed it here: Clean up javadoc comments by karussell Ā· Pull Request #2569 Ā· graphhopper/graphhopper Ā· GitHub
To reduce effort for now I planned to keep building the release from travis on jdk8 - would you find this ok? (having 1 build on travis and the others for every commit on github actions)
I think Iām ok with everything, just the per-commit github package build should be as fast as possible. And if we move the tagged/release build and the build that runs the tests to github actions why do we need a jdk8 build on travis anymore?
To later get rid of it
but make this change to github actions as fast as possible (setting up the maven release process was quite tedious, so I expect a certain delay for github actions too)
In fact I will merge this branch now
And why did maven fail because of the javadoc plugin when normally it does not fail?
This must be related to the exact JDK version. The command mvn compile javadoc:javadoc runs fine when I use
openjdk version "1.8.0_312"
OpenJDK Runtime Environment (build 1.8.0_312-8u312-b07-0ubuntu1~21.10-b07)
OpenJDK 64-Bit Server VM (build 25.312-b07, mixed mode)
but it fails for
openjdk version "1.8.0_332"
OpenJDK Runtime Environment (Temurin)(build 1.8.0_332-b09)
OpenJDK 64-Bit Server VM (Temurin)(build 25.332-b09, mixed mode)
(this is the one we setup for the tagged release recently).
Why did the build pass when maven failed?
I still donāt knowā¦ The only thing I understood now is that only one of the four builds failed, because the javadoc plugin only runs for the one for which we call mvn deploy (the release build).
Aha and apparently the reason is that the debian JDK build disables doclint, but the Temurin build probably does notā¦ java - Javadoc fails on Oracle JDK but doesn't on OpenJDK - Stack Overflow
This also explains why the javadoc not only does not error with the debian JDK, but does not even show any warningsā¦
Now it worked. The new release is 5.3: Release GraphHopper 5.3 Ā· graphhopper/graphhopper Ā· GitHub
This time I downloaded the web jar from maven central and uploaded it to the GitHub release page from there.
1 Like
Thanks a lot! And this is a good idea to upload the web jar from maven. Maybe we could even automated this or even link to the maven web jar?
Automating this seems a bit overkill and rather error-prone? But sure we could just add the link to maven central instead of uploading anything to GitHub.
1 Like