Hi, some _nice_ things I'd like to propose (in short): - move eclipse-stuff to /dev/eclipse in portage tree - get those several additional plugins which are into portage tree as ebuilds (so people don't have to collect them) Reproducible: Always Steps to Reproduce: Actual Results: Expected Results: cleaned up portage-tree easy-to-find plugins ;) for questions feel free to contact me ;)
Here are some more suggestions: -eclipse virtual(s) core/platform (eclipse core without which nothing is possible) is provided by eclipse-platform-bin AND eclipse-SDK PDE (eclipse Plugin Development Environment) is provided by eclipse-SDK (and should also be available via eclipse-pde-bin that does not exist) JDT (Java Development Tools) is provided by eclipse-jdt-bin AND eclipse-SDK CDT (C/C++ Development Tools) is provided by eclipse-cdt-bin AND eclipse-SDK However the plugins require eclipse-platform-bin, which is not required if eclipse-SDK was installed. There are several other eclipse related issues/suggestions (i.e. <a href="http://bugs.gentoo.org/show_bug.cgi?id=18754>18754</a>, <a href="http://bugs.gentoo.org/show_bug.cgi?id=19317>19317</a>, and <a href="http://bugs.gentoo.org/show_bug.cgi?id=20740>20740</a>)
(oops...looks like I didn't read bugzilla docs on creating bug links) Another question/comment: Why are all the eclipse ebuilds marked with SLOT="2"?
think we need some tweaks here as you said.
All current eclipse ebuilds are SLOT="2"ed, because plugins are not compatible between eclipse 1.x and 2.x. If plugin compatibility breaks between 2.x and 3.x, we'll add SLOT="3" to the 3.x platform and plugins. The dev-eclipse category is probably worthwhile soon. In general, we don't like to create a new category until we have in the order of 10+ packages to populate it with. As for the -bin packages, we are probably going to phase them out. Building eclipse from scratch doesn't seem to take any longer than building mozilla from scratch, _AND_ we're going to provide GRP (Gentoo Reference Platform) packages for it (ie, prebuilt binaries) anyway.
So one thing I'm not clear on - should I *NOT* be using the Update Manager built into eclipse to bring things in? For example, here I am, brand new to eclipse, with eclipse 2.1 -bin just in off the ebuild. I'm following instructions and get told to use the Update Manager. It, in turn, offers me an update to "Linux-GTK 2.1.2" . That sounds great, except that isn't that why we have portage? [I'm not knocking the devs here - they have plenty to do - just trying to figure out where I'm supposed to be] P.S. Actually, the scenario above didn't work because of bug #21380.
-Should have a consistent install location or have the plugins that are available through portage install to the proper places (IE: cdt/ftp wont install to the right place if I install the eclipse-sdk, but does with eclipse-platform-bin.. Neither does JDT but his only matters for people who are building plugins since -sdk installs it). -if -bin is being phased out then this makes sense. -Some of the dependancies need to be fixed if -bin is getting phased out, ftp webdav depending on 2.0* and jdt depending on 2.1* makes a mess and will install platform even if -sdk is installed -Last little thing is that the ~86 flag should be taken off some of the newer builds since they're more stable than the 2.0.2 build.
The phasing out of the -bin packages has taken far too long already, but I'll hack on it in the coming weeks. I'm trying to coordinate with the debian people wrt the update manager, as we have the same problem: we prefer people install packages available in portage instead of from the update manager. However, as we'll never be able to package all eclipse plugins in a timely fashion, we'll have to support the update manager somehow. I think at least each user (or a group of users) should be able to install their own plugins, but that these plugins will never overwrite what the sysadm has already installed. We'll probably need a plugin dir in $HOME and one in /usr/lib/eclipse.
Some things take a lot of time. Some things never finish. Then there's packaging eclipse, which just takes forever. Anyway, here's the current low-down on the plugin front: 1) With 2.1.3 and 3.0.0, we now have their update managers working (to the extent that these actually work) 2) After having started a new workspace, users can download and install new updates using the build-in update manager to any directory he has write access to; plugins will then be available on a per-workspace basis. 3) We may want to create a default per-user plugin directory, say $HOME/.eclipse-plugins-${SLOT}, that's hard-wired as an available plugin site in the platform itself. This allows for per-user plugins, across workspaces. 4) Ebuilds will install plugins compiled from source into /usr/lib/eclipse-plugins/${SLOT} or /usr/lib/eclipse-${SLOT}/extra (haven't decided). 5) Ebuilds will install binary-only plugins into /opt/eclipse-${SLOT}/extra or /opt/eclipse-plugins/${SLOT} Additionally, we may need some provision for site plugins, but that's probably something that will need to be configured on a per-site basis anyway, so I'm waiting with that until I get more experience with this scenario.
This is more or less done now, I should just write some documentation for it..
I think we're finally there, now.
