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

Add Gradle actions to Working Set context menu

    Details

    • Type: Improvement Improvement
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.8.0.RELEASE
    • Fix Version/s: None
    • Component/s: GRADLE
    • Labels:
      None

      Description

      When you have created a Working Set for your Gradle projects, it would be handy having a way to execute gradle actions on the projects that belong to the working set, simply right-clicking on the working set and choosing i.e. |Gradle|Refresh dependencies| for contest menu(as happend for Team and Maven).

        Activity

        Kris De Volder (c) made changes -
        Field Original Value New Value
        Assignee Kris De Volder [ kdvolder ]
        Andrew Eisenberg (c) made changes -
        Component/s MAVEN [ 11170 ]
        Component/s GRADLE [ 10460 ]
        Kris De Volder (c) made changes -
        Component/s GRADLE [ 10460 ]
        Component/s MAVEN [ 11170 ]
        Trevor Marshall (c) made changes -
        Workflow jira [ 38336 ] jira with Pivotal Tracker [ 66345 ]
        Hide
        Davide Cavestro added a comment -

        Hi Kris... any chance to have this feature added?

        Show
        Davide Cavestro added a comment - Hi Kris... any chance to have this feature added?
        Hide
        Kris De Volder (c) added a comment -

        I'll be honest with you. Developing the gradle tools has dropped in priority on my day-to-day job unfortunately and I have a lot of other work.

        Realistically if you want this feature you may need to get your hands dirty and try create a pull request. If you feel up to it let me know I can point you in the right direction and help with any questions you might have in the process.

        Kris

        Show
        Kris De Volder (c) added a comment - I'll be honest with you. Developing the gradle tools has dropped in priority on my day-to-day job unfortunately and I have a lot of other work. Realistically if you want this feature you may need to get your hands dirty and try create a pull request. If you feel up to it let me know I can point you in the right direction and help with any questions you might have in the process. Kris
        Hide
        Kris De Volder (c) added a comment -

        Also before going in and doing a lot of work, you'll have to sign a contributer agreement/release for pull request to get accepted.

        It's required by our legal department. This is pretty standard, but if you have a problem with that its good to know ahead of time before doing lots of work.

        Show
        Kris De Volder (c) added a comment - Also before going in and doing a lot of work, you'll have to sign a contributer agreement/release for pull request to get accepted. It's required by our legal department. This is pretty standard, but if you have a problem with that its good to know ahead of time before doing lots of work.
        Hide
        Mauro Molinari added a comment -

        Hi Kris,
        that's bad news, anyway, that SpringSource is not investing any more on the Gradle integration for STS. Like many other new technologies in the Java ecosystem, this seems to be something that promised a lot but was left somewhere at a half point
        Gradle is a great tool, but without a first-class integration with an IDE I don't think its adoption will ever be so high. Right now that Maven integration for Eclipse seemed to have gained momentum (at last!), leaving Gradle behind is a pity...

        Another thought (that's not strictly related to this issue, sorry): on one hand SpringSource seems to be betting on technologies like Gradle and Groovy, but on the other one it does not invest on adequate tooling for them (Greclipse is another component of STS which is sometimes embarrassing and that seems to be carried out by just a single committer ). This puzzles me quite a lot.

        Yes, we all know we're talking about open source technologies, but it's also a fact that it's not so easy to get involved unless you have the possibility to invest on them a lot. If the leaders (like SpringSource is) are the first to give up, it's hard to think that someone else could realistically carry on the work.

        Just my thoughts to share with you.

        Show
        Mauro Molinari added a comment - Hi Kris, that's bad news, anyway, that SpringSource is not investing any more on the Gradle integration for STS. Like many other new technologies in the Java ecosystem, this seems to be something that promised a lot but was left somewhere at a half point Gradle is a great tool, but without a first-class integration with an IDE I don't think its adoption will ever be so high. Right now that Maven integration for Eclipse seemed to have gained momentum (at last!), leaving Gradle behind is a pity... Another thought (that's not strictly related to this issue, sorry): on one hand SpringSource seems to be betting on technologies like Gradle and Groovy, but on the other one it does not invest on adequate tooling for them (Greclipse is another component of STS which is sometimes embarrassing and that seems to be carried out by just a single committer ). This puzzles me quite a lot. Yes, we all know we're talking about open source technologies, but it's also a fact that it's not so easy to get involved unless you have the possibility to invest on them a lot. If the leaders (like SpringSource is) are the first to give up, it's hard to think that someone else could realistically carry on the work. Just my thoughts to share with you.
        Hide
        Andy Clement (c) added a comment -

        Hey Mauro,

        As Kris says, we have a lot of different projects we work on. We have to prioritize what to do next. Not to single out this particular jira but this one has just 1 vote - more votes raises it on our priority list, doesn't necessarily mean it immediately gets addressed, but it is certainly something we factor in. If you'd like to see this feature too, or any feature/bugfix, please vote for it.

        I'd also be interested in hearing further about what is embarrassing about the groovy tooling? Maybe that's a bit off topic for the jira though, so feel free to email me aclement AT gopivotal.com with your thoughts.

        Yes, unfortunately the barrier to community involvement in eclipse development is very high and so we get very few pull requests for the tools projects. I'm not sure how to improve this situation but I'm open to suggestions if you have any.

        Show
        Andy Clement (c) added a comment - Hey Mauro, As Kris says, we have a lot of different projects we work on. We have to prioritize what to do next. Not to single out this particular jira but this one has just 1 vote - more votes raises it on our priority list, doesn't necessarily mean it immediately gets addressed, but it is certainly something we factor in. If you'd like to see this feature too, or any feature/bugfix, please vote for it. I'd also be interested in hearing further about what is embarrassing about the groovy tooling? Maybe that's a bit off topic for the jira though, so feel free to email me aclement AT gopivotal.com with your thoughts. Yes, unfortunately the barrier to community involvement in eclipse development is very high and so we get very few pull requests for the tools projects. I'm not sure how to improve this situation but I'm open to suggestions if you have any.
        Hide
        Mauro Molinari added a comment -

        Hi Andy, thanks for your reply. Kris's comment sounded more like a "almost no more work planned here" rather than a "this is a low priority issue" and this is why I said it's sad, especially because in the past years Kris did a fantastic job on the Gradle integration for Eclipse and was very committed on it. Put in other words, he spoiled us
        Anyway, I also think that if the Java ecosystem is fantastic when we talk about standards and platforms, the tooling aspects are always considered as low priority... This is in contrast with other much less spread technologies that are providing users with excellent tools from the beginning (think of Delphi, for instance).

        Regarding Greclipse, I'll write you an e-mail, thank you. As an extreme summary, since Groovy is almost all about productivity, having a tool which is far behind the JDT tools in functionality does certainly not help. Also, it sometimes suffers of problems that are so severe that prevents you from using Groovy at all in an enterprise-grade project, at least if Eclipse is your IDE of choice.

        Regarding the barrier to community adoption, I think there's also a great responsibility of companies that don't like to invest employees time to be spent on open source projects like these... So if the barrier is high it's difficult that one will be interested in spending his own spare time on them, especially because one needs time for real life, too. The extent of the Eclipse infrastructure also does not help: in my case, even if I'm an experienced Java SE/EE professional, I would need to learn SWT, the Eclipse Platform, OSGi, Eclipse plugin development, maybe EMF and so on to start to understand how things work...

        Show
        Mauro Molinari added a comment - Hi Andy, thanks for your reply. Kris's comment sounded more like a "almost no more work planned here" rather than a "this is a low priority issue" and this is why I said it's sad, especially because in the past years Kris did a fantastic job on the Gradle integration for Eclipse and was very committed on it. Put in other words, he spoiled us Anyway, I also think that if the Java ecosystem is fantastic when we talk about standards and platforms, the tooling aspects are always considered as low priority... This is in contrast with other much less spread technologies that are providing users with excellent tools from the beginning (think of Delphi, for instance). Regarding Greclipse, I'll write you an e-mail, thank you. As an extreme summary, since Groovy is almost all about productivity, having a tool which is far behind the JDT tools in functionality does certainly not help. Also, it sometimes suffers of problems that are so severe that prevents you from using Groovy at all in an enterprise-grade project, at least if Eclipse is your IDE of choice. Regarding the barrier to community adoption, I think there's also a great responsibility of companies that don't like to invest employees time to be spent on open source projects like these... So if the barrier is high it's difficult that one will be interested in spending his own spare time on them, especially because one needs time for real life, too. The extent of the Eclipse infrastructure also does not help: in my case, even if I'm an experienced Java SE/EE professional, I would need to learn SWT, the Eclipse Platform, OSGi, Eclipse plugin development, maybe EMF and so on to start to understand how things work...
        Hide
        Alex Boyko added a comment -

        Mauro, myself and Kris delivered the fix for this issue. Can you please try the latest to check if that fix solves the problem for you?

        Show
        Alex Boyko added a comment - Mauro, myself and Kris delivered the fix for this issue. Can you please try the latest to check if that fix solves the problem for you?
        Hide
        Davide Cavestro added a comment - - edited

        That's great
        I'm going to give it a try from http://dist.springsource.com/snapshot/TOOLS/gradle/nightly

        Show
        Davide Cavestro added a comment - - edited That's great I'm going to give it a try from http://dist.springsource.com/snapshot/TOOLS/gradle/nightly
        Hide
        Davide Cavestro added a comment -

        I'm stressing it quite a lot, and it works like a charm: many thanks!!!

        Show
        Davide Cavestro added a comment - I'm stressing it quite a lot, and it works like a charm: many thanks!!!
        Hide
        Mauro Molinari added a comment -

        Thanks for implementing this!

        Show
        Mauro Molinari added a comment - Thanks for implementing this!
        Alex Boyko made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 8 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        806d 1h 17m 1 Alex Boyko 23/Jan/14 10:07 AM

          People

          • Assignee:
            Kris De Volder (c)
            Reporter:
            Davide Cavestro
          • Votes:
            1 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              First Response Date: