2

IDE misconfiguration is a big source of inefficient time use in our team. I wanted to know if other teams have tried to check the health of the eclipse workspace with continuous integration. Eclipse is open source and extensible, and most (all?) of its files are in xml. So it should not be difficult to add a step to continuous integration that checks the health of the workspace, such as no missing Jar files, no errors, etc.

What we have is a separate ant script to do the real builds that go to QA and to the customers. This ant script is run with continuous integration and we have put in place a few simple checks that catch most big showstoppers.

The workspace configuration is a different story and we sometimes detect problems when it's too late (the dev left home).

EDIT: Note that we share our Eclipse config files.

flybywire
  • 261,858
  • 191
  • 397
  • 503
  • 4
    btw, what is your understanding on "Continuous Integration"? – Bozho Jan 21 '10 at 10:14
  • @Bozho, for our purposes, "continuous integration" is anything that can be run from a simple terminal command without human intervention – flybywire Jan 21 '10 at 10:56
  • http://en.wikipedia.org/wiki/Continuous_integration – Bozho Jan 21 '10 at 11:17
  • 3
    You are not using the term Continuous Integration correctly. That refers to building the bits that go to the customer after every change, not running batch files. – Thorbjørn Ravn Andersen Jan 21 '10 at 16:21
  • 1
    @Thorbjørn: not really. CI is about keeping the quality of your code as changes flow in. It doesn't necessarily need to be "bits that go to the customer", it can be unit tests, code conventions, quality metrics, whatever. – flybywire Jan 21 '10 at 18:00
  • 1
    If you do not build the bits going to the customer there is a lower hanging fruit for you right there. – Thorbjørn Ravn Andersen Jan 21 '10 at 19:44
  • 1
    @flybywire What you call CI is actually an **automated build** (CI means running that automated build continuously each time a change occurs). – Pascal Thivent Jan 22 '10 at 01:06
  • @Thorbjørn we already build the product, now we want to keep the quality of our workspace – flybywire Jan 24 '10 at 04:55

3 Answers3

2

There is some information on building with Eclipse from the command line here.

(Should be a comment, but I can't).

Community
  • 1
  • 1
clstrfsck
  • 14,715
  • 4
  • 44
  • 59
1

Since you are using Ant, you can create a custom task that verifies the following files against pre-defined ones. If they don't match, report problem:

  • workspace/.metadata/*.* (whichever configurations you think are important)
  • workspace/project/.classpath
  • workspace/project/.project
  • workspace/project/.settings/*.* (whichever configurations you think are important)

Of course, these files include some hard-coded paths, so you can use regular expressions in the pre-defined files.

If you want to check only simple things like "the project doesn't compile", then just compile the project in the ant script (using the javac task) and see if there are errors.

Another thing - continuous integration should better be IDE-agnostic. I.e. you must have a IDE-less environment (a CI Engine) that compiles the project. Imagine the following:

  • three developers, one of them accidentally removed a jar from his Eclipse, but the project in the repository is compiling. No need to report problems in that case
  • one of the developers adds a new jar and commits. The others have not updated. No problems are reported in there workspaces, although after they update, they might get the problem.

That all said, I think you'd better look at Hudson, which is a continuous integration engine. Thus you won't be dependent on IDE settings for your builds.

martin clayton
  • 76,436
  • 32
  • 213
  • 198
Bozho
  • 588,226
  • 146
  • 1,060
  • 1,140
  • what will you be checking against then? "There are no missing jars" - which jars can be missing? If the project doesn't compile then that's even easier to catch. – Bozho Jan 21 '10 at 09:48
  • yes, that the project compiles in the IDE would be a good check – flybywire Jan 21 '10 at 09:51
  • then just compile it in the ant task. if you don't know how to do it with – Bozho Jan 21 '10 at 09:57
  • 3
    @flybywire - it is **RUDE** to downvote an answer to your own question. You do want people to spend the time answering don't you? – Stephen C Jan 21 '10 at 09:57
  • @Bozho, that is exactly the point. I **don't** want to compile it in an ant task, I want to compile it exactly as eclipse would – flybywire Jan 21 '10 at 11:45
  • why? with CI you need to have a "build" as an output. Why do you care that some developer somewhere has screwed up his Eclipse? – Bozho Jan 21 '10 at 11:51
  • @bozho: because all developers share the eclipse project files. If a dev modifies a file so that it depends on library-1.1 instead of library-1.0 and he adds the jar to the project but doesn't commit the new .classpath file we want to know about it as early as possible. – flybywire Jan 21 '10 at 13:27
  • then the question would come - how are you producing your build artifacts? – Bozho Jan 21 '10 at 13:57
  • 8
    @Stephen C: It's hardly rude to down-vote your own question's answers. down-vote if not helpful, up-vote if helpful. Simple rules, no sugar on top. I've down-voted some answers on my questions before because they were actively unhelpful and/or missed the point. That's how the site works. People should make an effort to communicate and fix the problem, and try to alleviate the down-vote. – GManNickG Jan 21 '10 at 15:45
  • 1
    (As for the discussion about being rude: see http://meta.stackexchange.com/questions/36442/is-it-rude-to-downvote-an-answer-to-your-own-question) – Arjan Jan 21 '10 at 15:46
  • @GMan - indeed. But flybywire didn't communicate the fact that 1. he doesn't have a "stable config files" or that he misunderstands CI ;) – Bozho Jan 21 '10 at 15:50
  • 1
    I'm only responding to the blanket statement made by Stephen. There may be cases where it's unacceptable to have down-voted, and cases where it's completely acceptable. Stephen said only the former is possible. – GManNickG Jan 21 '10 at 16:50
  • @Bozho perhaps the misunderstanding comes from what you and me mean by *config files*. I also include in that concept classpath and project dependencies. Those files are almost never stable - they always change as the project progresses. – flybywire Jan 21 '10 at 18:04
1

I don't see why you want to do that. Eclipse complains loudly if anything is broken, so leave it to the developer.

What you should consider instead, in my opinion is to write tests that check that everything is as you expect it to in the building process of those builds from source code that the developer has checked in the source repository.

If a build breaks due to a jar is missing in the build, add a check. If a build breaks because it is dependent on a certain feature in the JVM, add a check.

Only ship builds outside of the development team that pass all tests. Those builds that fail, should be fixed by the developer introducing the change that broke the build.

Thorbjørn Ravn Andersen
  • 73,784
  • 33
  • 194
  • 347