I've created a Maven project in Eclipse on one PC, pushed it to Git, then deleted the local files, and then cloned it from GitHub again.
However, now all those empty folders which used to house tests, resources, etc, are gone.
Should I be worried about that? Is there some Eclipse shortcut which ensures a project conforms to the expected Eclipse structure, or should I add those directories myself?
Add them yourself. The project structure you need is a characteristic from Maven, not from Eclipse.
I do not know if these directories being missing will confuse Eclipse / Maven. I do know that, generally, build systems are smart enough to create missing directories.
However, from a Git point of view, you can force it to keep these directories by simply adding a file to them which is always present in your repository. Common examples of this are creating a "README" or a ".gitignore" inside the directory.
See this question for potential solutions:
How can I add an empty directory to a Git repository?
Related
I am working on a Java Project with Eclipse which we want to put on GitHub so that it is accessible for the public. But we are not entirly certain what is the correct way to put a Java Project onto GitHub. We have already made a GitHub and uploaded a Java Project. But when checked it out, with EGit, to my computer all the folders are now packages.
Is there any way how this can be avoided? How are you uploading a Java Project to GitHub? Are there any difficulties which we are not aware of right now?
A good example I like to use, is my getting started with selenium project.
This is a Maven enabled Java Project that is hosted on github.
But when checked it out, with EGit, to my computer all the folders are now packages.
This is because of your .classpath. If a source folder is added, (like src/main/java) any subsequent folders will be "packages".
How are you uploading a Java Project to GitHub?
Just as you see in the project above. Upload everything, except binaries, and jar dependencies. (which is why i use Maven)
Are there any difficulties which we are not aware of right now?
Where I work, we use a process in which our projects on github are entire java projects. I've heard that it's bad to upload eclipse specific things like .project, but even individuals who use IntelliJ IDEA, it doesn't seem to be an issue, because they can just upload their .file.
One thing to keep in mind, is your .gitignore. Make sure that /target/classes/* and other java specific compilations are avoided as you want your repo to be only source code. (one thing i DID forget to do on that project above.. will fix ;))
I'd rather not upload .projects or .idea files while uploading projects to VCS system (git or not).
I add these folders to my .gitignore file (wich i upload to VCS)
Regards.
I use Eclipse to edit Java, and use Git for my VCS. Should I have my local repository in my workspace, or outside it, and copy the files every time I want to commit? I know I can do it every way, but I'm new to Git, and wondering which way is better.
The best practice at the moment is to create your git repositories outside of your workspace. The most common form of repository contains a couple of projects in some logical structure, and the workspace likes projects in a flat structure. See the EGit User Guide/Considerations when creating Repos for more details.
When importing the projects into the workspace via standard import or EGit, Eclipse is happy to point to the other location on disk.
I just have the local repository in the workspace. I'm not sure why you'd want to keep the two separate - why create extra work for yourself?
Code, commit; code, commit... (where "code" includes tests of course)
Inside it. Creating an external one that you have to remember to copy files to, etc. starts to defeat some of the reasons to use a VCS like GIT :)
You can also always create and 'checkout' branches if you want to get some code separate for now. Then both the branch code and the base code are both in VCS and you'll always be able to mange them for merges, etc.
If you are used to subversion you may have this thoughts first. But working with Git means to have the complete repository as your own workspace.
You should configure Eclipse to use git and add to your .gitignore file the project folder if you do not want to have it in the repository.
As development workflow I can recommend the method Vincent Driessen bloged about: http://nvie.com/posts/a-successful-git-branching-model/
You have to remember that Git is just a single .git directory in your project. So you could just have one project folder that you work off of in your Eclipse workspace. If you are using Eclipse I recommend the EGit plugin.
Inside it; especially if all of your work is in Eclipse. Managing the repo outside of Eclispe is going to make it much more likely to add files you don't want in your repo (ex war/WEB-INF/classes). Also, managing from Eclipse means it will naturally be easier for other developers to sync your repo and setup their environment in Eclipse.
I suppose a good exception to this rule would be if you were maintaining a dev-environment folder of some sort (ex, jdk used/eclipse install used/jars for 3rd party libraries to add to build path/etc). So I guess the best general rule to follow would be if you're using Eclipse to change the files, you should also be using Eclipse to manage the file in your git repo.
Also, use EGit if you aren't already (I think others have mentioned this).
In Eclipse we have a project where we reference an external jar in the build path. When I upload my project to the repository and my colleagues check it out, the build path looks for the jar file in the same place. One of us uses a Mac so doesn't even have a C: drive and my other colleague has a different partition containing the jar, so it always breaks.
How do we fix this issue? Ideally the jar file would be included as part of the project but it seems that the svn commit doesn't include the referenced library.
Thanks
I would suggest you use a build tool (maven, ant/ivy, gradle, etc) along with a repository manager (such as nexus or archiva), depending on what you use to build your project. These store libraries in a central location(s) and then users get the libraries from there.
In eclipse, when you include your .classpath file in the checkin, you will have the issues you are describing, since the .classpath file will contain the path to the file, and then you all must have the files in the same locations. A workaround for this is to create a "lib" directory and put all of the libraries in there. Each of the users can then add all of the libraries in that directory to their path (but do not checkin the .classpath file). This is an older way of doing things before the concept of dependency managers.
Add the jar as part of the project (say in a lib folder in your project) and commit it to svn.
Start using Maven, to resolve your dependencies.
Worst case : Commit the external jar into another project called MyProjectDependencies
You can use Apache Maven to avoid incident like this and to get many others pluses.
You can find many guides on maven, for example this one.
Eclipse has integration with maven.
1.) Check in JAR in a directory inside the project.
2.) Use Maven (or something similar) to manage your dependencies.
3.) Create a User Library referencing the JAR and refer to it this way in your project. Each user will need to create the User Library in their install of Eclipse, but it sounds like you're already doing something similar by referencing the library externally anyway.
if you don't want to use a dependency management tool like Maven, a simple solution in your case would be to use an Eclipse Classpath Variable. All projects can reference the variable, but it will have a different value for each developer.
Set up a Classpath Variable with:
Right click on the Project, select Project Properties
Click Add Variable
Configure Variables
New...
Name the variable and point to a Folder
Now commit your .classpath file. The variable will be referenced in the .classpath. Each developer can configure to their particular directory, and Extend the variable to a specific jar file.
I have a eclipse workspace which constitutes of 15 different java projects . To configure the eclipse workspace , every time I need to add the java projects manually and add the dependency and refrences in the java build path.
Adding all the projects and resolving dependency every time becomes a manual and redundant task. I explored on the .classpath inside the every projects which stores the dependency and refrences information.
I would like to automate this redundant process.
Have any one tried doing that , any inputs will be helpful.
I don't need to add same project more than once , but often need to create a new eclipse workspace with new code changes and delivery (I can't take some of the changes in the current work space).In simple terms for e.g if some one need to create eclipse workspace again and again , or multiple people need to create the same workspace for their work . How can we reduce that manual effort?
I am still a little unsure about your motivations but I am going to assume that by new code changes and delivery you mean a different revision/branch of the same code base. For this purpose and for many other reasons, if you are not using source control like SVN or Git, look into it. These tools are priceless and also free.
Eclipse
I don't think this is technically part of your question but I wanted to add it for completeness. If you're implementing the techniques below, it is also handy to have a 'fully loaded eclipse'. I keep a 'fully loaded eclipse' on a network drive somewhere with some plugins pre-loaded so that new additions to the team don't have to download/install the plugins. It's not hard to do since eclipse doesn't need to be 'installed'. You can just copy the eclipse folder to where you want it and run it. Personally I like to include plugins for source control, code style, code coverage and metrics but you should include anything that you use consistently in your project.
The Workspace
To copy an existing workspace (not including any projects, I'll get to that later) all you have to do is copy the .metadata folder from an existing workspace folder to an empty folder that will be your new workspace folder. When you start up eclipse simply choose the new workspace folder and you will have all the same preferences as you had in the other workspace.
I have used this technique before so that when people join a project they can take a copy of a 'clean workspace' I keep on a network drive somewhere that helps them get up and running quickly. Preferably, this 'clean workspace' should not have any preferences that are only personal preferences like having the perspectives setup just the way you like it but should only have preferences like Ant global properties, compiler compliance level, pre-made commonly-used external tool and run configurations etc.
Projects
For the projects themselves, I would recommend checking them into source control including the eclipse .project and .classpath files. The SVN plugin (subclipse) makes it very easy to do this. Then when someone joins your project, all they have to do is check them out as projects in their new 'clean workspace' which is also very easy to do. Since the project you're checking-out already has the .project and .classpath files, all of the dependencies are already setup! Just make sure that all the jars and any other dependencies are checked-in with the projects.
Workspace Setup Procedure
Take a copy of the 'fully loaded eclipse'.
Take a copy of the 'clean workspace'.
Check out the projects into that workspace.
That's it! Your new recruit should be ready to go!
Multiple Code Branches
Now, if I was right to assume that by new code changes and delivery you mean a different branch of the same code base, creating a workspace for a different branch as easy as following the same steps but checking out the required revision or branch instead of the latest version from the trunk. If you don't quite understand what I mean by that, read up on source control.
Cudos
Good on you for taking the time to do this, I have been in projects where it can literally take a day to get setup...
Maybe little late, but stuck into the same problem and found a tool in eclipse marketplace that helps to manage setting up and launching eclipse all time for different branches, new developers or other reasons.
The tool is called yatta.
With this, one can create profiles which can be based on their current running eclipse with all the tools, plugins, workspace, CSM repos and what not.
This profiles can be exported to yatta profile hub which can be public or private and later shared with different developers and can be imported and launched.
You don't say whether you're using a build tool other than Eclipse, but if not you should.
Eclipse is able to parse Ant files to discover the source directories and libraries. And Maven and Gradle can both generate Eclipse project files for you to import.
As a longer-term benefit, using a build tool means that you can easily build and deploy your projects without any need for Eclipse. And it will be easier for new team members to work on the projects, as they won't need to figure out all the dependencies.
If you don't already have people with expertise, I would recommend Maven. It's easy to set up a basic Java build script, and its dependency management features are IMO better than the alternatives. It will, however, force you into its way of doing things, particularly wrt source tree layout.
You should really look into build tools like Maven, Ant, .... Those can generate needed classpath variables for you automatically and can do many more things as well
If you're checking out the projects from CVS / SVN in Eclipse, then it's possible to create a Team Project Set. This is essentially an XML file that will contain a list of projects and their source repository path
It can be exported via File | Export | Team | Team Project Set, and imported into another workspace via File | Import | Team | Team Project Set
There's more information on this feature at this link on Javalobby
Using vagrant it is quite easy to automate setting up an entire desktop development environment.
See the answer I provided to a similar question here, which has links to scripts that automate checking out maven projects, creating an eclipse workspace and importing the projects.
I want to checkin a Dynamic Web Project I created in eclipse into svn. Can someone tell me which files I have to check in and which one I should not? The idea is to be able to check out the project using the New Project Wizard so that I can create the Dynamic Web Project again. More specifically here are the files/directories I have in the project --
src
WebContent
build
dist
build.xml
.project
.classpath
.settings/
The build directory is not supposed to checked in obviously. What about the other ones?
I am guessing all the . files should not be checked in either. Can some one verify this?
What is this dist directory and the .settings directory?
Also where does eclipse store the Server information (tomcat)? I don't want to check it in either.
EDIT:
I initially checked in all of the above except the build directory of course. When I checked out the project from inside Eclipse it did not prompt me to create a new project since the .project is there but Eclipse was creating a JavaEE project or something instead of the Dynamic Web Project. Did anyone else run into this behavior?
** EDIT 2 **
Found it! Turns out I should not check in the following --
.project
.settings/
.classpath
Once these 3 are removed the New project Wizard works as expected and everything is fine.
If you check in .classpath/.project/.settings you make your project Eclipse-specific. What about developers who work with Netbeans or IntelliJ? IMO it is cleaner to keep your project IDE-independent and easy to set up.
I usually go for a Maven build. The pom.xml specifies all the required dependencies and mvn eclipse:eclipse generates the .classpath/.project files for you.
The .settings directory contains local settings (like which Java version you want to use). IMO it is not useful to check this in. You can enforce Java version compliance via the Maven2 pom.
Finally, for your next project, my protip is to svn-ignore the files or directories you don't want in SVN before your first commit. In a Maven2 setup that would be .settings .classpath .project target (the default output directory of Maven2) and any other generated stuff (log files, gfembed directories, etc). In your case you would ignore build and dist instead of target.
You can svn-ignore files or directories with RIGHT_MOUSE->Team->'Add to svn:ignore' (I use the Subclipse plugin). Ignore instructions are stored as svn-properties on the parent directory. The properties on a directory can be viewed by RIGHT_MOUSE->Team->Show properties. You can also edit the properties directly there by clicking on the value field. Make sure there is an end of line after each property.
Now that you have already committed and then removed these files, ignoring is not going to work anymore in my experience. Somehow I have never managed to successfully ignore generated files which have ever been checked into the SVN repository; they are like zombies, always coming back from the dead. Maybe by deleting their entries physically in the SVN repo this can be achieved, but I've never done it.
In our case, we have checked in all you mentioned in the list except, .settings/.
With .classpath and .project checked in, users can quickly check out the project and fire up Eclipse on a new computer and just start working on it; the alternative being to configure the project manually and adding in all the jar dependencies painstakingly (if you use ant). Many open source projects do this.
Read this, there are some really good points to ponder about.
Good Question... Many of us are in a dilemma on whether we want to check in IDE related files or not. I normally go for checking in .classpath for eclipse and I use eclipse variables to make sure that team needs to just change the variable value and it works. We also check in .project so that team need not to create new project in their workspace.
I would omit the .project, .settings/, dist, and build.
The .classpath can be left in if you use variables instead of hardcoded paths. This is useful so you don't have to rebuild your classpath every time you check out the project.