One of my colleague recently created a new project in eclipse ,committed and pushed with built-in git client.
After I cloned to my computer and opened with eclipse, I found eclipse creating .classpath file.
Isn't .classpath a crucial file for eclipse project(also .project) to find referenced jars?
I am very confused after googling, seeing all the discussions talking about ignoring them.
Aren't they crucial to Eclipse to work correct ?
Why are people ignoring them ?
What's the problem if I have them not ignored ?
These Eclipse-specific files make it easier to set up Eclipse and Visual Studio Code for a Java project.
In general, IDE and tool specific files (Eclipse, Jenkinsfile, GitHub workflows settings, etc.) should be shared as long as they are used and maintained. Otherwise, delete them.
Of course, if you use a different IDE than Eclipse and Visual Studio Code and do not use the Eclipse compiler in IntelliJ IDEA, these Eclipse-specific files are useless, but they do no harm. As long as you do not use functions like file or folder links (stored in the .project file), sharing these files does not lead to IDE lock-in.
In Maven and Gradle projects the .classpath file can be derived from the pom.xml or build.gradle file, but settings that cannot be derived like compiler settings (warnings and errors), formatter or save actions settings (which are stored in the project's .settings folder) should be shared so that everyone uses the same.
This also applies to the .project file, as it contains which natures the project has and which tooling is required. If something is missing, a dialog will ask if the missing plug-ins should be installed.
Eclipse puts these files into the project folder and not into the .metadata folder, because they are intended to be shared. But why there are people who do not share these files? Probably because of historical reasons. 15 or 20 years ago, there wasn't Git, Maven and Jenkins. In these days, a Java application was usually built on a developer's computer by manually exporting JARs or at best via some batch/shell scripts. This meant, making the same build on a different computer or even just with a different IDE or IDE version might led to a different result, causing a lot of trouble. IDE agnostic builds was the solution for this problem. Maybe that's why people today still think that everything have to be IDE agnostic and recommend to use Maven or Gradle. But these files are not shared to build a product to be shipped. Hopefully.
They're Eclipse specific, so they don't really belong to the project's source code. Developers might be using different IDEs, so Eclipse's .classpath would be useless for someone using IntelliJ IDEA for example.
Since the project most likely uses Maven / Gradle / some other build system, the IDE is capable of generating the classpath based on the pom.xml or build.gradle files, as you noticed. Only if there isn't a build system, and the project is IDE specific, it would be necessary to include those files to make sure the project keeps its meta-data. But that's an unlikely scenario in modern times and real life work situations.
It doesn't usually cause problems to include those (unless there are conflicting project specific configurations from different developers), but they're not necessary either. I don't include them since there's no advantage, and it keeps the root of the project cleaner.
That very much depends.
If your team decides that the eclipse project configuration files are the essential source of truth, and everybody else should be using them: then sure, these files should sit in your source code management repository.
But doing so leads to "IDE lock-in". Or worse, it leads to having multiple files containing the same information, as a future IntelliJ user might prefer to add .iml files on top of that. So any change to project definitions needs to happen twice now.
So, ideally, in 2020: use other tools as your base source of truth (like gradle definitions), and then tell your individual IDE to use that.
Related
I have an eclipse Java project and want to get information like project source dir, classpaths, etc. My current implementation parses the .project file. But as I didn't find any official documentation describing the structure of the .project file, I have some concerns for the robustness of this approach.
A more convenient and robust way would be to use JDT (headlessly) to load the project and get the relevant information from the IJavaProject object.
Although the developer guide of JDT says
JDT Core packages give you access to the Java model objects and headless Java IDE infrastructure.
all the examples I can find opening an existing Java project get the IJavaProject object from projects within a workspace or use an IProject object. But I couldn't find the way to add a project to the workspace or to construct a IProject/IJavaProject from a path to .project file.
Could anyone please help?
Yes, and can all be done through clear and stable API. org.eclipse.jdt.core is a plug-in, just like org.eclipse.core.resources (which is where you would get an IWorkspace instance), and they both expect to be running within an Eclipse runtime, which can be headless if that's how you write your Eclipse Application. JDT uses the .classpath file to record where sources, libraries, and build output are, and what abstracted references to libraries to use, while the .project file is what records what kind of project it is in general--Java, PHP, Web, some combination of those or others--and a little more information about what builders to execute.
So make yourself a headless Eclipse Application, or package your end-goal functionality inside of one.
https://wiki.eclipse.org/FAQ_What_is_an_Eclipse_application%3F
https://wiki.eclipse.org/FAQ_What_are_extensions_and_extension_points%3F
http://help.eclipse.org/mars/topic/org.eclipse.platform.doc.isv/reference/extension-points/org_eclipse_core_runtime_applications.html?cp=2_1_1_27
http://help.eclipse.org/mars/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/resources/ResourcesPlugin.html#getWorkspace--
http://help.eclipse.org/mars/topic/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/core/JavaCore.html#getJavaCore--
http://help.eclipse.org/mars/topic/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/core/IJavaProject.html#getResolvedClasspath-boolean-
See http://www.ant4eclipse.org/ for a project which allows you to work inside Eclipse projects.
I used it for a bit some years back, and found that this is too brittle for long term usage and build scripts. I would recommend against relying on internal Eclipse things. They break! Typically when mixing releases.
Instead I would suggest you move to Maven. This is a bit more work, but allows you to use the whole maven infrastructure and API's to do things. What you want to achieve here, may be possible already using a Maven plugin.
I love being organized, and I hate having all my java projects in eclipse right in the workspace. It makes it very cluttered, and I wanted a more organized approach, where I have folders in my workspace for different kinds of projects. However, folders can only be added into other folders, and not the workspace itself. Also, I wanted a way to be able to put classes into just any folder, and not just the src folder in a project. I love eclipse, but I really want the way to organize my programs to be a little more flexible. Does anyone know how I can do this?
I think what is organized to 1 person is not the same for another. I have found some of these techniques helpful maybe they will help you
Group projects to working sets so you do not see the full workspace
You can keep sources in different folders add those source folders in the build path
Use tools like Collabnet that integrates with your version control repository and issue management systems like JIRA and at given point in time you can view only the files that are relevant to the issue you are working with.
Know your keyboard shortcuts very well
For what I understand, you are formulating two expectations:
Have a clear directory structure for your projects, independent from the IDE;
Have a clear workspace organization, which reflects the underlying structure of your projects.
There is something you did not mention, which is the build facility for your project. I guess you are compiling and running your projects from within Eclipse? If not, or if you are willing to compile, test, deploy and run your project besides your Eclipse IDE, you can have a look to full-featured tool like Maven.
The point is that even if you do not want to build your project outside of the IDE, this tool will save you so much time that it is even worth to use it only to have a clear, proper, conventional and understandable directory structure as you seem to expect. On the other hand, the problem is that such a tool addresses issues that are far beyond your own requirements, which may render it overkill to use for the sole purpose exposed above.
Maven is a perfect tool for those who like to be organized. One of its core concept is convention over configuration.
This means, for instance, that if you follow Maven conventions for your projects, the simple command
mvn eclipse:eclipse
will generate for each of your them a corresponding Eclipse project, which you will be able to configure, generate and clean from outside Eclipse.
Accidentally I delete project ".settings" folder from directory where located Java project.
In this directory were located files like:
org.eclipse.jdt.core.prefs
org.eclipse.m2e.core.prefs
org.eclipse.wst.common.project.facet.core.xml
etc..
Can I restore them? Now eclipse show error when methods marked with #Override annotation (Eclipse don't understand that I implement some interfaces). It is not full list of errors.
Thanks!
i also had faced this issue once upon a time.
there is a solution for this.
Just delete the project from Eclipse workspace and import it again.
the settings will be created for the project.
Note: Don't delete it from Disk(it will ask for that when you try to
delete,so don't check the checkbox)
Unless you have a backup or generating your Eclipse project settings from some build system you should manually set your project preferences again in Eclipse (open project properties and look through the settings).
E,g, the problem with annotations is incorrect Java version setting for compiler (you need java 1.6 or higher).
Maybe your project is very simple then you may create new project with appropriate settings and copy your sources from broken project to new one.
If you want to avoid similar situation with workspace settings you may export them and backup resulting file (see file/export/general/preferences).
It is usually very convenient to generate Eclipse project from build configuration (e.g. all Maven, Gradle, Leiningen can do this). This works well unless you need some specific settings in Eclipse project that are not yet supported by build system.
It's needs lots of time. You should delete all eclipse files and import/create again this project. One time I have had some problem and I spent 3 hours for restoring. I tried restore using hdd recovery tools then manually checked some parameters. But in result I didn't fix all problems because in my case files was damaged.
I'm trying to learn project automation and I'm using the book Pragmatic Project Automation as a guide. It's examples are in Java so I find it easier to follow it along in Java. I don't have any experience using Java or any of its IDEs. However, I've learned some C# using Visual Studio (although I'm still a beginner).
I'm having trouble understanding some parts of setting up a Java project. I'm using Netbeans IDE 7.0 on Windows 7. With Visual Studio, I have a solution with projects underneath. With Netbeans, I appear to just have a project with directories determining the rest of the structure (and the IDE to some degree)? The equivalent to Add Reference appears to be adding a source to the Classpath. There also seems to be a degree of separation between the compiler and the IDE. I'm currently in a situation where I can compile my project just fine while the IDE tells me I still have errors (and I assume this is because I have the project set up incorrectly).
I'm basically looking for analogies that will help me better understand Java project structure.
Lots of similarities between the two languages and IDEs. I spent many years in both. For starters the equivalent to 'add reference' in VS is adding a library or jar in netbeans. In respect to a reference - a jar is pretty much the same thing as a module or .dll in VS. A jar is a compiled reference. To add a reference just go to the project menu and then properties then to the libraries menu from there you can add either pre-assembled netbeans libraries, which are collections of .jar's, or a single .jar, or even a project. Once you add a reference you can import them into your class just like you would in C#.
Netbeans doesn't really have a 'solution' as VS does. You deal with individual projects. It does however have the capability to add a project as a reference so you don't have to continually re-build the references when you change something between multiple projects. It also has project groups to group similar projects.
Lastly Apache ANT is responsible for tying everything together in the background. Netbeans creates a build.xml and build-impl.xml file in the background to tell ANT how to assemble the project into a .jar.
There are my other things to cover but I thing this answers most of your questions. Does this help?
I can't speak for NetBeans, as I use Eclipse, but you are on the right track with classpath being roughly equivalent to references in the Visual Studio world. Libraries (usually .jar files) are placed on the classpath and must be there both at compile time and runtime (you specify the classpath to the compiler at compile time, and to the JVM at runtime). The classpath can contain many different entries, and they can be anywhere in the project structure (or outside of it entirely).
Java itself doesn't impose many restrictions on your project structure, although various IDEs and build tools do. The one thing that is a universal restriction in all Java environments is that source files (and class files) are placed in a directory named after the package name. So if your package name is com.test.something, then your source files will be in SRC_DIR/com/test/something, and your class files in OUT_DIR/com/test/something (note: SRC_DIR and OUT_DIR are not special variables; each IDE will have a different way to specify those directories).
Java libraires tend to heavily build-on one-another, so at some point, you'll find that the classpath entries are too many to manage manually. Before you get there, you'll want to take a look at Apache Maven or Apache Ivy which are dependency management tools. You'll need to understand how they work (either one, not both) and how to integrate them with your IDE. If you use Eclipse and Maven, m2eclipse offers fairly complete integration between the IDE and the dependency management tool.
With Netbeans, I appear to just have a
project with directories determining
the rest of the structure (and the IDE
to some degree)?
Visual Studio dictates a particular project layout and since the compiler is so tightly integrated into the IDE there's no real concept of a build script. In contrast, Java has no such structure (although certain 'best practices' have emerged such as having a 'src' directory for source files, 'lib' for libraries, 'test' for test source, etc.) and a build script is usually required to tell the compiler were to find source files and libraries, what artefacts to produce and a miscellany of other chores (running tests, deployment, creating code metrics and so forth).
In simple cases, the IDE will take care of this for you (if you follow the convention for that particular IDE) but ultimately you will probably want to take a look at a build tool to understand what's going on behind the scenes. Apache Ant and Apache Maven are both prominent offerings. Ant is very flexible whereas Maven attempts to dictate a common layout. I suggest you investigate both and see which suits.
There also seems to be a degree of
separation between the compiler and
the IDE. I'm currently in a situation
where I can compile my project just
fine while the IDE tells me I still
have errors
If your code compiles, it is correct. The IDE is simply acting in an advisory capacity (and will highlight issues beyond compiler errors, such as warning you of potential code mistakes or bad practice).
and I assume this is because I have
the project set up incorrectly
This is a possibility although, as stated above, there are many other explanations.
I have looked for an answer for this nearly every where that I can think of, but there doesn't seem to be any way to actually SEE what Eclipse "runs" to compile the projects (as it does need the JDK installed and visible to actually build). I ask because I imported a few jars into my project, and even though I've looked through all the javac documentation, I can't seem to figure out how to mimic it quite like Eclipse does. I really, really need to be able to compile on the command line in this case - Eclipse or any other IDE just isn't what is needed.
I started to look through the Eclipse source, and although this sounds lazy, I just became overwhelmed and figured I would ask here first, hoping someone else had the same question at one point.
Eclipse JDT does not require the JDK and does not use javac - it uses it's own compiler.
You can see the classpath by reading your project .classpath file. The various builders that are used to perform build operations (Java, or whatever the project builds) are listed in the .project file. (These are also listed in the project settings.)
It is possible to invoke Eclipse to build your project in headless mode, or write Ant scripts that can be executed both with the JDK and within Eclipse, or install Maven support for internal and external building. It is also possible to configure the project builders to rely only on external tools.
Look at these two articles.
http://www.eclipse.org/articles/Article-Builders/builders.html
http://www.eclipsepluginsite.com/builders-natures-markers.html
Look at your .classpath file and start building an ANT build.xml. You need to do this to be able to have consistent builds on a build machine anyways. It is unlikely that a build server would have eclipse installed on it anyways.
Maven is also another tool that is used for builds. In our shop we use Ant.
Have a look at ant4eclipse - this project allows for generating the appropriate ant data structures for invoking <javac> from the .classpath files and a projectSet.psf file.
By using this we can use Eclipse "natively" and bend ant to conform to Eclipse. The usual approach is the other way around.