This question already has answers here:
What's in an Eclipse .classpath/.project file?
(4 answers)
Closed 8 years ago.
I have some doubts regarding the files .classpath and .project. I'm using eclipse IDE. I created a project. In that project is see that two files are created. They are
.classpath
.project.
Following questions I have:
Can I know what are the main differences between these two files(.classpath & .project)?
What is the main purpose of .project file?
Can i use .project file in place of .classpath file?
Whether .project file is created in all java IDE's?
Any help is highly appreciated
Most Java IDEs have their own method of storing metadata they need to assist you with your project. Eclipse uses the files you mention. IDEA uses a different file (or a directory if you choose that option).
You generally shouldn't edit these files directly unless you are trying to do something tricky - they are really there for the IDE, not for you, and are not required if you compile your project using an external tool such as javac, ant or maven.
As #geoand mentioned, these files are usually not added to source control as they generally relate to configuration specific to your machine (such as directory structure, etc) and they can be regenerated if required.
Related
I have a question, perhaps it was already answered, but i didn't manage to find it and I appologize if the solution already exists (let me know if it is before deleting my thread).
Problem is:
I have created a program on another PC and exported it from eclipse as a .jar file. It works on my main PC when I double click on it but when I import it in Eclipse I can't find the .java file. So i can't edit it.
What I have done so far:
In eclipse I have created a new empty project
I have right clicked,import, archive file, selected the .class files that eclipse sees, but when I am in the Project Explorer in Eclipse I can't find the .java file where the main is. I mean I can click run as a program and it works, but there is no .java file, only .class files. What am I doing wrong?
That cranes.class should be cranes.java. At least on my other PC it is.
Program works fine, but I can't edit it on my main PC. What am I doing wrong?
Thanks and best regards
You need to select the Export Java source files and resources option while creating the jar file and then your Java files will be available on importing the project from the jar file.
This is similar to how you use other libraries. You depend on the Jar file which contains class bytecode (compiled) of java code. You can't edit any of such files directly in the project you are using it. Thought you can always extends functionalities in your current project using simple inheritance concepts.
If you think such functionalities are trivial you should prefer to change in the original project rebuild the jar and use the newer version of jar.
However if you feel similar things for 3rd party library you can
always make changes after taking fork from those library source
code (if open source) and build and use your own version or go
ahead and raise pull request if you are confident about your
changes.
Mostly when you build a jar file, all you have in it are .class files; these are the result of compiling .java files, and so are not editable with text editors.
You CAN create a jar file that contains .java (also known as source) files, and even a jar file that contains both .java and .class files, but if you ask eclipse to create a jar file, by default it is just going to put .class files and files from resource folders in it, not .java files.
Assuming from the question, the jar is a library created by OP, by compiling java files into class files and packing/exporting them. Although the class files can't be edited in any IDE, they can be de-compiled into Java files by using third-party applications.
I personally use IntelliJ for this de-compiling source files authored by me
Note: Although this gives OP the desired functionality, it may lead to violations if the classes are Copyrighted.
As IntelliJ states, they neither encourage nor discourage de-compiling class files and the decision is purely to the user's discretion.
EDIT: It is always recommended to use the original source files for editing. Try to host them on git so that it may be retrieved anytime required
It may be simpler to not use eclipse but jar/zip/tar your project directory on the one computer and simply extract it onto the other, then open that folder as a new project in Eclipse.
Best is the suggestion from #SanjayBharathi to use git and clone the repo on your other machine.
This question already has answers here:
What exactly is 'Building'?
(4 answers)
Closed 4 years ago.
I am highly confused as why Build is needed in a java project.
I am new to Java. I have created a Java project which creates volume file.
I have run this code on my machine and created a JAR file and batch file which executes this JAR.
Now who ever needs it, I hand over the JAR file along with .bat file and it is good to go.
Where some one asks me source code, I give them via SVN.
In this process I couldn't relate what BUILD means and where it is actually needed? And why we need build tool like Maven (I know what maven is but can't relate)
I can easily share my JAR files and libraries with anyone who needs it.
Maven offers a whole lot of different services. Those are the most obvious ones:
Dependendy management: A big project usually needs a lot of different dependencies. Maven offers a smart mecanism to manage them, using remote and local repositories
Compilation: Your different java files need to be compiled as class files
Testing: Maven is able to play automated tests
Assembling of archives: those class files may need to be stored in jar or war files in order to be usable, often alongside other resources
Deployment: Maven can deploy your archives, for example in the repositories, so other projects using your codes will see your changes
Of course, you can customize those steps in order to adapt them to your needs, run scripts, for example.
This question already has answers here:
Including dependencies in a jar with Maven
(16 answers)
Closed 5 years ago.
I'm trying to develop a plugin for an FOSS application written by someone else. All I need to do is take a single class I've written, package it in a JAR file, and copy the JAR file to a directory in a pre-existing installation of the application.
When the application sees my JAR file, it should load it on startup.
Problem is, it doesn't seem to be able to load my JAR file.
According to their docs, my manifest may need a CLASSPATH specified.
My JAR file structure is simply: MyJarFile.jar/MyClass.java
It's literally just a JAR file with a single JAVA class file inside it.
I'm new at this, and all the manifest file examples I'm seeing on Google seem to reference other JAR files.
Do I even need to have a CLASSPATH in the manifest?
If so, how do I reference MyClass.java?
I'm using IntelliJ and Maven (for the first time).
Thanks.
Check out the article "Setting an Application's Entry Point" in the java docs:
https://docs.oracle.com/javase/tutorial/deployment/jar/appman.html
You need to add a line to the manifest like "Main-Class: MyClass" if you haven't already in order to run the jar.
Do you need to reference classes from another JAR from within your JAR?
If so, you will need to add to the JAR's classpath. See https://docs.oracle.com/javase/tutorial/deployment/jar/downman.html for how to do that.
In general, I would suggest reading the java docs info on JARs
https://docs.oracle.com/javase/tutorial/deployment/jar/index.html
If you still need help after reading that, please explain your specific use case in more detail, e.g. share actual code or error messages
Try this: Click "File" -> "Project structure" -> "Artifacts" -> right click your jar file and choose "Put into output root"
This question already has answers here:
.classpath and .project - check into version control or not?
(7 answers)
Closed 4 years ago.
Should I check in my .project and .classpath files?
My friend told me that I should only check in .java files and the build.xml to guarantee portability. He said ".classpath will cause you much less portability on different environment. .project is entirely your local eclipse setting"
I agree with him, but partially.
-- Not checking in .project file will make my development less efficient (I can't simply "import" a project code from a directory)
-- Not checking in .classpath file seems OK to me (?) if my build.xml is written carefully.
Anyone wants to share their experience here?
There is nothing wrong with checking in .project and .classpath. I would do so, if your build.xml isn't able to create both of the files for you. As you said, it's uncomfortable to miss these files when you try to create a new eclipse workspace.
Before you check in .classpath you should be sure that there is no absolute path in it. Convert it into a relative one with a text editor.
Edit: Or even better, use eclipse classpath variables in your otherwise absolute pathes, like #taylor-leese commented.
For my 2 cents, I would rate it as a bad practice. Projects should not be tied to an IDE, and especially should not be tied to a specific version of an IDE.
Checking in Eclipse config files might work well for simpler and short-term projects. For larger projects that are developed over several years this will generally cause more hassle, as IDE versions change, and project config files don't. Just imagine checking in a 2 year old branch with Eclipse 2.0 config files in Eclipse 4.3 with some customized libraries and m2e integration... No fun at all...
One thing I would caution against with checking in .classpath file is make sure you don't reference files outside of your project. Eclipse stores the location of these files with a full filepath, and you would need to make sure other developers had those files in exactly the same place.
The key question with all such files is "Can they be reproduced automatically?" If not, check them into source control.
In this case, I'd say "yes," unless you're using maven, which has m2eclipse and the eclipse plugin to generate them for you.
I don't really know eclipse preferences files, but with IntelliJ, those files are OS agnostics, which means that it won't ruin your portability. Unless you define libraries with a full path to your system (That would be pretty dangerous/stupid).
When you share preferences, you're sure that everyone will work with the same conditions on the project (plugins configuration, encoding, profiles [for intelliJ]) which can really be a good thing.
It doesn't bother me when some Eclipse files are here, and I think it shouldn't/doesn't really bother other developers when some hidden files just lay there.
We check in .project and .classpath. With ProjectSet's this allows us to check out complex workspaces with a single "Import Team ProjectSet"
Not checking in .project file will
make my development less efficient (I
can't simply "import" a project code
from a directory)
for this issue, you can choose to create new project and import existing source.
one issue with IDE specific files like .project is that other Developers may want to use another IDE do develop the project, so they may add another type of project files. this will make your repo messy.
I would prefer to checkin .project and .classpath.
This would be helpful when this project is being shared by multiple developers. It becomes easy and faster to setup development env. by simply importing this as existing project on any system using eclipse.
Only caution needs to be taken here is classpath's are relative to project.
I often have a similar, more general questionning. The problem essentially is :
which files am I commiting for me?
which files am I commiting for others?
→ How do I combine both objectives of "versionning"?
I offered discussing this there, so you may find more details about the problem, along with interesting solutions :)
The one I like best is the use of git submodule: keep your .project files etc. in a private commit repo. And make your final, pure, essential src production into a neat submodule nugget: a public repo.
project/ # root module
| .git # private repo
| .project
| .classpath
| momsNumber.txt
+---src/ # submodule
| | .git # public repo
| | main.java
| +---package/
| | | Etc.java
See there anyway.
There is not problem of checking in .classpath and .project files into repository. It will help developers which use Eclipse to get going faster.
Warning: Make sure your .classpath file is referencing only artifacts which either checked into the repository with the project or can be obtained automatically (such as maven artifacts).
I have a Java project I'd like to commit to my SVN repository, created with eclipse.
Now, what files (aside from the source code, obviously) are necessary? In the workspace root, there is a .settings folder with many files and subfolders, and inside the project folder there are two files - .classpath and .project, and another .settings folder with a single file - org.eclipse.jdt.core.prefs.
Which of these files should be committed to SVN and which can be safely excluded?
They're all useful if you want to have consistent settings across your team.
.classpath and .project mean everyone can get up and running with a project just by importing it. Any changes to the libraries and source files included in the project will be picked up by everyone when they're checked in.
The .settings directory has things like code formatting options and what the compiler considers as warnings, errors, or OK. For consistency, I've started checking these in as well (as long as everyone on your team can agree to a standard for formatting, I guess).
I've found that the biggest limitation in sharing things across version control in Eclipse is in the library definitions. Library definitions seem to be only stored on a per-user basis, so if you reference a "library" in the .classpath file, every other user has to manually define the contents of that library (or manually import your exported library definitions file).
Edit: (Addressing #mliebelt's comment below)
You'd only commit .settings files if you're trying to keep consistency/standardisation between developers. If that isn't an issue for the project, then not committing .settings files is one less thing to worry about maintaining. Files that are specific to an individual's favourite plugin(s) probably don't need to be committed either (although I don't think it would hurt if they were, would probably be ignored?).
The two most common ones I've found worth committing are org.eclipse.jdt.core.prefs and org.eclipse.jdt.ui.prefs, which are core to any (Java) Eclipse project.
You can exclude the .settings folder, but the .project file will be useful to other developers who want to reconstruct the same exact Eclipse project. If you examine the file it should only have relative references (if it doesn't, you should modify it as such.)
In contrast to the other answers I've made better experiences with not checking in the .project file in large open source projects that I work with.
You may disagree with me, but there is one problem with shared .project files: They contain references to the project natures used in the project. The project natures again depend on the plugins installed on the local developers machine.
Example: If you use Findbugs on a Java project, a new nature gets added to your Java project. Checking that file in, modifying it on another system (with no Findbugs installed) and afterwards using it on my system again has led to the Findbugs reference being lost for me (and therefore all Findbugs checks being removed silently).
But if you can have all of your developers agree on using the same tools, then you may be able to work around this problem easily.