Many of our projects include the Eclipse container corresponding to our application server runtime. The built-in (non-configurable) behavior of the Eclipse plugin is to generate the .classpath file in the following order:
- output dir * source folders * containers * project dependecies * libraries
We can work around this with a block like this to move that particular container to the bottom of the list. I guess we could also do it generically for all containers.
eclipse.classpath.file.whenMerged { classpath ->
def runtime = classpath.entries.find { it instanceof org.gradle.plugins.ide.eclipse.model.Container && it.path.contains('was.base') }
if (runtime != null) {
classpath.entries.remove(runtime)
classpath.entries.add(runtime)
}
}
Why is this the default behavior? At the surface, I feel like containers (which in my experience only represent things like JRE libraries and server runtimes) would be located at the bottom of the classloader in the production server environment. It seems appropriate that they would be at the bottom of the classpath during local development as well.
Is there some use case I’m not thinking of, or was this just an arbitrary implementation decision? What I’m getting at is whether there is any reason that I shouldn’t reorder the classpath.
This is Gradle 1.0-milestone-8 (not “8a”), by the way.