| Trolltech Home | Qt-jambi-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 1 | |
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I want to pick up the discussion concerning Jambi and Maven 2 by Jostein Gogstad on the mailing list. [1]<br><br><advertisement><br>Maven is a framework that can lower the bar for testing out new frameworks and make getting started easier without having to configure and read documentation to get started.<br>Wicket [2], and its wicket-examples project, is a good reference to how Maven leverages projects without need for extensive documentation.<br></advertisement><br><br>The problem is packaging the native libraries in a way that Jambi can reference them.<br>The normal procedure, as far as I know, is zipping the libs in a jar file, which is referenced in the pom. Maven places the dependencies on the classpath, but does not extract their contents. The lib jar will behave in the same way if one adds it as a project dependency in an IDE.<br>I have tried packaging packaging the lib files in the jar root and in a lib catalog of the jar, without success.<br><br>I have put a simple example, with instructions underneath, of how I believe Maven should work with Jambi. Hope you can help us Mavenaddicts out :)<br><br>Regards<br><br>-Stig,<br><br>[1] <a href="http://lists.trolltech.com/qt-jambi-interest/2007-11/msg00022.html";>http://lists.trolltech.com/qt-jambi-interest/2007-11/msg00022.html</a><br>[2] <a href="http://wicket.apache.org/index.html";>http://wicket.apache.org/index.html</a><br>[3] <a href="http://maven.apache.org/download.html";>http://maven.apache.org/download.html</a><br><br><br>Instructions:<br><br>* Follow Maven setup instructions [3]<br>* Unzip the project<br>* Copy your qtjambi.jar to jambi-example/lib/com/trolltech/qtjambi/jambi-core/gpl-1.0.0-beta2/jambi-core-gpl-1.0.0-beta2.jar<br>* In the terminal in the jambi-example folder, write;<br>* mvn eclipse:eclipse or mvn idea:idea - to set up the project files<br>* mvn install - to compile, test and package<br><br><br>When running mvn install, the test should fail.<br><br>jambi-example/target/surefire-reports/no.bouvet.jambi.CounterTest.txt should read something like:<br>testCounter(no.bouvet.jambi.CounterTest) Time elapsed: 0.083 sec <<< ERROR!<br>java.lang.UnsatisfiedLinkError: __qt_initLibrary<br><span class="Apple-tab-span" style="white-space: pre; "> </span>at com.trolltech.qt.core.QtJambi_LibraryInitializer.__qt_initLibrary(Native Method)<br>...<br><br>jambi-example/lib/com/trolltech/qtjambi/native-libraries/gpl-win-1.0.0-beta2/native-libraries-gpl-win-1.0.0-beta2.jar is the zipfile where the native libraries should be located (not included in the example due to filesize), and where the problem is located.<br>When one uses Maven, the libaries from jambi-example/lib, mentioned in jambi-example pom, are copied to your local repository. When you make changes to the native-libraries file, you should delete the local repository version at /~.m2/repository/com/trolltech/... because maven does not overwrite the dependencies if they already exist.<br><br>When the problem is fixed, mvn install should complete without errors.<br><br></body></html>
Attachment:
jambi-example.zip
Description: Zip archive
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "></body></html>
Stig Lau wrote:
> I want to pick up the discussion concerning Jambi and Maven 2 by Jostein
> Gogstad on the mailing list. [1]
>
> <advertisement>
> Maven is a framework that can lower the bar for testing out new
> frameworks and make getting started easier without having to configure
> and read documentation to get started.
> Wicket [2], and its wicket-examples project, is a good reference to how
> Maven leverages projects without need for extensive documentation.
> </advertisement>
>
> The problem is packaging the native libraries in a way that Jambi can
> reference them.
> The normal procedure, as far as I know, is zipping the libs in a jar
> file, which is referenced in the pom. Maven places the dependencies on
> the classpath, but does not extract their contents. The lib jar will
> behave in the same way if one adds it as a project dependency in an IDE.
> I have tried packaging packaging the lib files in the jar root and in a
> lib catalog of the jar, without success.
Hi Stig,
Sorry for the late reply, but I had to familiarize myself with Maven a
bit...
The recommended way of deploying software based on Qt Jambi is to bundle
our native libraries into a .jar file according to our deployment guide:
http://doc.trolltech.com/qtjambi-4.3.3_01/com/trolltech/qt/qtjambi-deployment.html
Qt Jambi has mechanisms for extracting native libs from .jar files and
loading them accordingly. This lets you treat Qt Jambi as any other
library that consists of _only_ pure java files.
So the problem with your current approach is that you're trying to put
our native libraries directly into the POM. You should instead create a
.jar file of them according to the guide and install them in maven as an
external dependency.
There might be other ways of doing this, but I'm not really familiar
with Maven so here goes... (linebreaks will be suboptimal ;-)
First of all, get the .jar files. I cheated and used our webstart .jar
files which are already set up:
wget
http://dist.trolltech.com/developer/download/webstart/qtjambi-win32-gpl-4.3.3_01.jar
wget http://dist.trolltech.com/developer/download/webstart/qtjambi.jar
Then install them in maven:
mvn install:install-file -Dfile=c:\qtjambi.jar
-DgroupId=com.trolltech.qtjambiclasses -DartifactId=qtjambi
-Dversion=4.3.3 -Dpackaging=jar
mvn install:install-file -Dfile=c:\qtjambi-win32-gpl-4.3.3_01.jar
-DgroupId=com.trolltech.qtjambiwin32gpl -DartifactId=qtjambi
-Dversion=4.3.3 -Dpackaging=jar
Add the dependencies to your POM:
<dependency>
<groupId>com.trolltech.qtjambiclasses</groupId>
<artifactId>qtjambi</artifactId>
<version>4.3.3</version>
</dependency>
<dependency>
<groupId>com.trolltech.qtjambiwin32gpl</groupId>
<artifactId>qtjambi</artifactId>
<version>4.3.3</version>
</dependency>
---
I used the analogclock example from our package and got it running with
the above.
I hope this helps,
best regards,
Gunnar
---
btw: Why are you still using the ancient 1.0.0-beta2 version?
Hello,
Glad maven is getting some interest..
How about trolltech deploying the jambi jar in a repository visible on
the Internet ?
Kind regards
Etienne
-----Original Message-----
From: Gunnar Sletta [mailto:gunnar@xxxxxxxxxxxxx]
Sent: jeudi 10 janvier 2008 10:57
To: Stig Lau
Cc: qt-jambi-interest@xxxxxxxxxxxxx
Subject: Re: Maven2 and Jambi
Stig Lau wrote:
> I want to pick up the discussion concerning Jambi and Maven 2 by
Jostein
> Gogstad on the mailing list. [1]
>
> <advertisement>
> Maven is a framework that can lower the bar for testing out new
> frameworks and make getting started easier without having to configure
> and read documentation to get started.
> Wicket [2], and its wicket-examples project, is a good reference to
how
> Maven leverages projects without need for extensive documentation.
> </advertisement>
>
> The problem is packaging the native libraries in a way that Jambi can
> reference them.
> The normal procedure, as far as I know, is zipping the libs in a jar
> file, which is referenced in the pom. Maven places the dependencies
on
> the classpath, but does not extract their contents. The lib jar will
> behave in the same way if one adds it as a project dependency in an
IDE.
> I have tried packaging packaging the lib files in the jar root and in
a
> lib catalog of the jar, without success.
Hi Stig,
Sorry for the late reply, but I had to familiarize myself with Maven a
bit...
The recommended way of deploying software based on Qt Jambi is to bundle
our native libraries into a .jar file according to our deployment guide:
http://doc.trolltech.com/qtjambi-4.3.3_01/com/trolltech/qt/qtjambi-deplo
yment.html
Qt Jambi has mechanisms for extracting native libs from .jar files and
loading them accordingly. This lets you treat Qt Jambi as any other
library that consists of _only_ pure java files.
So the problem with your current approach is that you're trying to put
our native libraries directly into the POM. You should instead create a
.jar file of them according to the guide and install them in maven as an
external dependency.
There might be other ways of doing this, but I'm not really familiar
with Maven so here goes... (linebreaks will be suboptimal ;-)
First of all, get the .jar files. I cheated and used our webstart .jar
files which are already set up:
wget
http://dist.trolltech.com/developer/download/webstart/qtjambi-win32-gpl-
4.3.3_01.jar
wget http://dist.trolltech.com/developer/download/webstart/qtjambi.jar
Then install them in maven:
mvn install:install-file -Dfile=c:\qtjambi.jar
-DgroupId=com.trolltech.qtjambiclasses -DartifactId=qtjambi
-Dversion=4.3.3 -Dpackaging=jar
mvn install:install-file -Dfile=c:\qtjambi-win32-gpl-4.3.3_01.jar
-DgroupId=com.trolltech.qtjambiwin32gpl -DartifactId=qtjambi
-Dversion=4.3.3 -Dpackaging=jar
Add the dependencies to your POM:
<dependency>
<groupId>com.trolltech.qtjambiclasses</groupId>
<artifactId>qtjambi</artifactId>
<version>4.3.3</version>
</dependency>
<dependency>
<groupId>com.trolltech.qtjambiwin32gpl</groupId>
<artifactId>qtjambi</artifactId>
<version>4.3.3</version>
</dependency>
---
I used the analogclock example from our package and got it running with
the above.
I hope this helps,
best regards,
Gunnar
---
btw: Why are you still using the ancient 1.0.0-beta2 version?
Charlier, Etienne wrote: > Hello, > > Glad maven is getting some interest.. > > How about trolltech deploying the jambi jar in a repository visible on > the Internet ? Hi, Starting with Qt Jambi 4.4 the binary packages will have the prebuilt .jar files included. We'll also provide an ant task for people to create their own .jar files with native libraries. This ant task will also be used by the source package to create .jar's including binaries. The ant task will also handle things like system library dependencies, like including msvcr70.dll, for instance. best regards, Gunnar
Thanks for the info !! Regards Etienne -----Original Message----- From: Gunnar Sletta [mailto:gunnar@xxxxxxxxxxxxx] Sent: jeudi 10 janvier 2008 12:00 To: Charlier, Etienne Cc: qt-jambi-interest@xxxxxxxxxxxxx Subject: Re: Maven2 and Jambi Charlier, Etienne wrote: > Hello, > > Glad maven is getting some interest.. > > How about trolltech deploying the jambi jar in a repository visible on > the Internet ? Hi, Starting with Qt Jambi 4.4 the binary packages will have the prebuilt .jar files included. We'll also provide an ant task for people to create their own .jar files with native libraries. This ant task will also be used by the source package to create .jar's including binaries. The ant task will also handle things like system library dependencies, like including msvcr70.dll, for instance. best regards, Gunnar
Gunnar Sletta wrote: > ... > I used the analogclock example from our package and got it running > with the above. > > I hope this helps, It works, thanks alot! Either the later version of the Jambi was better at finding the native libraries from the jar/classpath, or I just witnessed some Trolltech magic :) > btw: Why are you still using the ancient 1.0.0-beta2 version? That's what you get when you google for "download qtjambi", choose the second result and answer a questionnaire [1]. Perhaps I'm not bleeding edge enough anymore to checkout the latest greatest from SVN... > Etienne wrote: > How about trolltech deploying the jambi jar in a repository visible > on the Internet ? Next on my and Etiennes wishlist is a public repository where one can find jambi++ binaries, javadoc and sourcecode packaged in a Maven style repo [1], owned and maintained by Trolltech. Developers can thus browse and utilize released versions of your product without having to fill out questionaries, unzip, run maven or ant to compile, and possibly have to enquire by mail to get an old library which they depend on, that's hidden on some longforgotten server. The users project pom only needs to point to Trolltechs Maven repository, and specify what versions of which libraries and native libraries they use. Maven then handles all from downloading, installing to a local repository and placing jars in the local repository. The Codehaus repository [2]is a good example of what a public release repository can look like. The XFire project for example uploads their source, javadoc and binaries [3]. Ofcourse, Maven doesn't fit for everyone, but I'd be glad to help if Trolltech wants to set up a simple Maven repository as an improved distribution mechanism. Regards -Stig, [1] http://trolltech.com/developer/downloads/qt/qtjambi-beta [2] http://repository.codehaus.org [3] http://repository.codehaus.org/org/codehaus/xfire/xfire-core/1.2.6/
Stig Lau wrote: > > Gunnar Sletta wrote: >> ... >> I used the analogclock example from our package and got it running >> with the above. >> >> I hope this helps, > > It works, thanks alot! > Either the later version of the Jambi was better at finding the native > libraries from the jar/classpath, or I just witnessed some Trolltech > magic :) > >> btw: Why are you still using the ancient 1.0.0-beta2 version? > That's what you get when you google for "download qtjambi", choose the > second result and answer a questionnaire [1]. > Perhaps I'm not bleeding edge enough anymore to checkout the latest > greatest from SVN... Personally I would have gone with the top-most link that takes you here: http://trolltech.com/products/qt/jambi At the bottom you find a link to the opensource downloads, without questionares. >> Etienne wrote: >> How about trolltech deploying the jambi jar in a repository visible on >> the Internet ? > > Next on my and Etiennes wishlist is a public repository where one can > find jambi++ binaries, javadoc and sourcecode packaged in a Maven style > repo [1], owned and maintained by Trolltech. You're suggestion is noted, but doubt this will happen in the near future, as we would weigh this suggestion up against other features and suggestions we would like to and / or need to implement. There is also the licensing aspects that would have to be handled. One cannot simply make use of the open source package for commercial development, for instance. - Gunnar