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.
Related
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.
Today I faced problems in starting eclipse (reinstall etc. did not work). I had to use a vanilla eclipse and with luck it was working.
With that I experienced the problem of an IDE that is not working. That can be a mess if you need a quick bugfix for a hot system.
Is there a tool that takes an eclipse-project and converts it into a makefile for a more basic tool (like ant, maven, gradle, ...) that work from the commandline?
Sure I can make it by hand but because it should be only a safety I would prefere the automatic way and keep the development-work in the IDE.
EDIT:
Or maybe: Is there an build-command that works on the commandline without starting the IDE?
Thanks!
Running "gradle init" from the command line will attempt to create a build.gradle for your project. If your project layout is "conventional" it might do a good job. If it finds anomalies it tends to give up. Constructing a simple Gradle build script for a simple project takes a few minutes once you get used to it. Searching the web with intelligent queries will tend to find lots of examples.
Adding the "Gradle Nature" in Eclipse is simple if the project is buildable from the command line with Gradle.
You can use m2e eclipse plugin to convert your existing projects to maven projects. But you have to do it before hand(while your eclipse is still working)
https://crunchify.com/how-to-convert-existing-java-project-to-maven-in-eclipse/
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 prefer not to use Netbeans when I write Java code for a project,
but Netbeans is perfect for refactoring, and works nicely with svn.
The project is open-source on sourceforge, so I do not want to push other people into using Netbeans. My idea is to symlink the netbeans source direcory with the directory I consider to be the trunk of my project. Is this a good/bad idea?
EDIT: I solved it by adding adding the source directory to Netbeans instead.
Did not realize one could separate the Project from source.
http://wiki.netbeans.org/AutomaticProjects may be helpful in your case, assuming you have an Ant script. So long as NB can figure out what your script is doing as far as javac and the like are concerned, it will let the IDE open your project's sources - enough to do refactoring, run unit tests, use SVN, etc. - without adding any metadata to the source tree.
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.