eclipse-sdk-3.0-r6.ebuild is the clean and easy implementation of eclipse-sdk . This is only tested in x86. In the eclipse-sdk-3.0-r5.ebuild, there is a complex binding of KED/GNOME etc. Also, the installation is quite complex!! I doubt whether that kind of complexity for eclipse-sdk ebuild are needed or not. Anyway, the following ebuild for eclipse-sdk-3.0-r6 works perfectly for me. --cut here-- DESCRIPTION="Eclipse Tools Platform" HOMEPAGE="http://www.eclipse.org/" SRC_URI="http://download2.eclipse.org/downloads/drops/S-3.0M6-200312182000/eclipse-sourceBuild-srcIncluded-3.0M6.zip" LICENSE="CPL-1.0" SLOT="0" KEYWORDS="~x86" RDEPEND=">=virtual/jdk-1.3 >=x11-libs/gtk+-2.2.4-r1 >=dev-java/ant-1.4" DEPEND="${RDEPEND} >=virtual/jdk-1.3 >=dev-java/ant-1.4" src_unpack() { mkdir ${S} cd ${S} unpack ${A} } src_compile() { ./build -os linux -ws gtk -arch x86 -target clean ./build -os linux -ws gtk -arch x86 -target compile ./build -os linux -ws gtk -arch x86 -target install } src_install() { dodir /opt/${P} cp -dpR tmp/eclipse/plugins ${D}/opt/${P} cp -dpR tmp/eclipse/features ${D}/opt/${P} cp -dpR tmp/eclipse/linux.gtk.x86/eclipse/* ${D}/opt/${P} } --cut here-- Reproducible: Always Steps to Reproduce: 1. ebuild eclipse-sdk-3.0-r6.ebuild digest 2. emerge eclipse-sdk-3.0-r6.ebuild Actual Results: eclipse-sdk-3.0M6 is installed in /opt/eclipse-sdk-3.0 Expected Results: eclipse-sdk-3.0M6 is installed in /opt/eclipse-sdk-3.0
archan, can you please attach an ebuild, rather than paste, and also please make sure to have the header information (copyright -- to Gentoo, and license info)
This ebuild needs a little more work other than what Seemant requires. Currently, it does not introduce a link for eclipse in /usr/bin. That would sure be nice. Otherwise, this ebuild works about as well as the 3.0.0-pre5 one - it produces an eclipse that does not work. Not on my system.
Created attachment 23841 [details] eclipse-sdk-3.0-r6.ebuild Seemant I have made the changes which you had suggested. I am not sure why Dikey's system cant make proper eclipse binary!!
Dickey, can you paste a complete build log as an attachment to this bug? (ACCEPT_KEYWORDS="~x86" emerge "=eclipse-sdk-3.0-r5") 2> build.log I'll have a look at -r6 after LWE; I already have an upgrade in my local CVS
Created attachment 24278 [details] Combined stdout & stderr build log file. This is a typescript file of me building eclipse-sdk-3.0.0-pre5. It has the stderr output interspersed throughout the output, where it occurred. I'll also submit another build output that is split.
Created attachment 24279 [details] Another eclipse-sdk-3.0.0_pre5 build output - stdout only. I re-ran the build and saved the stdout and stderr separately. This is the stdout portion.
Created attachment 24280 [details] The stderr portion of the build. This is the stderr portion of the split build of eclipse-sdk-3.0.0_pre5.
Ok, I added three attachments. They are all gzipped text files. By the way, you may like to know that I tracked my problem down to something happening in the eclipse startup. When I start it, I get a little window that says: Problem during startup. Check the ".log" file in the ".metadata" directory of your workspace. Close this and eclipse stops. The above mentioned .log file has in it: !SESSION ---------------------------------------------------------------------- !ENTRY org.eclipse.core.launcher 4 0 Jan 23, 2004 08:05:18.828 !MESSAGE Exception launching the Eclipse Platform: !STACK java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.internal.boot.InternalBootLoader.startup(InternalBootLoader.java:1049) at org.eclipse.core.internal.boot.InternalBootLoader.run(InternalBootLoader.java:838) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:461) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:299) at org.eclipse.core.launcher.Main.run(Main.java:767) at org.eclipse.core.launcher.Main.main(Main.java:601) Caused by: org.eclipse.core.runtime.CoreException: Unable to create platform lock file: /home/ddickey/.eclipse/workspace/.metadata/.lock. at org.eclipse.core.internal.runtime.InternalPlatform.createLockFile(InternalPlatform.java:228) at org.eclipse.core.internal.runtime.InternalPlatform.loaderStartup(InternalPlatform.java:641) ... 14 more Ok, so I rm the above .lock file (it was there); restart eclipse; same problem; same entry in the .log; and same .lock file: fizban$ ls -l .lock -rw-r--r-- 1 ddickey dev 0 Jan 23 07:35 .lock fizban$ pwd /home/ddickey/.eclipse/workspace/.metadata Let me know if you need more info. And back to eclipse-sdk-2.1.2-r1 I go once again...
Created attachment 25124 [details] modded version of pre5 I modified the Pre5 Ebuild and removed stuff we don't need. I also don't support motif as most people seem to use gtk anyway. The most important, as I think, is the eclipse-startupscript, which uses .eclipse in $HOME for configuration and workspace in $HOME for Development. Since this is also the default for the IBM binary distributions we can go with that.
Uh, btw. the version included is beta6.. hehe
I've been machineless for a few weeks due to a run of really bad karma. Hopefully I'll have a suitable workstation running within the next (few) week(s).
Created attachment 25793 [details] eclipse-sdk-3.0_rc7.ebuild
Created attachment 25794 [details] 20eclipse-3.0m7 (put in files/ )
Created attachment 25795 [details] eclipse3.desktop ( put in files/ also)
I did this based on eclipse-sdk-3.0-r6.ebuild. I did some cleaning of deps, bumped it to m7 and added a env.d entry and a gnome menu entry.
The latest ebuild installs the following files: >>> /var/tmp/portage/eclipse-sdk-3.0_rc7/image/etc/env.d/20eclipse-3.0m7 >>> /var/tmp/portage/eclipse-sdk-3.0_rc7/image/usr/share/gnome/apps/Development/eclipse3.desktop >>> /usr/share/gnome/apps/Development/eclipse3.desktop Additionally I don't have +gnome use flag set so the .desktop file shouldn't be installed for gnome. But I have +kde set, so...
Created attachment 26779 [details] eclipse-sdk-3.0_rc7.ebuild No more need of a .desktop file the ebuild will create it. Also fixed the creation of the env.d entry.
Looks great Gustavo. A minor problem I didn't noticed before: The ebuild header is invalid -> http://www.gentoo.org/doc/en/ebuild-mistakes.xml
Another point: The .desktop executable entry won't work, because /opt/eclipse-sdk-3.0_rc7/ is not in path, so either the full path to the executable has to be given, or (better imho) a /usr/bin/eclipse symlink has to be crated.
Yes there is a bug in the header (nothing repoman would not complain when doing the commit). ABout the desktop entry, you have to env-update and source /etc/profile so that the env.d entry is used.
Right Gustavo, found another problem: The path in /etc/env.d/20eclipse-3.0m7 is /opt/eclipse-sdk-eclipse-sdk-3.0_rc7. Even updating the environment and making a open shell aware of the profile change doesn't help anything with a running Desktop. You still have to restart it, to get the .desktop file working. I still favor a symlink to /usr/bin (or better /opt/bin - I don't know if this path is official, added it some time ago, because /opt should stay seperate from the rest). I'd find it better to install in ${PN} or ${PN}-{PV}, if you want to use different slots, btw.
Sorry for the delay on this. I am testing the ebuild on M( if it works ok i will put it here. Carlo: this is eclipse-sdk-3.0_rc7.ebuild so P=eclipse-sdk-3.0_rc7 no need for diferent dirs for slots. If one wants to have several rc's they just need to change the ebuild and put it in another slot. Abiut the desktop entry, altought some WM might detect the new entry the env.d entrys are only available after a logout/login (or if you start a new shell) and your WM started from a shell with no entry.
*** Bug 46152 has been marked as a duplicate of this bug. ***
Created attachment 28325 [details] eclipse-sdk-3.0_rc8.ebuild" Version bump and small fix in the way the env.d entry.
>this is eclipse-sdk-3.0_rc7.ebuild so P=eclipse-sdk-3.0_rc7 no need for diferent dirs for slots. If one wants to have several rc's they just need to change the ebuild and put it in another slot. I just want to get rid of the _rcX part, because I have to adjust my symlink with every single milestone. But that's not that important of course. In general it would be good, if 3.x versions would be using SLOT="1" to allow usage of 2.x and 3.x side by side. There's still a problem with the /etc/env.d file. After upgrading to M8, /etc/env.d/20eclipse-3.0m7 wasn't removed.
>There's still a problem with the /etc/env.d file. After upgrading to M8, /etc/env.d/20eclipse-3.0m7 wasn't removed. That is portage's default behaviour: http://www.gentoo.org/doc/en/handbook/handbook.xml?part=2&chap=4#doc_chap1
But ebuilds usually do not add the version number to their env.d entry. What about /etc/env.d/20eclipse-3?
Just changed the name of the bug to reflect the work being
Created attachment 28598 [details] eclipse-sdk-3.0_rc8.ebuild tweaked for motif (probably not working) I did this version to add the chance to build using the gtk2 interface or the motif one. For some reason the build seems to run ok but i only get the packages and not thee main program...
Created attachment 28700 [details] eclipse-sdk-3.0_rc8.ebuild This one actually works :) Now you can use the gtk2 interface and the motif one (the motif one seems faster)
The ebuild from http://bugs.gentoo.org/attachment.cgi?id=28700&action=view doesn't compile for me. It hangs (without using CPU time) after: init: gather.bin.parts: children: [mkdir] Created dir: /var/tmp/portage/eclipse-sdk-3.0_rc8/work/eclipse-sdk-3.0_ /tmp/eclipse/features/org.eclipse.pde_3.0.0 [copy] Copying 5 files to /var/tmp/portage/eclipse-sdk-3.0_rc8/work/eclipse-sd .0_rc8/tmp/eclipse/features/org.eclipse.pde_3.0.0 ROOTFILESlinux_gtk_x86: I used: USE="-motif" ACCEPT_KEYWORDS='~x86' emerge "=dev-util/eclipse-sdk-3.0_rc8" I didn't install glib-2.4.0 and gtk+-2.4.0 yet - might this be the culprit? The dev-util/eclipse-sdk-2.1.3 ebuild these pulls in.
Michael Mauch: Acording to the docs gtk+ should be a runtime dep, not a build dep. In any case try to merge that first to see what happens
I tried attachment 28700 [details] and it seems to get stuck... the CPU is being used, but it goes forever and doesn't finish with -mosaic nor -gtk... The last output from the compile is: ---8<---snip---8<--- generateJavadoc: [mkdir] Created dir: /var/tmp/portage/eclipse-sdk-3.0_rc8/work/eclipse-sdk-3.0_rc8/plugins/org.eclipse.platform.doc.isv/reference/api ---8<---snip---8<--- I let each emerge go well over 10 minutes and nothing further occurred... :-/
@Gustavo: - there is a 3.0.0_pre5 and a 3.0_rc8 in portage. A bit inconsistent. - the rc8 ebuild header is invlid - could you make the gtk2 the default, even when both use flags are enabled, please? An einfo line to inform the user about it, would be fine, but being forced to change a use flag is annoying.
I got a good install on eclipse-sdk-3.0_rc8, BUT when I attempt to run it under my home directory, it gives me a Workspace in use. Choose another one. I am attempting to set the workspace to a subdirectory in my home directory. Could this be a permissions thing from the build? Thanks.
Stephen McConnell: probably not. Try to creat a clean directory and use it for your workspace, also, before starting eclipse rename your ~/.eclipse directory so that eclipse starts with clean settings.
Today i tried installing in another of my machines and had problems using blackdown-1.4.2, ibm-jdk-1.4.2 only worked with java-jdk-1.4.2 maybe this will help any one out there
Gustovo As part of another initiative, I have totally rebuild my Gentoo System. I installed sun-sdk-jdk1.4.2 (no problems here.) I installed: ACCEPT_KEYWORDS="~x86" emerge eclipse-sdk-3.0._rc8.ebuild And had no problems with the install. I am STILL getting the Workspace in use, choose another one. It goes ahead and creates the .eclipse directory, it goes ahead and creates the workspace directory... both are assigned the group "users". HOWEVER the permissions on the directories are rwxr-xr-x And eclipse cannot access them. Could it be that eclipse is running as root? I changed the group (recurively on the /opt/eclipse-sdk-3.0_rc8 folder to "users"... no change. Is anyone else experienceing this problem? Stephen McConnell
I got that, too. Take a look at this thread: http://forums.gentoo.org/viewtopic.php?t=157790
Last night, I remembered the "IgnoreLockFile" issue happening somewhere in the eclipse 2.1 release. It appears to be a bug in eclipse that pops up every once in a while (even the windoz version); and then gets cleared up later. Thanks for the point to the thread... I've bookmarked it and put it in my notes for the next time this thing occurs... Stephen McConnell
Ok, now..... I'm trying to do some plugin development. One of the things that happens in plug-in development is that you run your plugin in the "runtime workbench". Because it launches it's own runtime workbench, one does not have access to the "IgnoreLockFile" class and I get the same problem as before. Gustavo? Is there a solution either through Gentoo ebuild or through the Eclipse Bugzilla? Stephen McConnell
I have not been able to reproduce the "workspace in use" problem, either with blackdown-jdk-1.4.1 and ibm-jdk-1.4.1. Have you tried doing strace on it?
I think I got a fix for this in place now. People on x86 are advised to test dev-util/eclipse-sdk-3.0.0_pre8.ebuild. (the _rc8 ebuild is dead and removed, good points from it was scavenged for the new ebuild). If you get into trouble, feel free to open new bugs against it. If you feel very adventurous, look into making a patch to get motif building nicely again.
