bcel/bcel.spec

204 lines
7.1 KiB
RPMSpec

#
# spec file for package bcel (Version 5.2)
#
# Copyright (c) 2009 SUSE LINUX Products GmbH, Nuernberg, Germany.
#
# All modifications and additions to the file contributed by third parties
# remain the property of their copyright owners, unless otherwise agreed
# upon. The license for this file, and modifications and additions to the
# file, is the same license as for the pristine package itself (unless the
# license for the pristine package is not an Open Source License, in which
# case the license is the MIT License). An "Open Source License" is a
# license that conforms to the Open Source Definition (Version 1.9)
# published by the Open Source Initiative.
# Please submit bugfixes or comments via http://bugs.opensuse.org/
#
# norootforbuild
# icecream 0
Name: bcel
BuildRequires: ant java-1_5_0-gcj-compat-devel regexp xerces-j2-bootstrap xml-commons-apis-bootstrap
#!BuildIgnore: xml-commons-apis xml-commons-resolver xml-commons xerces-j2
BuildRequires: ant-nodeps
%define name bcel
%define version 5.2
%define release 5jpp
%define section free
%define manual 0
Version: 5.2
Release: 1
Summary: Byte Code Engineering Library
License: The Apache Software License
Source0: http://jakarta.apache.org/builds/jakarta-bcel/release/v%{version}/bcel-%{version}-src.tar.bz2
Url: http://jakarta.apache.org/bcel
Group: Development/Libraries/Java
Requires: regexp
BuildArch: noarch
BuildRoot: %{_tmppath}/%{name}-%{version}-build
%description
The Byte Code Engineering Library is intended to give users a
convenient way to analyze, create, and manipulate (binary) Java class
files (those ending with .class). Classes are represented by objects
that contain all the symbolic information of the given class: methods,
fields, and byte code instructions, in particular.
Such objects can be read from an existing file, transformed by a
program (such as a class loader at runtime), and dumped to a file
again. An even more interesting application is the creation of classes
from scratch at runtime. The Byte Code Engineering Library (BCEL) may
also be useful if you want to learn about the Java Virtual Machine
(JVM) and the format of Java .class files.
BCEL is already being used successfully in several projects, such as
compilers, optimizers, obfuscators, code generators, and analysis
tools.
It contains a byte code verifier named JustIce, which usually gives you
much better information about what is wrong with your code than the
standard JVM message.
%package javadoc
License: The Apache Software License
PreReq: coreutils
Summary: Javadoc for bcel
Group: Development/Libraries/Java
%description javadoc
This package contains the javadoc documentation of the Byte Code
Engineering Library.
The Byte Code Engineering Library is intended to give users a
convenient way to analyze, create, and manipulate (binary) Java class
files (those ending with .class). Classes are represented by objects
which contain all the symbolic information of the given class: methods,
fields and byte code instructions, in particular.
Such objects can be read from an existing file, be transformed by a
program (e.g. a class loader at run-time) and dumped to a file again.
An even more interesting application is the creation of classes from
scratch at run-time. The Byte Code Engineering Library (BCEL) may also
be useful if you want to learn about the Java Virtual Machine (JVM) and
the format of Java .class files.
BCEL is already being used successfully in several projects such as
compilers, optimizers, obfuscators, code generators and analysis tools.
It contains a byte code verifier named JustIce, which usually gives you
much better information about what's wrong with your code than the
standard JVM message.
%if %manual
%package manual
Summary: Manual for bcel
Group: Development/Libraries/Java
%description manual
This package contains the manual for the Byte Code Engineering Library.
The Byte Code Engineering Library is intended to give users a
convenient way to analyze, create, and manipulate (binary) Java class
files (those ending with .class). Classes are represented by objects
which contain all the symbolic information of the given class: methods,
fields and byte code instructions, in particular.
Such objects can be read from an existing file, be transformed by a
program (e.g. a class loader at run-time) and dumped to a file again.
An even more interesting application is the creation of classes from
scratch at run-time. The Byte Code Engineering Library (BCEL) may also
be useful if you want to learn about the Java Virtual Machine (JVM) and
the format of Java .class files.
BCEL is already being used successfully in several projects such as
compilers, optimizers, obfuscators, code generators and analysis tools.
It contains a byte code verifier named JustIce, which usually gives you
much better information about what's wrong with your code than the
standard JVM message.
%endif
%prep
%setup -q
# remove all binary libs
find . -name "*.jar" -exec rm -f {} \;
# very broken build
perl -p -i -e 's| depends=\"examples\"||g;' build.xml
touch manifest.txt
%build
export CLASSPATH=%(build-classpath regexp)
export OPT_JAR_LIST="ant/ant-nodeps"
export LC_ALL="en_US.UTF-8" # necessary for javadoc
%ant -Dbuild.dest=./build -Dbuild.dir=./build -Dname=%{name} compile
%ant -Dbuild.dest=./build -Dbuild.dir=./build -Dname=%{name} jar
%ant -Dbuild.dest=./build -Dbuild.dir=./build -Dname=%{name} javadoc
%install
# jars
%__mkdir_p %{buildroot}%{_javadir}
%__install -m 644 target/%{name}-%{version}.jar %{buildroot}%{_javadir}/%{name}-%{version}.jar
(cd %{buildroot}%{_javadir} && for jar in *-%{version}*; do %__ln_s ${jar} `echo $jar| sed "s|-%{version}||g"`; done)
# javadoc
%__mkdir_p %{buildroot}%{_javadocdir}/%{name}-%{version}
%__cp -a dist/docs/api/* %{buildroot}%{_javadocdir}/%{name}-%{version}
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(0644,root,root,0755)
%doc LICENSE.txt
%{_javadir}/*
%files javadoc
%defattr(0644,root,root,0755)
%{_javadocdir}/%{name}-%{version}
%if %manual
%files manual
%defattr(0644,root,root,0755)
%doc docs/*
%endif
# -----------------------------------------------------------------------------
%changelog
* Mon Jun 01 2009 mvyskocil@suse.cz
- fixed archive name (gz -> bz2) in Source
* Thu May 21 2009 mvyskocil@suse.cz
- update to 5.2
- fixed build under gcj44
- removed javadoc scripplets
* Sun Jul 27 2008 coolo@suse.de
- avoid xerces and xml-commons (ant still works)
* Tue Jul 22 2008 coolo@suse.de
- build with gcj to avoid build cycle
* Mon Sep 25 2006 skh@suse.de
- don't use icecream
- use source="1.4" and target="1.4" for build with java 1.5
* Wed Jan 25 2006 mls@suse.de
- converted neededforbuild to BuildRequires
* Wed Jul 27 2005 jsmeix@suse.de
- Adjustments in the spec file.
* Mon Jul 18 2005 jsmeix@suse.de
- Current version 5.1 from JPackage.org
* Thu Sep 16 2004 skh@suse.de
- Fix prerequires of javadoc subpackage
* Sat Sep 04 2004 skh@suse.de
- Switched to JPackage 1.5 version
- split off subpackages bcel-javadoc and bcel-manual
* Mon Feb 09 2004 pmladek@suse.cz
- package created, version 5.1
- added trigger to create link to the ant lib dir