I'm with a small team sustaining a Java-EE based web project. We're using Eclipse exclusively as the lead programmer is uncomfortable with Maven and doesn't know NetBeans at all (and the organization we work for won't buy a commercial IDE). We use GIT as our source control system.
We've solved a number of multi-programmer issues with Eclipse (e.g. how to define external jars with relative instead of hard-coded paths), but we've still got an annoying one. Frequently each of us has to go into the build path for each sub-project (there are 14 of them) and reset the JRE system library after a merge (from our remote master, and therefore from stuff pushed by the other programmers). We can't seem to see any rhyme or reason for it; it will reset the minor version of Java to one that none of us has installed (Java 8.0_77), or set to a blank "alternate JRE", or some such other issue. Early on, we sometimes did each have different JDK/JRE installed, but we're completely in sync now. We've tried using all three options (Execution environment, Alternate JRE and Workspace Default).
We cannot be the only people using Eclipse and GIT in a multi-programmer environment. How do you set up the Java library (or what workspace files have to be included in GIT) so that everyone stays in sync? Is there a way to do it so that when the Java version is updated (now automagically by our IT/IA people whether we want them to or not), Eclipse doesn't get confused by insisting on a specific minor version?
All of the 'resetting' answers I've found on Stack Overflow seem to deal with issues caused by the m2e plugin, which we're not using. Also note that we store the .settings and .classpath in GIT, but not .metadata, mostly because we frequently have to completely wipe out and recreate projects when we switch between branches (which is a subject for yet another question at another time).
These are some tips that may help:
At eclipse, go to Window > Preferences > Java > Installed JREs.
Verify that all your team have (at least) a JVM with the same minor version (I explain, jdk1.6 or jdk1.7 or jdk1.8) ... This will depend of the target JVM of your project! ... Also verify that everybody have the same JDK as default!
Then, go to "Execution Enviorments" and set a JVM for each JavaSE Version! Example:
This acts as label for your Java Environments... this way any eclipse project can say that it works with JavaSE8 instead of jdk1.8.0_70 or jdk1.8.0_60 (and the eclipse metadata files would not have to change between programmers)
Verify that you're versioning the .classpath file for each project and submodule. Verify that you're file has a node like this:
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.8">
Verify how this file is being stored at GIT... may be it's being updated between programmers because a bad IDE configuration.
Check if when you import your project into the IDE, the .classpath file is being modified... particularly, the <classpathentry kind="con" node
And for last (and may be the most important!), change your "Lead Programmer"! (Seems lost and clueless)... Any experience programmer will tell you that implement this kind of development environment only brings problems of Maintainability and High coupling (problems that you're facing right now)... In other words, you're going backwards and coding like the year 2003 or even before...
Take my advice, use MAVEN and let anyone use the IDE that they want (at my team, we're are 6 or more developers, and some use eclipse, some netbeans and some intelliJ, in the same project!)...
Related
I am trying to get started with Eclipse SCADA and import the projects from their git repository.
I have cloned the following projects:
org.eclipse.scada.external
org.eclipse.scada.utils
org.eclipse.scada.base
org.eclipse.scada.protocols
org.eclipse.scada.core
org.eclipse.scada.releng
For each project I did mvn verify in the parent folder and imported the projects in Eclipse. I also changed target platform. However, I still seem to have problems with their dependencies.
Any help would really be appreciated.
Actually the Eclipse SCADA java projects are not developed with "Maven first". So you should disregard maven completely while in the IDE. The maven build is basically only used to build the project unattended.
The issue with the target platform is more complex. We were a bit sloppy in providing a always working target platform (and it is actually difficult to keep them up to date, since the versions of the bundles are fix).
I made a target platform file for the current version, you can find it here: https://gist.github.com/CptMauli/ec6eda37734f0108510f
To make it work properly please download a classic eclipse put it somewhere and create an environment variable ECLIPSE_432_HOME which points to it. Alternatively you can just change the first entry in the target file and point it directly to it.
The reason behind it is, if you would use your own eclipse installation, it is possible that bundles installed there conflict with bundles provided in the target platform or from your workspace. This is actually mostly not even a problem when compiling, but as soon as you start a client or a server, Eclipse will complain about duplicated bundles.
If you have any more questions please go to our mailing list: https://dev.eclipse.org/mailman/listinfo/scada-dev
or our google group: https://groups.google.com/forum/#!forum/openscada
or write to me directly at juergen dot rose at ibh-systems dot com
Is the file .settings/org.eclipse.jdt.core.prefs part of the project or is it part of my personal eclipse configuration?
Should I add it to version control?
Yes, you should. If this file is not under version control, then you cannot create reproducable builds of the same project, because it is no longer self contained, but depends on your specific Eclipse installation and its settings.
If you import this project into another workspace (on your or any other machine), it may behave completely different, as the compiler compliance settings, the compiler warnings configuration and a lot of other stuff is suddenly missing or different. Chances are high that such a project suddenly shows warnings/errors in the new workspace, while it was completely fine before.
Note: This all also requires that you actually configure all Java related settings in the Project properties. Never use the Java compiler settings under Window -> Preferences if you want to have self contained projects.
Just to give a concrete example: If you have configured your projects compiler compliance level to Java 6, because you are using Java 6 specific features (like Override annotations on interfaces), then the project will create a lot of compile errors on other peoples machines. This is because the default compiler compliance level in every Eclipse workspace is Java 1.5, and in Java 1.5 that Override annotation is simply not allowed.
This doesn't have anything to do with whether you are developing closed source or open source, as indicated in the other answer.
Contrary to #nitind's opinion, no. You should not put any IDE-specific settings under version control. Except you are developing IDE features or plugins.
In case you really have mandatory team-wide IDE settings, putting them under version control would be a good idea, but IMO having mandatory team-wide settings is not a good idea in itself.
For all other cases, shared IDE settings are bad for portable builds, even with the same IDE, and useless at best for users of other IDEs.
EDIT: I should differentiate, depending on the target group of your project. If you are developing a closed source product in a team that works with eclipse, then keeping these preferences under version control is helpful and a good idea. If you are developing a library, closed or open source, or an open source project, I consider ignoring the preferences more appropriate and polite.
EDIT2: I'm afraid #Bananenweizen is misunderstanding what I am trying to say.
I know that these settings are the eclipse compiler settings. They are still IDE-specific in the sense that they won't have any effect in Netbeans or IntelliJ as they won't have any impact on ant or maven builds from the command line.
Yes, leaving these setting out of version control can bring you many red wavy lines in eclipse on a different machine. It won't, if it's a maven project with a set source level by the way, I'm not sure about ant.
Eclipse is not building the projects by itself - it builds them with ant if it's an eclispe or an ant project, or with maven if it's a maven project. Both ant and maven have specific settings for the source version that do not depend on IDEs.
And this is where these settings ought to be - in the build file. And the build file should be under source control. The exceptions I mentioned earlier still apply.
EDIT 2020.03.15 #howlger informed me that the usability of these formerly eclipse-exclusive files has improved. They can be used in VSCode and maybe IntelliJ. This improves their chances of being useful across IDEs and may change your decision towards sharing them.
IMO, the files are mixing concerns. While I support source level and code formatting as being part of the build, I consider issue highlighting rules, save actions and similar concerns to be out-of-scope. If possible, I separate those, sharing the former by putting them into the build definition, but not the latter.
Here is the problem with putting it under version control....
If you import and open a project, Eclipse insists when IProject.open(...) is called on touching the file in the .settings folder... and this is before you can register the team provider on the IProject object. That means validateEdit won't fire and you get annoying errors whether you click "yes" or "no" on the popup asking "do you want to make it writeable?" That's all well and good for optimistic file-locking providers, but no so great for the "pessimistic" ones. For us this is just been yet another eclipse annoyance.
If it's up to me, there is no way I'd put these in source control.
The answer is "yes" and here you find the motivation for it and the proper way to do it: watch the talk "Committing IDE meta files: misconceptions, misunderstandings, and solutions." or look at the corresponding slides from EclipseCon Europe 2015 by Aurélien Pupier #apupier (Senior Software Engineer, Eclipse specialist).
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.
I use the google plugin for eclipse with GWT and Appengine libraries. Every so often I upgrade one of the libraries, which currently involves:
I install the update somewhere on my HD
I add the update as an alternative SDK in eclipse, with a generic name
I update the project settings to point to the new generic name
I commit the changed settings files (which do NOT include the upgraded library) to our source control
The problem here are in unfortunate steps 5-7:
5 Everyone else's builds stop working past the change,
6 I go from machine to machine, repeating steps 1 and 2, and
7 I think for the nth time, "I should really find a way to automate this."
I'm here for the elusive step 8: Actually automating this. I want to include the SDK in my source control, so when I switch between versions or set up shop on a new machine, the relevant SDKs are automatically installed and downloaded. I don't want to have to configure eclipse settings at all. In my ideal situation, I am willing to install Eclipse and the GPE on each machine, but after that I just want to clone my repository and go.
I've tried doing this by removing the GWT library from my build settings, copying the entire GWT installation folder into the root of my project, and adding gwt-user.jar and gwt-dev.jar to the build path from there. This almost works, but eclipse complains that it can't find gwt-servlet.jar (even though it exists precisely where it claims to be looking for it!). There also seem to be other magical settings I don't understand.
Finally, the question: If this is the right track, what settings do I need to manually control? If this is the wrong track, what's the right one?
+1 good question. This may or may not answer your question, but I can share with you what I do. I also work with GAE and GWT.
I just include the SDK .tar/.zip files in my repository, remove the version numbers from the filename, and update it when I want to move to a new version. If that version migration fails, I can easily revert to the old SDKs. I also use GXT and a bunch of other GWT extensions, so my problem is even worse than yours. I don't use eclipse for GAE nor GWT, so I can't relate to the problems you are having there. If you don't want to have to configure eclipse every time, then don't use eclipse.
Disclaimer: I hate eclipse.
I have an application that is composed of about 10 different Eclipse projects. Some projects must be built with Java 5, and others with Java 6. I have both of these JDKs registered with Eclipse's "Installed JREs" list as "jdk5" and "jdk6", respectively.
The appropriate JRE is on each project's build class path, which is reflected in the .classpath files. However, other members on my team are using different symbolic names for these JREs on their machines. Also, the .classpath files are checked into source control. As a result, people need to make local changes to their .classpath file in order to be able to build.
My instinct is to choose a naming convention for the installed JREs list and ask all the team members to stick with it. However, this just complicates the process of setting up a new developer. Really, I just want to say "build this project with Java 5" and "build that project with Java 6". I don't care where they are installed, or what their symbolic name is. Does Eclipse support this kind of configuration?
Execution Environments are what you want (Preferences -> Java -> Installed JREs -> Execution Environments). You can change the classpath of your projects to use a JRE System Library that corresponds to a particular version of Java, like "J2SE-1.5" or "JavaSE-1.6". Then, Eclipse will categorize the installed JREs into those categories, and use the appropriate one when building your projects.
Honestly, I use the maven (maven-compiler-plugin and profiles) for exactly this.
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
Using a system like maven (or ant, etc) helps us tremendously with classpath/environment/os-disparities problems across developers.
You can configure project specific compiler settings in Preferences->Java->Compiler. However, this only allows you to set the compliance level, not choosing a particular JDK. But maybe that's already enough for your purpose?
If you are synchronizing your project files, eclipse maintains a current JDK in the Libraries tab of the projects build path configuration. This will carry over pretty well as long as everyone has the same JDK installed and loaded into eclipse.
Where possible, I'd still recommend the maven solution that Quotidian suggested, but I've had a fair amount of success manually as long as each developer workstation is set up the same. This can hang you up if you have developers running different operating systems though, as it might look for "C:\Program Files\java" on a linux system, or "/user/lib/jvm/" on wndows, neither of which would exist.
If you're stuck with having to check the .classpath fies into source control, then I'd encourage you to go with your idea of having all the devs install their JDKs in the same location (or use a common env variable name pointing to the locations). I think it's much easier for devs on the same team to have very similar environment setups, and if that common env setup is well documented. That way, as new devs come on board, you can point them to your documentation for env setup and have them up and running quickly - there should be no need to waste time debugging issues around where their JDKs are installed.
If that's not an option, though, and you're already using Maven, then you could consider removing the .classpath files from source control. We've recently done this, and we just have all the devs run the Maven eclipse plugin to generate (or update) their own .classpath files based on what's in the pom.xml file. (i.e. mvn eclipse:eclipse to run that plugin).