(no subject) [message #692962] |
Tue, 05 July 2011 14:44 |
Eclipse User |
|
|
|
Originally posted by: Mark Carroll
With a project depending on json-lib 2.2.3 I get errors in Eclipse
(Helios) about,
The type groovy.lang.Closure cannot be resolved. It is indirectly
referenced from required .class files
This is probably because net.sf.json.groovy.JsonGroovyBuilder uses some
Groovy classes but json-lib doesn't include them in the JAR; the Eclipse
errors go away if I make the project depend on Groovy.
We don't actually use JsonGroovyBuilder in any way, nor Groovy, so our
project builds and works just fine without dragging in this Groovy
dependency. We just use JSONObject and JSONArray. Is there some
annotation or something that I can use in the class files with the error
to suppress it?
Mark
--
Mark Carroll | Vecna Technologies, Inc. | http://www.vecna.com/
|
|
|
|
Re: (no subject) [message #693932 is a reply to message #693381] |
Thu, 07 July 2011 13:48 |
Eclipse User |
|
|
|
Originally posted by: Mark Carroll
Satyam Kandula wrote:
> This likely happens if the class file you depend on refers to the other
> library. For eg: If your class is depending on class named 'ClassA' from
> a library 'LibA.jar', and this 'ClassA' is depending on 'ClassB' from a
> library 'LibB.jar', JDT may need LibB.jar in the path to get all the
> signatures of methods and fields of 'ClassA'. If this is not the case
> that you are running into, please file a bug.
Yes, this is the case that I am running into. I don't want the LibB.jar
in the path because I know that the little I am using from LibA.jar will
not actually use LibB.jar at all. So I just want to be able to suppress
that error from Eclipse, manually on case-by-case basis. Perhaps it's
not possible?
Mark
--
Mark Carroll | Vecna Technologies, Inc. | http://www.vecna.com/
|
|
|
|
|
Re: (no subject) [message #694390 is a reply to message #693944] |
Fri, 08 July 2011 13:25 |
Eclipse User |
|
|
|
Originally posted by: Mark Carroll
forums-noreply@eclipse.org wrote:
> You will have to include the LibB.jar file in your path at run time as
> well. If you reference a class in LibA that references a class in LibB,
> then the run time class loader will need to have the LibB class
> available at runtime. If it isn't available, you will receive a
> NoClassDefFound exception when attempting to load the class from LibA.
No, I won't have to include it. As I already said, the app runs fine
because its usage of LibA is so minimal it never gets near anything
related to LibB, which is only used in certain situations that aren't
relevant to us. So I just want to suppress the error rather than have to
include a large JAR that I know will never need any classes loaded.
Mark
--
Mark Carroll | Vecna Technologies, Inc. | http://www.vecna.com/
|
|
|
Powered by
FUDForum. Page generated in 0.02454 seconds