emerging eclipse-cdt-2.0-r2 fails during the build with: * Building Java code Exception in thread "main" java.lang.NoClassDefFoundError: org/eclipse/core/launcher/Main It seems a few of us are having this problem -- http://forums.gentoo.org/viewtopic.php?t=222073&highlight= I downgraded to eclipse-3.0.0-r3, and that allowed eclipse-cdt to emerge succesfully. I guess the build is looking for eclipse-3 directories, but not 3.1? Reproducible: Always Steps to Reproduce: 1. emerge eclipse-sdk-3.1_pre1.ebuild 2. emerge eclipse-cdt-2.0-r2.ebuild 3. eclipse-cdt breaks immediately on building java files Actual Results: Expected Results: eclipse-cdt should install with eclipse-3.1
For now this ebuild should be limited to the 3.0 release of eclipse. In the ebuild, line 25 and 27, it refers to /usr/lib/eclipse-3. To use this with eclipse 3.1, it needs to be changed to /usr/lib/eclipse-3.1 (which would break the 3.0 release). Also, in the build.xml file, you will have to change line 17 and 53. After doing this it will compile, but I have yet to see the installation work.
I'm not even sure the CDT will work with 3.1. I have updated the CDT ebuild to require 3.0.x, and not accept a 3.1. If anybody wants to submit a patch for the ebuild that allows it to work for 3.1, don't be shy;)
Created attachment 39563 [details, diff] patch to make eclipse-cdt compile against eclipse-3.1
Created attachment 39564 [details] ebuild to make eclipse-cdt compile against eclipse-3.1 This ebuild will only work against eclipse-3.1.
Sorry about the "bad" submit. The first patch is supposed to be called "00-eclipse-3.1.patch" and be placed under eclipse-cdt/files/ catalog in portage. Also you will have to place the new ebuild in parallel with the old one. Since eclipse 3.0 and 3.1 can be installed at the same time, I don't see a easy way of selecting which one the eclipse-cdt package shall be installed to. What if the user wants to install the packages to both versions?
*** Bug 64515 has been marked as a duplicate of this bug. ***
This is marked RESOLVED FIXED, but from the comments it appears that neither status is correct. Or am I missing something? -Mike
As there is now patch here, the bug should be reopened.
Mine.
Created attachment 43235 [details] patch Someone who has gotten eclipse-3.1* to compile please test this. This should make the eclipse-cdt ebuild less version dependant. This should also fix for bug #65358, which is a similar bug relating to eclipse 3.0.1. (don't mind the ~amd64 addition, but add it if you feel like it =D I have done some testing on my main box with eclipse 3.0.1-r1 with good results).
Tried the ebuild. Patch failed so I did it manually (didn't seem to line up right), and the ebuild is fine. Build.xml still blows up, has issues with the plugins versioning during Java build stage, ie "/var/tmp/portage/eclipse-cdt-2.0-r2/work/eclipse-cdt-2.0/build.xml:59: Basedir /var/tmp/portage/eclipse-cdt-2.0-r2/work/eclipse-cdt-2.0/results/eclipse-copy/plugins/org.eclipse.pde.build_3.1_pre3/scripts does not exist"
Nerdboy kindly requested that dev-tools take over all eclipse stuff.
In case anybody is wondering, the work which needs to be done to this project is at least the following: 1) A complete snapshot must be made at the same date of a particular CDT release. AFAIK, they still don't tag their CVS properly, so it's quite difficult to find the exactly correct CVS snapshot. 2) The build.xml file and all supporing .xml files must be patched to take one build.properties (or perhaps a gentoo.properties file as their property file. Particularly the sed magic we currently do to the build.xml file will not work. 3) In the gentoo.properties, the ebuild should generate relevant versions for all required eclipse packages, such as org.eclipse.ui, etc.
eclipse-cdt is package.mask'd, pending removal.
