Hi, I’m trying to fix a Java port (logstash) that's crashing in FreeBSD because of a bug in a Java class in a JAR that's included as a dependency. Three different persons, included I, have submitted a PR upstream (you can see mine here: https://github.com/jnr/jnr-ffi/pull/26) but the activity in that project is pretty slow and nobody has taken action yet.
Now, this issue is blocking the port update in FreeBSD and since I'm not confident upstream is going to answer quickly, I thought about updating the port so that it patches the binary distribution. Fortunately, the offending class is just one so that the patching process may be as simple as this: * Download the binary distribution. * Extract it to the working directory. * Copy the library containing the offending class to a temporary directory. * Extract the JAR. * Substitute the offending class with the patched class. * Recreate the JAR. * Copy the update library to the working directory. The patched class could be distributed as a binary file belonging to the port itself. I'm not sure this approach fits the FreeBSD port philosophy, but on the other hand we could leverage the Java platform independence to simplify a great deal the patch phase of the port: after all, this is a no-build port. Otherwise, the port should grab the sources of the dependent library, building them, and then use the compiled class to perform the aforementioned changes. Since this library (jnr-ffi) is a Maven project, building it would require Maven as a dependency, and during the build Maven would fetch quite a lot of dependencies to perform its job. If I should give somebody a solution, I'm not sure I'd choose the latter. Would you please share your thoughts about this issue? Any feedback and suggestions are greatly appreciated. Regards, -- Enrico
smime.p7s
Description: S/MIME cryptographic signature
