'gradle eclipse' against gradle itself should not create top level .project and .classpath files

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Resolution: Won't Fix
  • Affects Version/s: None
  • Fix Version/s: 1.0

Description

Run `gradle eclipse` against the latest gradle sources.

Notice that a .classpath and .project file are created in the root directory.

Notice also that .classpath and .project files are created for each project in the 'subprojects' directory.

Upon trying to import gradle projects into Eclipse, the top-level .project file 'hides' the nested project files.

The user is forced to remove the root .classpath and .project manually.

They are unnecessary and should not ever be created.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Hans Dockter added a comment -

I'm not sure. In case of Gradle you can avoid your issue by importing with subprojects as root. Additionally you can tweak Eclipse to accept a hierarchical layout in which case you would need the top level eclipse files.

Show
Hans Dockter added a comment - I'm not sure. In case of Gradle you can avoid your issue by importing with subprojects as root. Additionally you can tweak Eclipse to accept a hierarchical layout in which case you would need the top level eclipse files.
Hide
Permalink
Philip Crotwell added a comment -

Another example of this is in the samples/java/multiproject. "gradle eclipse" generates .classpath and .project files for the services directory as well as the 2 subdirectories shared and webservice inside it. But "services" itself is not a project, not listed in the settings.gradle, and is really nothing more than a directory that happens to contain subprojects. It seems incorrect to me to generate .project and .classpath entries for the services directory.

gradle eclipse
find . -name .classpath
./api/.classpath
./services/.classpath
./services/shared/.classpath
./services/webservice/.classpath
./shared/.classpath

Show
Philip Crotwell added a comment - Another example of this is in the samples/java/multiproject. "gradle eclipse" generates .classpath and .project files for the services directory as well as the 2 subdirectories shared and webservice inside it. But "services" itself is not a project, not listed in the settings.gradle, and is really nothing more than a directory that happens to contain subprojects. It seems incorrect to me to generate .project and .classpath entries for the services directory. gradle eclipse find . -name .classpath ./api/.classpath ./services/.classpath ./services/shared/.classpath ./services/webservice/.classpath ./shared/.classpath
Hide
Permalink
Hans Dockter added a comment -

@Philipp The services is added in the settings.gradle. For good or bad, the current default policy is to add the dirs between leafs and root automatically as projects. I fully see your point though. This is something we need to think about. At least provide some easy ways to express what you want. Of course you can always do a eclipseClasspath(Project).enabled = false for a specific project. But this is not very nice.

Show
Hans Dockter added a comment - @Philipp The services is added in the settings.gradle. For good or bad, the current default policy is to add the dirs between leafs and root automatically as projects. I fully see your point though. This is something we need to think about. At least provide some easy ways to express what you want. Of course you can always do a eclipseClasspath(Project).enabled = false for a specific project. But this is not very nice.
Hide
Permalink
Szczepan Faber added a comment -

I don't think we want to fix it this way. For example, if I don't pull the 'gradle' project into eclipse I cannot work on the root 'build.gradle'. Yet, I agree it is somewhat annoying that eclipse import wizard does not show all recursive projects

As far as not generating the eclipse projects for subfolders - the way to work around it could be applying eclipse plugin to selected projects either explicitly or using filter:
configure(subprojects.findAll { /* should have the eclipse plugin applied? */ }) { apply plugin: 'eclipse' }

Show
Szczepan Faber added a comment - I don't think we want to fix it this way. For example, if I don't pull the 'gradle' project into eclipse I cannot work on the root 'build.gradle'. Yet, I agree it is somewhat annoying that eclipse import wizard does not show all recursive projects As far as not generating the eclipse projects for subfolders - the way to work around it could be applying eclipse plugin to selected projects either explicitly or using filter: configure(subprojects.findAll { /* should have the eclipse plugin applied? */ }) { apply plugin: 'eclipse' }

People

  • Assignee:
    Szczepan Faber
    Reporter:
    Chris Beams
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: