I have created a Dynamic Web Project in my Eclipse workspace. It is also a Maven project, and under SVN control. But in "Open Resource" (Ctrl+Alt+R) no file from this project appears, unless I check from the window's options (top right drop-down) "Show Derived Resources".
I have checked on some of the project's folders and they are not marked as "Derived".
I have two more (plain Java) projects in the workspace, and all the files from them are visible in "Open Resource".
Do you know what might be wrong with either Eclipse, the Maven plugin or Subclipse (the SVN plugin)?
I experienced a similar issue in Eclipse (Ganymede), when using the Maven and Subclipse plugins. I have not determined which plugin caused this problem, but I suspect that it is related to my pom.xml containing nested modules (ie. a <modules><module>main-module</module><module>integration-test</module>). These appear in Eclipse as nested folders with their own pom.xml files (I did not use the Multiple Projects plugin although I have installed it).
I assume that one of the plug-ins has incorrectly set the derived flag on these folders when I checked out the project by SVN and then updated the MVN dependencies and project settings.
When I right click->properties on the top-level nested module directories I can see the Derived flag is checked. By unchecking the derive flag on the module directories (and checking the derive flag on the target directories within each sub-module instead), it fixed the Open Resource functionality.
As the derived flag is inherited from directories, you may need to check all of your directories in the hierarchy to find the 'culprit'.
If it helps the plug-in authors, my top level module directories contain a hyphen '-' in their names. Maybe that is throwing out one of the plugins.
I think it is the maven plugin:
Jira issue
See also the notes for July 31, 2008 at the New and Noteworthy page for m2eclipse.
Several other nice links deleted because of restrictions of stackoverflow.
In fact, I think that somehow this is eclipse in its own right, as I don't have m2eclipse or using maven for this.
By default, eclipse uses /bin as the target directory. My situation is similar to having maven in the project in that the target directory was changed to lib/classes to accommodate an existing project.
I started seeing issues similar to what is reported here, and while searching for the problem, came across this solution. Eclipse somehow didn't "uncheck" the bin directory as no longer derived, so I ran into the same issues. I tried replicating it, but I couldn't.
Related
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.
This issue is a variation on the one described here: Eclipse buildpath automatically taking all JARs of a internal directory
But instead of any local folder, I'd rather have a linked folder from another project be picked up automatically in the buildpath.
Basically, I have a main project in my workspace that holds directories lib, ext-lib that contain multiple jar files each. These jar files may be upgraded/removed or new ones added every few days.
I also have many other projects in the workspace that relay on the exact same (up-to-date) jars from my main project.
My goal is that as I modify the jars in these two folders in my main project, to have them as linked folders in all other projects and have those linked projects dynamically picked up as part of the buildpath of all those projects.
Any suggestion on how to do that in eclipse would be highly appreciated.
Unfortunately, the "dynamic directory" plugins people mention can not work with "linked" folders :(
Sincerely,
Guy
I would suggest creating a USER LIBRARY in eclipse and then using that in all of your eclipse projects.
Try going into preferences Java -> Build Path -> User Libraries and creating a new user library with all your jars. Then use this everywhere you need these jars.
See this page for more details.
Also, this page explains creating a user library in a bit more detail. There is also a use-case there which seems a bit more aligned to what you had in mind:
6.2.1. Linked Library Project
A useful hybrid strategy is to configure a user library that is also available as a linked folder in your Eclipse workspace. Follow these steps:
1.
Create a simple project in your workspace. Unlike Java projects, a simple project has no Java build path configuration in its properties. Use the command File > New > Project > Simple Project.
2.
Uncheck the option to use a default project location within the workspace folder and enter the path for your \eclipse-contrib\libraries folder (see Figure 6-8).
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.
What is the "correct"/better place to put eclipse's .launch files in a maven/gradle project? I want to commit my run configurations but I don't know where to put the files
I know maven and gradle are always about standarization so I rather ask than put them in a random folder and then get in trouble with some plugin
After creating a launcher on each maven module now I have each launcher appearing twice in eclipse. This is due to the fact that when I check out my multi-module project it creates an eclipse project for the top POM as well as for each child POM and all the files are "duplicated" in the Navigator view, once for the top and once for each module. This to me means that either I have some problem in my maven organization or that I am putting the launcher in the wrong place
Edit
Since I asked this question I learned of a new way to solve this. Enable an experimental feature in eclipse which will prevent the subprojects to appear in the top project. The setting is under windows/preferences/maven/Hide folders of physically nested modules
The standard location in Eclipse is in the project's root directory, that's where I always save them (and commit to SVN). Maven will ignore them there by default, so they will not show up in your artifacts.
One additional thing to keep in mind (since you mentioned that you want to commit the launch configurations to SCM and possibly share them with others): Avoid absolute paths in the launch configurations, since they will probably not work for other people. Try to use relative paths or Eclipse variables pointing to your local resources.
Edit: moved comment that answers the question
In this case you might consider moving them to a sub-directory (launch?). It should be one that is ignored by Maven by default (so not src/main/java or src/main/resources. On the other hand, I'm not sure whether Eclipse will pick up the files from a sub-directory... I've always kept them in the project root.
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.