I wrote an ebuild for sesame (a database which is used in approaches to create a semantic web). I copied some parts from the soap ebuild the cocoon ebuild and the lucene ebuild. It works quite nice an I think I got all dependecies right. But some java guru might need to look at it. (How do I assign bugs to the java heard when using "new bug", not "new-expert"?) Reproducible: Always Steps to Reproduce:
Created attachment 62589 [details] dev-db/sesame-1.2 The ebuild. I threw it into dev-db, but maybe it suits more in dev-java.
(In reply to comment #0) > (How do I assign bugs to the java heard when using "new bug", not "new-expert"?) You can't... :(
Created attachment 62591 [details] dev-db/sesame-1.2 Same ebuild, improved postinst message. So noobs like me can install and use sesame :D
Looks good. Needs just a couple adjustements. For example the jars in ext are not actually deleted because of the quotes. I will put this to the experimental tree and post a link here.
(In reply to comment #3) > Created an attachment (id=62591) [edit] > dev-db/sesame-1.2 > > Same ebuild, improved postinst message. So noobs like me can install and use > sesame :D Newer Tomcat ebuilds don't have anything to do with /opt/tomcat. I think it is best not to hard code the path to the ebuild.
(In reply to comment #5) > Newer Tomcat ebuilds don't have anything to do with /opt/tomcat. I think it is > best not to hard code the path to the ebuild. Hmm, I thought it is a good idea to give the user the right direction. Therefore the first occurence was labeled "like /opt/tomcat". Maybe replacing with [TOMCAT_DIR] is better?
https://gentooexperimental.org/svn/java/gentoo-java-experimental/dev-java/sesame/ I am off to play golf now and will look more into this tonight.
I just did some more testing and noticed that sesame builds without problems with saxon and junit not installed. Junit is used to run tests so this probably should have the junit use flag and I have to find out what saxon is used for if anything.
good point on that. I will play around with the build.xml file an add a corresponding useflag in a few hours (or tomorrow)
ant junit brings up something graphical and I have to use java-pkg_jar-from to get the build to use the junit.jar. If you manage to run the tests from the commandline without anything graphical, please do so. If that isn't possible we can just remove the dep of junit, having the junit use flag is not mandatory but it is of course nice to have. The build process also seems to have other jars in build/lib: pena lib # ls openrdf-model.jar openrdf-util.jar rio.jar sesame.jar sesame.war Shouldn't we install these too?
Hmm, must have overlooked them. We definitely need to install them, since they are officially part of that package. Will have a look later, too.
(In reply to comment #11) > Hmm, must have overlooked them. We definitely need to install them, since they > are officially part of that package. Will have a look later, too. Sorry. The ebuild does install them. What I meant was that is there a need for doing something with them when putting sesame to a web container.
I have no idea about webcontainers and haven't found out what exactly to do. afaik we don't need to put them anywhere, as long as they are in the classpath of the tomcat. if that means we need to copy them, we have to.
I looked into that build.xml file and found out 2 things. a) junit can't be done non-graphical b) From what I understand Saxon will work with that file. They ship "saxon-6.5.3.jar" and refer to "saxon651.jar" in the file. But: Removing the jar and building the "userdoc" will fail then. Simply adding saxon8 is not suitable, since they changed from "com/icl/saxon" to "net/sf/saxon". No idea how to fix that properly :(
(In reply to comment #12) > is there a need for doing something with them when putting sesame to a web > container. Yes. I needed to do: cd ${catalina.home}/common/lib ln -s /usr/share/commons-fileupload/lib/commons-fileupload.jar . ln -s /usr/share/soap/lib/soap.jar . ln -s /usr/share/sesame/lib/* . ln -s /usr/share/saxon/lib/* . I have no idea if saxon is really needed (I really doubt that), but I symlinked it anyway. Now sesame works fine.
Boy did we let this one rot. This is used optionally by soprano in KDE 4 so will be packaging version 2.
May be it will be used in openoffice in the future. See: http://www.mail-archive.com/dev@openoffice.org/msg08720.html
KDE4 (4.2.2) currently bundles own blob with its deps: openrdf-sesame-2.1.4-onejar.jar slf4j-api-1.5.5.jar (in tree alread) slf4j-simple-1.5.5.jar (no idea whytf it's there) Package it please and I can package some KDE4 stuff for ya! ;)
Sebastian Trueg (the guy who works on KDE4 NEPOMUK) suggests in a bug report on b.k.o to be using Sesame2 instead of Raptor: http://bugs.kde.org/show_bug.cgi?id=182607#c2
(In reply to comment #19) > Sebastian Trueg (the guy who works on KDE4 NEPOMUK) suggests in a bug report on > b.k.o to be using Sesame2 instead of Raptor: > http://bugs.kde.org/show_bug.cgi?id=182607#c2 > HMMMMMM,prior to kde4.4 I had never seen any mention of the sesame db,tis only since my upgrade that it has emerged(!),also a search of the portage db doesn't show any ebiuld to suite(as of 01-03-2010)
Since Soprano was the only ebuild using Sesame and Sesame has been considered deprecated by upstream[1] in favour of Virtuoso, I propose we close this bug as WONTFIX. [1] http://bugs.kde.org/show_bug.cgi?id=182607#c9
(In reply to comment #21) > Since Soprano was the only ebuild using Sesame and Sesame has been considered > deprecated by upstream[1] in favour of Virtuoso, I propose we close this bug as > WONTFIX. > > [1] http://bugs.kde.org/show_bug.cgi?id=182607#c9 Ok by me,as Ive upgraded to 4.6.2 now any way Geoff
