I'm trying to develop a small project using Eclipse and the Google Web Toolkit.
It's a (small) group project so I want to use SVN.
So far I have created a GWT Project in Eclipse and added it to my SVN Repository.
The problem is that when I use 'compile' on the project, it breaks SVN's metadata and the whole war-directory is marked as broken. (Red Exclamation mark).
I then cannot commit and/or update - neither can I just ignore the war directory because of the web.xml / appengine-web.xml files which Eclipse complains about when they are missing... Cleanup also fails.
So far the problem -
Does anyone of you know how to properly set up a new GWT Project with SVN?
Which files need to be ignored? Which files can be committed? ...
A beginner-friendly solution would be great!
Thanks in advance
In the answer below I'm assuming you're not using Maven. I tried to answer generically as well so the below should apply to any version control system (I'm on Bazaar).
You want to commit the files which constitute the application source code (e.g. *.java files) and configuration metadata (e.g. *.xml files). Some (like me) also like to commit Eclipse project configuration (.settings, .classpath and .project), even though doing so might on occasion cause some inconvenience to other team members due to differing Eclipse setups. I think the convenience of not needing to guess which Eclipse natures the project has or what's supposed to be on the classpath is worth it (Maven helps even more, but that's a separate discussion).
You want to ignore the files and folders which are build products (and hence are temporary and reproducible by nature). For GWT apps developed in Eclipse using the Google Plugin for Eclipse these are typically war/WEB-INF/classes, war/WEB-INF/deploy and war/<module_name>, where <module_name> is the name GWT uses for the folder where it places your GWT module compiled into JavaScript/HTML. You might also want to exclude .gwt where GWT dumps log information during work in Development Mode.
Also in your project directory be sure to ignore the gwt-unitCache. This is where gwt stores a manifest of what units have been compiled for re-usability.
Hope this helps.
Related
I have a netbeans project that is under mercurial. What I would like to do is to strip down everything that makes this project netbeans project to only to leave code in there so that I can easily import it in say eclipse.
Is there some automated way to do this or do I have to remove manually this?
What approach would you recommend.
Cheers
You only have to add the nbproject folder to ignore (= don't check in). All NetBean-settings are placed in this folder. Dont check in the build and dist folder as well, because these contain the compiled code (but they are ignored per default).
The best way to do "IDE neutral projects" is to use Maven !
In NetBeans when the project is Maven-based (as opposed to Ant-based) you'll see that all those NetBeans-specific files that you normally see in nbproject folder are just not there. The nbproject folder doesn't even exist. The reason is that for a Maven-based project NetBeans essentially uses the pom.xml as the definition of the project and that's a good thing because the POM is portable and directly understood by other IDEs.
Even for a Maven-based project NetBeans will still store some IDE-specific stuff in a file called nb-configuration.xml but you can include all of the contents of this file as properties inside the pom.xml. These properties will then be ignored by other IDEs when they load the POM. This way you can pretty much avoid altogether to check any IDE-specific files into the VCS. Also it is worth mentioning that the stuff in nb-configuration.xml is never needed for someone else (using NetBeans or another IDE) to be able to build your project. Another way to put it is that it contains non-essential data. The POM - by virtue - is always guaranteed to be a complete description of how to build the project.
Contrary if your NetBeans project is Ant-based then at least in my experience you cannot avoid checking NetBeans specific files into the VCS ... because otherwise even those using NetBeans won't be able to correctly open your project.
However even with Maven there's one area where you'll be forced to have NetBeans-specific files in the VCS and that is if you use the Matisse GUI builder in NetBeans. The Matisse GUI builder produces some proprietary files with .form extension and you really need to have those in your VCS. But this is the only example I can come up with where NetBeans-specific files will need to go into the VCS assuming your project is Maven-based.
If the project indeed is Maven-based and you still feel that there are NetBeans-specific files that you need to have in the VCS then let us know exactly which files you're thinking of. Then we can take it from there. :-)
Should I put .classpath, .project files and .settings files on SCM when working with Maven project with m2eclipse plugin? Theoretically every developer can grab the sources and import maven projects.
Due to your experience is it better to do this that way or to put Eclipse files to SCM too? Some developers are using InteliJ so I don't want the projects to be Eclipse specific. It seems that the .project file may change according to the set of installed plugins, e.g. change buildCommand from org.eclipse.jdt.core.javabuilder to org.eclipse.wst.common.project.facet.core.builder etc.
Please share your knowledge and experience.
In my experience, you should not include .classpath, .project or .settings. All the information needed to re-import the project is in the pom file, so long as you use "import existing maven projects".
If you put all those local ones, you are likely to end up having SCM changes for irrelevant things, such as different order of entries, local modifications someone made to their project preferences, etc...
As per my experience , it is safe to check-in .project file as it defines the nature and other properties which is useful for developers who will be creating new workspace. Many times, custom facets needs to be added via Eclipse and you may want to share it with other members of your team provided all others use the same IDE for example RAD.
They won't have to go through the pain of again setting and changing project nature, so it might help. Even we had to share our .settings folder in most cases because ppl were facing issues with workspace setup. So all depends on the need and it might help.
One situation in which it is very convenient to have Eclipse project files under version control is when you have Java code automatically generated by plugins. Eclipse removes missing source directories from its configuration before code generators run.
UPDATE
With recent Eclipse releases (I'd say since Juno, certainly since Mars) this is no longer the case.
Over the years the m2e plugin was greatly improved and nowadays there is really no need to store project settings in your SCM, as these settings are properly recreated from the project POM. This has the added benefit of allowing the use of different Eclipse releases with the same project.
When I commit a web appliction to source control should I also include the .project & .classpath files ? I don't think it should make any difference either way as other users who use the project should have the same project settings ?
This is the sort of question that gets people bent out of shape in a debate that never ends. You basically have two camps:
Only put source code into the source control system. Each developer chooses their own IDE and manages their own project configuration. Setting up your IDE after getting source code from the repository will be tricky. If one dev changes project dependencies, they have to explicitly communicate that so that all other devs update their project configurations. There are some tools that try to address this problem, like a Maven plugin that will attempt to generate Eclipse project metadata from pom.xml, but all have their limitations. Groups that go this way favor the purity of not restricting developer choice in IDE over the convenience of having Eclipse projects across the team that just work.
Standardize on Eclipse. Put all Eclipse project metadata into source control. This includes .project, .classpath and the entire contents of .settings. Basically, the only thing that you don't want in your source control repository is content marked as derived in Eclipse. You can check that in right-click->properties. Taking this approach ensures that developers can get started coding immediately after getting the project from source control. No additional configuration required. Also, when one dev changes project configuration, the rest of the team will see the same change on next sync.
Choose the approach that makes the most sense for your team.
For ClearCase, including the .project and .classpath can make a difference when you are using the IBM ClearCase plugin for Eclipse.
That plugin will work better if it can rely on those (versioned) files being there, right next to the sources (as opposed as being in the Eclipse workspace, which doesn't necessarily contains said sources).
In general, nothing generated should go into repository. Those files are generally generated by IDE or maven. However, sometimes you may need to click a button or execute a command to get those generated.
i would include them.
The .project file have plugin info (e.g. maven, ant, pdt, wst, aspectj, findbug..). It is essential if it is not a plain java project.
.classpath contain the classpath. it is needed if you use jar files.
I would say that all files - including .project and .classpath - should go to source control, to ensure that everyone in the team has the exact same setup.
When sharing a project with team members through version control, it is customary to include the .project in the source under version control. This makes sure that others on the team get all the dependencies and resources for the project. But the .project uses full/rooted paths to the resource, and not all members of a team will be working in the same environment. Even if all the members are on the same platform, the paths can often be in the user's home directory.
For the .classpath file, we can get around this problem by using build path variables. Each member defines the path to location of dependent libraries on their system, and the .classpath only refers to the variable.
This is a particular concern for Grails project - when we add a plugin, it updates the .project accordingly.
IMO resources themselves should not be part of the project at all. There is excellent plugin called m2eclipse which simplifies such tasks using Maven. It will immensely simplify your dependency management. All you'd have to keep in your version control system, besides your source code, is project configuration (pom.xml) - all the dependencies will be downloaded and cached automatically no matter what environment developer works in. There a lot more advantages in this approach - just read up on it :)
UPDATE: Just noticed "grails" tag on your question. if you're using Groovy - Maven can be replaced with Gradle. STS is probably the best Eclipse build to use if you're coding in Groovy. Next version of STS will have Gradle support.
General Approach
As others have mentioned, you should not keep the IDE files in VCS, you should keep an IDE-agnostic description of the project in VCS and generate the IDE-specific project files from them.
Java-Maven Example
Keep the pom.xml file(s) in VCS and generate the Eclipse files by running mvn eclipse:eclipse
Grails Example
A Grails project is described by application.properties and grails-app/conf/BuildConfig.groovy. These files are present in every Grails application. You can generate the Eclipse project descriptions from them by running:
grails integrate-with --eclipse
This command also supports other tools such as IntelliJ and Textmate
I don't think its standard practice to include the project file. I personally tell my VCS to ignore all IDE files, and just use VCS for the source. I include at the root level a README telling others how to configure the project (e.g. jars are in lib)
The resource links feature that you are referring to also has ability to use path variables. These are defined under Preferences -> General -> Workspace -> Linked Resources.
You could try keeping the project files in a shared Dropbox with an agreed upon path for each developer.
I'm an Eclipse newbie, and I have an Eclipse workspace with projects for a Google Web Toolkit App. What directories/files should I commit to version control (we're using Subversion)? I believe I don't need to commit .metadata directories, and it seems to me that I don't need to commit war directories, but I'm not positive. The committed projects need to be shared across multiple developers.
stacker covered Eclipse's files, let me cover GWT ;)
Assuming you are using the standard layout:
The war directory is the deployment
image of your web application. It is
in the standard expanded war format
recognized by a variety of Java web
servers, including Tomcat, Jetty, and
other J2EE servlet containers. It
contains a variety of resources:
Static content you provide, such as the host HTML page
GWT compiled output
Java class files and jar files for server-side code
A web.xml file that configures your web app and any servlets
So as you can see it's a mixed bag. As it's been suggested before, you should use svn:ignore to let SVN know what exactly you want to put under source control - obviously the compiled output and class files are out :)
You shouldn't commit directories which contain artifacts as well as the .project file which would demand to checkout the project into workspace. (which isn't desirable if you need to work with different versions of your project).
Unless you use maven you might want to add the .classpath also to your version-control system.
Keep in mind that all team-members have to be careful to add only relative-paths to the classpath.