F9: Eclipse problems found
by Dan Thurman
I noticed errors showing up with Eclipse on F9.
I checked and verified the claims as to missing components and they are
missing.
I did not attempt to try and reinstall eclipse from past experience in
that it never worked
and want to wait until someone responds and tells me what to do. It
seems that there are
problems trying to install other components (Software Updates) such as
BIRT (missing
required components from which I could not find to resolve), Mylin,
PyDev and so on
as I also wanted to wait to get the core Eclipse fixed before
continuing. PyDev in
particular was hanging every time, at random places, during downloads so
I never
made it past that point. Downloading from Europa Discovery Site was no
problem
and made it all the way through to installation with no errors.
Following is what shows up in: Help->Software Updates->Manage Configuration
=============
/usr/share/Eclipse
=============
+ Eclipse C/C++ Development Tools 4.0.3 200804041441
Plug-in "org.eclipse.cdt.core.linux.x86" version "4.0.0.200804041441"
referenced by this feature is missing.
+ Eclipse C/C++ Development Tools SDK 4.0.3 200804041441
Included feature "Eclipse C/C++ Development Tooling Source" version
"4.0.3.200804041441" contains problems.
+ Eclipse Project SDK 3.3.3r33x_r20080120-7M7J7LB-u3aphGW6o3_VmiVfGXWO
Included feature "Eclipse Platform" version
"3.3.3.r33x_r20080129-_19UEl7Ezk_gXF1kouft" contains problems.
Included feature "Eclipse Platform Plug-in Developer Resources" version
"3.3.3.r33x_r20080129-_19UEl7Ezk_gXF1kouft" contains problems.
Included feature "Eclipse Java Development Tools" version
"3.3.2.r33x_r20080129-7o7jE7_EDhYDiyVEnjb1pFd7ZGD7" contains problems.
Included feature "Eclipse JDT Plug-in Developer Resources" version
"3.3.2.r33x_r20080129-7o7jE7_EDhYDiyVEnjb1pFd7ZGD7" contains problems.
Included feature "Eclipse Plug-in Development Environment" version
"3.3.3.r33x_r20080129-7N7M5DQVIA_6oJsEFkEL" contains problems.
+ Fedora Eclipse Feature 1.0.0
Plug-in "org.fedoraproject.ide.platform" version "0.0.0" referenced by
this feature is missing.
+ Graphical Editing Framework SDK 3.3.0 200802201606
The feature is disabled.
(Replaced by Graphical Editing Framework SDK 3.3.2.v20080129)
+ SETools 3.3.2.4
Plug-in "com.tresys.setools.linux.x86" version "3.3.2" referenced by
this feature is missing.
===========
/usr/lib/eclipse
===========
+ Eclipse RCP 3.3.3.r33x_r20080129-8y8eE9UEUWI6qyjeED)xT7bc
Plug-in "com.ibm.icu" version "3.6.1.v20070906" referenced by this
feature is missing.
Plug-in "org.eclipse.core.commands" version "3.3.0.I20070605-0010"
referenced by this feature is missing.
Plug-in "org.eclipse.core.databinding" version "1.0.1.M20070822-0800"
referenced by this feature is missing.
Plug-in "org.eclipse.core.databinding.beans" version
"1.0.1.M20070910-0800b" referenced by this feature is missing.
Plug-in "org.eclipse.core.jobs" version "3.3.1.R33x_v20070709"
referenced by this feature is missing.
Plug-in "org.eclipse.core.expressions" version "3.3.0.v20070606-0010"
referenced by this feature is missing.
Plug-in "org.eclipse.core.runtime" version "3.3.100.v20070530"
referenced by this feature is missing.
Plug-in "org.eclipse.core.runtime.compatibility.auth" version
"3.2.100.v20070502" referenced by this feature is missing.
Plug-in "org.eclipse.osgi" version "3.3.2.R33x_v20080105" referenced by
this feature is missing.
Plug-in "org.eclipse.help" version "3.3.2.v20071126_33x" referenced by
this feature is missing.
Plug-in "org.eclipse.swt" version "3.3.2.v3349d" referenced by this
feature is missing.
Plug-in "org.eclipse.jface" version "3.3.2.M20080207-0800" referenced by
this feature is missing.
Plug-in "org.eclipse.jface.databinding" version "1.1.1.M20080207-0800"
referenced by this feature is missing.
Plug-in "org.eclipse.ui" version "3.3.1.M20071128-0800" referenced by
this feature is missing.
Plug-in "org.eclipse.ui.workbench" version "3.3.2.M20080207-0800"
referenced by this feature is missing.
Plug-in "org.eclipse.update.configurator" version
"3.2.101.R33x_v20070810" referenced by this feature is missing.
Plug-in "org.eclipse.rcp" version "3.2.1.r33x_r20080131" referenced by
this feature is missing.
Plug-in "org.eclipse.core.contenttype" version "3.2.100.v20070319"
referenced by this feature is missing.
Plug-in "org.eclipse.equinox.app" version "1.0.1.R33x_v20070828"
referenced by this feature is missing.
Plug-in "org.eclipse.equinox.common" version "3.3.0.v20070426"
referenced by this feature is missing.
Plug-in "org.eclipse.equinox.preferences" version
"3.2.101.R33x_v20080117" referenced by this feature is missing.
Plug-in "org.eclipse.equinox.registry" version "3.3.1.R33x_v20070802"
referenced by this feature is missing.
Plug-in "org.eclipse.equinox.launcher" version "1.0.1.R33x_v20080118"
referenced by this feature is missing.
15 years, 3 months
pdebuild messages
by Orion Poplawski
Are these anything to worry about?
+ /usr/lib/eclipse/buildscripts/pdebuild -d cdt -f
org.eclipse.photran_feature -a '-Djavac
Source=1.5 -DjavacTarget=1.5'
mkdir -p
/builddir/build/BUILD/org.eclipse.photran-v20080808_4_0_0_Beta4/build
mkdir -p
/builddir/build/BUILD/org.eclipse.photran-v20080808_4_0_0_Beta4/build/home
Building feature = org.eclipse.photran_feature.
Symlinking SDK and "cdt" into
/builddir/build/BUILD/org.eclipse.photran-v20080808_4_0_0_Be
ta4/build/SDK directory.
/bin/sh /usr/lib/eclipse/buildscripts/copy-platform
/builddir/build/BUILD/org.eclipse.phot
ran-v20080808_4_0_0_Beta4/build/SDK /usr/lib/eclipse cdt
ls: cannot access plugins/*cdt*: No such file or directory
ls: cannot access features/*cdt*: No such file or directory
ls: cannot access *cdt*: No such file or directory
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
15 years, 3 months
Help with photran eclipse feature
by Orion Poplawski
I'm pretty close to getting the Eclipse Photran package ready for
Eclipse 3.4. However, I'm having some trouble packaging it up.
It seems to contain four "features", and I'm building them with:
for feature in org.eclipse.photran_feature org.eclipse.photran.intel \
org.eclipse.photran.vpg_feature
org.eclipse.photran.xlf_feature
do
%{eclipse_base}/buildscripts/pdebuild -d cdt \
-f $feature -a "-DjavacSource=1.5 -DjavacTarget=1.5"
done
Now the issue seems to be how/where to install. Each of the zip files
created starts with the directory "eclipse/" and 3 contain
"eclipse/contents.xml" files (which are different) so I don't think they
should unzip into the same directory. What makes sense?
Some more zip file details:
Archive: org.eclipse.photran_feature.zip
testing: eclipse/ OK
testing: eclipse/plugins/ OK
testing: eclipse/plugins/org.eclipse.photran.ui_4.0.4/ OK
..
testing:
eclipse/plugins/org.eclipse.photran.managedbuilder.gnu.ui_4.0.4.jar OK
testing:
eclipse/plugins/org.eclipse.photran.managedbuilder.ui_4.0.4/ OK
..
testing: eclipse/plugins/org.eclipse.photran.core_4.0.4/ OK
testing: eclipse/plugins/org.eclipse.photran.core_4.0.4/META-INF/ OK
testing:
eclipse/plugins/org.eclipse.photran.core_4.0.4/META-INF/MANIFEST.MF OK
testing:
eclipse/plugins/org.eclipse.photran.core_4.0.4/photrancore.jar OK
testing:
eclipse/plugins/org.eclipse.photran.core_4.0.4/plugin.properties OK
testing: eclipse/plugins/org.eclipse.photran.core_4.0.4/plugin.xml OK
testing: eclipse/plugins/org.eclipse.photran.core_4.0.4/about.html OK
testing: eclipse/content.xml OK
testing: eclipse/features/ OK
testing: eclipse/features/org.eclipse.photran_feature_4.0.4/ OK
testing:
eclipse/features/org.eclipse.photran_feature_4.0.4/license.html OK
testing:
eclipse/features/org.eclipse.photran_feature_4.0.4/feature.xml OK
testing:
eclipse/features/org.eclipse.photran_feature_4.0.4/epl-v10.html OK
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
15 years, 3 months
Building a package that uses Maven and depends on other libraries
by Mary Ellen Foster
I've embarked on a quest to package JabRef for Fedora
(http://jabref.sourceforge.net/). It has an annoying number of
dependencies, but the one I'm stuck on right now is "spin"
(http://spin.sourceforge.net/). This in turn depends on cglib
(http://cglib.sourceforge.net), which is easy to package and I've got
a version already at
http://mef.fedorapeople.org/cglib/
(haven't put it up for review yet because I want to try to get
everything complete).
The problem now is: spin is built with maven, about which I know just
about nothing. I've managed to install the required maven plugins
(compiler, assembler, etc), but how do I point maven at my cglib jar
file in /usr/share/java? The relevant part of the pom.xml file looks
like this:
<dependency>
<groupId>cglib</groupId>
<artifactId>cglib-nodep</artifactId>
<version>2.1_3</version>
<optional>true</optional>
</dependency>
I've tried making the obvious edits -- changing cglib-nodep to cglib
and version to 2.2 to agree with the cglib RPM -- but mv-jpp still
persists in not finding it when I try to build. What's the magic
trick? Is it documented in the wiki anywhere that I've missed?
Thanks for any help,
MEF
--
Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/
Informatik 6: Robotics and Embedded Systems, Technische Universität München
and ICCS, School of Informatics, University of Edinburgh
15 years, 3 months
Adding an "asm3" package
by Mary Ellen Foster
In Fedora at the moment, there's an "asm2" package
(asm2-2.2.3-2jpp.1.fc9.noarch). ASM was actually upgraded to version 3
quite a while ago (see http://asm.objectweb.org/), and the current
version is 3.1. A package I'd like to submit to Fedora appears to
(indirectly) depend on asm version 3. I'm wondering how to proceed ...
why is the current package called "asm2" rather than just "asm"? Does
this mean we need an "asm3" package now too, or is it possible to just
create an "asm" package with the correct versioning.
I've made a first stab at creating an "asm3" package based on the
current asm2 one; it can be seen here:
http://mef.fedorapeople.org/packages/asm3/
How should I proceed from here?
Thanks,
MEF
--
Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/
Informatik 6: Robotics and Embedded Systems, Technische Universität München
and ICCS, School of Informatics, University of Edinburgh
15 years, 3 months
Eclipse 3.4
by Andrew Overholt
Hi,
I've finally got version 3.4 of the Eclipse SDK ready to go, targetting
Fedora 10:
http://koji.fedoraproject.org/koji/buildinfo?buildID=58121
(See [1] for an in-progress build with some minor fixes.)
Action item for plugin package maintainers:
-------------------------------------------
Please look at the relevant attached patches and apply them or something
like them in the devel directory of your plugin(s). Feel free to commit
and tag but note that you won't be able to build until I tag the build
for rawhide.
Email me personally if you have questions. Please also let me know when
you're finished and I can do koji builds of everything in the right
order (chain-build or otherwise). I'd like to do this very soon so
please take a few minutes to apply the changes.
Testing of the above build is greatly appreciated.
-------------------------------------------
There are a few minor changes for packagers of plugins/features:
- Bits are now installed to %{_libdir}/eclipse instead of
%{_datadir}/eclipse. This brings us in line with upstream's file layout
and avoids the crazy split-install osgi.sharedConfiguration.area hack.
It's also what Debian does, FWIW.
- p2 is the new provisioning platform in 3.4. Essentially it replaces the
old update manager but does other things as well. It requires
Eclipse-based apps to use profiles -- like Mozilla profiles -- and manage
them using its "director". In order to avoid fragile %post scriptlets,
we're going to use the "dropins mechanism" for plugin installation. This
means that all non-Eclipse platform plugins will be installed into their
own directory under %{_libdir}/eclipse/dropins. There are a variety of
layouts that are acceptable to p2, but we'll largely be going with
dropins/eclipse/<short name>/{plugins,features}. This has the nice side
benefit of simplifying %files sections :) . See [2] for more
information here.
- I added a flag to the pdebuild script to allow for Orbit-style
dependencies. If you don't know what this means, that's okay, but if
a plugin you want to package uses Orbit dependencies, you'll want to
use the -o flag to pdebuild. Plugins that use non-Eclipse JARs but
don't have a lib directory with JARs are probably using Orbit-style
dependencies. They'll have Require-Bundle or Import-Package entries
in their plugin MANIFEST.MFs. See eclipse-mylyn for an example of how
to use pdebuild in this case.
- I've renamed (and Obsoleted/Provided) libswt3-gtk2 to eclipse-swt. I
can't count the number of times people have been confused by this
naming and since we're not going to ship swt2 or swt.motif any time
soon, the naming is silly. I also folded pde-runtime into pde since
PHPEclipse no longer needs the separate pde-runtime package.
Outside of the CDT and the SELinux tools (both maintainers are working on
the necessary changes themselves), I've got patches for all of the plugins
we have as packages in Fedora. I've attached these patches and CC'd all of
the maintainers.
I will update the packaging guidelines very soon with the above
information.
Thanks,
Andrew
[1]
Build with branding fixed and removing some unnecessary Requires(post)
and the pde-runtime package which is now folded into pde:
http://koji.fedoraproject.org/koji/taskinfo?taskID=750696
[2]
There are some performance considerations here. Since it's generating
the associated metadata and "provisioning" the bits on the fly based on
files dropped into a directory, users may notice a slightly longer
startup the first time they start the Eclipse IDE after installing a new
plugin package. Subsequent startups won't be impacted. There is a lot
of performance improvement work going on upstream and much of it will
land in 3.4.1. If 3.4.1 is released early enough, we'll ship it in
Fedora 10. If not, we can ship it as an update. Should testing between
now and Fedora 10 show unacceptably poor performance (I haven't noticed
this in my own testing), we can look at back-porting some of the
performance work. The other main way of speeding up dropins-installed
plugins is by shipping pre-generated p2 metadata (like yum metadata).
I've experimented with this and think I can make it so that we
transparently generate it via pdebuild meaning it would only require a
rebuild of Fedora plugin packages. Things will work without these
generated content.xml files so in the interest of getting testing sooner
rather than later, I'm going to push ahead without the metadata for
dropins.
15 years, 4 months