Was released June 23rd, 2010.
Is anybody able to provide an ebuild?
The need for an eclipse 3.6 ebuild is very high, since all downloadable binary builds crash due to swt/xulrunner incompatability (at least on x86_64).
In fact I used it with a binary downloaded from the eclipse site and it worked perfeclty on my amd64 laptop.. Anyway, having it merged in portage would be far better than using a binary package.. (In reply to comment #2) > The need for an eclipse 3.6 ebuild is very high, since all downloadable binary > builds crash due to swt/xulrunner incompatability (at least on x86_64). >
It's over my head. The downloads directory seems to have changed some, since the last ebuild: http://download.eclipse.org/technology/linuxtools/eclipse-build/e36-branch/ Maybe the build process has changed or moved location?
Yeah, it would really be awesome to have this in portage. I wonder if something else is holding this up.
Vote for an ebuild of Eclipse 3.6!
Andrew Overholt is about to tag the release of Eclipse Build 0.6.0. [1] I've updated my ebuild to build Eclipse 3.6, and all looks well with it. I'm just waiting for Andrew to integrate a needed patch (which I submitted to him [2]) and cut the release. Then I'll post the new ebuild here. [1] http://dev.eclipse.org/mhonarc/lists/linuxtools-dev/msg00583.html [2] http://dev.eclipse.org/mhonarc/lists/linuxtools-dev/msg00584.html
Created attachment 242343 [details] eclipse-sdk-3.6.0.ebuild
Created attachment 242345 [details] files/3.6/eclipse-3.6
Created attachment 242347 [details] files/3.6/eclipserc-3.6
Created attachment 242349 [details] files/3.6/gtk_makefile.patch
Created attachment 242351 [details] files/3.6/hamcrest-junit-lib.patch
Created attachment 242353 [details] files/3.6/iterators.patch
From what I can tell, it runs fine. After reinstalling various plugins everything runs smoothly. Thank you! However, I wonder about the (ant-)eclipse-ecj ebuilds: will they be updated as well?
(In reply to comment #14) > From what I can tell, it runs fine. After reinstalling various plugins > everything runs smoothly. Thank you! I tried to build swt-3.6 with the attached files from depended bug 331959 which failes due to a missing files/build.xml. How did you get swt-3.6 emerged?
(In reply to comment #15) > (In reply to comment #14) > > From what I can tell, it runs fine. After reinstalling various plugins > > everything runs smoothly. Thank you! > > I tried to build swt-3.6 with the attached files from depended bug 331959 which > failes due to a missing files/build.xml. How did you get swt-3.6 emerged? I took the ones that's already in the main portage tree, i.e. cp /usr{,/local}/portage/dev-java/swt/files/build.xml
3.6.1 was released this day. update this bug or create a new one?
Created attachment 249314 [details] eclipse-sdk-3.6.1.ebuild I've updated some of the dependencies, mostly from those I could find in the Debian list [1]. New ebuild are needed for dev-java/swt-3.6.1, dev-java/lucene-2.9.3 and dev-java/junit-4.8.1. With the former two it's just a matter of renaming the ebuild. However, SWT's new source url is dated 201009090800. I couldn't use eclipse-build-0.6.1 because it was struggling to find junit's real path and thus failed at src_install(). From what I can tell, it runs as it's supposed to. However, do backup your plugin sources, they'll be vanished even with a minor release change... [1] http://git.debian.org/?p=pkg-java/eclipse.git;a=blob_plain;f=debian/control
Created attachment 249332 [details] eclipse-sdk-3.6.1.ebuild (In reply to comment #18) > I've updated some of the dependencies, mostly from those I could find in the > Debian list [1]. All of the dependency changes you introduced, except one, were unfounded. Eclipse SDK 3.6.1 ships with commons-codec-1.3, commons-logging-1.0.4, and lucene-1.9.1. The only updated dependency in Eclipse 3.6.1 is junit-4.8.1. (And of course SWT 3.6.1.) Thus, the only needed changes from eclipse-sdk-3.6.0.ebuild to eclipse-sdk-3.6.1.ebuild are: --- eclipse-sdk-3.6.0.ebuild 2010-08-10 19:16:25.905372714 -0400 +++ eclipse-sdk-3.6.1.ebuild 2010-10-02 10:55:06.630907485 -0400 @@ -12,7 +12,7 @@ inherit java-pkg-2 java-ant-2 check-reqs -BUILD_ID="3.6.0" +BUILD_ID="3.6.1" ECLIPSE_BUILD_VER="0.6.0" S="${WORKDIR}/eclipse-build-${ECLIPSE_BUILD_VER}" @@ -37,7 +37,7 @@ >=dev-java/icu4j-4.2.1:4.2 >=dev-java/jsch-0.1.41 >=dev-java/junit-3.8.2:0 - >=dev-java/junit-4.5:4 + >=dev-java/junit-4.8.1:4 >=dev-java/lucene-1.9.1:1.9 >=dev-java/lucene-analyzers-1.9.1:1.9 >=dev-java/sat4j-core-2.2.0:2 @@ -147,6 +147,7 @@ cd "${S}" # building with ecj fails for some reason (polluted classpath probably) java-pkg_force-compiler javac + sed -e 's/label=3.6.0/label=3.6.1/1' -i build.properties -i pdebuild.properties || die eant unpack }
Created attachment 249334 [details] eclipse-sdk-3.6.1.ebuild A couple more things. Shinydoofy's change to build.properties was insufficient: the "buildId" property needs to be updated to match the 3.6.1 release ("I20100909-0800"), and the "testsBuildLabel" property needs to be changed to "3.6.1" so that the "p2.director.version" property gets set correctly. The attached ebuild has the necessary changes and also does them in a way that is more friendly to future version bumps.
There are many unmet dependencies, when using gentoo and the general overlays. I don't want to patch the ebuilds each time the version of eclipse gets updated. Do you have started any git/svn or whatever overlay with those packages, to be easily added to a portage tree?
(In reply to comment #21) > There are many unmet dependencies, when using gentoo and the general overlays. > > I don't want to patch the ebuilds each time the version of eclipse gets > updated. Do you have started any git/svn or whatever overlay with those > packages, to be easily added to a portage tree? What unmet dependencies are those? Everything you need is either already in the main Portage tree or is filed in separate bug tickets upon which this ticket depends.
any idea when that baby hits main tree then?
(In reply to comment #23) > any idea when that baby hits main tree then? It can't until someone makes a proper ebuild for Jetty, and I have no interest in doing that.
Hope someone steps up! Just wanted to say that I got eclipse 3.6 built and installed thanks to your ebuilds, using it right now. Would be extremely neat to have this in tree!
(In reply to comment #24) > (In reply to comment #23) > > any idea when that baby hits main tree then? > > It can't until someone makes a proper ebuild for Jetty, and I have no interest > in doing that. > What is the problem with the one in bug 328747? also, the current ebuild attached references >=dev-java/swt-3.6.1:3.6 but there is currently only a dev-java/swt-3.6:3.6 ebuild in the tree, and I see no version bump ticket for it. renaming the 3.6 ebuild and changing the MY_DMF var to MY_DMF="download.eclipse.org/eclipse/downloads/drops/R-${MY_PV}-201009090800 worked
(In reply to comment #26) > What is the problem with the one in bug 328747? Apparently there's a lot more to Jetty than meets the eye. My ebuild for it avoids its entire build system. The resulting build product is enough for Eclipse to compile against, but I have no idea if it actually runs in its own right. > also, the current ebuild attached references >=dev-java/swt-3.6.1:3.6 but there > is currently only a dev-java/swt-3.6:3.6 ebuild in the tree, and I see no > version bump ticket for it. > renaming the 3.6 ebuild and changing the MY_DMF var to > MY_DMF="download.eclipse.org/eclipse/downloads/drops/R-${MY_PV}-201009090800 > worked That's how I got SWT 3.6.1 as well. Possibly someone should open a ticket for it and add it as a blocker of this ticket.
So after updating my system yesterday (~x86) eclipse-3.6 would no longer launch. I updated to eclipse-3.6.1 but still didn't work. Running eclipse with: `eclipse-3.6 -debug -consoleLog` showed the following: java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons: no swt-gtk-3650 in java.library.path no swt-gtk in java.library.path Can't load library: /tmp/swtlib-32/libswt-gtk-3650.so Can't load library: /tmp/swtlib-32/libswt-gtk.so Took a look in /usr/lib and saw that libswt was at 3655 not 3650. I was able to workaround the problem by doing the following: cd /usr/lib ln -s libswt-gtk-3655.so libswt-gtk-3650.so ln -s libswt-pi-gtk-3655.so libswt-pi-gtk-3650.so ln -s libswt-glx-gtk-3655.so libswt-glx-gtk-3650.so ln -s libswt-cairo-gtk-3655.so libswt-cairo-gtk-3650.so ln -s libswt-awt-gtk-3655.so libswt-awt-gtk-3650.so ln -s libswt-atk-gtk-3655.so libswt-atk-gtk-3650.so
(In reply to comment #28) > Running eclipse with: `eclipse-3.6 -debug -consoleLog` showed the following: > java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons: > no swt-gtk-3650 in java.library.path > no swt-gtk in java.library.path > Can't load library: /tmp/swtlib-32/libswt-gtk-3650.so > Can't load library: /tmp/swtlib-32/libswt-gtk.so > > Took a look in /usr/lib and saw that libswt was at 3655 not 3650. Hmm, I only have 3655 in my /usr/lib64, and Eclipse 3.6.1 runs fine. $ find /usr/lib64 -name '*swt*.so' /usr/lib64/libswt-gtk-3655.so /usr/lib64/libswt-pi-gtk-3655.so /usr/lib64/libswt-atk-gtk-3655.so /usr/lib64/libswt-cairo-gtk-3655.so /usr/lib64/libswt-awt-gtk-3655.so /usr/lib64/libswt-glx-gtk-3655.so /usr/lib64/libswt-mozilla-gtk-3655.so /usr/lib64/libswt-xpcominit-gtk-3655.so /usr/lib64/libswt-xulrunner-gtk-3655.so
Is this in any overlay already?
(In reply to comment #30) > Is this in any overlay already? Not to my knowledge. We're still waiting for anyone to fix the Jetty ebuild (bug 328747).
(In reply to comment #30) > Is this in any overlay already? > It isn't official by any stretch of even the wildest imagination, but I have collected all of these ebuilds in my personal overlay. If you're interested, you can add http://pyrocufflink.net/layman-list.xml to your list of overlays in layman.cfg and then `layman -a dustin`. Eclipse builds fine and runs well; I have been using it both at work and at home for several weeks.
(In reply to comment #32) > (In reply to comment #30) > > Is this in any overlay already? > > > > It isn't official by any stretch of even the wildest imagination, but I have > collected all of these ebuilds in my personal overlay. If you're interested, > you can add http://pyrocufflink.net/layman-list.xml to your list of overlays in > layman.cfg and then `layman -a dustin`. Eclipse builds fine and runs well; I > have been using it both at work and at home for several weeks. > Thank you for your overlay. It emerges fine until eclipse-sdk stage: 2011-02-11 21:04:35 (32.3 KB/s) - `eclipse-3.6.1-src.tar.bz2' saved [62823517/62823517] ('Filesize does not match recorded size', 62823517, 62707872) !!! Fetched file: eclipse-3.6.1-src.tar.bz2 VERIFY FAILED! !!! Reason: Filesize does not match recorded size !!! Got: 62823517 !!! Expected: 62707872 But there's also need to do the following: "eselect maven set 1" before jetty emerge. Otherwise, it shows the following error: * Messages for package www-servers/jetty-6.1.24: * ERROR: www-servers/jetty-6.1.24 failed: * (no error message) * * Call stack: * ebuild.sh, line 56: Called src_compile * environment, line 4156: Called die * The specific snippet of code: * mvn -ff -s ${FILESDIR}/settings.xml install -Dmaven.test.skip -DWORKDIR="${WORKDIR}" || die *
(In reply to comment #33) > Thank you for your overlay. It emerges fine until eclipse-sdk stage: > The linux-build team changed the tarball without renaming it a while back. I corrected the issue in my overlay, which has actually moved. Please remove the extra URL in the "overlays" directive in layman.cfg and remove/re-add the "dustin" overlay; it is now listed in the main overlays list. > > But there's also need to do the following: "eselect maven set 1" before jetty > emerge. Otherwise, it shows the following error: > This is discussed in bug #328747 for the jetty ebuild.
Thank you very much, I've just successfully emerged eclipse-sdk-3.6.1 from new location of your overlay and it works fine.
Thank you for your ebuild, Eclipse 3.6 has been here for a while now! I had to downgrade to maven-bin:2.2 to compile jetty. The build failed with maven-bin:3. I also had to eselect it as well.
(In reply to comment #36) > Thank you for your ebuild, Eclipse 3.6 has been here for a while now! > > I had to downgrade to maven-bin:2.2 to compile jetty. The build failed with > maven-bin:3. I also had to eselect it as well. > Yeah, jetty has been the main show stopper here for a long time. I gave it a shot using maven, and we've seen how well that works. I'd recommend that the overlay switch to using Matt's version of the e-build until a better solution can be had. Possibly update it for slotting if it's not already.
As of 20110218 a new version 3.6.2 has been released. Has anyone ported the ebuild to 3.6.2 yet?
(In reply to comment #38) > As of 20110218 a new version 3.6.2 has been released. > > Has anyone ported the ebuild to 3.6.2 yet? It's not the Eclipse releases you should be looking at but rather the Eclipse-Build releases. Currently the latest Eclipse for which there is an Eclipse-Build is 3.6.1. http://download.eclipse.org/technology/linuxtools/eclipse-build/3.6.x_Helios/ As soon as an Eclipse-Build for 3.6.2 is released, this ebuild can be updated.
I'm curious about the relevance of the dependencies dev-java/tomcat-servlet-api:2.5 >=www-servers/jetty-6.1.23:6 >=www-servers/tomcat-5.5.17:5.5 I use Eclipse primarily as an editor for HTML/CSS/JS etc on a desktop machine and have absolutely no need for a Java application server - let alone TWO! Are these really build/run-time dependencies or are they just there to support optional features? If the later could they at least be controlled by USE variables?
Just to be clear, since I can't edit my previous comment, I suspect those dependencies are all related to JSP development and as such should probably depend on +jsp to avoid pulling in complex dependencies that C++/Web developers don't need when using Eclipse as an IDE. My suspicions are based on the existence of packages on the Eclipse downloads page that are specifically tailored to languages other than Java.
I would love to be free of those dependencies on my installation, too. Ideally, I would make a separate ebuild for each Eclipse "feature" (related collection of plugins). Unfortunately, Eclipse's build system and provisioning system are very monolithic, brittle, and poorly documented. My ebuild has to jump through significant hoops just to rip out the documentation and source plugins if you have USE='-doc -source'. Attempting to segment the build into individual features presently would be nearly impossible, given the current state of the build system. In fact, it's so bad, I can't even produce an ebuild for Eclipse 3.6.2 until the Eclipse-Build team releases their specially seasoned sources tarball, which contains a big sticky wad of bandaids intended to help the build process run outside of an Eclipse-powered continuous integration build environment.
Yes I noticed. I used your sed_xml_element to experimentally rip jetty out of build.xml and pdebuild.xml files ---- ebegin 'Removing JSP plugins' rm -rf "${buildDir}"/plugins/org.eclipse.equinox.http.jetty{,_*} eclipse_delete-plugins '.*\.jetty\(\..*\|\)' sed_xml_element 'file\|includes\|fileset' -e '/jetty/d' \ -i "${S}"/pdebuild.xml -i "${S}"/build.xml || die eend ----- ... but it doesn't build because jetty is used by plugins/org.eclipse.help.base for the help system. I suspect tomcat might be easier to rip out though.
(In reply to comment #39) > (In reply to comment #38) > > http://download.eclipse.org/technology/linuxtools/eclipse-build/3.6.x_Helios/ > > As soon as an Eclipse-Build for 3.6.2 is released, this ebuild can be updated. There it is. ;) new BUILD_ID="I20110210-1200", am I right?
Created attachment 265785 [details] eclipse-sdk-3.6.2.ebuild * Updated to use Eclipse-Build 0.6.1 * Updated to build Eclipse SDK 3.6.2-I20110210-1200 * Fixed a bug in dependency relinking (Ant symlinks were placed in wrong subdir)
*** Bug 359921 has been marked as a duplicate of this bug. ***
Hm, here is the usage of the discovery site broken, so installing subversive and such doesn't work as expected, someone a hint?
Is there an important reason to depend on tomcat-5.5? I would prefer to use tomcat 6 instead.
(In reply to comment #47) > Hm, here is the usage of the discovery site broken, so installing subversive > and such doesn't work as expected, someone a hint? I am able to install Mylyn, Subclipse, TestNG, and Saros from their respective update sites, so I think it works. As a hint, if you're upgrading from a previous version of Eclipse, your plugins will still be installed but will not load. I don't know why. You can fix it by going to About Eclipse, Installation Details, select all the installed plugins from the list and click the Uninstall button at the bottom. Then restart Eclipse and install them all again. (In reply to comment #48) > Is there an important reason to depend on tomcat-5.5? I would prefer to use > tomcat 6 instead. The ebuild depends on that version because that is the version that ships bundled with Eclipse. I think you can have 6 installed on your system at the same time. (They are slotted, aren't they?)
After changing BUILD_ID in 3.6.2 ebuild from I20110210-1200 to M20110210-1200 and recompiling eclipse-sdk i was able to update previously installed plugins without uninstalling them
> (In reply to comment #48) > > Is there an important reason to depend on tomcat-5.5? I would prefer to use > > tomcat 6 instead. > > The ebuild depends on that version because that is the version that ships > bundled with Eclipse. I think you can have 6 installed on your system at the > same time. (They are slotted, aren't they?) Thanks for the fast reply. Yes, you are right. But I don't want install a package which I not really need. Moreover I had a strange build error at the moment with tomcat-5.5. The reason for tomcat-5.5 is that the ebuild of Eclipse depend on "jasper-compiler" and "jasper-runtime" which are included in tomcat-5.5 but not in tomcat-6. Is there any way to change the ebuild to include this jar files separately (after downloading from anywhere)? Or much better: Exist any other package which including this jar files to depend on it? Could "java-overlay/dev-java/tomcat-jasper" eventually do the job?
I guess I missed it somewhere, but where does one get swt-3.6.2 required by this e-build? I'm anxious to give this e-build a try. Great work keeping eclipse alive on Gentoo, btw.
(In reply to comment #51) > The reason for tomcat-5.5 is that the ebuild of Eclipse depend on > "jasper-compiler" and "jasper-runtime" which are included in tomcat-5.5 but not > in tomcat-6. Is there any way to change the ebuild to include this jar files > separately (after downloading from anywhere)? Or much better: Exist any other > package which including this jar files to depend on it? Could > "java-overlay/dev-java/tomcat-jasper" eventually do the job? I honestly don't know. I went with what was closest to what is being distributed with the Eclipse binary download so as to cause the fewest problems. If you are able to make Eclipse work with different dependencies, post your results here so others can try it. (In reply to comment #52) > I guess I missed it somewhere, but where does one get swt-3.6.2 required by > this e-build? I'm anxious to give this e-build a try. Great work keeping > eclipse alive on Gentoo, btw. See the "Depends on" bugs list at the top. SWT 3.6.2 is bug 358773.
Created attachment 267309 [details] 3.6.2 depend on tomcat-6 (not tomcat-5.5) I have copied the 3.6.2 ebuild and changed the tomcat dependencies to "jasper" and "jasper-el".
(In reply to comment #47) > Hm, here is the usage of the discovery site broken, so installing subversive > and such doesn't work as expected, someone a hint? Later it where working after readding the discovery-site
I successfully installed 3.6.2 but the Check for Updates and Install New Software features are not working. I first tried with the "I" build_id where it would time out and fail to find an XML file or something, so I tried the "M" build_id as mentioned in comment #50 at the same time as switching to the new ebuild that depends on tomcat:6, and now it immediately shows the error "Could not find http://...". Any clues as to what is going on and how to fix it? I have 3.5.1 installed, which works fine. Thanks for providing these ebuilds, keep up the great work, cheers!
Can someone make an ebuild for eclipse-sdk-bin? Eclipse < 3.6.2 contains a security bug, and if no one wants to do a jetty ebuild... I think that's the best solution right now.
(In reply to comment #57) > Can someone make an ebuild for eclipse-sdk-bin? Eclipse < 3.6.2 contains a > security bug, and if no one wants to do a jetty ebuild... I think that's the > best solution right now. I'm using Eclipse 3.6.2 built by the ebuild just fine. If you want a binary distribution, just download the tarball from Eclipse.org and extract it, but there's nothing wrong with the ebuild. If your point is that you'd like to push Eclipse 3.6.2 into the main Portage tree, then maybe we could have a jetty-bin, and Eclipse could depend on a virtual/jetty so later someone could make a real ebuild for it and add that as an alternate to the virtual.
The problem is that the jetty ebuild I found (the one is here), no longer builds, and therefore, I cannot build eclipse 3.6 either
(In reply to comment #59) > The problem is that the jetty ebuild I found (the one is here), no longer > builds, and therefore, I cannot build eclipse 3.6 either Use the first Jetty ebuild on bug 328747.
Created attachment 274843 [details] eclipse-sdk-3.6.2.ebuild I've added a virtual jetty and a jetty-bin ebuilds to the jetty bug #328747 and was able to build eclipse against the jetty-bin install. Included is an update that supports the virtual jetty package Maybe this will help get eclipse into the main tree.
Created attachment 277171 [details] eclipse-3.7-ebuilds.tar.bz2 This tarball contains ebuilds for the following packages that are needed to build Eclipse SDK 3.7.0: dev-java/asm-3.3.1 dev-java/lucene-analyzers-2.9.4 dev-java/sat4j-core-2.3.0 dev-java/sat4j-pseudo-2.3.0 dev-java/swt-3.7_rc4 dev-util/eclipse-sdk-3.7.0 The needed eclipse-build-0.7.0.tar.bz2 has not yet been uploaded to eclipse.org, but you can create it using these commands: $ git clone git://git.eclipse.org/gitroot/linuxtools/org.eclipse.linuxtools.eclipse-build.git/ $ cd org.eclipse.linuxtools.eclipse-build $ mv eclipse-build-{config,feature} eclipse-build/ $ mv eclipse-build{,-0.7.0} $ tar -cvjf eclipse-build-0.7.0.tar.bz2 eclipse-build-0.7.0 The eclipse-sdk-3.7.0.ebuild runs to completion on my system (after installing all the needed dependencies), but I haven't tried the resulting Eclipse installation yet. The installation image does look complete, so I expect it to work.
Wanted to mention that the eclipse-3.7 ebuilds and instructions that Matt provided works perfectly. I was able to install it just fine on my Gentoo box, no problems at all. Thank you Matt!
(In reply to comment #63) > Wanted to mention that the eclipse-3.7 ebuilds and instructions that Matt > provided works perfectly. I was able to install it just fine on my Gentoo box, > no problems at all. Thank you Matt! I just gave it a shot and couldn't fetch 'eclipse-build-0.7.0.tar.bz2': 404 Not Found.
(In reply to comment #64) > I just gave it a shot and couldn't fetch 'eclipse-build-0.7.0.tar.bz2': 404 Not > Found. Yeah, like I said in comment 62, the tarball for Eclipse-Build 0.7.0 doesn't appear to have been posted, but you can create it by checking out Eclipse-Build via Git, as I outlined.
Ah, derr, thanks. Why does eclipse-sdk-3.7 depend on tomcat:5 whereas eclipse-sdk-3.6 depends on tomcat:6? Is that an oversight?
Created attachment 278389 [details] Failed 3.7 build Thanks for 3.7 update! I've encountered two problems: - swt-3.7_rc4 patch and build.xml are not included, 3.6 patch didn't work so I've made new one. (It seems that upstream fixed as-needed issues) - eclipse-sdk-3.7.0.ebuild failed because of patches, log included.
Created attachment 278399 [details] eclipse-3.7-ebuilds.tar.bz2 This updated tarball includes ebuilds for the following: dev-java/asm-3.3.1 dev-java/lucene-analyzers-2.9.4 dev-java/sat4j-core-2.3.0 dev-java/sat4j-pseudo-2.3.0 dev-java/swt-3.7 (*) dev-util/eclipse-sdk-3.7.0 (*) (*) = updated since the last tarball Eclipse-Build has released a tarball, so this new Eclipse ebuild references that, and you no longer need to do the git clone yourself. (In reply to comment #67) > - swt-3.7_rc4 patch and build.xml are not included, 3.6 patch didn't work so > I've made new one. (It seems that upstream fixed as-needed issues) I used the as-needed-and-flag-fixes-3.6.patch and build.xml from the main Portage tree. This new tarball includes those for your convenience. > - eclipse-sdk-3.7.0.ebuild failed because of patches, log included. All patches apply for me.
(In reply to comment #66) > Ah, derr, thanks. Why does eclipse-sdk-3.7 depend on tomcat:5 whereas > eclipse-sdk-3.6 depends on tomcat:6? Is that an oversight? The Eclipse SDK 3.7 download from Eclipse.org includes Jasper 5.5.17, so that is taken as the canonical version required. This is not a change from Eclipse 3.6.2. (You may have been looking at one of the experimental eclipse-sdk-3.6.2.ebuilds that were posted by others.)
The problem seems to be that the eclipse source archive does not have the BUILDID in its root directory name. I've added the following to src_unpack to "fix" this: cp -r "${S}/build/eclipse-${PV}-src/"* "${buildDir}/" || die "Copying sources failed" rm -r "${S}/build/eclipse-${PV}-src" || die "Removing dir failed" ln -s "eclipse-${BUILD_LABEL}-src" "${S}/build/eclipse-${PV}-src" || die "Creating link failed"
Is it possible for this all to be just put in an overlay so it could be added via layman? It would make it much easier to install and test. Could actually add both 3.6 and 3.2 ebuilds that way.
Created attachment 280385 [details] emerge --info for emerging eclipse-sdk-3.7.0 after failure Using Matt's ebuilds I get through stuff just fine until emerging eclipse-sdk-3.7.0 - the following failure occurs. * Removing source plugins ... [ ok ] * Linking dependencies ... * com.ibm.icu_4.4.2.v20110208 => icu4j-4.4 { - more things here that work ok - } * org.hamcrest.core_1.1.0.v20090501071000 => hamcrest-core * org.mortbay.jetty.server_6.1.23.v201004211559 => jetty-6 jetty !!! ERROR: Package jetty-6 was not found! * ERROR: dev-util/eclipse-sdk-3.7.0 failed (prepare phase): * There was a problem getting the classpath for jetty-6. * * Call stack: * ebuild.sh, line 56: Called src_prepare * environment, line 4646: Called eclipse_create-osgi-dep 'org.mortbay.jetty.server' 'jetty-6.1.26' 'jetty-6' 'jetty' * environment, line 1055: Called java-pkg_jar-from 'jetty-6' 'jetty.jar' * environment, line 3510: Called die * The specific snippet of code: * [[ $? != 0 ]] && die ${error_msg}; As per instructions for bug reporting: GENTOO_VM=sun-jdk-1.6 CLASSPATH="" JAVA_HOME="/opt/sun-jdk-1.6.0.26" JAVACFLAGS="-source 1.5 -target 1.5" COMPILER="javac" emerge --info =dev-util/eclipse-sdk-3.7.0 is attached.
I am experiencing the same issue with the hamcrest junit patch as described in comment 67. The patch in comment 70 appears to correct the issue and allows Eclipse to compile successfully. During the compile process, though, I get several sandbox access violations on open_wr /dev/random. I am currently running the build again with FEATURES=-sandbox to see if that makes a difference. I will post results and logs once that's done
I experience the issue of comment 67. Comment 70 corrects the issue as well. I also experience the same issue than comment 73 (sandbox violations). Using FEATURES="-sandbox" is a working work-around : eclipse-3.7 builds and runs fine. I used eclipse-3.5-ebuilds.tar.bz2 found here + patch from comment 70, and jetty from bug #328747.
Created attachment 282553 [details] Fixed ebuild for eclipse-sdk-3.7 This is my fixed ebuild file for eclipse-sdk-3.7. Fixed 2 bugs - error hamcrest-junit-lib and [java] ACCESS DENIED open_wr: /dev/random
So the latest ebuild works on my system, but Eclipse is unable to open/edit any ant files: Unable to create editor ID org.eclipse.ant.ui.internal.editor.AntEditor: Editor could not be initialized. java.lang.Error: Unresolved compilation problem: The method registerProjectHelper(ProjectHelper) in the type ProjectHelperRepository is not applicable for the arguments (Class<T>) at org.eclipse.ant.internal.ui.model.AntModel.init(AntModel.java:205) at org.eclipse.ant.internal.ui.model.AntModel.<init>(AntModel.java:144) at org.eclipse.ant.internal.ui.editor.text.AntEditorDocumentProvider.createAntModel(AntEditorDocumentProvider.java:70) at org.eclipse.ant.internal.ui.editor.text.AntEditorDocumentProvider.createFileInfo(AntEditorDocumentProvider.java:114) ... I'm running sun JDK 1.6.0.26 and the ant installed on my system is 1.8.1 I noticed that ant 1.8.2 came out back in Dec 2010, but not in portage yet, not sure if it's related.
Created attachment 282939 [details] Jetty Eclipse Help System Error I manage to build the eclipse-sdk and needed dependencies from the fixed ebuilds posted by Slayer. The IDE seems to be working however help system is not accesible. I'm getting error 500, when lunching the help in external browser. SWT was build w/o xullrunner support - due to the fact I'm using firefox 5.0 in my system.
I have changed the eclipse-3.7.0.ebuild on my system to depend on java-virtuals/jetty-server:6 to be able to use jetty-bin-6 from Bug 328747. After modifying the jetty-bin-6.1.26.ebuild to install as "jetty" and not "jetty-bin", eclipse-3.7.0 builds and merges just fine. It has to be noted that I did not have the time to test eclipse-3.7 properly, yet! However, until I have tested everything properly I have added the ebuilds posted in here to my gentoo overlay (layman -a seden) for further testing. The ChangeLog states rightful authors of the ebuilds, I hope that is ok with you, Matt and Slayer?
(In reply to comment #78) > I hope that is ok with you, Matt and Slayer? *shrug* I don't care, as long as people don't come asking me to help them make it work on their systems. I donate my work on the Eclipse ebuilds into the public domain, so do whatever you want with it. When Eclipse 3.7.1 comes out, I'll probably create an ebuild for that too and post it here, but no promises. :-)
(In reply to comment #78) > I have changed the eclipse-3.7.0.ebuild on my system to depend on > java-virtuals/jetty-server:6 to be able to use jetty-bin-6 from Bug 328747. > After modifying the jetty-bin-6.1.26.ebuild to install as "jetty" and not > "jetty-bin", eclipse-3.7.0 builds and merges just fine. > The correct way to use the virtual package is to update the eclipse package to use jetty-server. Otherwise the virtual package is useless in your current setup.
All of the 3.7 ebuilds fail for me if the doc USE-flag is enabled; I'll attach a log of such a failed build. Emerge --info: Portage 2.1.10.3 (hardened/linux/amd64, gcc-4.4.5, glibc-2.11.3-r0, 2.6.38-hardened-r6 x86_64) ================================================================= System Settings ================================================================= System uname: Linux-2.6.38-hardened-r6-x86_64-Intel-R-_Core-TM-2_Duo_CPU_T6670_@_2.20GHz-with-gentoo-2.0.3 Timestamp of tree: Thu, 18 Aug 2011 07:15:01 +0000 distcc 3.1 x86_64-pc-linux-gnu [disabled] app-shells/bash: 4.1_p9 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.7.1-r1, 3.1.3-r1 dev-util/cmake: 2.8.4-r1 dev-util/pkgconfig: 0.26 sys-apps/baselayout: 2.0.3 sys-apps/openrc: 0.8.3-r1 sys-apps/sandbox: 2.4 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.5 sys-devel/gcc-config: 1.4.1-r1 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82 sys-kernel/linux-headers: 2.6.36.1 (virtual/os-headers) sys-libs/glibc: 2.11.3 Repositories: kde-sunset hardened-dev sunrise java-overlay science anarchy bazaar gentoo-haskell local seden eclipse g-cpan hackport_laptop gentoo ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -mtune=core2" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/maven-bin-2.2/conf /usr/share/maven-bin-3.0/conf /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -pipe -mtune=core2" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--with-bdeps y" FEATURES="assume-digests binpkg-logs collision-protect compress-build-logs distlocks ebuild-locks fakeroot fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms strict test unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="" GENTOO_MIRRORS="http://mirrors.rit.edu/gentoo/ http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" LANG="C" LC_ALL="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en en_US" MAKEOPTS="-j2 -l5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/kde-sunset /usr/portage/local/layman/hardened-development /usr/portage/local/layman/sunrise /usr/portage/local/layman/java-overlay /usr/portage/local/layman/science /usr/portage/local/layman/anarchy /usr/portage/local/layman/bazaar /usr/portage/local/layman/haskell /usr/local/portage /usr/portage/local/layman/seden /usr/portage/local/layman/eclipse /usr/portage/local/layman/g-cpan /usr/portage/local/layman/hackport /usr/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="X acl alsa amd64 bash-completion berkdb bluetooth bzip2 caps cracklib crypt cxx dri gdbm gpm hardened iconv ipv6 jpeg justify libnotify lm_sensors mmx modules mudflap multilib ncurses nls nptl nptlonly ogg openmp pam pcre perl png policykit pppd python readline session speex sse sse2 sse3 ssl ssse3 startup-notification sysfs tcpd theora truetype udev unicode urandom vorbis xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="braindump flow karbon kexi kpresenter krita tables words" CAMERAS="all" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_US" NETBEANS_MODULES="apisupport ergonomics cnd groovy harness ide java nb ruby" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="intel vesa" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS ================================================================= Package Settings ================================================================= dev-util/eclipse-sdk-3.7.0 was built with the following: USE="(multilib) source test -doc -gnome"
Created attachment 283735 [details] Failed build with USE=doc (compressed)
Thats weird, I have eclipse-3.7.0 installed with doc USE flag enabled. My USE Flags for that version: (doc -elibc_FreeBSD -gnome -source) Well, your log starts to error out with this: [java] /var/tmp/portage/dev-util/eclipse-sdk-3.7.0/work/eclipse-build-5791c48513b4207ab1eec1e00bed4b2186f9aad5/build/eclipse-3.7.0-I20110613-1736-src/plugins/org.eclipse.platform.doc.isv/buildDoc.xml:115: Problem: failed to create task or type replaceregexp [java] Cause: the class org.apache.tools.ant.taskdefs.optional.ReplaceRegExp was not found. [java] This looks like one of Ant's optional components. [java] Action: Check that the appropriate optional JAR exists in [java] -/var/tmp/portage/dev-util/eclipse-sdk-3.7.0/work/eclipse-build-5791c48513b4207ab1eec1e00bed4b2186f9aad5/bootstrap/plugins/org.apache.ant_1.8.2.v20110505-1300/lib [java] -/var/tmp/portage/.ant/lib [java] -a directory added on the command line with the -lib argument [java] [java] Do not panic, this is a common problem. [java] The commonest cause is a missing JAR. [java] [java] This is not a bug; it is a configuration problem So it seems a needed ant-package is missing. The class the build is moaning about belongs to "dev-java/ant-nodeps". So this package has to be added to the dependency list if the doc use flag is set.
Created attachment 283875 [details] eclipse-sdk-3.7.0-r2.ebuild Changes: - Use java-virtuals/jetty-server:6 to enable the usage of jetty-bin-6.1.26-r1.ebuild from Bug 283873 - Add dependency to dev-java/ant-nodeps if doc use flag is set
(In reply to comment #84) > - Use java-virtuals/jetty-server:6 to enable the usage of > jetty-bin-6.1.26-r1.ebuild from Bug 283873 ARGH! I added the number of the attachement visible in the firefox tab title. The Correct number is Bug 328747 of course. Sorry!
This updated ebuild still fails; I think ant-nodeps was already implicitly pulled in, since it said "Using following ANT_TASKS: ant-nodeps" at the top of the log even before you added the explicit dependency. However, I just noticed that the error message says it's looking for it in a plugin bootstrap directory; a bunch of JARs got linked there in src_prepare(), but it didn't. Adding ant-nodeps to NONOSGI_DEPENDENCIES might work. I'll try that and report back ...
I discovered a Changelog entry inside the build directory mentioning removing ant-nodeps.jar (and ant-trax.jar, for that matter) from the dependencies file (which eclipse_create-nonosgi-dep() parses to find out where to put the link to the jar file) because Ant 1.8.2 (which is the version Eclipse bundles---we should perhaps make this bug depend on bug #351850 ) doesn't have them anymore. I put them back in (and added ant-trax to WANT_ANT_TASKS), so that ant-nodeps.jar ended up where ant claims it wants it, but it still wouldn't build. I tried switching from sun-jdk to icedtea6, but that didn't help. Finally, in desperation, I linked ant-nodeps.jar to the ebuild environment's ${HOME}/.ant/lib (/var/tmp/portage/.ant/lib) and, using an /etc/portage/env entry, added " -lib /usr/share/ant-nodeps/lib/ant-nodeps.jar " to all the ant calls via EANT_EXTRA_ARGS ... and one of those worked. Now to see whether it *runs* properly ...
Thank you for all the great work in the past. I'm afraid that for the next versions of eclipse every time some new ebuilds are necessary for the first start. Therefore only my opinion and a suggestion: It would be better to open a new bug for all 3.7 related issues. Be in mind the actual headline is "dev-util/eclipse-sdk-3.6 released".
I can confirm that the eclipse-sdk-3.7.0-r2.ebuild works on my machine without tweaking. I am using x86_64 gentoo-sources-3.0.3 (system-vm: sun-jdk-1.6). After adding all of eclipse's dependencies to my local portage overlay, it installed fine and I could start the application. The missing ebuilds were taken from Sven Eden's overlay: http://gentoo-overlays.zugaina.org/seden/portage/ Although java-overlay was possibly covering further deps, I needed to copy: dev-java/asm dev-java/lucene-analyzers dev-java/sat4j-core dev-java/sat4j-pseudo dev-java/swt dev-util/eclipse-jdk java-virtuals/jetty-server www-servers/jetty-bin Big thanks to everyone, who worked on it! By the way, there already is a separate bug report for eclipse-sdk-3.7: Bug #374251
Thanks for the ebuild. Got it and its dependencies from seden overlay via layman and everything compiled and runs fine. I'll try to get rid of tomcat-5.5 too, it's rather old and I wonder why they don't upgrade to the latest version (tomcat-7). Does anyone know if the proposed solutions in the comments here still work, and do they perhaps work with tomcat-7 too?
Created attachment 287295 [details, diff] Patch for ebuild to use more up-to-date Tomcat 7. Ok, I tried the suggestions regarding tomcat above and the modification still works. Everything builds and starts fine, I did not try anything else though.
Guys, please enforce the following USE flag: dev-java/swt cairo It's necessary for XML build-in editor Here is more details: http://forums.gentoo.org/viewtopic-t-860218.html
I notice that 3.7.1 is showing up when my 3.7.0-r2 checks for updates. Anybody have an ebuild yet? I tried to do a simple ebuild bump, but it's not finding the source tar ball.
(In reply to comment #93) > I notice that 3.7.1 is showing up when my 3.7.0-r2 checks for updates. Anybody > have an ebuild yet? I tried to do a simple ebuild bump, but it's not finding > the source tar ball. I tried, but the problem is: There is no 3.7.1 source. There is 3.7.0 only under http://download.eclipse.org/technology/linuxtools/eclipse-build/3.7.x_Indigo/ - at least right now.
Created attachment 290999 [details] eclipse-sdk-3.7.0-r2.ebuild with tc-7 + QA fix Silenced some QA (check-reqs) and added the tomcat-7 patch from this bug. I hope everything is correct. It compiles fine on my amd64 machine.
Hi! Is there any hope that eclipse 3.7 will make it into the main Gentoo repository in the near future, for example before New Year?
(In reply to comment #94) > (In reply to comment #93) > > I notice that 3.7.1 is showing up when my 3.7.0-r2 checks for updates. Anybody > > have an ebuild yet? I tried to do a simple ebuild bump, but it's not finding > > the source tar ball. > > I tried, but the problem is: There is no 3.7.1 source. There is 3.7.0 only > under > http://download.eclipse.org/technology/linuxtools/eclipse-build/3.7.x_Indigo/ - > at least right now. And now I have the answer. 3.7.1 is an update to 3.7.0. It can not be built directly (yet?), eclipse has to be updated from within. (In reply to comment #96) > Hi! Is there any hope that eclipse 3.7 will make it into the main Gentoo > repository in the near future, for example before New Year? I do not think so. To build eclipse 3.7 a jetty server must be available. There is an ebuild for the binary version, but the source version won't hit the tree for a long time. (See bug 328747) In short: jetty needs maven, and maven is not supported. The ebuilds in the said bug are of not high enough quality to make it into the tree.
(In reply to comment #97) > > In short: jetty needs maven, and maven is not supported. The ebuilds in the > said bug are of not high enough quality to make it into the tree. So the questions are, i) who can write high quality ebuilds, and ii) how do we convince them to? i) Gentoo developers, perhaps some others...? ii) Can we put a call-out on the developers' mailing list for help? Point them to a particular bug #? (I don't even know which!) Just ideas off the top of my head. No problem is insurmountable, we just have to take it step by step.
Created attachment 291561 [details] swt-3.7.1.ebuild
Created attachment 291563 [details] eclipse-sdk-3.7.1.ebuild This is based on my original eclipse-sdk-3.7.0.ebuild. If you want the Tomcat 7 "fix," you'll have to apply those changes to this new ebuild.
Nice! Yesterday I looked, and there was no eclipse-3.7.1-src.tar.bz2, but today it is. cool!
Created attachment 291583 [details, diff] Patch to add Q/A-fixes and Tomcat7 patch to 3.7.1 ebuild Your eclipse-sdk-3.7.1.ebuild works perfectly here, thank you very much Matt! I have added your two new ebuilds to my overlay (http://git.overlays.gentoo.org/gitweb/?p=user/seden.git - Available via layman -a seden) after adding ScytheMans QA fixes and Small Penguins Tomcat7 patch. Instead of posting another ebuild I thought it would be better to post a patch to your ebuild.
Matt & Sven - Thank you both! Added Sven's overlay and upgraded to 3.7.1...absolutely painless. As good as if it's in portage.
Stra(In reply to comment #103) > Matt & Sven - Thank you both! Added Sven's overlay and upgraded to > 3.7.1...absolutely painless. As good as if it's in portage. Just add seden overlay. Emerge fails with sandbox violation: like: F: open_wr S: deny P: /dev/random A: /dev/random R: /dev/random C: /opt/icedtea6-bin-1.10.3/jre/bin/java -classpath /var/tmp/portage/dev-util/eclipse-sdk-3.7.1/work/org.eclipse.linuxtools.eclipse-build-9e028fbc74e844e96a6fd944d7d4f68909283a5d/eclipse-build/bootstrap/plugins/org.eclipse.equinox.launcher.jar org.eclipse.equinox.launcher.Main -configuration configuration -application org.eclipse.ant.core.antRunner -buildfile ../pdebuild.xml generateScripts2 -DbuildArch=x86_64 -DbuildId=I20110909-1335 -debug -consolelog short build-log: http://paste.pocoo.org/show/503210/ emerge --info : http://paste.pocoo.org/show/503203/
I'm getting the same problem compiling as Nikolay. I'm using icedbin6 (self-compiled, though), too. Maybe that's the problem?
(In reply to comment #105) > I'm getting the same problem compiling as Nikolay. I'm using icedbin6 > (self-compiled, though), too. Maybe that's the problem? Could be. It emerged fine for me using sun-jdk.
I just upgraded to the new Icedtea 7, and then it compiled fine.
(In reply to comment #107) > I just upgraded to the new Icedtea 7, and then it compiled fine. That's odd. I took a look into the build logs above, and it builds without any errors. The log states: "BUILD SUCCESSFUL; Total time: 13 minutes 52 seconds", and then the sandbox violations start. Normally this means that an ebuild tried to manipulate a file outside its dedicated build directory in /var/tmp/portage, but I can't find a hint about that in the command lines mentioned in the log. Strange. (Or maybe I am just a bit blind...) Luckily it works with Icedtea 7, though...
After switching to sun-jdk everything builds successfully! Thanks! but as in 3.6.x "Available update sites" are empty...
Has anyone created a binary ebuild yet? Seems the src version requires to much "junk" to build and I would rather not pollute my system with jetty, tomcat, maven and the rest of this stuff that is only needed to build eclipse.
I worked around the sandbox violation by adding "addpredict /dev/random" to src_compile() in my local copy. (In addition to adding dependencies on ant-nodeps and ant-trax, which some version required to build docs, and cleaning up the CHECKREQS boilerplate slightly.) I haven't had my update sites go away, but my pet peeve with all recent versions is that after upgrading or even recompiling Eclipse, until I either install or uninstall a plugin Eclipse doesn't actually use any of the plugins I already have installed. (It recognizes that they're there, so I can't just install one of them again, but I can't *use* them.)
(In reply to comment #110) > Has anyone created a binary ebuild yet? Seems the src version requires to much > "junk" to build and I would rather not pollute my system with jetty, tomcat, > maven and the rest of this stuff that is only needed to build eclipse. A binary ebuild would install those other libraries, too, only they'd be private copies that only Eclipse could use. When you install them through Portage, no additional space is wasted, but they do wind up in locations where they can meet pre-reqs of other packages you might install. (In reply to comment #109) > but as in 3.6.x "Available update sites" are empty... That's a bug in Eclipse: https://bugs.eclipse.org/bugs/show_bug.cgi?id=249133 (In reply to comment #111) > I haven't had my update sites go away, but my pet peeve with all recent > versions is that after upgrading or even recompiling Eclipse, until I either > install or uninstall a plugin Eclipse doesn't actually use any of the plugins I > already have installed. (It recognizes that they're there, so I can't just > install one of them again, but I can't *use* them.) Happens for me too.
Trying to access Workbench basics in fresh install of 3.7.1 from seden overlay I get error. Does any one know how to resolve it? HTTP ERROR 500 Problem accessing /help/index.jsp. Reason: Unresolved compilation problem: The type org.apache.tomcat.PeriodicEventListener cannot be resolved. It is indirectly referenced from required .class files Caused by: java.lang.Error: Unresolved compilation problem: The type org.apache.tomcat.PeriodicEventListener cannot be resolved. It is indirectly referenced from required .class files at org.eclipse.equinox.jsp.jasper.JspServlet.<init>(JspServlet.java:1) at org.eclipse.equinox.jsp.jasper.registry.JSPFactory.create(JSPFactory.java:56) at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:262) at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:55) at org.eclipse.equinox.http.registry.internal.ServletManager$ServletWrapper.initializeDelegate(ServletManager.java:194) at org.eclipse.equinox.http.registry.internal.ServletManager$ServletWrapper.service(ServletManager.java:179) at org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(ServletRegistration.java:61) at org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:126) at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:60) at javax.servlet.http.HttpServlet.service(Unknown Source) at org.eclipse.equinox.http.jetty.internal.HttpServerManager$InternalHttpServiceServlet.service(HttpServerManager.java:317) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:322) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) Powered by Jetty://
*** Bug 374251 has been marked as a duplicate of this bug. ***
(In reply to comment #113) > Trying to access Workbench basics in fresh install of 3.7.1 from seden overlay > I get error. > > Does any one know how to resolve it? Not yet. None of the jsp-based tutorials or the help center work at the moment. *maybe* jetty-6 is too old, but I have no real idea. Maybe it is neccessary to bump jetty to jetty-7 or 8?
Created attachment 298019 [details] eclipse-sdk-3.7.1-r2.ebuild I have switched from sat4j-*:2 in my overlay to sat4j-*:2.3 in the portage tree (*yay*), this ebuild now uses the slotted version.
Thanks a lot for your work. :) In case of ant-1.8.2, bug 351850 is *almost* there. Anyone willing to step up and do the final work?
I'm getting problems with Eclipse 3.7.x built from the seden overlay with ant builds. When I try to create a run configuration, it seems eclipse cannot read the build.xml file to determine targets, so the list of targets remains empty and I cannot actually create a run config. When trying to open build.xml in the editor, another error occurs, saying "Editor could not be initialized". Is there maybe some prerequisite missing? It used to work in earlier 3.6.x builds.
Can anybody add eclipse-sdk-bin ebuild for 3.6 and 3.7 if you can't make it compile? It would be more useful than nothing.
Breaking News: ant-*.1.8.2 packages have made it into Portage. :) As soon as rebuilding half of @world for native 32-bit is finished, I'm going to give eclipse-sdk-3.7.2 a try with updated ant deps. Unless someone else is faster.
Created attachment 302535 [details] eclipse-sdk-3.7.1-r3 based on seden's, with ant-1.8.2 deps Built fine and starts up. I did notice however that it crashes when trying to set up an existing workspace at startup.
OK, 3.7.1-rc4 installs fine, and I too got the workspace crash once. After that, it's working, but when I tried doing some updates this failed with the following message: Cannot complete the install because of a conflicting dependency. Software being installed: Eclipse SDK 3.7.1.M20110909-1335 (org.eclipse.sdk.ide 3.7.1.M20110909-1335) Software currently installed: Shared profile 1.0.0.1329842219396 (SharedProfile_SDKProfile 1.0.0.1329842219396) Only one of the following can be installed at once: Eclipse SDK 3.7.0.I20110909-1335 (org.eclipse.sdk.ide 3.7.0.I20110909-1335) Eclipse SDK 3.7.1.M20110909-1335 (org.eclipse.sdk.ide 3.7.1.M20110909-1335) Cannot satisfy dependency: From: Shared profile 1.0.0.1329842219396 (SharedProfile_SDKProfile 1.0.0.1329842219396) To: org.eclipse.sdk.ide [3.7.0.I20110909-1335] Anyone got a similar experience?
(In reply to comment #122) > OK, 3.7.1-rc4 installs fine, and I too got the workspace crash once. After > that, it's working, but when I tried doing some updates this failed with the > following message: > > Cannot complete the install because of a conflicting dependency. > Software being installed: Eclipse SDK 3.7.1.M20110909-1335 > (org.eclipse.sdk.ide 3.7.1.M20110909-1335) > Software currently installed: Shared profile 1.0.0.1329842219396 > (SharedProfile_SDKProfile 1.0.0.1329842219396) > Only one of the following can be installed at once: > Eclipse SDK 3.7.0.I20110909-1335 (org.eclipse.sdk.ide 3.7.0.I20110909-1335) > Eclipse SDK 3.7.1.M20110909-1335 (org.eclipse.sdk.ide 3.7.1.M20110909-1335) > Cannot satisfy dependency: > From: Shared profile 1.0.0.1329842219396 (SharedProfile_SDKProfile > 1.0.0.1329842219396) > To: org.eclipse.sdk.ide [3.7.0.I20110909-1335] > > Anyone got a similar experience? Yes, this is a platform upgrade which has to be done via ebuild bump, as the relevant files belong to root. But the ebuild already installs 3.7.1, so this update is unnecessary. (See COmments #100 and #102)
(In reply to comment #120) > I'm going to give eclipse-sdk-3.7.2 a try with updated ant deps. Unless someone > else is faster. So how's it going with 3.7.2?
Sorry that was a typo, but the 3.7.1-r3 ebuild with ant-1.8.2 and icedtea7 works fine for me.
Hrmmmm....something (I have no idea what) seems to have upgraded and broken my perfect 3.7.1-r5 eclipse build. A days ago, I was able to upgrade to 3.7.1-r5 with no issues...today I tried to re-emerge it after the portage version of swt broke the eclipse runtime and now it won't emerge. I downgraded back to the seden version of swt and it works again, but I get this error if I try to re-emerge eclipse (btw, Xlib.h is there): [exec] cc -O2 -pipe -march=core2 -mcx16 -msahf -msse4.1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=core2 -Wall -fpic -DLINUX -DMOZILLA_FIX -DDEFAULT_OS="\"linux\"" -DDEFAULT_OS_ARCH="\"x86_64\"" -DDEFAULT_WS="\"gtk\"" -DDEFAULT_JAVA_EXEC -DGTK_LIB="\"libgtk-x11-2.0.so.0\"" -DGDK_LIB="\"libgdk-x11-2.0.so.0\"" -DPIXBUF_LIB="\"libgdk_pixbuf-2.0.so.0\"" -DGOBJ_LIB="\"libgobject-2.0.so.0\"" -DX11_LIB="\"libX11.so.6\"" -I. -I.. -I/opt/sun-jdk-1.6.0.31/include -I/opt/sun-jdk-1.6.0.31/include/linux `pkg-config --cflags gtk+-2.0` -c eclipseGtkCommon.c -o eclipseGtkCommon.o [exec] In file included from eclipseGtk.h:16:0 [exec] from eclipseGtkCommon.c: [exec] /usr/include/gtk-2.0/gdk/gdkx.h:32:22: fatal error: X11/Xlib.h: No such file or directory [exec] compilation terminated. [exec] make: *** [eclipseGtkCommon.o] Error 1
(In reply to comment #126) > Hrmmmm....something (I have no idea what) seems to have upgraded and broken > my perfect 3.7.1-r5 eclipse build. A days ago, I was able to upgrade to > 3.7.1-r5 with no issues...today I tried to re-emerge it after the portage > version of swt broke the eclipse runtime and now it won't emerge. I > downgraded back to the seden version of swt and it works again, but I get > this error if I try to re-emerge eclipse (btw, Xlib.h is there): > I installed 3.7.1-r5 fine, but it wouldn't execute. Looking at the log it was missing some SWT deps in java.library.path, and there not being links in ~/.swt. Is something supposed to be setting java.library.path? I just symlinked the appropriate files via: find /usr/lib/ -name 'libswt*' -exec ln -s {} ~/.swt/lib/linux/x86_64/ \; and then renaming the resultant links to version agnostic (e.g. libswt-atk-gtk-3740.so -> libswt-atk-gtk.so)
(In reply to comment #127) > (In reply to comment #126) > > Hrmmmm....something (I have no idea what) seems to have upgraded and broken > > my perfect 3.7.1-r5 eclipse build. A days ago, I was able to upgrade to > > 3.7.1-r5 with no issues...today I tried to re-emerge it after the portage > > version of swt broke the eclipse runtime and now it won't emerge. I > > downgraded back to the seden version of swt and it works again, but I get > > this error if I try to re-emerge eclipse (btw, Xlib.h is there): > > > > I installed 3.7.1-r5 fine, but it wouldn't execute. Looking at the log it > was missing some SWT deps in java.library.path, and there not being links in > ~/.swt. Is something supposed to be setting java.library.path? I just > symlinked the appropriate files via: > > find /usr/lib/ -name 'libswt*' -exec ln -s {} ~/.swt/lib/linux/x86_64/ \; > and then renaming the resultant links to version agnostic (e.g. > libswt-atk-gtk-3740.so -> libswt-atk-gtk.so) That looks like it would explain the issues with the Gentoo swt upgrade. Still not sure about the missing Xlib.h compile failure though.
Same here, I updated the CDEPEND to "=dev-java/swt-${PV%.0}*:${SLOT}" in my local overlay. I can't confirm the Xlib.h breakage though. Perhaps you should try and rebuild libX11.
All is fine back at swt-3.7.1 - there are no links in ~/.swt/lib/linux/x86_64/ as well, and only versioned *.so files in /usr/lib: /usr/lib64/libswt-atk-gtk-3738.so /usr/lib64/libswt-awt-gtk-3738.so /usr/lib64/libswt-glx-gtk-3738.so /usr/lib64/libswt-gtk-3738.so /usr/lib64/libswt-pi-gtk-3738.so eclipse-sdk-3.7.1 probably expects those: # equery f eclipse-sdk | grep swt /usr/lib64/eclipse-3.7/plugins/org.eclipse.swt.gtk.linux.x86_64_3.7.1.v3738a.jar /usr/lib64/eclipse-3.7/plugins/org.eclipse.swt_3.7.1.v3738a.jar ...
Created attachment 304989 [details] eclipse-sdk-3.7.1-r7.ebuild fixed dependencies I have updated the ebuild in my overlay to this one. 1.: Less memory requirement, Users with only 1.5GB RAM should no longer have problems emerging this. 2.: Add libpng:1.2 to RDEPEND, some crashes seem to be related to the old libpng version being missing on some systems. (Very vague, I know!) 3.: CDEPEND on the $BUILD_VER of Eclipse-SDK of SWT. Eclipse-SDK-3.7.1 does not seem to be fit to run with anything but ~dev-java/swt-3.7.1
I created a 3.7.2 tarball the way it says here http://wiki.eclipse.org/Linux_Tools_Project/Eclipse_Build/Inner_Workings#Fetching_Sources and used Sven's ebuild with the variables updated. BUILD_VER="3.7.2" BUILD_ID="M20120208-0800" ECLIPSE_BUILD_VER="bd5e22fe1c5897603235f7da0d6db31035ab270b" But I'm getting errors like this [javac] /var/tmp/portage/dev-util/eclipse-sdk-3.7.2/work/org.eclipse.linuxtools.eclipse-build-bd5e22fe1c5897603235f7da0d6db31035ab270b/eclipse-build/build/eclipse-3.7.2-src/plugins/org.eclipse.equinox.app/src/org/eclipse/equinox/internal/app/AppPersistence.java:22: error: package org.osgi.service.event does not exist [javac] import org.osgi.service.event.Event; pretty early during the compile stage. Here's the complete log http://paste.pocoo.org/show/566180/ Could someone help me out?
I'd wait until the official source tarball shows up. The build script you have been using is building for R3_7_1, not 3_7_2. I am testing it right now, but it seems it is not fetching some dependencies.
I filed a bug report requesting the source tarball https://bugs.eclipse.org/bugs/show_bug.cgi?id=373323 It doesn't seem there will be an official tarball for 3.7.2. I got patching errors from the eclipse37 branch so I used eclipse-build from the master branch. I guess that's the reason for the missing dependencies. I changed the variables in the build script to the following buildID="M20120208-0800" baseBuilderTag="vM20120208-0800" eclipseBuilderTag="vM20120208-0800" label="3.7.2"
(In reply to comment #134) > I filed a bug report requesting the source tarball > https://bugs.eclipse.org/bugs/show_bug.cgi?id=373323 > > It doesn't seem there will be an official tarball for 3.7.2. After your message Andrew Overholt wrote: > Jesse, if 3.7.2 builds are important to you, they're probably important to > others. Would you mind publishing a git clone somewhere (GitHub, perhaps) with > your changes in them and submit them here (just put the URL)? Then we could > get this sorted for all and you could have your name in the git log :) So I daresay there *could* be an official tarball thanks to your work. :) I tried to build a tarball myself last friday, but ended in the same errors (patching hell) you ended up with and didn't have the time to look for a solution myself.
I have built and installed eclipse 3.7.1-r3 with apparent success. I'd like to report a rather strange problem using CDT, this seems like the best place: regarding math.h, the float and long double versions of the functions are not availble (they error as unresolved (e.g., rint() is okay but not rintf() or rintl(), same for all the others too). Happens with and without explicitly adding m to the libraries, and whether or not I add /usr/lib or /usr/lib64 (this is a 64b machine). Noteworthy is that I have Anjuta 3.2.2 on the same machine and it compiles the same code and resolves the rintf() et al symbols without any issues. Any thoughts on how to find this problem? As another datapoint, eclipse 3.7 on Ubuntu (another developer's box) compiles the same code without error using all of the same compiler/linker settings. Any suggestions would be welcome...
(In reply to comment #136) This ebuild does not build the CDT. Your report likely does not belong here unless you can show that the CDT is depending on some piece of the core platform that this ebuild is building incorrectly.
(In reply to comment #137) You are correct, it is in CDT (which of course I didn't realize until after I posted this). I am brand-new to Eclipse and quite unsure about its architecture. Given how many marked-unstable packages I unmasked and how many ebuilds I needed to create by hand and stick in my overlay and patches I needed to fetch to get this running, I simply wasn't sure what was going on, and thought you folks might know something. Sorry for any unintended bother. For the record, CDT's symbol indexer seems to be flawed. If I understand it correctly, it cannot reliably index complicated header files (like math.h's) very well. Even though I was (am) getting a stubborn and terrifying errors about unrsolved symbols, these were (are) benign. My code builds fine, runs fine. One is left to examine each error carefully to decide whether the error is real or not. Developers are forecasting a fix for summertime 2012, and they are saying it will be released as CDT 8.1 or 9.0. Nice work on the ebuild though. Obviously not a straightforward one. Very grateful.
Sad to say, but the seden eclipse-3.7.1-r7 ebuild is failing with "ACCESS VIOLATIONS" on my x86_64 system. Will attach emerge --info output and the log file.
Created attachment 312359 [details] output of emerge --info
Created attachment 312361 [details] emerge log file
(In reply to comment #139) Try using the sun-jdk instead of icedtea
@sven Not that I'm making presure or anything ;) but any progress on a 4.2 ebuild?
Just a heads up to everyone following this bug, I created a new one for a "binary" version of eclipse-sdk. bug #424457
(In reply to comment #143) > @sven > Not that I'm making presure or anything ;) but any progress on a 4.2 ebuild? For weeks now I am working 10-12 hours a day on 5 to 6 days. This held me of anything fun lately. Until I saw your comment I didn't even realize that Eclipse 4.x was beyond "alpha stage". :-( So in short: No, I didn't even try, yet.
Sorry, I know this isn't exactly meant to be a support forum, but I'm having trouble accessing any plugin sites from within eclipse-sdk-3.7.1-r7. I've populated the Available Software Sites, but: [1] Install New Software shows nothing available regardless of which site I choose. [2] Check for Updates shows the 3.7.2 update but it also says that the operation cannot be completed because "There were no installable units selected when the plan was computed." :\ Any help would be appreciated, thanks.
Sorry, I should have searched the web some more before I posted that, I found the solution.
is eclipse still maintained by dev-tools or java herd? You guys are still listed in metadata.xml, but the masking message tells me it's unmaintained, that's inconsistent. Either work with proxy-maintainers, request help from other devs or remove yourself from metadata.xml, so other people can pick up the ebuild.
(In reply to comment #148) > is eclipse still maintained by dev-tools or java herd? > > You guys are still listed in metadata.xml, but the masking message tells me > it's unmaintained, that's inconsistent. > > Either work with proxy-maintainers, request help from other devs or remove > yourself from metadata.xml, so other people can pick up the ebuild. I committed to maintain eclipse with the java herd. I'm just waiting for my PC to arrive (for the 2nd time) 'cause it was DOA.
Eclipse 4.2.2 is out.
(In reply to comment #150) > Eclipse 4.2.2 is out. The binaries are, the sources aren't. For Eclipse SDK to be added to the portage tree it needs to be build from source as per the policies, for 4.2.0 there are way too many fixes needed that it is unfeasible to build it from source. I'm not so sure whether that will improve once 4.2.2 is out. http://download.eclipse.org/technology/linuxtools/eclipse-build/4.2.x/ http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.eclipse-build.git/ One Does Not Simply Compile Eclipse. http://thume.ca/2013/03/29/contributing-to-eclipse/
Wow thanks for your very informative comment! Yes that sounds not as great. But here are some people who want to try their luck and want help out for creating a good ebuild. Also if it would be not 4.2.2 but it would be nice to have something newer than 3.7.x Also the binary version of eclipse if totaly painfull for me. I got various memory errors. I have added java and eclipse more memory but that did not work. But eclipse is the best IDE if you want to create android apps like I know. :-(
*** Bug 328739 has been marked as a duplicate of this bug. ***
*** Bug 385467 has been marked as a duplicate of this bug. ***
(In reply to comment #151) > (In reply to comment #150) > > Eclipse 4.2.2 is out. > > The binaries are, the sources aren't. Yes, thank you for the last link especially, interesting stuff. I find the eclipse-sdk-bin ebuild works quite well, but I would be interested in seeing it build from source in the long run. Is there a discussion happening on a mailing list or something about it?
(In reply to comment #155) > Is there a discussion happening on a mailing list or something about it? No, but I'm making progress using a milestone of 4.3, found how to fetch sources so can continue to see how well 4.3 ends up compiling against the Portage tree. Can't do 4.2.2 since some tags of certain plugins have been removed; the organization of those matters isn't so stable, if you wait for too long you can't reproduce the source build. If 4.3 ends up working, it'll end up adding it to the Portage tree; if not, I'll throw it experimentally masked on my dev overlay and / or attach work to the bug.
How is this progressing, 4.3 has been out for a week already?
The combined pain of this bug should give you an estimate of the weeks or months it will take to get 4.3 into portage, if it ever does. ;)
Created attachment 352782 [details] unsatisfied-import-packages.txt Yeah, we need to put together a team to resolve this; too much to resolve alone. > Bundle org.apache.commons.el: > Unsatisfied import package javax.servlet.jsp_[2.0.0,2.1.0). Currently I'm a bit stuck on this one, commons.el expects jsp-api (which I think is from tomcat-servlet-api) to be between 2.0.0 and 2.1.0 whereas Eclipse has a directory that is 2.2.0. If I try to satisfy one I will unsatisfy the other, so I'm not sure which one of both is better; and the code to patch the versions to trick one of both is not yet in place. If anyone wants to help, feel free to let me know; I can then try to host this ebuild somewhere and push as many missing dependencies (~20 or so) as possible to the Portage tree, so we can work together on this.
*** Bug 517288 has been marked as a duplicate of this bug. ***
almost 1 year after last stable release. maybe it time to get a up to date version in portage?
Eclipse 4.5 was released 24 June 2015. See: http://www.eclipse.org/community/eclipse_newsletter/2015/june/article1.php I don't understand why eclipse-sdk is not maintained up-to-date in the portage tree.
I think the dependencies and the build system are too complex? -bin package would be an alternative, but apparently nobody is has enough use for this package to become a tree champion for it.
Hi folks, Just a bit of background: many members of the Gentoo Java team have gone AWOL / retired or for some, their involvement in Gentoo have thinned out. At the moment, there's a lack of manpower in the Gentoo Java team which results in many bugs left behind. Truth to be told, we are 2 actives developers looking after Java-related ebuilds in the tree (Chewi - James Le Cuirot, and myself). Such is life. Feel free to put together draft of ebuilds you'd want to see bumped/updated and we'll be glad to have a look. Thanks!
(In reply to Jean-Claude Repetto from comment #162) > Eclipse 4.5 was released 24 June 2015. See: > http://www.eclipse.org/community/eclipse_newsletter/2015/june/article1.php > > I don't understand why eclipse-sdk is not maintained up-to-date in the > portage tree. Actually I once tried to figure out how to actually build eclipse from source and gave up after a couple of hours. It was not possible for me to find any useful information about that. It it like the Eclipse dev publish open source, that is simply not usable but by them. I know, a java guru with much time and experience *can* figure this out. The two main reasons I was not successful are: a) Lack of java experience (and interest, I use eclipse for perl, c, c++, SQL and XML, but not java) and b) due to that lack of experience I simply have no straight idea where to look. However, I am using Eclipse on a daily basis and outside the tree, by simply downloading the idea installing locally in my user home directory. Which, btw, is what is endorsed by the eclipse devs. At least that is what you get when you go downloading eclipse.
(In reply to Jean-Claude Repetto from comment #162) > Eclipse 4.5 was released 24 June 2015. See: > http://www.eclipse.org/community/eclipse_newsletter/2015/june/article1.php > > I don't understand why eclipse-sdk is not maintained up-to-date in the > portage tree. See comment #159. Got quite far in the build myself; but given the size and complexity, it just takes a ton of time to get it to complete. And as a complete build does not equal a complete product, you can expect issues with the built executable and libraries to take ages to resolve. Given sole dedication to it, a single man can accomplish the build. But to do it properly as well as resolve issues, you'll need to put together a team. Just to give you an idea, Eclipse itself is an ebuild of hundreds of lines and you need to add or update a full tree of tenths of packages to the tree. If someone needs it, I can try to search my work together and put it online. It's been some time and it's a bit complex; so, it even takes quite some search and figuring out work to be able to put it online... :)
Given the amount of work needed, I believe it is clear that this needs both a team effort and ideally also a process that works for the next release again, as well. I have had a look at (what looks like) the direct dependencies of Eclipse, i.e. the non-Eclipse jars I found in the Eclipse 4.5 tarball. For those jars I tried to find existing packages in Gentoo and compared version used (assuming precise match needed) and package in Gentoo as of today. To allow you to edit and extend that data, I made it a table in a dedicated Gentoo wiki page: https://wiki.gentoo.org/wiki/EclipseSDK/BuildingFromSource So far, that only includes direct dependencies. So it may only be a scratch at the surface. If you would like to contribute, you could write ebuilds (for things missing altogeter first, maybe), help discover dependencies of dependencies (and document them at the wiki page), help organizing the effort or review upcoming pull request. Java ebuilds are not trivial so there will be things to learn. I have no idea if this is going to work but we only know if we tried :) For pull requests with ebuilds, I have created this repository: https://github.com/gentoo/eclipse-overlay
(In reply to Sven Eden from comment #165) > > Actually I once tried to figure out how to actually build eclipse from > source and gave up after a couple of hours. It was not possible for me to > find any useful information about that. It it like the Eclipse dev publish > open source, that is simply not usable but by them. > I do not know how you could build the whole Eclipse platform (anyway how would you define the platform, do CDT/JDT also belong into this build or not - questions over questions?) but at least for one of its sub-projects there is information available: Read the "How to contribute) section from https://github.com/eclipse/xtext/blob/master/README.md The basic idea is: You use Eclipse Oomph which sets up the workspace and downloads the individual Eclipse projects (e.g., from GitHub). Anyway you can do this on your own. Then you can start the complete build by jumping to the releng-project and execute the ANT-build file which starts the bootstrapping and building with buckminster and maven (yes, it is that complicated!). Afterwards you find a simple archive-file which can be used as an update-site.
Just a heads up to say that eclipse-sdk has now been removed from the tree as it was ancient, broken, and vulnerable. This doesn't mean it will never be packaged again but there's still a huge mountain to climb. We're not proactively maintaining eclipse-sdk-bin in java-overlay either but feel free to file a pull request to bump it on GitHub.
Newer versions already exist in eclipse-overlay. Not sure if this should stay open or be closed.
(In reply to William L. Thomson Jr. from comment #170) > Newer versions already exist in eclipse-overlay. Not sure if this should > stay open or be closed. Good point brining it up. It got removed from Gentoo it seems (https://github.com/gentoo/gentoo/commit/7911dc7f5600eb64b5ea8bef3a57df7c33b641c6) so there's nothing to bump at the moment, technically. For anyone how may find this ticket, let me repeat the overlay location: https://github.com/gentoo/eclipse-overlay/ Best, Sebastian
It is not my mission, happening as part of packing deps for other java ebuilds. I have packaged a considerable amount of eclipse libraries from source. Likely a fair amount are missing stuff, resources that should be in the jar etc. For like swt, compiling and installing the native parts. This is part of a real effort to package from source. Any of this would need to be done to package eclipse from source. I believe this is the most progress anyone has actually made on packaging eclipse from source. Which again is not what I am interested in, as I use Netbeans. These are necessary ebuilds to build eclipse from source. https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/dev-java
