Why are eclipse containers included in .classpath before libraries?

(andrew.oberstar) #1

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) {

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.

(Szczepan Faber) #2

Hello Andrew,

There is no strong reason why containers are before project deps, etc. What are the reasons you need to put them at the end of the classpath? I.e. I’m wondering what’s the actual problem.

We might update the default behavior and couple it with some DSL to configure the order if we believe there are compelling reasons. The way to configure containers to be at the end of the classpath is:

eclipse.classpath.file.whenMerged { classpath ->
    //putting containers at the end of the list
    def containers = classpath.entries.findAll { it instanceof org.gradle.plugins.ide.eclipse.model.Container }