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.
Related
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.
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. :-)
I want to create a runnable Jar using Eclipse export tools.
However, when I export my project, Eclipse includes .svn directories in the Runnable jar.
I try to exclude these directories using Eclipse properties without success (using **/.svn/* in the source excluded file ; I also try other combinations like **/.svn, **/.svn/, .svn, etc...).
Does anyone know if it is possible to do that or should I manually delete the .svn directories from the executable JAR?
You can pass to the recent >1.7 working copy format (update your svn clients). It make no more use of .svn directories, so you won't have the problem anymore.
If you use external clients (such as TortoiseSVN) you must conform your plugins for svn in Eclipse (subclipse, etc.) to >1.7 version too.
The new working copy version does not work with older ones (they must be converted),
If you use a Maven build to build your jar, the .svn directories (among others tipical SCM systems control directories) are excluded by default behaviour; see in particular the maven archiver plugin configuration to have an executable jar.
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.
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.