Runtime classpath resolver is "injected" into Java Application and JUnit launch configurations.
Goals
- As close to classpath used by maven CLI to the extend possible
- Support workspace dependencies
- Allow arbitrary user entries in maven project build classpath and launch configuration classpath
- Preserve relative order of classpath entries to the extend possible
Runtime classpath resolution
In this context, "resolution" means calculation of runtime classpath (i.e. actual jars and class folders) during launch of application or test using Java App and JUnit test launch configurations in Eclipse.
- Overall classpath content and order are defined by launch configuration classpath.
- Resolution of all entries except for "Maven project classpath" is delegated to JDT launch code. This is important to maintain consistent behaviour of classpath containers, variables, projects, etc.
- Custom maven projects added to launch configuration classpath will be resolved as regular java projects.
Resolution of "Maven project classpath" launch configuration classpath entry
- Overall classpath content and order are defined by project build path
- Source folder entries corresponding to main/test maven project resource folders are ignored during runtime classpath calculation
- classpath for "Run as / Java Application" launch configuration
- all custom entries
- includes main classes/resources (i.e. no test classes/resources)
- dependencies with runtime, provided and system scope
- classpath for "Run as / JUnit test" launch configuration
- all custom entries
- includes main and test classes/resources with test entries put in front of main entries
- dependencies with test scope (includes all dependencies)
The following table illustrates resolution of project build classpath. "Custom N" are the entries configured manually using either java project build path properties page or via launch configuration "Classpath" tab.
| build classpath | application classpath | test classpath |
|---|---|---|
| custom 1 | custom 1 | custom 1 |
| main sources | main classes/resources | test classes/resources |
| custom 2 | custom 2 | main classes/resources |
| test sources | custom 3 | custom 2 |
| custom 3 | dependencies (see below) | custom 3 |
| dependencies container | custom 4 | dependencies (see below) |
| custom 4 | custom 4 |
Resolution of workspace dependencies
The following table illustrates resolution of dependent project's build classpath
| build classpath | dependency scope!=test | dependency scope==test |
|---|---|---|
| custom 1 | custom 1 | custom 1 |
| main sources | main classes/resources | test classes/resources |
| custom 2 | custom 2 | main classes/resources |
| test sources | custom 3 | custom 2 |
| custom 3 | custom 4 | custom 3 |
| dependencies container | custom 4 | |
| custom 4 |
In other words, because of transitive nature of maven dependencies resolution, dependencies container is not included into resolved classpath for dependent projects.
Example
Consider the following two Maven projects
/A /src/main/java /src/test/java depends on B /B /src/main/java /src/test/java depends on junit-3.8.1.jar with scope==test
Project A has custom "libC.jar" entry at the end of JDT classpath.
Application classpath of project A
A/target/classes B/target/classes libC.jar
Test classpath of project A
A/target/test-classes A/target/classes B/target/test-classes B/target/classes junit-3.8.1.jar libC.jar
Notes
- JDT does not fully honour build classpath order. More specifically, all project's output folders come together and cannot be intermixed with libraries or other projects' output folders.