I will like to assist my group standardize to a reproducable Java tooling environment that aligns with some good practices to improve on our workflow. We are predominantly a .NET shop that has been doing quite a bit of Java development recently and have been burned too many times with our current Java development process.

The process is ad-hoc, since we are kind of new to all things Java. Each developer decides on their tool of choice (somewhat a good thing) and due to the lack of any kind of procedure in terms of 3rd party dependency management, we more often than not run into build or deployment problems and hit serious setbacks when developer machines have to be rebuilt for one reason or another. Our Java development environments are simply neither consistent nor repeatable from one machine to another.

We do not have a similar problem with our .NET projects. Everyone runs the same version of Visual Studio, Resharper, and all 3rd party and open source libraries. Possibly because we pay for most of the stuff but there is also a consistent pattern across our C# projects where everything one needs is encapsulated into the solution file and all 3rd party dlls required for this solution are checked into sub a directory relative to the parent solution in source control. Visual Studio helps here too with its version check but this process is working well and I feel it could be replicated for our Java development efforts.

To help achieve this goal, I have compiled the following list of questions to gauge what the experts are using out there.

What Java development IDE do you use? Eclipse, NetBeans or IntelliJ ?

Do you use a dependency management tool such as Apache Maven, Gradle, a standardize home grown solution, or does each developer determine what works best for them? What we have

If the answer to 2, is yes, how do you integrate such tools with your build system?

Do you standardize on a specific version of the IDE, related tools and runtime? For example, are all devs running Eclipse IDE for Java EE Developers 3.7, IntelliJ 12.1.6, JDK1.7 or 1.8 and are there any policies to enforce that all devs are using the same version?

How do you ensure that projects settings are consistent and repeatable across dev machines? Do you mandate checking in all of a project settings into source control or just the respective source files?

For each tool, including IDE, dependency management and build, what selection process did you use?

Items highlighted in bold is what we are learning towards based on past experiences. But it will be good to learn from what others are doing.

I will start by answering some of the questions, listing some of the problems we are facing:

Every developer uses Eclipse. However Eclipse and JDK versions could differ from one machine to another. Dev A could be running Eclipse Juno with JDK 1.6 while Dev B is running Eclipse Galileo with JDK 1.7. The build machine could be running something different and we will only know there is a problem next morning when build is broken. WIth resources also distributed across continents, this causes serious headaches. For IDE standardization, I am leaning towards IntelliJ for usability and consistency, just to name a few.

We do not use any such tool. Instead all 3rd party libs are stored in a 3rdParty central folder outside of the solution tree. Then we have an Eclipse project setup to reference these JARs. This works well but this 3rdparty folder is very large. So if you do not want to selectively checkout the JARs you need just to get this project compile, you are in for a long morning waiting to check out the entire 3rdParty folder from SVN. For dependency management, I am leaning towards Maven.

We use raw ANT scripts. Each developer needs to ensure that all the stuff required to build the project is checked into source control. But because these resources are all over the place, remember, the 3rd party folder is not part of the project tree, it is very easy to forget checking in that new dependent JAR downloaded from somewhere. And if you use Maven, like I do, I need to copy the JAR from my local Maven repo to the relevant centrll 3rdParty folder so that the build machine does not complain. However, there is still a good chance that this build will fail since the build environment could also be different. For build and packaging, I am also leaning towards Maven to ensure that the build environment is similar to the dev environment. I want to relieve the pain of having to remember where to put dependencies.

No. See answer 1.

We do not, possibly because we are not saving the entire Eclipse workspace into source control. So if I receive a new machine and check out an Eclipse project, I will have to spend a good portion of my day configuring project settings that should have been saved in source control.

TIA for all comments.

EDIT: Just to add that we do have a CI server and use Jenkins/ANT scripts for building.

This question appears to be off-topic. The users who voted to close gave this specific reason:

"Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – MichaelT, gnat, GlenH7, Dynamic, ChrisF

5 Answers
5

Java projects tend to grow to tens or hunderds of dependencies. You start from Guava, JodaTime, SLF4J some commons and it grows... and it's OK. Just don't try to maintain it manually. Maven/Gradle is a must!

Never ever commit eclipse workspace files. It just not work.

Let's start from the beginnig.

Set up a CI server. An independent tool that will pull the code from repository, build it, run the tests and send an e-mail if the build is broken. Jenkins is a pretty straightforward tool.

