atom feed12 messages in com.googlegroups.bluecove-users[BlueCove-users] Re: Bluecove native ...
FromSent OnAttachments
F. KoomanJan 16, 2009 3:21 am 
Vlad SkarzhevskyyJan 16, 2009 8:14 am 
Vlad SkarzhevskyyJan 16, 2009 8:45 am 
F. KoomanJan 16, 2009 10:33 am 
F. KoomanJan 16, 2009 10:38 am 
Mina ShokryJan 17, 2009 5:22 am 
F. KoomanJan 17, 2009 9:13 am 
Vlad SkarzhevskyyJan 17, 2009 12:02 pm 
F. KoomanJan 17, 2009 1:31 pm 
Vlad SkarzhevskyyJan 17, 2009 2:57 pm 
Vlad SkarzhevskyyJan 17, 2009 3:45 pm 
Vlad SkarzhevskyyJan 17, 2009 4:11 pm 
Subject:[BlueCove-users] Re: Bluecove native library loading, Fedora RPM packaging
From:Vlad Skarzhevskyy (skar@gmail.com)
Date:Jan 17, 2009 2:57:39 pm
List:com.googlegroups.bluecove-users

The "2.1.1-SNAPSHOT" is not a problem it is a feature! Now the library is in development! So for version 2.1.1 only SNAPSHOTs are available. Once we made a release of 2.1.1 (some time this spring) it would have a version number without "-SNAPSHOT"

I would suggest to make a packages for 2.1.0 version. Using some selected files from current svn!

BTW bluecove.jar is also platform defendant and is using native code on windows and Mac OSX.

If you taking changelog.txt from svn the keep in mind that it is not maintained. better get the text from this URL http://code.google.com/p/bluecove/wiki/Changelog

bluecove-bluez was intended to rplace bluecove-gpl! It was fasted to make bluecove-gpl module then proper implementation 'bluecove-bluez' using D-Bus bluecove-bluez is still work in progress.

""BlueCove-gpl" GPLv2 or GPLv3." I'm managing the headers and I probably made a mistake! As I see we can't link to GPLv2 (bluez) and say that we are GPLv3. So its a mess....

On Sat, Jan 17, 2009 at 4:32 PM, F. Kooman <fkoo@tuxed.net> wrote:

On Jan 17, 9:02 pm, Vlad Skarzhevskyy <skar@gmail.com> wrote:

This is my points. - There should be minimum two jars in RPM package, because this is the way library distributed now!

I have done this now, actually gpl is now a subpackage in bluecove spec file. This can still be split up in multiple "real" packages if necessary, it may make sense to do that seen the amount of different modules :)

Don't forget that there are additional modules: bluecove-emu, bluecove-emu-gui, bluecove-bluez

bluecove-bluez is what exactly? A backend that doesn't use BlueZ itself directly, only through dbus? Or is it only for device discovery / using existing trusts/bindings? Will it eventually replace bluecove-gpl or is it an addon for bluecove-gpl?

Also in next version I would add bluecove-stack

What is the purpose of this one?

- I suggested /usr/lib/bluecove/${version}/ because native library cab be loaded only once. If it is not compatible it can't be unloaded so proper version is loaded. User may have different versions of BlueCove on his computer. One from package one from webstart, one from maven repository .....

I'm not sure I understand correctly why it's needed, but for now I have done this, the problem now is that "SNAPSHOT" is included in the version, so the layout of the (bluecove-gpl) package on x86_64 is like this:

drwxr-xr-x /usr/lib64/bluecove drwxr-xr-x /usr/lib64/bluecove/2.1.1-SNAPSHOT -rw-r--r-- /usr/lib64/bluecove/2.1.1-SNAPSHOT/bluecove-gpl-2.1.1.jar -rwxr-xr-x /usr/lib64/bluecove/2.1.1-SNAPSHOT/libbluecove_x64.so drwxr-xr-x /usr/share/doc/bluecove-gpl-2.1.1 -rw-r--r-- /usr/share/doc/bluecove-gpl-2.1.1/AUTHORS.txt -rw-r--r-- /usr/share/doc/bluecove-gpl-2.1.1/LICENSE.txt

- Build puts the native lib inside the JAR. This can be changed! There is no point to have native libs inside RPM package twice. One in jar another in /usr/lib/bluecove

I was doing that already in the spec file, but that's a bit ugly. It makes more sense to modify the build.xml file indeed, or make it somehow optional...

- I have no preferences where to put jar in the system /usr/share/java or /usr/lib(64)/$name/ I think that it would be nice to have then located together side by side.

I put now the platform independent jar (bluecove) in /usr/share/java and the bluecove-gpl in /usr/lib<arch>/bluecove/version/ for now.

We need to clarify "BlueCove-gpl" GPLv2 or GPLv3. I was thinking that we should keep the same license as BlueZ. The links on out website are incorrect. We never specified the exact version of GPL we used.

Well, I just checked the text in the source files of the projects and this is what came up. So they are actually specifically licensed under what I said above, so it seems to be clear :)

Some other (minor) issues that came up while packaging: - README.txt in bluecove has DOS line endings (fix with: sed --in- place 's/\r$//' README.txt) - AUTHORS.txt in bluecove-gpl has DOS line endings (fix with: sed --in- place 's/\r$//' AUTHORS.txt) - AUTHORS.txt in bluecove-gpl has wrong permissions (executable, fix with chmod 0644 AUTHORS.txt) - device.txt is not UTF-8 (fix with: iconv --from=ISO-8859-1 -- to=UTF-8 device.txt > device.txt.new ; mv device.txt.new device.txt) - changelog.txt is not UTF-8 (fix with: iconv --from=ISO-8859-1 -- to=UTF-8 changelog.txt > changelog.txt.new ; mv changelog.txt.new changelog.txt)

Also, the native library is not linked against libc and doesn't have a soname, apparently this is not really nice as it generates some errors in the build process of the package. I fixed this by removing the line: <arg value="-nodefaultlibs"/>

from bluecove-gpl build.xml and adding the line: <arg value="-Wl,-soname,${library_name}"/>

Not sure whether ${library_name} is appropriate as a soname, but it seems to work.

I'm using the SVN snapshot r2706 now.

To make it complete, here the layout of the bluecove package:

drwxr-xr-x /usr/share/doc/bluecove-2.1.1 -rw-r--r-- /usr/share/doc/bluecove-2.1.1/AUTHORS.txt -rw-r--r-- /usr/share/doc/bluecove-2.1.1/LICENSE.txt -rw-r--r-- /usr/share/doc/bluecove-2.1.1/README.txt -rw-r--r-- /usr/share/doc/bluecove-2.1.1/changelog.txt -rw-r--r-- /usr/share/doc/bluecove-2.1.1/device.txt -rw-r--r-- /usr/share/doc/bluecove-2.1.1/stacks.txt -rw-r--r-- /usr/share/doc/bluecove-2.1.1/todo.txt -rw-r--r-- /usr/share/java/bluecove-2.1.1.jar

Thanks, François