| Summary: | [New ebuild] dev-java/db4o | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Thomas Sachau <tommy> |
| Component: | Current packages | Assignee: | Thomas Sachau <tommy> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | andrew, java, serkan |
| Priority: | High | Keywords: | InVCS |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://www.db4o.com | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 128783 | ||
| Attachments: |
db4o-7.4.ebuild
additional build.xml (the source does not contain such a file) |
||
|
Description
Thomas Sachau
2008-09-07 15:52:26 UTC
Created attachment 164826 [details]
db4o-7.4.ebuild
Created attachment 164827 [details]
additional build.xml (the source does not contain such a file)
The basic ones are now in cvs as -db4o-jdk11 -db4o-jdk12 -db4o-jdk5 Hey, you did up a db4o .ebuild. Nice! I would have recommended against packaging them with the JRE version in the name, though. It's not like we have any < 1.5 JDKs around here; and the package names with JRE versions in 'em look really cumbersome :( If you really wanted to ship the ancient VM .jars you could put them in /usr/share/db4o/lib/ but not have them turn up in the `java-config -p` result. [I was talking to Serkan about getting this packaged, and was going to help him navigate the horror show that is their build system. So I'm willing to help if you need it] I have a number of projects using db4o, so I will give your ebuild a test in the next few days. AfC (In reply to comment #4) > Hey, you did up a db4o .ebuild. Nice! > > I would have recommended against packaging them with the JRE version in the > name, though. It's not like we have any < 1.5 JDKs around here; and the package > names with JRE versions in 'em look really cumbersome :( > > If you really wanted to ship the ancient VM .jars you could put them in > /usr/share/db4o/lib/ but not have them turn up in the `java-config -p` result. > The package names are from upstream naming scheme of jars and the ones for newer jdks depend on the ones for older. So we have no chance of leaving them out in classpath. > [I was talking to Serkan about getting this packaged, and was going to help him > navigate the horror show that is their build system. So I'm willing to help if > you need it] Any help is always welcome. (I intentionally choose splipt packaging so that anyone needing a specific jar can contribute ebuild for it) > > I have a number of projects using db4o, so I will give your ebuild a test in > the next few days. That will be awesome. > > AfC > Thanks for the comments Andrew. (In reply to comment #4) > I would have recommended against packaging them with the JRE version in the > name, though. It's not like we have any < 1.5 JDKs around here; and the package > names with JRE versions in 'em look really cumbersome :( 1. There is still JDK-1.4 around, if i did not miss something recently 2. I only follow the naming of db4o, those are probably the naming to show which JDK/JRE you need at minimum. db4o-jdk11 is the base, at least for the following two, but probably for most or all packages. db4o-jdk12 contains some code for 1.2-1.4, so you can use this (+the previous one), if you have some 1.4 JDK/JRE, you should be able to use this one (+the previous one as dependency). db4o-jdk5 is another addition, depends on the previous ones and has some code, which needs JDK/JRE-1.5. Since not everyone or everything needs all of them, it is imho the best thing to keep them seperate, so that everyone can choose and use what fits best to him. There are also many more packages, i only added the basic ones i need myself for adding the freenet app. > > If you really wanted to ship the ancient VM .jars you could put them in > /usr/share/db4o/lib/ but not have them turn up in the `java-config -p` result. As already written, they are needed for the more current ones, while they can be run without the 1.5 code. So the choices are there, use, whatever you need. > [I was talking to Serkan about getting this packaged, and was going to help him > navigate the horror show that is their build system. So I'm willing to help if > you need it] I have had a talk with him, while packaging this mess. To get it at least maintainable, i created different packages with tarballs containing simple build instructions. Probably much easier than messing with their build system or their xmls, which they only have in their repo. If you have suggestions/improvements/comments, send me a mail or contact me via IRC (see below). > I have a number of projects using db4o, so I will give your ebuild a test in > the next few days. Would be nice to have some feedback. I did some tests with freenet locally and it works for me, so cannot be totally broken. :-) You may be interested to join e.g. #gentoo-java or #gentoo-sunrise, if you want to talk to me directly (best at european evening time). |