Spring Tool Suite
  1. Spring Tool Suite
  2. STS-2173

Importing a Gradle project under version control: timing/building issue

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.8.0.M2
    • Fix Version/s: 2.9.0.M1
    • Component/s: GRADLE
    • Labels:
      None

      Description

      Suppose you have a Gradle multiproject under version control (Subversion, for instance).
      You check it out in a folder, say d:\myprj.
      Let's say the Eclipse workspace is in d:\workspace and it is empty.
      In Eclipse you do an import using the Gradle project import wizard; you select the d:\myprj folder, you presso the "build model" and then select the whole myprj multiproject, including its subprojects, and import it.

      Then, the Gradle import wizard starts to create the projects in the workspace, set dependencies, etc.
      What I'm observing is that if the myprj is huge, it takes some time before:

      • all the projects are created in the workspace
      • dependencies are set
      • the SVN data is collected so that projects are recognized as under version control (the repository decoration appears on project and file icons in Project/Package Explorer)
      • the project is built

      The problem I observe is this. Having "build automatically" enabled, the project building can start BEFORE the SVN data is collected. This means that there's a timeframe in which the building of the project is made before the IDE realizes that the project is under version control.

      What does this mean? It means that the "copying resources to the output folder" operations DOES NOT apply the exclusion filters inherited by the SCM plugin: in my case I find that the "bin" output folder of my projects contain copies of the .svn folders coming from the source folders.

      This can lead to severe problems, especially if you don't use the resource filters to hide subprojects in the main project and you make a synchronization with the repository.

      It's not easy to revert from this situation. If you clean all the projects after they have been recognized as being under version control, the "bin" output folders are cleaned, but the .svn folders right inside them are not removed. I mean, if after the first build the situation is this:

      • mysubprj
      • bin
      • .svn
      • com
      • .svn
      • example
      • .svn
      • package
        (etc.)

      after cleaning the situation becomes this:

      • mysubprj
      • bin
      • .svn
      • com
      • example
      • package
        (etc.)

      So, the .svn folders inside the packages are removed, but the one directly inside bin is not.

      You have to manually remove that folder to take things back to normal.

      My idea is the following: isn't there a way to "force" the team plugin (i.e.: Subversive, CVS, etc.) to collect the needed data BEFORE letting the first build of the imported project(s) start? I don't know if it's just a problem of setting the SVN nature before the Java nature or something like that (I'm not so expert...).

        Activity

        Hide
        Mauro Molinari added a comment -

        Manually adding the exclusion for .svn folders has the problem that, if it's STS fault (and we're not sure it is) this would solve just the case for Subversion integration, but not with other SCM plugins.

        I didn't try the same scenario with CVS sharing, I may do some tests to see if the same happens...

        Mauro.

        Show
        Mauro Molinari added a comment - Manually adding the exclusion for .svn folders has the problem that, if it's STS fault (and we're not sure it is) this would solve just the case for Subversion integration, but not with other SCM plugins. I didn't try the same scenario with CVS sharing, I may do some tests to see if the same happens... Mauro.
        Hide
        Kris De Volder (c) added a comment -

        I think we are hitting a subversive bug here:
        https://bugs.eclipse.org/bugs/show_bug.cgi?id=361831

        Yes, it would be nice to test CVS, git, and even other SVN support, like subclipse. They could have problems also, but they wouldn't be (or shouldn't be considered) the same bug.

        Show
        Kris De Volder (c) added a comment - I think we are hitting a subversive bug here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=361831 Yes, it would be nice to test CVS, git, and even other SVN support, like subclipse. They could have problems also, but they wouldn't be (or shouldn't be considered) the same bug.
        Hide
        Mauro Molinari added a comment -

        Thank you Kris, I'm following your discussion with Alexander Gurov and the opened bug.

        I may try Subclipse to see if it suffers of the same problem.

        Meanwhile, for me it's ok to close this bug as it isn't STS's fault. Feel free to do as you like.

        Show
        Mauro Molinari added a comment - Thank you Kris, I'm following your discussion with Alexander Gurov and the opened bug. I may try Subclipse to see if it suffers of the same problem. Meanwhile, for me it's ok to close this bug as it isn't STS's fault. Feel free to do as you like.
        Hide
        Kris De Volder (c) added a comment - - edited

        Since I think it may be hard for the subversive devs to reproduce. I created a small patch that fixes the bug for me.

        https://bugs.eclipse.org/bugs/attachment.cgi?id=205870&action=diff

        I'll close this bug as 'won't fix'. It isn't something we can fix in STS, but I'll follow up with the Eclipse bug to get my patch applied.

        Show
        Kris De Volder (c) added a comment - - edited Since I think it may be hard for the subversive devs to reproduce. I created a small patch that fixes the bug for me. https://bugs.eclipse.org/bugs/attachment.cgi?id=205870&action=diff I'll close this bug as 'won't fix'. It isn't something we can fix in STS, but I'll follow up with the Eclipse bug to get my patch applied.
        Hide
        Mauro Molinari added a comment -

        Hi Kris,
        I just verified that Subclipse does not suffer from this problem.
        It's hard for me to test with CVS now, while I don't know Git at all and its decentralized nature makes me think that things may be quite different.

        So, I think it was just a Subversive issue. Thanks for finding it out and help the Subversive team to fix it.

        Show
        Mauro Molinari added a comment - Hi Kris, I just verified that Subclipse does not suffer from this problem. It's hard for me to test with CVS now, while I don't know Git at all and its decentralized nature makes me think that things may be quite different. So, I think it was just a Subversive issue. Thanks for finding it out and help the Subversive team to fix it.

          People

          • Assignee:
            Kris De Volder (c)
            Reporter:
            Mauro Molinari
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              First Response Date: