[Is this fixed with the latest release of the Scala IDE??]  

• This page goal is to describe how Scala IDE is expected to work with a multi-modules project. The main focus is brought on incremental changes and recompilation between modules.

Eclipse configuration

For the sake of simplicity, we will consider the following Eclipse installation:

• Eclipse 3.7 Indigo
• Scala-IDE 2.0.0-beta8
• m2e eclipse 1.0, comming with Indigo
• m2e-scala 0.3.0, see https://www.assembla.com/spaces/scala-ide/wiki/With_M2Eclipse

Project Configuration

On file system

The whole point is to have at least 2 dependants modules, on two dependant system.

.
├── scala-ide-interproject1
│   ├── module1A
│   │   ├── pom.xml
│   │   ├── src/main/scala/samples/module1A/Api1.scala
│   │   └── target/...
│   ├── module1B
│   │   ├── pom.xml
│   │   ├── src/main/scala/samples/module1B/Impl1.scala
│   │   └── target
│   └── pom.xml
└── scala-ide-interproject2
    ├── module2C
    │   ├── pom.xml
    │   ├── src/main/scala/samples/module2C/Main.scala
    │   └── target
    └── pom.xml

Main use Impl1 which is an implementation of Api1.

On Eclipse

Download the project on github https://github.com/fanf/scala-ide-interproject, and then use "Import... Maven -> Existing maven project" to import them all.

Maven should be configured to hide module on parent ( menu Windows > Preferences > Maven > "Hide folders of physically nested modules").

Maven workspace dependency resolution must be activated for each modules. Its the default, but you can check that in each project's contextual menu (right click on project on explorer wiew), you see Maven > Disable Workspace Resolution.

The result should look like:

Expected behaviour

• Wished behaviour:
• a modification on Impl1 only rebuild it, not Main, but executing Main see the modified code
• a modification on Api1 display error on Imp1 and Main (but not the full Module2C)
• a modification on Api2 only rebuild Module1A
• a modification on Api3 only rebuild Impl3 (not full module1B)
• a "clean all" rebuild all modules WITH the correct last source for each, i.e if the "clean all" follows a modification on Api1, Main see it.

• Acceptable behaviour:
• a modification on any module trigger the rebuild of all module depending upon it WITH the correct last source for each source
• a "clean all" rebuild all modules WITH the correct last source for each, i.e if the "clean all" follows a modification on Api1, Main see it.

• We-can-do-with-it behaviour
•  a modification on any module only rebuild-it and does not trigger a build of other module
• a "clean all" rebuild all modules WITH the correct last source for each, i.e if the "clean all" follows a modification on Api1, Main see it.

 Current status

Well, even the worst case does not work correctly. Currently, depending of the modification (add/remove methods, change number or types of parameters, add/remove classes, etc) , the alignement between planets, and others clear criteria, what we see is:

• on a modification on Api1, no rebuild at all for dependant projects
• on a modification on module1A, module1B and module2C see a lots of false errors
• on a modification on Api1, a rebuild of other module is triggered but without the last source version of Api1, forcing to clean them, again (for modification on module1B), and again (for module2C), each time with dependant build triggered.

The last behaviour is the worst imaginable behaviour: in a large mulit-project workspace, with lots of modules, a modification in a deep dependency will trigger a rebuild of a lot of modules, but with error, and a lot of clean/build/clean is needed before seing the modified source reach the main project. When builds take seveal minutes, that just a bunch of time lost.