How to prevent the creating of subprojects in Eclipse?


(Horcrux7) #1

We have in the settings.gradle some include for creating variants of the artifacts in the build system.

The buildship plugin create for every of the subprojects its own eclipse project. The disadvantages:

  • The count of project incrments
  • The subproject contains the same content as the main project
  • There are conflicts with other projects because the subprojects has ever the same names like “demo”, “client”, “server”, …

Is there an option to prevent this eclipse subprojects? For example with the eclipse task in the gradle script.


(Horcrux7) #2

A first and bad hack is the follow code in the settings.gradle:

if( file('bin').isDirectory() ) {
    println '=========================================='
    println 'Inside from Eclipse IDE'
    println '=========================================='
    return
}

before the includes of the subprojects. The disadvantages is that we can not run any tasks in the subprojects inside Eclipse.

The next step is to differ between gradle refresh and gradle task run.


(Stefan Oehme) #3

I’m afraid I don’t understand the setup or what problems in Eclipse it causes. Could you create an example on GitHub and elaborate more on the problem you are trying to solve?

There is no way to prevent creation of an Eclipse project per sub-project. You can certainly modify them to make them essentially empty if that would help. E.g. remove source folders, dependencies etc. That’s the best advice I can give without understanding the project better.


(Horcrux7) #4

You can use every sample from your documentation with subprojects.

Our solution already prevent the creation of subprojects. We need only to differ between “Refesh Gradle Project” and “Run Gradle Tasks” do do it perfect.

We have one Eclipse project that produce multiple jar files.The project has only one “src” folder and “test” folder. It look like:

  • src
  • test
  • .project
  • .classpath
  • settings.gradle
  • build.gradle
  • client\build.gradle
  • server\build.gradle
  • demo\build.gradle
  • stup\build.gradle
  • rmi\build.gralde

All the build files use mostly the same source files. There are only different annotation processing. One project, multiple artifacts.


(Stefan Oehme) #5

Now I see what you are doing, thanks for the explanation. This should be one project with multiple compile/jar tasks instead of creating multiple projects “linking” the same sources.


(Horcrux7) #6

How is this possible without multiple build files? Many attributes in a build file are singleton.


(Stefan Oehme) #7

That’s not the case. There are some top-level convenience methods like sourceCompatibility, but everything can be configured on a lower (e.g. task) level as well.

For instance, you can create additional SourceSets and you will automatically get a compile task wired up for them. You can set all kinds of options on the specific compile task directly. Similarly you can create jar task that packages the output of such a custom SourceSet and give it a custom classifier for publishing.

If that seems too far from your current setup and you’d rather like a quick fix for Eclipse, then something like the following should work for the “variant projects”:

eclipse {
  classpath.file.whenMerged {
    entries.clear() //this will remove all source folders and dependencies
  }
}

(uklance) #8

You might be interested in my java-flavours-plugin plugin. Interesting code is in JavaFlavoursPlugin.groovy


(Horcrux7) #9

You forgot the dependency chain of the tasks. We have more as only compile and jar task. The task use the outputs from the previous task. compile, jar, obfuscate, sign, plugin, etc. Currently the sub builds has only a few line. This is the great feature of Gradle. Our old ant files was thousand line long. We add only a script plugin from our pool an no extra configuration is needed.

Does not prevent the creation of subprojects in Eclipse.


(Horcrux7) #10

How should this help?


(uklance) #11

How should this help?

It’s an example of what @st_oehme was suggesting. Multiple build variants (flavours) within a single project


(Stefan Oehme) #12

You would do exactly the same, just for every flavor instead of for every “project”. Have a look at @Lance plugin, it goes into the direction you are talking about. You could easily add more logic on top like “create a sign task for every flavor” etc.

I know, it’s just a workaround. Our Eclipse plugin assumes that if you have a project, then that project is actually meaningful by itself. Your case stretches the concept of a project beyond that definition, because really they are all the same project. That’s a use case we don’t support, so I can only give you workarounds and advice on how to structure the project better.


(Gerry Weißbach) #13

Disclaimer: I work together with @Horcrux7

The Flavours-Plugin looks like something for very simple projects. It can not replicate and duplicate our whole dependency tree. Especially since our setup has worked for over a year - it might have worked when we started from scratch.

To not create subprojects as Eclipse projects would be the optimal solution and as far as I can see we would only need a hint - a variable, a task / doFirst, doLast - when buildship is about to refresh the workspace.

Alternatively - and something that I would have expected from the beginning - is a better Name for the subproject. I have not yet checked, but what happens when several projects have the same subproject names? They will not be distinguishable any more.
The name of a subproject should be derived from the main project name in combination with the subproject name.


(Horcrux7) #14

I think I have found a solution to differ between “Gradle Refresh Project” and “Run Gradle Task”. On refresh there is no task set. I use the follow hack/solution now:

if( getStartParameter().getTaskNames().isEmpty() ) {
    println '=========================================='
    println 'Inside from Eclipse IDE. Subpjoject was killed.'
    println '=========================================='
    return
}
include 'foo'
include 'bar'

(uklance) #15

Perhaps another alternative is

boolean isEclipse = System.getProperties().containsKey('osgi.requiredJavaVersion')

Never tried it but can see that system property in eclipse.ini


(Stefan Oehme) #16

You can easily change that, see the first item on our FAQ.


(Horcrux7) #17

“Gradle Refresh Project” and “Run Gradle Task” are both inside of Eclipse that this will not work.