I have a Groovy script in Eclipse and I get the following at the import statement:
Groovy:unable to resolve class org.apache.commons.lang.time.DateFormatUtils
When I add the external commons-lang-2.4.jar to the Libraries in the build path, the error message goes away. But if I remove it and instead add the external Class Folder that contains this and other jars, then I get the error message.
Try adding the jar by navigating to Preferences->Java Build Path->Libraries and using add External JARs. I don't believe Eclipse will pick up the various jar files in a folder for compilation - you may need to be explicit with each JAR, and I don't think it supports wildcards for those as command-line javac does these days. (See aspects of this answer for some treatment of this, and a potentially interesting plugin).
Related
I have following import in my class
import org.apache.commons.lang.exception.ExceptionUtils;
ExceptionUtils is indeed referenced in my class.
JOptionPane.showMessageDialog(this, "An Server Error occured during saving.\n\n" + ExceptionUtils.getStackTrace(e), "Error",**
But in the classpath i have package org.apache.commons.lang3
I am really not sure how this runs and why there are no errors?
I am using Eclipse Indigo
Please advice.
It sounds like your Apache Commons Lang .jar file satisfies your org.apache.commons.lang.exception.ExceptionUtils import.
Look here:
http://www.java2s.com/Code/Jar/a/Downloadapachecommonslangjar.htm
STRONG SUGGESTION:
Take a look inside of your .jar file. One easy way to do this is with a tool like 7-Zip, or jd-gui. Another way is to temporarily rename the file from .jar to .zip, and look at its contents in Windows Explorer.
This will show you the packages (directories and subdirectories) and classes inside of the .jar.
Interesting stuff - try it sometime!
I have a few projects which run using Jython 2.7b1 where I add the jars (in fact all the jars in a directory) by doing this:
set CLASSPATH=.;"%SYSADMIN%\resources\java jar files/*"
set JYTHONPATH=...
C:\jython2.7b1\jython myproj\__main__.py
But my latest project is using 2.7.0FR and this "set CLASSPATH" approach doesn't seem to work. I then tried this:
D:\apps\jython2.7.0\bin\jython -Dpython.path="%SYSADMIN%\resources\java jar files/*" my_latest_proj\__main__.py
... but it didn't work. Then I wanted to see whether I could load an individual .jar:
D:\apps\jython2.7.0\bin\jython -Dpython.path="%SYSADMIN%\resources\java jar files\lucene-analyzers-common-4.6.0.jar" my_latest_proj\__main__.py
This didn't work either: the following line
from org.apache.lucene.analysis.fr import FrenchAnalyzer
leads to the following error: "No module named apache"... nor is there any "unpacking" of the jar as you typically see with Jython the first time you use a jar.
Finally I tried this:
set CLASSPATH=.;"%SYSADMIN%\resources\java jar files\lucene-analyzers-common-4.6.0.jar"
... same thing: "No module named apache"
NB I have no trouble getting jars to work from within my project when running it under Eclipse.
Can anyone tell me what I'm doing wrong?
Aha...!
1) It appears that with Jython2.7.0FR you have to use forward slashes in paths in the CLASSPATH, even in a Windows OS. This appears to be a change relative to 2.7b1...
2) I also seem to find that paths with spaces are to be avoided... previously I could enclose such a path in quotes and it would work OK. This seems not to work any more.
Any comments from the Jython "High Command" would be welcome...
I'm trying to compile the javadocs for my application, and for some reason it throws errors while compiling like this:
/Users/Sander/.gradle/caches/artifacts-23/filestore/com.google.gwt/gwt-user/2.4.0/jar/949dcb5d14cb0e2c8dec98efc0760be68753c124/gwt-user-2.4.0.jar(com/google/gwt/dom/client/CanvasElement.java):18: error: cannot access Context
import com.google.gwt.canvas.dom.client.Context;
All the errors thrown are found in gwt-user-2.4.0.jar. Basically, what (I think) it's trying to do is compile the .java source files the jar file contains, which it shouldn't do. Is there a way to make the javadoc command ignore java source files?
I've tried removing the source files from the jar manually, this way the build succeeds. However, since the jar is a gradle dependency, manually altering the file is not an option.
I finally got it to work. As it turned out, the javadoc command needed a sourcepath flag set, because otherwise it would start looking for the source files in the classpath, which contained some source files from the GWT jar file. Since the MinimalJavaDocOptions GWT class doesn't support this, I had to set it manually by adding the following line:
options.addStringOption("sourcepath", <path_to_source>)
This fixed the problem. Obviously it is not ideal, a topic in the Gradle Support Forums has already been created, see http://forums.gradle.org/gradle/topics/allow_javadoc_sourcepath_to_be_set_directly
I have an eclipse plug-in working fine within eclipse environment.
I wanted to export it into a jar file, so I chose Export > Deployable plug-ins and fragments.
I could get a jar file, but an error was reported.
Opening the log file, it reports that I have 1242 problems (191 errors, 1051 warnings). This is some copy from the error log.
2. ERROR in /Users/LSclipse/src/lsclipse/LSDiffRunner.java (at line 61)
import edu.washington.cs.induction.OnePipeLineScript;
^^^
The import edu cannot be resolved
----------
3. ERROR in /Users/LSclipse/src/lsclipse/LSDiffRunner.java (at line 261)
OnePipeLineScript.getMatchingForRefFinder(projName, proj1, proj1Loc
^^^^^^^^^^^^^^^^^
OnePipeLineScript cannot be resolved
Why I got errors? I had 2049 warnings, but no error when I compile the plugin in eclipse IDE.
ADDED
The main project references two other projects, and references many external libraries. I attach the package view and Java build path.
There were multiple issues involved for this problem. However, the core issue was that the project apimatching and originanalysis were not eclipse plugins but just java projects. As a result, those two projects were not included in the final jar file to break the build.
Symbolic linking the two projects into the main project
I solved this issue by symbolic link the src directory into the main eclipse plugin project.
ln -s /workspace/seal/edu.ucsc.originanalysis/src /LSclipse/originanalysis
ln -s /workspace/seal/edu.ucsc.apimatching/src /LSclipse/apimatching
From the Java Build Path/Source tab, I added those two included projects as source. Eclipse Java Missing required source folder: 'src'
Now I have eclipse plugin jar file without error.
Then click F-5 to refresh the project explorer and check they are java src directory.
Select the included projects in Build tab.
Updating bin.include and source.. in build.properties tab is important. One should understand that in bin.include the ordering is also critical. lib/cdtparser.jar and lib/cdtcore.jar should be placed prior to the user of them - origin analysis/.
Copying jar files for included project into main project
I also had to copy some jar files in those projects file into the main project, and select them in Binary Build tab.
And add tim in Runtime/Classpath tab.
Select the JavaSE-1.6 in Execution Environments.
I have lots of "Must Override a Superclass Method" errors. With the hint from this post - 'Must Override a Superclass Method' Errors after importing a project into Eclipse , I removed the J2SE-1.5 to resolve this issue.
You can not add third party libraries into class path of Java when developing a plug-in. It is the way to build standard Java application, but plug-in is a kind of OSGi bundle that has itself rule for class loading.
The correct way is adding third party libraries into the class path of your plug-in.
Add below declaration into MANIFEST.MF of your plug-in,
Bundle-ClassPath: lib/log4j-1.2.7.jar,
xml-apis.jar,
...
Check those links [1], [2] for understanding it.
This is what have a question on and see as potential solutions to potential problems.
Is this class comfing from a referenced jar or is it in the actual plugin edu.washington.cs.induction.OnePipeLineScript;
You seem to have a lot of soure folders and wondering if your build.properties file is showing any warnings and that you also have this defined for each of the source folders in your build.properties source.. = src/
Your external jar libraries appear to be in a folder that is of type source which is not correct. It should be a non-source folder (which you can tell a source folder by the package icon decorator) and you should make sure in your manifest editor that for runtime you have the lib checked so that it includes the jars in the build. To unmark it as a source folder select the drop down menu in your navigator view go to filters and uncheck .resources which will then show the .classpath file in that file you will see the folder to be kind="src" (i believe) remove that.
Somehow it also looks like you have linked source folders which is a practice I would not suggest and am not sure if that will cause problems when exporting the plugin. If you can avoid linked source folders that would be better.
Also it seems like you are confusing java build path configuration for plain java applications with plugins running in OSGI which is not configured through java build path but your manifest.editor So as a rule of thumb if its a plugin don't even bother trying to configure the java build path because OSGI is different, that could be causing issues as well
Select "Use class files complied in the workspace" in Options works for me.
I've seen that there are quite a few questions regarding this problem, but unfortunately none have solved it for me. Here is a screencap of what's going on:
It is dependent on the android-support-v4 jar file which as you can see is added to my build path. It the exact jar file from the maven library directory's libs folder. I've tried the following:
Restarting Eclipse
Cleaning the project
Right-clicking the project and updating dependencies
Updating project configuration Disabling and re-enabling workspace resolution
Nothing has helped. Is there any other tricks to getting this resolved? All of the answer's I've seen suggest doing these things that I have already tried.
Thanks a lot!
Actual root cause:
The OP JMRboosties reports in this instance having to desactivate Proguard (the tool which shrinks, optimizes, and obfuscates your code by removing unused code and renaming classes, fields, and methods with semantically obscure names)
disabling proguard on the line where the error occurred (the <plugin> item) in pom.xml solved the problem
(See "How to use ProGuard with android-maven-plugin ").
Certain side-effects can result from using Proguard: For example, the Proguard page does mention:
The default proguard.cfg file tries to cover general cases, but you might encounter exceptions such as ClassNotFoundException, which happens when ProGuard strips away an entire class that your application calls.
Original answer:
As mentioned in this GitHub post:
you need to use maven Android SDK Deployer to install it:
I'm going to deploy my own android artifacts to my personal repository to avoid having this problem again.
If you're not explicitly using Maven you can just import it as a regular Android project into eclipse and it'll pick up the .jar from the libs/ directory.
(Note your android-support-v4.jar isn't in libs in your project)
declare it in your pom.xml.
You have to install both Android 1.6 and the compat lib using the maven SDK deployer for now.
cd to platforms/platform-4/ and extras/compatibility-v4/ in the deployer and run mvn install in each.
Hopefully the compat lib makes it into maven central soon so I can avoid this step.
Again, the project is set up to be used as a normal Android project in eclipse too completely separate from maven.
File, New, Project, Android, use existing sources, select library/ folder.
Assuming you're using m2e-android behind the scenes, the reason you're getting compile problems is that the m2e-android plug-in strips out all provided scope dependencies from the Eclipse project classpath.
We do this because, due to changes in ADT 16.0.0, any JAR file in the Eclipse classpath will be packaged into distributable APK file.