I set up an Eclipse project with Maven. The sources are versioned using Git. The work environment is Windows.
For some reason a "Users" directory is visible in the project tree, containing the following structure:
Users
+--kaupps
+--git
+--<projectname>
+--<projectname>
+--target
+--m2e-wtp
+--web-resources
+--META-INF
+--maven
+--<EclipseProjectName>
| +--<EclipseProjectName>
| +--pom.properties
| +--pom.xml
+--MANIFEST.mf
What's the purpose of this directory and do I need to check it in to Version Control or is ignoring it better? pom.xml at the project's top is checked in already.
You should exclude the target-Directory from source control. Usually generated resources from maven are put into that directory.
This is basically equivalent to excluding bin/ from source control since both directories contain build-process artifacts that can (and often will) change on every build. Versioning them is not useful.
c:/Users/<username>/git/ is the default directory of git. This is where the project is located on your disc. You should just check-in the <projectname> directory.
Related
I currently switched to eclipse and trying to migrate my projects. I created a java-workspace and used 'File->Open Projects from File System'.
The project with all the folders is added, not only the 'src' but everything I put into it (datasheets, documentation,...). Also the libraries are added two times. One time in the folder and what seems like a link to the compiled library.
folder structure
In netbeans I just added the desired library to the /libs folder and linked it to the project.
Can I manually add folders and/ or libraries to existing projects? Why are there two instances of the libraries?
By using Open Projects from File System, folders containing .java files has been configured as source folders (source code intended to be compiled). This can be undone via right-click Build Path > Remove from Build Path (the reverse function is Build Path > Use as Source Folder).
In the Package Explorer, source folders are shown as virtual folders. If the source folder is not a subfolder of the project, it is displayed as virtual folder in addition to the project subfolder to be able to navigate to that non-source project subfolder (in your case you have a single src source folder and in addition to the non-source folder lib you have multiple virtual lib/... source folders).
The node Referenced Libraries lists all JARs and class folders on the Java Build Path (classpath/modulepath). To remove something from the Build Path, right-click it and choose Build Path > Remove from Build Path. JARs can be added to the Build Path by right-clicking the JAR and choosing Build Path > Add to Build Path. Class folders can be added only via Project > Properties: Java Build Path in the tab Libraries with the button Add Class Folder....
I dont know if this is a workaround or good practice for migration:
Create a new Java-Project in Eclipse
add desired Folder structure (including /libs)
In 'Project->Properties -- Libraries' add libraries manually
Clean and Build Project
I have to test functionality and stability but it seems ok.
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.
What are the typical entries in your source control ignore files for a GWT App (developed in eclipse)?
I would recommend:
you leave the eclipse files (.project, .classpath, ...) in your VCS,
you ignore what is generated by GWT compilation, like in this project
(.gitignore)
:
/build
/classes
*.jar
*.class
*~
*/web-app/gwt
*/web-app/WEB-INF/classes
target
The name of certain generated directories can vary slightly, so you should adapt them for your project.
In addition to VonC's eclipse/ant/maven suggestions, I'd add the a few more gwt-specific entries:
.gwt - compilation logs
gwt-unitCache - caching for already compiled files
www-test - gwt junit compilation files
Personally I'd stay away from trying to blacklist files/folders in any webapp dir, except either on a project-by-project basis, or by making sure that your compilation process builds gwt compiled files to another dir in a build/ or target/ dir - this might make things more annoying to start up, but you won't need to customize .gitignore with any new gwt module.
I'm using NetBeans to develop J2EE web service.
NetBeans create a directory called nbproject inside my project directory.
I'm wondering if I should put this directory under source control. I think it is required to build the project without NetBeans.
This is usually not required. Think of it this way: If I was to check out your project but happened to be using a different IDE, I would not require your nbproject directory. In other words: This directory is machine specific, not project specific. Hope this helps.
The nbProject folder contains all the netbeans metadata about your project. When you go Project -> properties all the settings (and others) that you find there are stored in the nbProjects folder.
EDIT:
This has been answered in another question, and the answer there is more complete and accurate
In short you should include nbproject, but not nbproject/private
If you are building your project with Maven or Gradle you should definitely exclude the folder from the VCS.
in my Java Eclipse project that contains JUnit tests, I also have a package "resource" that contains all input data used for the tests. But when compiling JUnit tests, the Java compile also data available in resources, so I find the same data in the "bin" folder. Is there a way to avoid this?
thanks.
If you have a particular package within the source path you want to exclude (your resources folder for example), you can right click on the package and select: Build Path > Exclude.
This will tell Eclipse that you don't want to include that package as part of the build.
This is making a couple of assumptions: that you're using Eclipse Helios (because the option might be different in older versions), and that the resources are stored in the same folder as your regular java source files (because if resources is in a folder by itself, you can remove that entire folder from the build by using Build Path > Configure Build Path -> Source tab.
Update:
After the discussion in the comments regarding why you would or would not want to copy resources into the bin directory:
The contents of your bin directory should be ignored and not checked into to a version control system (when using CVS, bin should be an entry in the .cvsignore file)
The resources are only duplicated on your local machine, which is fast and hard discs are big. I'm not sure you should be worrying about this
If you're using Class.getResource to access those resources, they need to be on the classpath somewhere. The bin directory is as good a place as any
So, realistically (barring some unknown, like the files are hundreds of gigabytes or something), I don't think you need to be concerned about excluding these files from the build.