Bug 685464

Summary: jakarta-taglibs-standard: FTBFS - uses deprecated API
Product: Red Hat Enterprise Linux 6 Reporter: Zenon Panoussis <redhatbugs>
Component: jakarta-taglibs-standardAssignee: Java maintainers <java-maint>
Status: CLOSED WONTFIX QA Contact: BaseOS QE - Apps <qe-baseos-apps>
Severity: unspecified Docs Contact:
Priority: low    
Version: 6.0CC: bochecha, mizdebsk
Target Milestone: rcKeywords: EasyFix
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-07-22 08:35:41 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Build with GCJ-1.5
none
Yum deps solver log none

Description Zenon Panoussis 2011-03-15 13:43:01 UTC
[javac] Note: /root/rpmbuild/BUILD/jakarta-taglibs-standard-1.1.1-src/standard/src/org/apache/taglibs/standard/extra/spath/SPathFilter.java uses or overrides a deprecated API.
    [javac] Note: Recompile with -Xlint:deprecation for details.
    [javac] 1 error
    [javac] 40 warnings

BUILD FAILED

It's a common problem, many of the EL6 java applications can only be built under earlier JDKs.

Comment 2 RHEL Program Management 2011-03-15 14:09:00 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

Comment 3 Alexander Kurtakov 2011-04-14 16:37:47 UTC
It builds with java 1.5 only as it was done. Please use gcj for the builds.

Comment 4 Mathieu Bridon 2011-06-03 10:24:16 UTC
Created attachment 502773 [details]
Build with GCJ-1.5

Just stumbled upon this issue as well.

In case that can be useful, I'm attaching the patch (to applly on the latest SRPM in RHEL6) I used to make the package build with GCJ-1.5, so that it can build in mock.

This is based on the instructions at http://fedoraproject.org/wiki/NativeJava

Comment 5 Alexander Kurtakov 2011-06-03 11:39:48 UTC
This patch has nothing to do with the fix. 
The package builds fine because this patch BRs java-gcj-compat-devel, this change only will fix the  build on systems having OpenJDK installed. But I don't agree that the build is broken in mock java-1.5.0-gcj-devel will be preferred by yum thus building just fine.

Comment 6 Mathieu Bridon 2011-07-19 10:28:05 UTC
(In reply to comment #5)
> But I
> don't agree that the build is broken in mock java-1.5.0-gcj-devel will be
> preferred by yum thus building just fine.

It isn't here.

When I try rebuilding the stock RHEL 6 source RPM in mock (after having purged the cache and previous buildroots), I get the following in root.log:
[... snip ...]
DEBUG util.py:284:  Executing command: ['/usr/bin/yum-builddep', '--installroot', '/var/lib/mock/epel-6-x86_64/root/', '/var/lib/mock/epel-6-x86_64/root///builddir/build/SRPMS/jakarta-taglibs-standard-1.1.1-11.4.el6.src.rpm']
DEBUG util.py:250:  Getting requirements for jakarta-taglibs-standard-1.1.1-11.4.el6.src
[... snip ...]
DEBUG util.py:250:  Installing:
DEBUG util.py:250:   ant                         x86_64  1.7.1-13.el6                base     2.5 M
DEBUG util.py:250:   apache-tomcat-apis          noarch  0.1-1.el6                   base     164 k
DEBUG util.py:250:   java-1.6.0-openjdk-javadoc  x86_64  1:1.6.0.0-1.36.b17.el6_0    updates   14 M
DEBUG util.py:250:   jpackage-utils              noarch  1.7.5-3.12.el6              base      59 k
DEBUG util.py:250:   xalan-j2                    noarch  2.7.0-9.8.el6               base     1.8 M
DEBUG util.py:250:  Installing for dependencies:
[... snip ...]
DEBUG util.py:250:   java-1.5.0-gcj              x86_64  1.5.0.0-29.1.el6            base     139 k
DEBUG util.py:250:   java-1.6.0-openjdk          x86_64  1:1.6.0.0-1.36.b17.el6_0    updates   25 M
DEBUG util.py:250:   java-1.6.0-openjdk-devel    x86_64  1:1.6.0.0-1.36.b17.el6_0    updates  8.5 M
[... snip ...]

This is 100% reproduceable, I can upload the full mock logs if you want.

Unless of course there is something I'm doing wrong, in which case I would appreciate any pointer. :)

Comment 7 Alexander Kurtakov 2011-07-19 10:51:38 UTC
Can you find what is pulling java-1.6.0-openjdk-devel for you ?

Comment 8 Mathieu Bridon 2011-07-20 04:29:37 UTC
Created attachment 513909 [details]
Yum deps solver log

Here is the log of the build deps resolution (taken with debuglevel=3).

The relevant lines seem to be:
DEBUG util.py:250:  --> Processing Dependency: java-devel >= 1.5.0 for package: ant-1.7.1-13.el6.x86_64
DEBUG util.py:250:  TSINFO: Marking 1:java-1.6.0-openjdk-devel-1.6.0.0-1.39.1.9.8.el6_1.x86_64 as install for ant-1.7.1-13.el6.x86_64

Comment 9 Mikolaj Izdebski 2012-07-19 11:53:39 UTC
I cannot reproduce this on RHEL 6.3 -- the package builds fine.

Comment 11 Mikolaj Izdebski 2012-07-19 12:21:59 UTC
We are unable to reproduce this bug in current Red Hat Enterprise Linux release. I am closing this bug as NOTABUG.

If you still have this problem then please contact your Red Hat Support representative and open a support request through Red Hat GSS. Bugzilla is not quite the correct forum for Support requests, Bugzilla is an engineering tool.

Comment 12 Mikolaj Izdebski 2016-07-22 05:41:14 UTC
Red Hat Enterprise Linux version 6 is entering the Production 2 phase of its lifetime and this bug doesn't meet the criteria for it, i.e. only high severity issues will be fixed. Please see https://access.redhat.com/support/policy/updates/errata/ for further information.

Comment 13 RHEL Program Management 2016-07-22 08:35:41 UTC
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.