Community
Participate
Working Groups
Build Identifier: M20100909-0800 In my project I'm getting: "The type javax.el.ValueExpression cannot be resolved. It is indirectly referenced from required .class files". With ant or plain javac I can compile this file using the same classpath. There're many similar tickets here, most are "fixed". Applied the patch from bug 281848 , but nothing changed Reproducible: Always Steps to Reproduce: 1. Import attached project to eclipse
Created attachment 181116 [details] test case
The problem is reported while looking at inherited methods. Srikanth, would it be possible to bypass the hierarchy check once we end up inside binary types ? On the other hand, with the current classpath, even if javac can compile the code, if you add a main method to C, the code doesn't run. Exception in thread "main" java.lang.NoClassDefFoundError: javax/el/ELException Caused by: java.lang.ClassNotFoundException: javax.el.ELException at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) Could not find the main class: org.foo.C. Program will exit.
In this case the missing classes are provided by jboss/
(In reply to comment #3) > In this case the missing classes are provided by jboss/ Does this comment mean that you are able to run the program as opposed to Olivier's observation in comment# 2 ?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
I'd like to reopen this as it is very annoying and requires PDE users to manually craft Manifests with useless imports. As an example one can use 1) go to org.eclipse.equinox.p2.artifact.repository 2) open the maninfest > dependecies > find unused dependecies 3) PDE will suggest (among others) to remove 'org.osgi.service.prefs' as it is never used 4) now ArtifactRepositoryManager will complain about "The type org.osgi.service.prefs.Preferences cannot be resolved. It is indirectly referenced from required .class files" This is cause by extending the class AbstractRepositoryManager that (internally) uses classes from org.osgi.service.prefs To resolve this, one needs to add the import back even though it is never used. Maybe this is not JDT fault but PDE is doing something wrong, in this case I would need some information fro the JDT team what is causing this in this situation, as from an OSGi perspective there is nothing wrong as far as I can tell as the package org.osgi.service.prefs is imported correctly by the org.eclipse.equinox.p2.repository bundle. The only thing one might complain about is a missing use-clause on the export of package as AbstractRepositoryManager#putValue references the org.osgi.service.prefs.Preferences in a protected method, but adding those use-clause do not solve the issue here.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
