On Tue, Feb 14, 2017 at 4:29 AM Mikolaj Izdebski <mizdebsk@xxxxxxxxxx> wrote:
On 02/14/2017 09:28 AM, Christopher wrote:
> On Tue, Feb 14, 2017 at 2:58 AM Mikolaj Izdebski <mizdebsk@xxxxxxxxxx>
> wrote:
>
>> On 02/08/2017 02:19 AM, Christopher wrote:
>>> So, there's apparently an issue with objectweb-asm{,4}.noarch versions in
>>> RHEL7, in that those versions don't support Java 8 byte code, so I get
>>> errors like in
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=17660223
>>
>> This is known issue in RHEL.
>> See https://bugzilla.redhat.com/show_bug.cgi?id=1381883
>>
>>> objectweb-asm 5 does support Java 8 byte code (as well as previous
>>> versions), but it's not packaged for EPEL7. The current objectweb-asm in
>>> Fedora is version 5.
>>>
>>> How does one go about packaging version 5 for EPEL7? Should I use the
>> epel7
>>> branch of objectweb-asm to create an objectweb-asm5 package for EPEL7?
>> Or,
>>> should I fork the objectweb-asm repo and submit a new package review for
>>> objectweb-asm5?
>>
>> It won't help with the issue you are facing because xmvn (which is part
>> of RHEL) would still use ASM 3.
>>
>>
> And, I can't override that with CLASSPATH= or anything like that with xmvn?
> Does that mean the only option is to wait for RedHat to eventually update
> to 5? Or, is there another option?
ASM 3 and 4+ have incompatible APIs, so you can't simply replace one JAR
with another.
There are some possible workarounds:
1. don't use %mvn_install (use %add_maven_depmap instead)
2. replace JAR containing Java 8 bytecode with some dummy (empty) JAR,
call %mvn_install and restore the JAR after %mvn_install returns.
Thanks! I followed option 2, and it worked great. I didn't quite understand what %mvn_install was doing before, but I think I'm beginning to understand it. I now understand it to be doing:
1. copying artifacts from target/ to %{buildroot}
2. generating depmap metadata
3. creating .mfiles
I guess it's inspecting byte code to determine if the code is noarch or arch-specific (because JNI/JNA)? I guess I just have to be careful when I manually perform these steps that the jar is installed to the correct directory (either %_javadir or %_jnidir). Using an empty jar would make %mvn_install think the jar goes in %_javadir. Am I understanding this correctly?
1. copying artifacts from target/ to %{buildroot}
2. generating depmap metadata
3. creating .mfiles
I guess it's inspecting byte code to determine if the code is noarch or arch-specific (because JNI/JNA)? I guess I just have to be careful when I manually perform these steps that the jar is installed to the correct directory (either %_javadir or %_jnidir). Using an empty jar would make %mvn_install think the jar goes in %_javadir. Am I understanding this correctly?
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
_______________________________________________
java-devel mailing list -- java-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to java-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
--
Christopher
_______________________________________________ java-devel mailing list -- java-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to java-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
