This framework distribution includes a lib folder (where all the binary .jars are) and a src one (where you can find the corresponding .javas for each .jar). So far I only have added lib to the Java project build path.
How would you copy src now? Just adding it or is there a way of somehow link it to lib? I don't have in mind what the gain would exactly consist of but I reckon that that would be somewhat better.
Edit - src is provided as a folder hierarchy, not source .jars.
If you're not modifying the source, performance will be better if the source for each jar is in its own source jar. It's usually also more convenient. This is a convention at this point - especially if you can get the jars from a maven repository. Each jar should be organized as you'd expect, with top level directory(s) "org", "com", etc. In the build path, you can attach a source jar to each binary jar.
I'm not 100% sure this is what you're looking for, but if you have added jars to your build path, you can right click on individual jars in the Project Explorer and select Properties. In the resulting pop-up is a Java Source Attachment tab, which has options for linking source files depending on where they're located.
The main advantage to this that I'm aware of is when you're debugging code that makes use of the jars. If you have source attached, you can step through the code, including comments (which are not available if you use a de-compiling tool to step through classes for which you don't have source).
Related
Besides src/main/java folder, we have one folder that contains some generated java sources that are required for the main sources. Code generation is invoked manually, when needed. Generated source is checked into the source repo. Everything will be built and packed together.
What would be the best location for generated java sources that are going to be compiled together with main sources? Should it be:
/src/generated/java (following the same naming logic for src/testInt/java for integration tests)
/generated-src/main/java (in collision with "The src directory contains all of the source material for building the project")
/src/main/generated-java (well... generated-java is not a type)
...?
The first option seems like the most appropriate one for this case. What do you think? Is there anything in Maven docs that describes this situation (that I have overlooked)? Do you know any repo with similar structure?
Thank you.
Answer
As suggested by #Absurd-Mind, direction we are thinking about is to split the source into the submodules (which works nice in gradle). So, the generated source and some other related source will go into its own submodule (they will produce the separate artifact) and the rest will go in other submodule, that uses this one. Thank you.
I think the location depends on how the source is generated and handled.
The source code is generated automatically during the build process: Then i would use target/main/java/, target/test/java/ and so on. This code is not checked in into CVS since you can rebuild it fairly easy. In case you clean your project the target directory will be removed and the source will be rebuild.
The source code is generated manually by an external tool or similar: I would use generated/src/main/java/, generated/src/test/java/, generated/src/main/resources/ and so on. This code should be checked in. A benefit is, as soon you see that the top-level directory name is generated you know that all files/directories below are also generated. Also you have the standard maven directory structure under the top-level directory. Another point is that clean-up is easy, just delete generated and recreate it, without looking through many other directories (like in your example: src/main/generated-java and src/test/generated-java).
EDIT: Another nice solution would be to create a maven project which only contains the generated source like myproject-generated-1.0.3.jar. This project would be a dependency in your real application. Then you would just put your generated source int src/main/java.
As much as i know there is no standard folder structure for generated sources. In my projects, i prefer src/gen/java kind of notation.
I totally agree with the accepted answer. I just want to offer a slightly different suggestion for naming the directory that contains code generated by third-party tools:
src-gen/main/java
Background: In the Eclipse/Maven Tycho world (where code/resource generation often plays a large role) there is the src-gen directory for generated code, which has been established as some kind of standard convention. (the default project layout is a bit different compared to Maven, as all source files are directly in src and src-gen).
In a Maven project that could be translated for example to src-gen/main/java, src-gen/main/resources, src-gen/test/java, src-gen/test/resources. I like that more than moving everything into a "generated" directory, because
Sources in src/main/javaand src-gen/main/java are on the same depth in the directory tree
It's more clear that src-gen contains generated sources/resources that contribute to the build. On the other hand a folder just named "generated" dosn't tell you much about its content. It could contain anything, like generated documentation or generated test data or it could be just a temporary folder.
All the mentioned advantages of generated/src/main/java still apply (e.g. easy cleanup)
After a quick google search it looks like there are already projects on Github that use this pattern
Some thoughts/opinions about the other suggestions from the question:
Instead of /src/main/generated-java I would probably rather go with something like /src/main/java-gen which, when sorting directories alphabetically, keeps generated and regular code next to each other (<lang>-gen is also another pattern already used in Eclipse projects)
In my opinion gen fits in with the brief official names like src, it etc. more than generated. I've already seen src/gen/java a few times in the wild and have the feeling it is a more common than /src/generated/java. On the other hand some Maven plugins use the quite verbose target/generated-sources/<lang> directory, so generated-sources/main/java could also be an option if your not into short names...
Ultimately I think the naming doesn't matter that much and it is up to your preference since none of this is "official" convention.
NetBeans adopted <project>/target/generated-sources/<tool> as the location for generated code. As a result you would see an extra leaf appear in your project tree named as Generated Sources (<tool>), and source code will be navigable and not show up with compiler errors in the markup.
So if you commit your code, it will not be under the /target directory, and you will have to setup your maven project for the additional Source Code locations. Otherwise, I will suggest to keep with that adopted standard and put things under <project>/target/generated-sources/<tool>.
In Maven project source file store inside src/main/java , src/main/resources and test class store inside src/test/java.
In Maven generated code (Compile code) stored into target/ folder.
When you build your Maven project, all generated code to be updated in target folder.
I check out a java project from svn repository include .classpath and .project files. And I import these codes into eclipse. But the eclipse will modify the content of .classpath file. How can I stop eclipse to do this? just write off build automatically option?
You can't. But instead of putting a JAR on the Java build path you could
choose an execution environment which should stay stable when you change
the JRE and hence the .classpath file will not change either.
.Project and .classpath files should not be checked in under svn repos.Blindly copying such files from one machine to another may be risky. These are the files that eclipse automatically constructs for you as per your project structure. If you want to edit, you can do that.
Here is the nice explanation What's in an Eclipse .classpath/.project file?
Adding information to a 2-year old question just in case of any one else is stumbling across this.
Due to insufficient detail in the original question, I am guessing that the problem experienced is due to the project's classpath pointing to a different location on the questioner's machine as on the original project author's machine. When a project uses 3rd party libraries (JARs) and is shared between different team members (as hinted at by the use of a version control tool), this is a common occurrence.
A solution to this would be to have all team members set up the location of the directory containing all 3rd party JARs to have an identical structure on all individual machines. So instead of changing the classpath, change the directory structure to that required by the classpath.
Unfortunately this is not always the best solution:
Team members may have different operating systems (Windows vs Linux) and you will not be able to have a (absolute) class path that works on all platforms (e.g. C:\libraries\3rdparty.jar vs /opt/libs/3rdparty.jar)
Team members may differ in how they prefer to organize their directory structure. Especially, if a team member places libraries into his home directory (e.g. C:\User\abcd\libraries\3rdparty.jar or /usr/abcd/libs/3rdparty.jar), another team member will struggle to replicate that directory structure.
Eclipse provides various methods to set up a project so that it can easily be shared between team members. These however require team members to all agree on the convention, and will be slightly easier if set up by the original project author right from the start. Two methods most commonly used:
Add all third-party libraries to the project itself (the usual convention is to have a /lib directory inside the project for this - on the same level as /src and /bin etc.). The classpath can now be set up to be relative to the project's root and thus usable across different setups. A variation for large multi-project-file projects would be to have a separate eclipse project containing the libraries, then add it to other projects as a dependency ("Required projects on the build path" in the "Java Build Path" dialog).
This has the benefit of being able to version control your JARs too. However, it may use up a lot of extra storage/bandwith, so may not always be desirable. For instance, I would not do this with Java Enterprise Edition JARs contained in my preferred Application Server distribution, as I may want to migrate my project in future to a new version or another product, without such dependencies - I also do not want to have my project saddled with duplicate JARs that are in any case already available in the AS distribution. So you need to think through your requirements.
Eclipse also provides the concept of a classpath variable. This may be set up to point to the root of a team member's JAR-containing directory, and be extended with subdirectories and filenames inside the classpath. This needs to be done only once, and is also accessed via the "Java Build Path" dialog.
Whenever a new team member uses the project for the first time, he needs to configure eclipse (once) to point that variable to the relevant path on his own machine.
The above mechanisms are explained in more detail on various web pages, here is one reference: http://www.informit.com/articles/article.aspx?p=367962
In the “create a Java project” wizard.
For the “project layout”, there are two choices:
1) use project folder as root for sources and class files.
2) Create separate folders for source and class files
Which one should I choose?
For the “Working set”
Whether I need to check the “Add project to working set”? What does it mean?
I always choose Create separate folders for source and class files, it's just separate your src files and your output files
The one you choose is up to you. It doesn't matter one way or another, at least as far as your tools are concerned.
The first option means that all files will be in the root directory of the project (typically PATH_TO_WORKSPACE/projectName). Your .java and .class files will be here if you choose that option. The second option will create PATH_TO_WORKSPACE/projectName/bin and PATH_TO_WORKSPACE/projectName/src. Your source files will be in /src and your compiled files will be put into /bin.
My personal preference is to not use the project folder as the root for sources and class files and to create separate folders for source and class files. However, it's all up to you.
In my opinion, choose different folders for sources and binaries. It will make source control and versioning easier.
Working sets only make sense when you are using more than one project for one workspace. I would guess that you won't need working sets until you are more experienced with Eclipse.
it is only a metter of user convinience. eclipse is able to handle both ways.
working set is a way to handle eclipse workspace when you have many projects. to get started, you don't need that.
I've been tasked with picking up someone elses Java code and adding some functionality to it.
I'ved pull down the source tree from CVS and see a bunch of .jar files in different folders. I'm guessing the developer did not use Eclipse.
I am new to Java (coming from .NET background) and have used Eclipse so far to create one Java project. I'm wondering now that I have this guys files (he has classpath.jar and other .jar files along with some subfolders each with 'java' files in them), how do I open them? I tried opening one at a time, etc.. but doesn't seem to work. IS tehre an easy way to do this? I thought there' might be some kind of 'import existing code' thing in Eclipse but I can find it. How can I do this? Do I re-create the folder structure and just add the existing files one a time?
Thanks much for any help
something like 'create project from existing source'?
http://www.stanford.edu/class/cs108/JavaTools/eclipse-guide/
if the existing code is not structured well, you are either going to have to heavily configure your project sources, or just change the project structure.
File -> new
Than select general->folder.
To make developing easier in eclipse i recommend some refactoring to the project.
create a new eclipse project using the parent folder as the home.
every folder that's the root of a hierarchy of java classes becomes a folder in the "source" tab (either on creation, or add through "project->properties").
every jar (at least the ones he's using, there may be extras) gets added in the project->properties libraries tab.
This is assuming that all of the hierarchies belong together and that the thing isn't structured to build little sub-projects out of pieces of the hierarchy. If there's a build file for this thing you might want to be sure that if the build file is doing that you're building things appropriately.
File->Import->General->Existing Projects into Workspace
OR
File->New->Java Project
This will create a sample java project for you. You can add the files appropriately.
Below is an example of a j2ee Project:
http://java.sun.com/blueprints/code/projectconventions.html
If C:\Workspace is the folder you are using as the workspace and you have your existing project placed as "C:\Workspace\ExistingProject"
Open Eclipse Got to File->New Project
Select the type of Project you want to create Use the name as "ExistingProject" for the project and click Finish or complete the remaining steps of project creation wizard normally.
Internally a .project file would be created in the ExistingProject folder and a .metadata folder would be generated under Workspace folder.
If you want to place the ExistingProject not under the workspace u follow the same steps.
There's 2 possibilities:
Import project from file system:
Create a blank Eclipse Project.
Then select File -> Import -> General -> File System. Select project, and point it to your created project.
Importing from CVS
Goto File -> Import -> CVS -> Project from CVS
Enter your CVS Host, Repository Path, Username and Password, and click next,....
Add what you need and click next (follow the instructions) until you're satisfied and click finish.
Hope this helps.
A simple tutorial that incorporates my 1st option and commmits it to CVS: http://thedesignspace.net/MT2archives/000662.html
Two options:
Maven - highly recommended but rather read this: http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html than have me re-write it here. Maven might seem like more effort up front but it pays for itself a hundred times over during the course of even a simple project.
Do it yourself (assuming Helios):
Move the source code Java files to ~/development/MyProject/src/java. Move the jars to ~/development/MyProject/resources.
In Eclipse, File > New > Java Project. Type in your project name.
Untick "Use default location" and browse to ~/development/MyProject.
Select src/java as your source folder (if Eclipse doesn't pick it up automatically).
Finish.
Then, for each error, you will need to find the corresponding JAR and add it as a library to your classpath in the project properties.
The important thing to bear in mind is that Eclipse is not like Visual Studio - you cannot easily just edit one file at a time and that is not what it is designed for. People can get frustrated with Eclipse after working with VS but if you just allow it to do things the way it wants you, your life will be much easier.
trick is finding the root folder. Generally, developers use the following:
project root
-- src
-- bin
at least, what's what Eclipse does by default. There are other ways it can be organized as Maven uses the following:
project root
-- src
-- -- main
-- -- -- java
etc...
More info on how Maven standardizes here:
That said, finding out how the source is organized shouldn't be too hard. Open up one of the .java files and look for the line at the top that starts with "package ". Should be something like this:
package com.somecompany.client.utils
Note, that's just an example, it won't be that exactly although it should start with "package". The value after package represents the path that the file should be in relative to the root of the source folder.
source
folder/com/somecompany/client/utils
So, if you follow the default way that Eclipse organizes things, it should look look like this:
project root
-- src
-- -- com
-- -- -- somecompany
-- -- -- -- client
... etc
SO, as other people have mentioned, you'll import from existing filesystem, point to the folder at the project root. You may need to configure it to point to "src" folder as a source folder. You may also need to import those .jar files into your project as well.
Good luck
I'm tasked with converting an existing Java/C++ mixed web-application to pure Java, but I'm hampered by some missing Java sources (.java files) for which only the class-files are available. Fortunately I don't need to change anything in that code, just need to continue calling the methods.
I created a new Java Web Application project (using Netbeans); recreated the applet by copying it's sources in and got it working in a skeletal fashion, with the calls to classes & methods not in the sources commented out, but I am now stuck on how to add the class-files (of the missing sources) to this project.
(I'm new to Java, obviously) Any pointers on how I should proceed will be most welcome.
Package the .class files in a jar.
$ jar cvf my-library.jar the/package/*.class
Add this jar to the CLASSPATH of your project/application. In Netbeans:
go to the project view on your left
then right click on the library option,
then click add JAR/Folder option.
To add some source/code to your project, classic java project or webapp java project, you have to declare the path to the needed class/jar in the classpath variable.
If you are running your dynamic web project via eclipse, just add the path to the classpath tab in the "run configurations" of your server.
To learn more about classpath, see wikipedia.
The usual approach is to collect all these class files in a JAR file (use the jar tool) and put them on the classpath.
Different from C/C++, for Java you don't need the source code to these other pieces in order to compile the applet. There is enough information in the class file for the Java compiler to do what needs to be done.
So you can uncomment the calls to this code and follow the instructions in the other posts to put the class files on your project classpath.
In the Project window, right click on your project and select Properties. Go to the Libraries category. Then click Add JAR/Folder and select the location of your .class files.