Hi, On Tue, 2006-01-10 at 09:00 -0800, Daniel B. Thurman wrote: > Problem here is that when one wants to install a 'feature', then > in most cases these are installed in the features and plugins folders, An Eclipse feature is a collection of Eclipse plugins. > and other places - so what is not clear - is if there is any "dangers" > in doing this - in cases where it *might be possible* to overlay the > files that are FCX ports. Now I'm confused :) What do you mean? > >I personally don't have time to test the many plugins out there and I > >would appreciate your feedback about WTP and others. Please let us know > >if there are issues that you find and report them at > >http://bugzilla.redhat.com. > > Yes, I have obviously complained and I am not the only one clearly, > but probably a loud grumbler than most. Some have cussed me out - > but I am sure you understand that I am doing my bit of 'reporting' > but hopefully with something of value to you/fedora. :) > Will you/redhat-buzilla be the front-end for all Eclipse-FC4 > issues if we submit a bug there? Should we report Eclipse errors in > the Eclipse bugzilla instead? Perhaps you can clarify this? Submit everything to RH Bugzilla. If it's an upstream issue, we can always move it there. It's probably best if we figure out what's causing a problem first before moving distro-specific issues upstream. > As for the Eclipse-FC4 - perhaps you can reduce the confusion > by posting the differences between Eclipse stock and FC port I explained in another email what the runtime differences are. In terms of what patches we have, you can look in the specfile that I gave the CVS link for. Most are build patches, but here are the more notable ones: eclipse-efj: Adds the command-line source code formatter eclipse-gnuformatter*: Adds a GNU style to the default formatters eclipse-updatehomedir*: Allows for installation in ~/.eclipse using the update manager. eclipse-tomcat5*: Uses the system tomcat for the help system. eclipse-compare-create-api: Allows the Bugzilla plugin to apply patches that are attached to bugs. As you can see, what you refer to as the "FC port" isn't that different from what is released upstream. All we do is take the buildable src zip from upstream and build it. > and maybe explain the Do's and Don'ts when attempting to install > stuff from the Eclipse project files? Is there a reference to > this anywhere? There is no such list :) AFAIK there are no "dos and don'ts". If something doesn't work, we can try to fix it. > The most recent update (I believe taken from jpackage) blew > my eclipse out of the water This is an issue with all of our java packages. Our specfiles are mostly derived from JPackage ones with changes going both ways between them and ours containing the native-compilation bits. I'm actually surprised that your latest update came from JPackage. I would have thought that your problem was due to our latest FC update which has this issue: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177210 There is no hard-and-fast rule about what to take from JPackage and what to take from FC. If you have ideas in this area, it would be cool to discuss them on fedora-devel-java-list. > Anyway, to recover from a corrupted eclipse, I did the following: > > 1) yum groupremove eclipse > [...] > This seems to be the only way to get the un/installation of eclipse > to work right. Geez. I don't believe you should have needed to do this. The groupinstall mechanism just uses groups from comps.xml which is used for anaconda's groups. > I also wanted to point out something curious - I note that if I used > the Eclipse update facility - as a non-root user - it *appears* to work > but the minute that I become a *differet user* or a root user - it appears > as if the update is not there - or accessable - and for the fun of it - Yes, that's because the update manager is installing things in ~/.eclipse which is only accessible by the user that installed it. System-wide installation of non-RPMd plugins is a bit of an uncharted territory at this point. There's always the unzip in /usr/share option, but then those files aren't RPM-managed. It's an issue we're actively trying to fix. > If I encounter anything else I will squawk and you can come to the rescue ;-) > Thats all for now. Cool. Take care, Andrew
