Java 8 objectweb-asm for EPEL7

[Christopher]

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

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?

-- 
Christopher

[Christopher]

I'm still hoping to get feedback on what to do with this one.

On Tue, Feb 7, 2017 at 8:19 PM Christopher <ctubbsii(a)fedoraproject.org&gt;
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
>
>  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?
>
>  --
>  Christopher
>  
-- 
Christopher

[Mikolaj Izdebski]

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.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk

[Christopher]

On Tue, Feb 14, 2017 at 2:58 AM Mikolaj Izdebski <mizdebsk(a)redhat.com&gt;
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?


>  --
>  Mikolaj Izdebski
>  Software Engineer, Red Hat
>  IRC: mizdebsk
>  _______________________________________________
>  java-devel mailing list -- java-devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to java-devel-leave(a)lists.fedoraproject.org
>  
-- 
Christopher

[Mikolaj Izdebski]

On 02/14/2017 09:28 AM, Christopher wrote:
>  On Tue, Feb 14, 2017 at 2:58 AM Mikolaj Izdebski
> <mizdebsk(a)redhat.com&gt;
>  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.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk

[Christopher]

On Tue, Feb 14, 2017 at 4:29 AM Mikolaj Izdebski <mizdebsk(a)redhat.com&gt;
wrote:

>  On 02/14/2017 09:28 AM, Christopher wrote:
>  > On Tue, Feb 14, 2017 at 2:58 AM Mikolaj Izdebski <mizdebsk(a)redhat.com&gt;
>  > 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?


>  --
>  Mikolaj Izdebski
>  Software Engineer, Red Hat
>  IRC: mizdebsk
>  _______________________________________________
>  java-devel mailing list -- java-devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to java-devel-leave(a)lists.fedoraproject.org
>  
-- 
Christopher

[Mikolaj Izdebski]

On 02/15/2017 01:29 AM, Christopher wrote:
> > 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 
Correct, and:
4. injecting some fields into JAR manifest

>  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? 
Yes, that's correct.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk