CODEWITHSUNDEEP
java
egbokul
egbokul

Reputation: 3974

Remote Java compiler

I'm looking for a way to boost my team's productivity, and one way to do that would be to shorten the time it takes to compile & unit test & package & deploy our Java EE application which is getting bigger and bigger.

The trivial solution that I know of is to set up a powerful computer with N processors (N ~= num of developers) and a blazingly fast disk system and a lot of memory, and run everything on this computer and connect to it via X remotely. It would certainly be much faster than compiling on our laptops, but still cheaper and easier to maintain than to buy each developer his/her own supercomputer.

Is there another way to solve this problem? For example, could we run our IDEs locally and then tell it to remote compile java source? Can Netbeans / Eclipse / IntelliJ / etc. do this? Or is there a special tool that enables remote java compilation, also that makes use of multiple processors? It need not be free/open source.

Unfortunately our laptops MUST run a (company managed) Windows Vista, so another reason to go for the separate server computer is to let us use linux on it and finally get rid of the annoying managed environment.

EDIT: to sum up the answers so far, one way to shorten build times is to leave compilation for the developers individually (because compiling is supposed to be fast), skip running unit tests and hot-deploy (without packaging) to the container.

Then, when the developer decides to check his/her code in, a continuous integration server (such as Hudson) is triggered to clean & build & run tests & package & deploy.

SOLUTION: I've accepted Thorbjørn's answer since I think that's going to be the closest to which way I'm planning to proceed. Although out of curiosity I'm still interested in solving the original problem (=remote Java compiling)...

Upvotes: 18

Views: 5170

Answers (6)

Thorbjørn Ravn Andersen
Thorbjørn Ravn Andersen

Reputation: 75406

You essentially need two workflows.

  1. The OFFICIAL build, which checks out the sources, builds the whole thing from scratch, runs all the unit tests, and then builds the bits which will eventually ship to the customer after testing.
  2. Developer hot-deploying after each source code change into the container the IDE knows about.

These two can actually be vastly different!

For the official build, get Jenkins up and running and tell it to watch your source repository and build whenever there is a change (and tell those who break the build). If you can get the big computer for building, use it for this purpose.

For the developers, look into a suitable container with very good IDE deployment options, and set that up for usage for each and every developer. This will VERY rapidly pay off! JBoss was previously very good for exactly this purpose.

And, no, I don't know of an efficient remote java compilation options, and I don't think this is what you should pursue for the developers.

See what Joel thinks about Build Servers: http://www.joelonsoftware.com/articles/fog0000000023.html

If you don't like Jenkins, plenty others exist.

(2016 edit: Hudson changed to Jenkins. See https://stackoverflow.com/a/4974032/53897 for the history behind the name change)

Upvotes: 6

anonymous
anonymous

Reputation: 31

JavaRebel can increase productivity also. It eliminates the need for redeployments.. You can recompile a single file and see the changes being applied directly on the server.

Upvotes: 3

chrismh
chrismh

Reputation: 141

When things start getting too big for efficient builds, it may be time to investigate breaking up your code into modules/JARs (how it breaks apart would depend on many project specifics and how your team tends to work). If you find a good setup, you can get away with less compiling (dont always need to rebuild the whole project) and more/quicker copying/jaring to get to the point where you can test new code.

Upvotes: 2

rsp
rsp

Reputation: 23373

What your project need is a build system to do the building, testing and packaging for you. Hudson is a good example of such a continuous integration build system.

Upvotes: 0

nos
nos

Reputation: 229204

It's common to set up a build server , e.g. running hudson to do the compiling/packaging/unit-testing/deploying.

Though you'd likely still need the clients to at least perform a compile. Shifting to using a build server, you might need to change the work process too if you arn't using a build server now - e.g. if the goal is to take load off the client machines, your developers will check code in , automatic unit tests gets run, instead of running unit tests first, then checking in.

Upvotes: 6

Gadolin
Gadolin

Reputation: 2686

You could mount each developer dir with ntfs on the powerful machine and then create External Tool Configuration in Eclipse (GUI access), that would be triggering build on external server.

Upvotes: 3

Related Questions