| 1 |
>> I'm trying to fix up the JAlbum ebuild: |
| 2 |
>> |
| 3 |
>> http://bugs.gentoo.org/show_bug.cgi?id=128356 |
| 4 |
>> |
| 5 |
>> and get it to use java-pkg-2. Here's what I have so far: |
| 6 |
>> |
| 7 |
>> inherit java-pkg-2 eutils |
| 8 |
>> |
| 9 |
>> S="${WORKDIR}/Jalbum" |
| 10 |
>> DESCRIPTION="Web photo album generator" |
| 11 |
>> HOMEPAGE="http://jalbum.net/" |
| 12 |
>> SRC_URI="http://jalbum.net/download/Jalbum${PV}.zip" |
| 13 |
>> |
| 14 |
>> LICENSE="as-is" |
| 15 |
>> SLOT="0" |
| 16 |
>> KEYWORDS="x86" |
| 17 |
>> IUSE="" |
| 18 |
>> |
| 19 |
>> DEPEND=">=virtual/jre-1.5" |
| 20 |
>> RDEPEND="${DEPEND}" |
| 21 |
>> |
| 22 |
>> src_install() { |
| 23 |
>> java-pkg_dojar JAlbum.jar |
| 24 |
>> java-pkg_dolauncher jalbum \ |
| 25 |
>> --jar JAlbum.jar \ |
| 26 |
>> --java_args -Xmx400M |
| 27 |
>> |
| 28 |
>> local dest=/usr/lib/${PN} |
| 29 |
>> dodir ${dest} |
| 30 |
>> cp -R ${S}/* ${D}/${dest} || die "Install failed" |
| 31 |
>> |
| 32 |
>> doicon ${FILESDIR}/Jalbum-icon.png |
| 33 |
>> make_desktop_entry ${PN} |
| 34 |
>> } |
| 35 |
>> |
| 36 |
>> It executes just fine, but I get: |
| 37 |
>> |
| 38 |
>> $ jalbum |
| 39 |
>> Error: se.datadosen.jalbum.JAlbum |
| 40 |
>> java.lang.ClassNotFoundException: se.datadosen.jalbum.JAlbum |
| 41 |
>> at java.net.URLClassLoader$1.run(URLClassLoader.java:200) |
| 42 |
>> at java.security.AccessController.doPrivileged(Native Method) |
| 43 |
>> at java.net.URLClassLoader.findClass(URLClassLoader.java:188) |
| 44 |
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:307) |
| 45 |
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:252) |
| 46 |
>> at se.datadosen.jalbum.Main.main(Main.java:23) |
| 47 |
>> |
| 48 |
>> I was told I need to define the main class with --main. Does anyone |
| 49 |
>> know how to determine what the main class should be? |
| 50 |
> |
| 51 |
> |
| 52 |
> No, it has clearly already loaded at least one class (last line of that |
| 53 |
> stack trace reveals this), and is looking for some others needed by that |
| 54 |
> class -- but the classloader fails to find them. JAlbum probably also has a |
| 55 |
> Main-Class header defined in the jar's manifest, so this is likely to be |
| 56 |
> just another classpath-related issue. |
| 57 |
> |
| 58 |
> But the ebuild you're pushing ... I think it would need some serious work |
| 59 |
> for the installation part. I think it installs files in all wrong places, |
| 60 |
> and thus Gentoo's Generation 2 java system cannot automatically add them to |
| 61 |
> classpath. |
| 62 |
> |
| 63 |
> There is some advice on the issue in section 3, the Filesystem layout over |
| 64 |
> here: |
| 65 |
> |
| 66 |
> http://www.gentoo.org/proj/en/java/java-devel.xml |
| 67 |
> |
| 68 |
> After trudging through that you might understand why Gentoo Java team has |
| 69 |
> constantly several dev positions advertised on "help wanted". Some of Java's |
| 70 |
> ways don't mix that well with Gentoo's approaches, especially with compiling |
| 71 |
> and packaging (installations). |
| 72 |
> |
| 73 |
> If you are in a hurry of some sort, you might just try taking the jar, |
| 74 |
> unpacking it into a subdir under your homedir, cd'ing in, and trying |
| 75 |
> something like "CLASSPATH=.:${CLASSPATH} foo.sh". With a little luck it |
| 76 |
> might work as such, without the pain of making a proper ebuild for it. |
| 77 |
> |
| 78 |
> -- |
| 79 |
> Arttu V. |
| 80 |
|
| 81 |
So 'emerge JAlbum' isn't feasible? |
| 82 |
|
| 83 |
- Grant |
Archives