You definetely need Maven or Gradle. (You can try Ant+Ivy but I woouldn't go that way). Most of IDEs integrate pretty good and transparent with Maven.

It's good to have same version of JDK 1.7. However you set the source and target version in Maven.

Don't try to force anyone to use any IDE. It does not matter.

So if I was answering your questions:

Does not matter. Let anyone choose the one he/she knows key shortcuts and is most productive with.

Maven! or Gradle but Maven has better IDE integration.

It is a build system. You integrate IDE with it and it just works.

Does not matter.

All you need is sources and pom.xml (if Maven). No other files. You just pick IDE of your choice and import/open Maven project.

Dependency management/build system you need to choose aribtrary. Maven is easier and has better intergation. Gradle may need some work but it's more extensible. Ant is a road of pain. IDE - let everyone choose.

Thanks for response and I agree with you that we are doing most of it wrong.
–
e28MakaveliNov 22 '13 at 13:50

I fully agree except for the 'never commit eclipse workspace files'. It actually works really well, and allows to somewhat standardize (or at least prod in the right direction) settings like code templates or warning levels. The goal is not to force everyone into the same mold, but provide something that just work OOB (aka import project, and you're done).
–
ptyxNov 22 '13 at 18:15

If committing the Eclipe workspace allows another dev to be able to check out a project and not have to change run or debug settings to successfully compile and execute the project, I think this is improved productivity.
–
e28MakaveliNov 23 '13 at 2:19

1

Maven is a great tool for build automation. And automation tends to lead to consistency. Plus it works really well with CI. So once you've got it set up for your team, you don't need to care what tools are used to generate the code (IntelliJ, Eclipse, emacs, vi, or even Windows Notepad [the horror!]) as long as it passes the CI builds and automated tests.
–
AllanNov 23 '13 at 4:20

Pushing eclipse workspace to SCM just causes lots of trouple. People have different sets of plugins with different versions and settings. Many times there are absolute local paths on those files. On the other hand having Maven project and m2e plugin makes is as simple as opening the project. pom.xml has all information needed to build/run/test the code.
–
Piotr GwiazdaNov 25 '13 at 13:59

Eclipse has "first class" support: we make sure that whatever changes we do in the development environment doesn't break anyone, and make sure the developer experience is as smooth as possible. It's also the IDE used for trainings.

That said, people can use whatever environment they like, and we have a sizable crowd using IntelliJ. The deal is that they should still comply with all Eclipse based requirements (such as code formatting conventions, warning settings, etc...) - and that it's on them to figure it out.

We have a 'recommended' version of Eclipse, but you can use something else - you just fall in the 'whatever' category.

R2. We use maven.

The maven command line build is actually the reference. It doesn't matter if something works within Eclipse if it doesn't on the command line.

Both Eclipse and IntelliJ have excellent integrations with maven, so the additional work required to make sure that a maven projects opens smoothly and correctly in either is minimal.

R3. Our build system is based on Jenkins, so equivalent to command line build (which is the reference).

R4. The CI server is always the reference: it doesn't matter so much what you use locally, unless you break the build (or tests) and then it probably means you diverge enough it matters. Fix it.

R5. We generally source control eclipse .project, .classpath and .settings.

While in theory it's not strictly required and those can be generated, checking them in ensure more consistency between developers. It also make accommodations for complex setups where m2e or maven-eclipse-plugins are not quite reliable, or where the IDE needs slightly more information than available in the pom to run smoothly. (It also makes the dev experience of importing projects smoother).

Interesting that you source control project, classpath and settings . But then if every developer is allowed to use whatever IDE they prefer, this procedure is not guaranteed repeatable from one machine to another which is one of my goals. This is also one reason I want to standardize on IDE. Most of the devs around here complain about Eclipse so I am sure introducing an IDE like IntelliJ, which I have used extensively will be a good welcome.
–
e28MakaveliNov 22 '13 at 14:03

Guaranteed repeatable is a lot of work, and require strict constraints on environment. Developers (I'm one) tend to be (a) capable of fixing most issues by themselves, (b) really picky about which tools they like to use, (c) really annoyed at management restricting their tools. Settling for 'mostly repeatable' and using extensive validation at the CI level is imho a better approach (obligation of results, but get there however you like). It's also is making changes in the dev environment smoother (it's even harder to guarantee anything there).
–
ptyxNov 22 '13 at 18:11

If you are already a .Net shop and don't seem to have these same issues over there. My recommendation is to do what they are doing. My bet is, they have a known IDE version, with a known framework version across all machines.

None of these problems are JAVA specific, although I will admit .NET has not quite embraced dependency management as well as the Java community as a whole. My answer to that one is yes use one of those tools. You lean towards Maven, use that it is a great tool.

Standardize on one version of one IDE (we use Eclipse) that everybody uses. Make sure it's kept up-to-date (you seem to be using Eclipse versions that are seriously out of date). Make sure that most of the settings (like code formatting) are shared between machines. Make sure everybody runs the latest JDK.

Set up a CI server

We use ant but you should seriously consider Maven or Gradle.

Check in all files the IDE needs on a clean install of the project.

Open source software is cheaper in the long run and you can fix errors yourself. If needed, commercial support is available.

Thanks for the comment. I am also leaning towards IDE/tools standardization as this provides a better recipe to provide a repeatable work space, if there is such a thing.
–
e28MakaveliNov 23 '13 at 2:06