Project dependencies declared in .project files

Help/Discuss Buildship
1

We noticed that, when using Buildship, the generated .project files leave the … block blank and declare no dependencies (“referenced projects”) there. In our experience these declarations help Eclipse build projects in the correct order. This is especially important when there is no direct dependency but, say, a dependency on a code generated by another project.

What is the way to ensure that these references are indeed written to .project files?

Presently experimenting with Gradle 2.14 + Eclipse Neon + Buildship 2.0.0.v20160714-1015-s.

2

NVM. Found it - “referencedProjects”, it works:

https://docs.gradle.org/current/dsl/org.gradle.plugins.ide.eclipse.model.EclipseProject.html

3

Please note this is completely unnecessary with Java projects, as Jdt already tells Eclipse the correct ordee based on the classpath.

4

Actually, my bad again… it does not work. It seems that these are not used by Buildship…

And, it is NOT unnecessary because there may be dependencies that are not expressed on the classpath - dependencies on other artifacts.

5

What kind of other artifacts? In general such dependencies should be expressed as Gradle project dependencies and thus should be part of your JDT classpath.

6

They are Gradle task and even project evaluation dependencies. But they are not things that are expected (or wanted) in the Java classpath. Think normal files in the file syste, such as various configuration and descriptor files (e.g. XML), pictures, native binaries, etc. These should not be visible to Java class loaders in any of their forms - binary or as a project dependency when that is implemented. Your next question may be how do they affect in-Eclipse compilation then. Well - they do participate in other-than-Java builders on the projects, some of which are validation, others produce other artifacts.

7

Thanks for the explanation, I see what you mean now :slight_smile: We already have that information in the Tooling API, so I added this to the roadmap for Buildship 1.0.18.

Unrelated to Buildship: Generally you should avoid configuration time dependencies as much as possible and use artifacts instead. So if project A publishes some library and project B wants to consume it, then you would do something similar to this:

Project A:

configurations {
  libraries
}

task createSomeLibrary {...}

artifacts {
  libraries createSomeLibrary
}

Project B

configurations {
  libraries
}

dependencies {
  libraries project(path: ':a', configuration: 'libraries')
}

task usesLibraries() {
  libraries = configurations.libraries
}

That avoids configuration time ordering issues and also makes it easier to split a project into several repositories later.

8

Re:

Unrelated to Buildship: Generally you should avoid configuration time dependencies as much as possible and use artifacts instead. So if project A publishes some library and project B wants to consume it, then you would do something similar to this:

Yes, I am aware of that. Trying to avoid whenever possible - but it isn’t always possible. One of the big problems we are facing is this:

Other issue is that not every artifact is a single file. We need some to be directory structures. Making a file up would require packing that directory and unpacking it somehow every time it is used, which would be a performance suicide.

Unrelated but relevant note: I will be away for a month. Other people may communicate with you. I won’t post this to every discussion I started, though…

9

Update on my status - by seeding .classpath files with (literally):

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
    <classpathentry kind="output" path="bin-eclipse"/>
</classpath>

(did this in Gradle, by simply copying a template file over) before importing into Eclipse (via Buildship) this works. Buildship modifies the file and preserves the entry.