Improving the Java development workflow [closed]

Question

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.

1. What Java development IDE do you use? Eclipse, NetBeans or IntelliJ ?
2. 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
3. If the answer to 2, is yes, how do you integrate such tools with your build system?
4. 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?
5. 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?
6. 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:

1. 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.
2. 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.
3. 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.
4. No. See answer 1.

5. 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.

Klaus

Answer 1

I feel that you're doing it wrong. You're heading towards a. unmaintainable spaghetti environment.

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.

1. 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.
2. 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.
3. It's good to have the same version of JDK 1.7. However you set the source and target version in Maven.
4. Don't try to force anyone to use any IDE. It does not matter.

So if I was answering your questions:

1. Does not matter. Let anyone choose the one he/she knows key shortcuts and is most productive with.
2. Maven! or Gradle but Maven has better IDE integration.
3. It is a build system. You integrate IDE with it and it just works.
4. Does not matter.
5. 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.
6. Dependency management/build system you need to choose arbitrarily. Maven is easier and has better integration. Gradle may need some work but it's more extensible. Ant is a road of pain. IDE - let everyone choose.

We've just finished migrating Ant+Eclipse-commited-workspace+3rd-paarty-libs-in-SVN project to Maven projects...

Answer 2

1: I use IntelliJ (I'm biased as a prior JetBrains employee); other people use IntelliJ or Eclipse. I tried to use Eclipse and seriously disliked it.

2: Currently we use a custom closed-source tool. Before that, we all used IDEA and used its dependency control. Another team used Maven.

3: Currently there are custom build plugins for both IDEA and Eclipse, but I prefer the command line anyway. (In a Linux environment the command line is a nice friendly place.)

4: Not standardized, since IDEA seems to handle project files from other versions well, as long as versions don't differ too much. Not sure about Eclipse.

4: When we standardized on IDEA, we checked the project file into the VCS. Now we don't, instead we keep our custom tool's build files in the VCS.

5: Developers come with their own preference of an IDE (unless they develop that very IDE, then the choice is obvious). I use the community edition of IDEA.

Answer 3

R1. We use Eclipse or whatever, including IntelliJ

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).

R6. Whatever people liked at the time (or thought was good).

Answer 4

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.

Answer 5

First: Get a copy of Clean Code and Effective Java for every developer. And use Git and Gerrit.

1. 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.
2. Set up a CI server
3. We use ant but you should seriously consider Maven or Gradle.
4. Check in all files the IDE needs on a clean install of the project.
5. Open source software is cheaper in the long run and you can fix errors yourself. If needed, commercial support is available.