FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development Java

 
 
LinkBack Thread Tools
 
Old 07-01-2008, 03:43 PM
Daniel Veillard
 
Default libvirt-java bindings

Hi,

I have just started to release and package java bindings for libvirt.
I have made a request for review for Fedora on the new package:
https://bugzilla.redhat.com/show_bug.cgi?id=453119

I found the exercise rather hard, JNI is of course on the edge of the Java
land, but it's hard to find good resources to look at for Java bindings
in Fedora, the gnome-java stuff seems very specific, and a lot of packages
basically rely on gcj for compilation of any JNI stuff.

I would like something more flexible, to that end I added some JDK dynamic
detection in configure.in for my package, which then allows to guess the
jni.h and jni_md.h based on the javah and javac used to generate the bindings
(so things should stay consistent).
In the spec file I used the following:

%define java java
and
Requires: %{java} >= 1.5.0
BuildRequires: %{java}-devel >= 1.5.0

to easilly allow the user to specify more strictly what java development
package to use. I don't know if this is sufficient in general for the
previous versions of Fedora, it seems to work with java-1.6.0-openjdk
in F-9 or something as old as java-1.5.0-ibm-1.5.0.7 on a RHEL-4 box,
but the java class compilations break for example with java-1.5.0-gcj [-devel]
on Fedora-8 (didn't tried icedtea yet, though I guess that would work)
this looks related to dependancies when compiling a bunch of .java
together in one command as

/usr/bin/javac -classpath "org/libvirt" org/libvirt/*.java
2. ERROR in org/libvirt/VirConnectAuthDefault.java (at line 14)
credType= new VirConnectCredential.VirConnectCredentialType[] {
^^^^^^^^
credType cannot be resolved

though VirConnectCredential.java is there and defines the type.

Portability tricks and eyeballs for the review would be very welcome !
(as well as patches to improve the package source of course but that
would be best conducted on the libvirt list).

thanks in advance,

Daniel

--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
 
Old 07-01-2008, 03:54 PM
Andrew Haley
 
Default libvirt-java bindings

Daniel Veillard wrote:
> the java class compilations break for example with java-1.5.0-gcj [-devel]
> on Fedora-8 (didn't tried icedtea yet, though I guess that would work)
> this looks related to dependancies when compiling a bunch of .java
> together in one command as
>
> /usr/bin/javac -classpath "org/libvirt" org/libvirt/*.java
> 2. ERROR in org/libvirt/VirConnectAuthDefault.java (at line 14)
> credType= new VirConnectCredential.VirConnectCredentialType[] {
> ^^^^^^^^
> credType cannot be resolved
>
> though VirConnectCredential.java is there and defines the type.

Hmm. I think we need to find out if this is a real bug in ecj, and
fix it if so. I can't remember seeing anything like this before.

Can you create a stand-alone test case that shows this failure? I can't
figure out how to do so.

I don't think we should target a particular Java compiler if that can be
avoided.

Andrew.

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
 
Old 07-01-2008, 04:15 PM
Benjamin Reed
 
Default libvirt-java bindings

Daniel Veillard wrote:


Portability tricks and eyeballs for the review would be very welcome !


It also still wouldn't work with the official sun RPMs, which I wish we
had some kind of simpler solution for, interoperability-wise.


At least making it a define of some kind would make it easy to generate
the packages twice, once for fedora deps, and once for sun deps. ie,
instead of:



%define java java


...you could do something like this instead:

%{!?java_requires:%define java_requires java}
%{!?java_buildrequires:%define java_buildrequires java-devel}
%{!?java_min_version:%define java_min_version 1.5.0}


and
Requires: %{java} >= 1.5.0
BuildRequires: %{java}-devel >= 1.5.0


...and then:

Requires: %{java_requires} >= %{java_min_version}
BuildRequires: %{java_buildrequires} >= %{java_min_version}


This lets you do:

rpmbuild
--define "java_requires jre"
--define "java_buildrequires jdk"
--define "java-min_version 1.6.0"
-ba mypackage.spec

...to override the defaults. (I think that's the right syntax...)

--
Benjamin Reed
The OpenNMS Group
http://www.opennms.org/


--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
 
Old 07-01-2008, 04:24 PM
David Walluck
 
Default libvirt-java bindings

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Veillard wrote:
| I would like something more flexible, to that end I added some JDK dynamic
| detection in configure.in for my package, which then allows to guess the
| jni.h and jni_md.h based on the javah and javac used to generate the
bindings
| (so things should stay consistent).
| In the spec file I used the following:

There is no need since java and java-devel are virtual Provides provided
by every compliant JDK, so the user is already allowed to choose the JDK
that they want to build with.

Also, there are macros that should be used when refering to the JDK so
that you pick up the default JDK used for building and not the current
default alternative (e.g., %{java_home}, %{java}, %{javac}, %{jar}).

Unfortunately, there are recent packages passing the Fedora review that
directly specify java-1.6.0-openjdk-devel as the JDK and I personally
don't like this.

I think that this comes from two schools of thought: one group wants to
tie the Fedora package even more tightly to Fedora and the other wants
to leave the options open. Since Fedora more-or-less has only one JDK
(or two counting GCJ which is optional), this benefit is mostly
theoretical, but you can see from the current discussion that it can be
useful. Similarly, since Fedora can force the default JDK setup at build
time through the build system, although the packages are technically not
as flexible as they could be, it's never really a problem in practice.

- --
Sincerely,

David Walluck
<david@zarb.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iEYEARECAAYFAkhqWlAACgkQItObMyg2XCUpNgCghlrnFGtwJP ikTBuBxLCCNLLe
3r0AnRs5bIeVxAruG1Ri/bkhQuYwY/63
=6Tqq
-----END PGP SIGNATURE-----

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
 
Old 07-01-2008, 04:35 PM
"Mary Ellen Foster"
 
Default libvirt-java bindings

2008/7/1 David Walluck <david@zarb.org>:
> Unfortunately, there are recent packages passing the Fedora review that
> directly specify java-1.6.0-openjdk-devel as the JDK and I personally
> don't like this.

I have one recent package that does this (specifies openjdk on F9+ and
icedtea on F8) and one that doesn't (just wants java >= 1.5). The
first package uses JNI and needs a Sun-like JVM to work (or at least
it took more autotools hacking than I cared to try to make it work),
and if I just put Requires: java it tended to grab gcj. I guess I
could also put java > 1.5, but the issue isn't the 1.5-ness, it's the
Sun-style JNI classes.

(The packages are pl-jpl and ice-java, respectively, if you're wondering).

MEF

--
Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/
Informatik 6: Robotics and Embedded Systems, Technische Universität München
and ICCS, School of Informatics, University of Edinburgh

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
 
Old 07-01-2008, 04:36 PM
"Mary Ellen Foster"
 
Default libvirt-java bindings

[ oops, just replied to Andrew the first time ... ]

2008/7/1 Andrew Haley <aph@redhat.com>:
> Daniel Veillard wrote:
>> the java class compilations break for example with java-1.5.0-gcj [-devel]
>> on Fedora-8 (didn't tried icedtea yet, though I guess that would work)
>> this looks related to dependancies when compiling a bunch of .java
>> together in one command as
>>
>> /usr/bin/javac -classpath "org/libvirt" org/libvirt/*.java
>> 2. ERROR in org/libvirt/VirConnectAuthDefault.java (at line 14)
>> credType= new VirConnectCredential.VirConnectCredentialType[] {
>> ^^^^^^^^
>> credType cannot be resolved
>>
>> though VirConnectCredential.java is there and defines the type.
>
> Hmm. I think we need to find out if this is a real bug in ecj, and
> fix it if so. I can't remember seeing anything like this before.
>
> Can you create a stand-alone test case that shows this failure? I can't
> figure out how to do so.

I think the problem might actually be a lack of "-source 1.5" on the
javac line, actually. Without that, it doesn't seem to like the "enum"
declarations and doesn't create any of the enum classes, resulting in
the above error (and, if you scroll down, errors about the enum
declarations too).

This is testing with java-1.5.0-gcj-devel-1.5.0.0-17.fc8 on Fedora 8, FWIW.

MEF

--
Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/
Informatik 6: Robotics and Embedded Systems, Technische Universität München
and ICCS, School of Informatics, University of Edinburgh

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
 
Old 07-01-2008, 04:39 PM
Andrew Haley
 
Default libvirt-java bindings

Mary Ellen Foster wrote:
> [ oops, just replied to Andrew the first time ... ]
>
> 2008/7/1 Andrew Haley <aph@redhat.com>:
>> Daniel Veillard wrote:
>>> the java class compilations break for example with java-1.5.0-gcj [-devel]
>>> on Fedora-8 (didn't tried icedtea yet, though I guess that would work)
>>> this looks related to dependancies when compiling a bunch of .java
>>> together in one command as
>>>
>>> /usr/bin/javac -classpath "org/libvirt" org/libvirt/*.java
>>> 2. ERROR in org/libvirt/VirConnectAuthDefault.java (at line 14)
>>> credType= new VirConnectCredential.VirConnectCredentialType[] {
>>> ^^^^^^^^
>>> credType cannot be resolved
>>>
>>> though VirConnectCredential.java is there and defines the type.
>> Hmm. I think we need to find out if this is a real bug in ecj, and
>> fix it if so. I can't remember seeing anything like this before.
>>
>> Can you create a stand-alone test case that shows this failure? I can't
>> figure out how to do so.
>
> I think the problem might actually be a lack of "-source 1.5" on the
> javac line, actually. Without that, it doesn't seem to like the "enum"
> declarations and doesn't create any of the enum classes, resulting in
> the above error (and, if you scroll down, errors about the enum
> declarations too).
>
> This is testing with java-1.5.0-gcj-devel-1.5.0.0-17.fc8 on Fedora 8, FWIW.

Okay, thanks. That should be easy to fix then.

Daniel, please try that and report.

I could have sworn that we changed the default for ecj to 1.5. We
surely should have done.

Andrew.

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
 
Old 07-01-2008, 04:42 PM
Benjamin Reed
 
Default libvirt-java bindings

David Walluck wrote:


Also, there are macros that should be used when refering to the JDK so
that you pick up the default JDK used for building and not the current
default alternative (e.g., %{java_home}, %{java}, %{javac}, %{jar}).


Aha, I was not aware of these defines.


Unfortunately, there are recent packages passing the Fedora review that
directly specify java-1.6.0-openjdk-devel as the JDK and I personally
don't like this.

I think that this comes from two schools of thought: one group wants to
tie the Fedora package even more tightly to Fedora and the other wants
to leave the options open. Since Fedora more-or-less has only one JDK
(or two counting GCJ which is optional), this benefit is mostly
theoretical, but you can see from the current discussion that it can be
useful. Similarly, since Fedora can force the default JDK setup at build
time through the build system, although the packages are technically not
as flexible as they could be, it's never really a problem in practice.


My main issue is that as a package maintainer, if I want to support
Fedora officially *and* other RPM-based distributions (through our own
yum repository) I have doubled my workload since I need to make packages
that use fedora-style dependencies for fedora, and package that use
sun-jdk-style dependencies for everyone else. Right now I depend on
"jdk" and everything works peachy everywhere, we make a .noarch.rpm and
it runs on every supported RPM platform on the planet.


Depending on java-1.6.0-openjdk-devel is the worst of the options, from
a 3rd-party-packager point of view. However, now that I know about the
fedora %{java_home} macros, perhaps a better option is to provide
fallback macros for various compatibility levels.


IE, for building my generic everyone-but-fedora packages I would have a
"sun-java-macros" set (in ~/.rpmmacros?) that would set %{java_home} to
/usr/java/jdk1.6.0_05, %{jdk} to jdk (the sun package name)
%{jdk_version} to 2000:1.6.0_05 and so on, and do:


Requires: %{jre} >= %{jre_version}
BuildRequires: %{jdk} >= %{jdk_version}

%build
JAVA_HOME=%{java_home} mvn install assembly:directory-inline


...and on fedora, it would fill those macros in to use the
openjdk-provided deps, or if someone needs something specific, they can
set %{jre} or %{jdk} to a specific package name.


It still wouldn't leave me with a universal "opennms.noarch.rpm" which
would be best, but it would simplify generating distro-specific rpms.


Not that I can't generate spec files to work with fedora with a script
or something, it just seems really lame to have to special case "fc9" vs
"!fc9" specifically. =)


--
Benjamin Reed
The OpenNMS Group
http://www.opennms.org/


--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
 
Old 07-01-2008, 06:01 PM
David Walluck
 
Default libvirt-java bindings

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Benjamin Reed wrote:
| David Walluck wrote:
|
|> Also, there are macros that should be used when refering to the JDK so
|> that you pick up the default JDK used for building and not the current
|> default alternative (e.g., %{java_home}, %{java}, %{javac}, %{jar}).
|
| Aha, I was not aware of these defines.

These should be available through the jpackage macros from
jpackage-utils (see /etc/rpm/macros.jpackage).

| My main issue is that as a package maintainer, if I want to support
| Fedora officially *and* other RPM-based distributions (through our own

Not at all. If you follow the JPackage conventions you will support any
distribution which carries jpackage-utils. These include: ALT, Fedora,
Mandriva, PCLOS, Red Hat, Suse, and possibly others.

This means using java-devel like I said and not relying on the Sun
conventions (this also allows you to support multiple JDK versions and
not just multiple Linux distributions with a single JDK version). Also,
since Sun supported the DLJ Java packages, at least Mandriva is shipping
JPackage-compliant DLJ Sun Java bundles with their OS which would be far
superior to any Sun packaging offering due to JPackage compliance.

This also means, like I said in a previous email, that I don't think
additional macros are needed, but check the macros file first and see if
you think anything is missing.

- --
Sincerely,

David Walluck
<david@zarb.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iEYEARECAAYFAkhqcP0ACgkQItObMyg2XCVXcQCgiVGskRSE2w j8lAR8vwgy0+TF
1kIAoKshQHjcf/AGOhv6EbU0L1RACWk0
=dkhY
-----END PGP SIGNATURE-----

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
 
Old 07-01-2008, 06:08 PM
David Walluck
 
Default libvirt-java bindings

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mary Ellen Foster wrote:
| I have one recent package that does this (specifies openjdk on F9+ and
| icedtea on F8) and one that doesn't (just wants java >= 1.5). The
| first package uses JNI and needs a Sun-like JVM to work (or at least
| it took more autotools hacking than I cared to try to make it work),
| and if I just put Requires: java it tended to grab gcj. I guess I
| could also put java > 1.5, but the issue isn't the 1.5-ness, it's the
| Sun-style JNI classes.

This is not an issue with the java-devel packages, but rather an issue
with either the upstream configure or an issue with the GCJ packaging.

If it is lack of JNI support in GCJ, that is one thing. If it is simply
that the package is expecting a differnt layout that is another.

| (The packages are pl-jpl and ice-java, respectively, if you're wondering).

I was not referring specifically to your packages. But I also haven't
been able to look and see if there is a simple fix available for GCJ.
You should raise the issue on this list though because there are people
here who can help with either issue.

- --
Sincerely,

David Walluck
<david@zarb.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iEYEARECAAYFAkhqcokACgkQItObMyg2XCXywACfTMLzyrvRTV T08cw6zwNZmCum
tK0An1nRpk0WuFIlLRJljVaZjTKQSZTO
=/Hdt
-----END PGP SIGNATURE-----

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
 

Thread Tools




All times are GMT. The time now is 10:12 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org