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).
Related
All!
In our project team, people use either IntelliJ or Eclipse IDE depending on what they are comfortable with. Eacf of the IDEs have their own settings files. For instance, IntelliJ uses .idea and .iml and Eclipse uses .project, .settings, .classpath! While some other stack overflow thread says it's not needed to check in any of these files from either IDEs if you are using Maven, I'm unsure why that's the case. None of the threads say why using Maven does not warrant (some of) the settings, .project, .classpath be checked in?
Can someone help me understand 2 things
1) Why don't we need these files to be checked in when using Maven?
2) If we must check in (Assuming Maven is not used), how do we ensure that either IDEs work okay when checking out from source control and what to check in to ensure cross compatibility.
Thanks!
1) These files are not needed because bothe IDEs can import maven projects using the pom.xml file. So the pom.xml file is your single source of project description for both IDEs.
https://projects.eclipse.org/projects/technology.m2e
https://www.jetbrains.com/help/idea/maven-support.html#maven_import_project_start
2) You see it right, it's hard to ensure cross-compatibility if you use only the native project files of the IDEs. Among many other things that's why it's encouraged to separate the build chain (Maven, Gradle, etc.) from the IDE. Also continuous integration systems can be configured more easily if a unified build tool is used so it's kind of a best practice to use one and keep it independent from the IDE.
In case you don't want to switch to maven now, check in the Eclipse .project and .classpath files, Intellij is able to understand them.
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!)...
For some reasons, my computer has 3 Eclipse IDE instances on it, Indigo, Juno and Kepler.
Indigo is used in real developing, Juno is for program execising, Kepler is being used in another project. Each of them contains a maven project.
But, there is only 1 maven in my computer, and 3 eclipse instances are now sharing it.
And these are errors keep coming which associate with maven, sometimes I need to clear some directories in maven or modify some maven config files. That makes me worry about whether one change would affect other maven project in other eclipses.
So I decide to isolate different eclipse, give each eclipse its own maven and tomcat and so on.
Could that be possible? if it so, how should config the system path and other relevant configuration??
Thanks a lot!!!
Could that be possible?
Yes its completely possible.
how should config the system path and other relevant configuration?
Goto Window -> Preference -> Maven -> Installations -> Add and add a new installation of maven and you can switch between any installation of maven within the eclipse
And these are errors keep coming which associate with maven, sometimes I need to clear some directories in maven or modify some maven config files. That makes me worry about whether one change would affect other maven project in other eclipses
Firstly this shouldn't happen unless and until you have different settings and profiles set-up in your settings.xml. So, prior to configuring multiple mavens, first debug why the maven settings get distubred in the other projects.
EDIT
If you are working with different maven settings ( and by settings I mean different repositories setup for each project and different server configurations that you want to keep isolated with other projects ) make use of Maven Profiles . Although, the real purpose of profiles is building for different environments ( like for dev/test/production ) you can use these profiles for building your different projects.
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
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.