Open matinh opened 4 years ago
The release process currently uses
maven-gpg-plugin` to generate md5/sha1 checksums. It is nowadays recommended to use sha512 checksums. We should probably configure PGP/GPG to use a suitable key for signing.
Update: it seem not the maven-gpg-plugin
but the Maven Resolver
is responsible for generating the checksums. So this is probably an issue for sonatype, where we upload the release to.
The L10n issue was fixed by a plugin update and is working again.
@matinh any interest in me forking this and putting it under the PrimeFaces Extensions org? That way you don't have to worry about maintaining this personally?
Hi @melloware!
@matinh any interest in me forking this and putting it under the PrimeFaces Extensions org? That way you don't have to worry about maintaining this personally?
The release-process is quite straight forward and not that much effort. This time (release 2.1) was a bit of an exception as some infrastructure changed in comparison to previous release (github, sonatype OSS). But all is setup again and working smooth. So currently I don't see any big advantage in handing this over to primefaces. However, you could of course fork it if you like to. But as long as there are no problems with current state I'd prefer to keep it as is.
If you have any ideas for improvement, just file a pull-request and I'm happy to include it in the next version.
No worries. I just always worry about libraries like this that are now in use in bigger projects like PF that whenever they are maintained by one person you could get "hit by a train" and then this project just goes dead on GitHub and no one knows why :)
I can make you a committer on the plugin in PFE of course.
You're right, of course. But same goes for Vdldoc itself, which was controlled by a company sun/oracle and just disappeared until BalusC took over maintainership some years ago. So companies are in this case (IMHO) no better than individuals. And hey, as long as github won't disappear, the code is always there and can be forked, no matter if I got hit by a train or whatever ;-)
The plugin itself and the plugin site builds fine with (at least) Java 11. But while doing the 2.0 release an error occurred due to the use of cobertura-maven-plugin 2.7 with JDK 11. This error was already reported as https://github.com/cobertura/cobertura/issues/271 but is currently still open. Performing the 2.0 release with JDK8 was a usable workaround, but the release process should be fixed/adapted to work with recent JDKs. Probably a switch from cobertura to jacoco will be necessary.
Further on, the L10n Status Report seems not correct. The used plugin was last updated 2009, maybe there's a new version somewhere around.
One more thing: the Checkstyle Report reports some errors. Either disable the report, fix the errors or use a different rule-file.