Is the Eclipse project Properties > Java Build Path > Libraries tab the analog of the java -classpath definitions? What is the difference between a "build path" and a "classpath"?
The classpath is a Java thing. It's a list of either folders or jar files to consider (in order) when resolving classes to be loaded. It's used by the Java JVM. It can be specified by the CLASSPATH environment variable or java -classpath. It's a list of either Jar files or folders separated by a ":" on Linux/OSX systems or ";" on Windows.
The Eclipse build path is a means to construct this Java classpath from artifacts in the Eclipse environment. The Configure Build Path dialog is used to manipulate a file in your project called .classpath (normally hidden). This dialog allows you to form the Java classpath from Jar files, files you have built, folders, external Jar files and other things. It also controls where the Java Development Tooling (JDT) will locate your compiled files, and other things related to class files. The Eclipse help has pretty good documentation on this.
The classpath is the place in memory where your Class files and other resources (*.properties, *.xml, among many other types of resources) are made available to the programs running within the JVM.
Eclipse's build path is simply a folder where Eclipse will put the result of whatever 'build' process is set up: this process typically includes the compilation of classes, but it could also include other steps, like code generation, depending on plug-ins that might be installed.
Because you might be running your program from within Eclipse, the build path and the Classpath could possibly contain the same resources. However, keep in mind that the 'build path' is a view of your resources from the Operating System file system perspective, the Classpath is a view of your resources from the Java Virtual Machine perspective.
Related
Newcomer to the Intellij IDE here, with no Java background. I've looked at Build Definition to get a brief idea on how should I organize my scala files, but their example doesn't cover the full structure of an SBT-based project shown attached.
Can you advise what each folder should be used for (e.g. where my source files should go, etc.) and also point me to sources where I can go read up more.
Thanks so much
It is described pretty well here:
http://www.scala-sbt.org/0.13.5/docs/Getting-Started/Directories.html
But to sum up.
.idea:
This contains the project files for your idea project, and has nothing directly to do with sbt itself. However idea (if auto refresh is enabled) updates its own project, each time the sbt build files change.
project:
This contains the sbt project files, except for the main build file (files ending in .sbt). Sbt build is itself based on scala, and if you need to have some scala code included in your build (e.g., code-generation/meta-programming, pre-compiler macros), then you can place scala source files in this directory. The code of these files can be used in your build system, and is not part of your project itself. To really understand how a build is made, then you will need to understand the difference in how sbt files and scala files for the build should be placed. When you run sbt, then it will search for .sbt files in the directory your are standing in, when these are found, it will search for scala files in the project directory. These files together are the source of the build system, but because these are source files, they need to be built before they can be used. To build this build system, sbt uses sbt. So a build system to build the build system is needed. It therefore looks for sbt files inside the project directory, and scala files for this build inside project/project and build these files to get a build system, that can build the build system (that can build your project). Actually it can continue recursive down to any project/project/project... directory, until it finds a project folder containing no scala files, and therefore needs no building before use.
The target folder inside project, is the target folder for the sbt build of your build definition. See below what a target folder is.
Normally you would not need to be concerned about this; just remember that build.sbt in your root directory is the build script for your project. project/plugins.sbt defines plugins activated for your build system, and project/build.properties contains special sbt properties. Currently the only sbt property I now of, is what version of sbt should be used.
src:
This is where your place the source files of your project. You should place any java sources in src/main/java, scala sources in src/main/scala. Resources are placed in src/main/resources.
The src/main/scala_2.11 folder is typically used, if you have some code that it not binary compatible with different versions of scala. In such cases you would be able to configure sbt to use different source files when building for different versions of scala. You probably do not need this, so I would advise to just delete the src/main/scala_2.11 folder.
Test sources are placed inside src/test/java and source/test/scala, and test resources are placed in src/test/resources.
target
This folder is the target folder for sbt. All compiled files, generated packages and so on are placed somewhere inside this dir.
Most things in this dir are not so interesting, as most of it is just internal sbt things. However if your build a jar file by calling sbt package, then it will be placed inside target/scala-x (where x is the scala version). There are also a lot of different plugins, that can package your application in different ways, and they will normally also place the package files somewhere inside the target dir.
Every projects in eclipse has 4 .files(.settings,.classpath,.cprojects and .projects).
Can anyone explain me why are these files generated and what happens if I delete these 4 files. I have deleted these files from one app which resulted in changing the name of app.
Eclipse is a runtime environment for plugins. Virtually everything you see in Eclipse is the result of plugins installed on Eclipse, rather than Eclipse itself.
The .project file is maintained by the core Eclipse platform, and its goal is to describe the project from a generic, plugin-independent Eclipse view. What's the project's name? what other projects in the workspace does it refer to? What are the builders that are used in order to build the project? (remember, the concept of "build" doesn't pertain specifically to Java projects, but also to other types of projects)
The .classpath file is maintained by Eclipse's JDT feature (feature = set of plugins). JDT holds multiple such "meta" files in the project (see the .settings directory inside the project); the .classpath file is just one of them. Specifically, the .classpath file contains information that the JDT feature needs in order to properly compile the project: the project's source folders (that is, what to compile); the output folders (where to compile to); and classpath entries (such as other projects in the workspace, arbitrary JAR files on the file system, and so forth).
Blindly copying such files from one machine to another may be risky. For example, if arbitrary JAR files are placed on the classpath (that is, JAR files that are located outside the workspace and are referred-to by absolute path naming), the .classpath file is rendered non-portable and must be modified in order to be portable. There are certain best practices that can be followed to guarantee .classpath file portability.
The .settings folder is used by various plugins to set persistent 'Properties' as opposed to 'Prefereneces' to specify project specific settings that should be preserved.
.settings is usually a directory you most definitely want checked into svn/cvs/git etc as it will ensure that all users who check that project out into eclipse use the right project specific settings.
In our case we use it to supply a minimum compiler version of java but we want things compiled to 5 for our servers. We also use it to enforce some coding standards and auto-formaters which makes version diffs much easier to read.
In your specific case you selected 'Enable Project Specific Settings' under "Properties->Java Compiler" by right clicking on the project and choosing properties.
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.
How should I add JAR libraries to a WAR project in Eclipse without facing java.lang.ClassNotFoundException or java.lang.NoClassDefFoundError?
The CLASSPATH environment variable does not seem to work. In some cases we add JAR files to the Build Path property of Eclipse project to make the code compile. We sometimes need to put JAR files inside /WEB-INF/lib folder of the Java EE web application to make the code to run on classes inside that JAR.
I do not exactly understand why CLASSPATH does not work and in which cases we should add JARs to Build Path and when exactly those JARs should be placed in /WEB-INF/lib.
The CLASSPATH environment variable is only used by the java.exe command and even then only when the command is invoked without any of the -cp, -classpath, -jar arguments. The CLASSPATH environment variable is ignored by IDEs like Eclipse, Netbeans and IDEA. See also java.lang.ClassNotFoundException in spite of using CLASSPATH environment variable.
The Build Path is only for libraries which are required to get the project's code to compile. Manually placing JAR in /WEB-INF/lib, or setting the Deployment Assembly, or letting an external build system like Maven place the <dependency> as JAR in /WEB-INF/lib of produced WAR during the build, is only for libraries which are required to get the code to deploy and run on the target environment too. Do note that you're not supposed to create subfolders in /WEB-INF/lib. The JARs have to be placed in the root.
Some libraries are already provided by the target JEE server or servletcontainer, such as JSP, Servlet, EL, etc. So you do not need put JARs of those libraries in /WEB-INF/lib. Moreover, it would only cause classloading trouble. It's sufficient to (indirectly) specify them in Build Path only. In Eclipse, you normally do that by setting the Targeted Runtime accordingly. It will automatically end up in Build Path. You do not need to manually add them to Build Path. See also How do I import the javax.servlet / jakarta.servlet API in my Eclipse project?
Other libraries, usually 3rd party ones like Apache Commons, JDBC drivers and JEE libraries which are not provided by the target servletcontainer (e.g. Tomcat doesn't support many JEE libraries out the box such as JSF, JSTL, CDI, JPA, EJB, etc), need to end up in /WEB-INF/lib. You can just copy and paste the physical JAR files in there. You do not necessarily need to specify it in Build Path. Only perhaps when you already have it as User Library, but you should then use Deployment assembly setting for this instead. See also ClassNotFoundException when using User Libraries in Eclipse build path.
In case you're using Maven, then you need to make absolutely sure that you mark libraries as <scope>provided</scope> if those are already provided by the target runtime, such as JEE, Servlet, EL, etc in case you deploy to WildFly, TomEE, etc. This way they won't end up in /WEB-INF/lib of produced WAR (and potentially cause conflicts with server-bundled libraries), but they will end up in Eclipse's Build Path (and get the project's code to compile). See also How to properly install and configure JSF libraries via Maven?
Those JARs in the build path are referenced for the build (compile) process only. If you export your Web Application they are not included in the final WAR (give it a try).
If you need the JARs at runtime you must place them in WEB-INF/lib or the server classpath. Placing your JARs in the server classpath does only make sense if several WARs share a common code base and have the need to access shared objects (e.g. a Singleton).
If you are using Maven:
Open the project properties, and under Deployment Assembly click Add...
Then select Java Build Path Entries and select Maven Dependencies
Resolved by setting permissions.
Had related issue using PySpark and Oracle jdbc. The error does not state that the file cannot be accessed, just that the class cannot be loaded.
So if anyone still struggles, check the permissions. Some might find it obvious tho'.
I want to give the answer for the folowing link question ClassNotFoundException oracle.jdbc.driver.OracleDriver only in servlet, using Eclipse
Ans: In Myeclipse go to Server-->left click on Myeclipse Tomcat7-->Configure Server Connector-->(Expand)Myeclipse Tomcat7--> Paths-->Prepend to classpath-->Add jar (add oracle14 jar)-->ok
I've written an ant task that extracts the classpath of a project form eclipse's .classpath file - so I don't need to maintain the project's dependencies both in eclipse and in my ant file.
This ant task works great and it makes my compilation ant scripts to be very elegant, short, and the most important thing maintainable.
In Eclipse you can use a pre-defined Libraries (under project > Properties > Java Build Path > Libraries), for example: Junit, Apache Tomcat, and JRE System Library. I am not talking about a user library
Each library hold a list of jars associated with it. I can see this list by expanding the library. Foe example the Juni4 library contains 2 jars: junit.jar
What keeps me from finalizing my work is that I don't know where eclipse stores the information about the jars inside the library.
-- Yonatan
Maybe in bundles.info (the following paths are from the Helios3.6 distribution, but you can find similar paths with Galileo 3.5)
C:\Prog\Java\eclipse-SDK-3.6-win32-x86_64\eclipse\configuration\org.eclipse.equinox.simpleconfigurator\bundles.info
, where you can read:
org.eclipse.jdt.junit4.runtime,1.1.100.v20100526-0800,plugins/org.eclipse.jdt.junit4.runtime_1.1.100.v20100526-0800.jar,4,false
which references the junit.jar found in:
C:\Prog\Java\eclipse-SDK-3.6-win32-x86_64\eclipse\plugins\org.junit_4.8.1.v4_8_1_v20100427-1100\
That is consistent which what you cansee when you actually "add a Library":
alt text http://img805.imageshack.us/img805/4581/eclipseaddlib.png