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

As a developer, I would like to be able to import Spring Security using Gradle Integration

    Details

    • Type: Improvement Improvement
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: 2.7.0.M2
    • Fix Version/s: 2.9.0.M1
    • Component/s: GRADLE
    • Labels:
      None

      Description

      First I would like to say that the Gradle integration is coming along great and I hope that it continues to progress so quickly. Thank you for all your hard work!

      I am one of the Spring Security committers and would love to be able to use STS Gradle integration to import Spring Security. Below are a list of things I would like to be able to 'just do'. Please note that all of these things are done when using standard Gradle (i.e. running gradle eclipse) which might be useful for helping understand what I am looking for.

      • Everything should compile. One of the things I noticed is that spring-security-core's src/test/java is normally added to other project's (i.e. spring-security-web) classpath. However, when running with STS Gradle integration I get this error:

        The container 'Gradle Dependencies' references non existing library '/home/rwinch/spring-security/core/build/classes/test'

      • All tests should pass
      • AspectJ integration should work (this is necessary for the tests to pass)
      • All the war sample projects should be able to be ran using WTP (i.e. WTP integration)
        • It would be nice if the context root of the application could be specified. Currently we configure WTP context root using the context root configured for the Jetty plugin.
      • It would be nice if the eclipse projects were renamed as they are in the standard build. For example when importing the project using STS I get the project name spring-security.spring-security-crypto, but when using standard Gradle the name is spring-security-crypto
      • Use EGit to clone the project. Then support Import project...->Use the new projects wizard to invoke Import -> Gradle project

      Bonus Features:

      Thanks again for all the hard work and let me know if there is anything I can do to assist.

      Rob Winch

        Activity

        Hide
        Rob Winch (c) added a comment -

        PS: For your convenience here is a link to obtaining the source for Spring Security http://static.springsource.org/spring-security/site/source.html

        Show
        Rob Winch (c) added a comment - PS: For your convenience here is a link to obtaining the source for Spring Security http://static.springsource.org/spring-security/site/source.html
        Kris De Volder (c) made changes -
        Field Original Value New Value
        Assignee Kris De Volder [ kdvolder ]
        Hide
        Kris De Volder (c) added a comment -

        Hi Rob, this is a useful 'todo list' .

        Just a quick comment. The names for imported projects can follow one of two naming schemes. All you have to do to get the other naming scheme (the one you want) is to uncheck the "Use hierarchical names" checkbox in the wizard.

        Perhaps I should consider switching the default to have the checkbox off.

        Show
        Kris De Volder (c) added a comment - Hi Rob, this is a useful 'todo list' . Just a quick comment. The names for imported projects can follow one of two naming schemes. All you have to do to get the other naming scheme (the one you want) is to uncheck the "Use hierarchical names" checkbox in the wizard. Perhaps I should consider switching the default to have the checkbox off.
        Hide
        Kris De Volder (c) added a comment - - edited

        Everything should compile. I think this is now indeed the case. Problem you mentioned was something that I think came about because of problems in early versions of the Gradle tooling API returning some bad info.

        EDIT: Sorry, I retract that. There are still problems it just took a while before they showed up.

        Show
        Kris De Volder (c) added a comment - - edited Everything should compile. I think this is now indeed the case. Problem you mentioned was something that I think came about because of problems in early versions of the Gradle tooling API returning some bad info. EDIT: Sorry, I retract that. There are still problems it just took a while before they showed up.
        Kris De Volder (c) made changes -
        Description First I would like to say that the Gradle integration is coming along great and I hope that it continues to progress so quickly. Thank you for all your hard work!

        I am one of the Spring Security committers and would love to be able to use STS Gradle integration to import Spring Security. Below are a list of things I would like to be able to 'just do'. Please note that all of these things are done when using standard Gradle (i.e. running gradle eclipse) which might be useful for helping understand what I am looking for.

        * Everything should compile. One of the things I noticed is that spring-security-core's src/test/java is normally added to other project's (i.e. spring-security-web) classpath. However, when running with STS Gradle integration I get this error:
        {quote}
        The container 'Gradle Dependencies' references non existing library '/home/rwinch/spring-security/core/build/classes/test'
        {quote}
        * All tests should pass
        * AspectJ integration should work (this is necessary for the tests to pass)
        * All the war sample projects should be able to be ran using WTP (i.e. WTP integration)
        ** It would be nice if the context root of the application could be specified. Currently we configure WTP context root using the context root configured for the Jetty plugin.
        * It would be nice if the eclipse projects were renamed as they are in the standard build. For example when importing the project using STS I get the project name spring-security.spring-security-crypto, but when using standard Gradle the name is spring-security-crypto
        * Use EGit to clone the project. Then support Import project...->Use the new projects wizard to invoke Import -> Gradle project

        Bonus Features:

        * Dependency management support similar to maven eclipse
        ** Adding/removing dependencies using maven indexes
        ** Viewing a dependency tree and filtering based upon the configuration
        * Editing .gradle files
        ** DSL descriptor support for gradle as described in http://blog.springsource.com/2011/05/08/better-dsl-support-in-groovy-eclipse/
        ** Type inference of standard Gradle objects

        Thanks again for all the hard work and let me know if there is anything I can do to assist.

        Rob Winch
        First I would like to say that the Gradle integration is coming along great and I hope that it continues to progress so quickly. Thank you for all your hard work!

        I am one of the Spring Security committers and would love to be able to use STS Gradle integration to import Spring Security. Below are a list of things I would like to be able to 'just do'. Please note that all of these things are done when using standard Gradle (i.e. running gradle eclipse) which might be useful for helping understand what I am looking for.

        * DONE: Everything should compile. One of the things I noticed is that spring-security-core's src/test/java is normally added to other project's (i.e. spring-security-web) classpath. However, when running with STS Gradle integration I get this error:
        {quote}
        The container 'Gradle Dependencies' references non existing library '/home/rwinch/spring-security/core/build/classes/test'
        {quote}
        * All tests should pass
        * AspectJ integration should work (this is necessary for the tests to pass)
        * All the war sample projects should be able to be ran using WTP (i.e. WTP integration)
        ** It would be nice if the context root of the application could be specified. Currently we configure WTP context root using the context root configured for the Jetty plugin.
        * It would be nice if the eclipse projects were renamed as they are in the standard build. For example when importing the project using STS I get the project name spring-security.spring-security-crypto, but when using standard Gradle the name is spring-security-crypto
        * Use EGit to clone the project. Then support Import project...->Use the new projects wizard to invoke Import -> Gradle project

        Bonus Features:

        * Dependency management support similar to maven eclipse
        ** Adding/removing dependencies using maven indexes
        ** Viewing a dependency tree and filtering based upon the configuration
        * Editing .gradle files
        ** DSL descriptor support for gradle as described in http://blog.springsource.com/2011/05/08/better-dsl-support-in-groovy-eclipse/
        ** Type inference of standard Gradle objects

        Thanks again for all the hard work and let me know if there is anything I can do to assist.

        Rob Winch
        Kris De Volder (c) made changes -
        Description First I would like to say that the Gradle integration is coming along great and I hope that it continues to progress so quickly. Thank you for all your hard work!

        I am one of the Spring Security committers and would love to be able to use STS Gradle integration to import Spring Security. Below are a list of things I would like to be able to 'just do'. Please note that all of these things are done when using standard Gradle (i.e. running gradle eclipse) which might be useful for helping understand what I am looking for.

        * DONE: Everything should compile. One of the things I noticed is that spring-security-core's src/test/java is normally added to other project's (i.e. spring-security-web) classpath. However, when running with STS Gradle integration I get this error:
        {quote}
        The container 'Gradle Dependencies' references non existing library '/home/rwinch/spring-security/core/build/classes/test'
        {quote}
        * All tests should pass
        * AspectJ integration should work (this is necessary for the tests to pass)
        * All the war sample projects should be able to be ran using WTP (i.e. WTP integration)
        ** It would be nice if the context root of the application could be specified. Currently we configure WTP context root using the context root configured for the Jetty plugin.
        * It would be nice if the eclipse projects were renamed as they are in the standard build. For example when importing the project using STS I get the project name spring-security.spring-security-crypto, but when using standard Gradle the name is spring-security-crypto
        * Use EGit to clone the project. Then support Import project...->Use the new projects wizard to invoke Import -> Gradle project

        Bonus Features:

        * Dependency management support similar to maven eclipse
        ** Adding/removing dependencies using maven indexes
        ** Viewing a dependency tree and filtering based upon the configuration
        * Editing .gradle files
        ** DSL descriptor support for gradle as described in http://blog.springsource.com/2011/05/08/better-dsl-support-in-groovy-eclipse/
        ** Type inference of standard Gradle objects

        Thanks again for all the hard work and let me know if there is anything I can do to assist.

        Rob Winch
        First I would like to say that the Gradle integration is coming along great and I hope that it continues to progress so quickly. Thank you for all your hard work!

        I am one of the Spring Security committers and would love to be able to use STS Gradle integration to import Spring Security. Below are a list of things I would like to be able to 'just do'. Please note that all of these things are done when using standard Gradle (i.e. running gradle eclipse) which might be useful for helping understand what I am looking for.

        * Everything should compile. One of the things I noticed is that spring-security-core's src/test/java is normally added to other project's (i.e. spring-security-web) classpath. However, when running with STS Gradle integration I get this error:
        {quote}
        The container 'Gradle Dependencies' references non existing library '/home/rwinch/spring-security/core/build/classes/test'
        {quote}
        * All tests should pass
        * AspectJ integration should work (this is necessary for the tests to pass)
        * All the war sample projects should be able to be ran using WTP (i.e. WTP integration)
        ** It would be nice if the context root of the application could be specified. Currently we configure WTP context root using the context root configured for the Jetty plugin.
        * It would be nice if the eclipse projects were renamed as they are in the standard build. For example when importing the project using STS I get the project name spring-security.spring-security-crypto, but when using standard Gradle the name is spring-security-crypto
        * Use EGit to clone the project. Then support Import project...->Use the new projects wizard to invoke Import -> Gradle project

        Bonus Features:

        * Dependency management support similar to maven eclipse
        ** Adding/removing dependencies using maven indexes
        ** Viewing a dependency tree and filtering based upon the configuration
        * Editing .gradle files
        ** DSL descriptor support for gradle as described in http://blog.springsource.com/2011/05/08/better-dsl-support-in-groovy-eclipse/
        ** Type inference of standard Gradle objects

        Thanks again for all the hard work and let me know if there is anything I can do to assist.

        Rob Winch
        Hide
        Kris De Volder (c) added a comment -

        I think the build path problem is caused by this bit in the XXX.gradle files of the respective projects that have this error:

           testCompile project(':spring-security-core').sourceSets.test.classes,
                       ...
        

        Gradle is translating that for us into a dependency on an output folder that doesn't exist (the output folder is, I think created by running gradle build on the commandline). I'll raise an issue against Gradle tooling API for defining some better way to handle this.

        Maybe the solution is to have gradle actually provide more info on output folders that are supposed to be associated with given source folders (now all are mapped onto the same default output folder).

        Or maybe the dependency could be approximated as a project dependency. It does seem to work for me if I change the dependency above into

        testCompile project(':spring-security-core')

        Show
        Kris De Volder (c) added a comment - I think the build path problem is caused by this bit in the XXX.gradle files of the respective projects that have this error: testCompile project(':spring-security-core').sourceSets.test.classes, ... Gradle is translating that for us into a dependency on an output folder that doesn't exist (the output folder is, I think created by running gradle build on the commandline). I'll raise an issue against Gradle tooling API for defining some better way to handle this. Maybe the solution is to have gradle actually provide more info on output folders that are supposed to be associated with given source folders (now all are mapped onto the same default output folder). Or maybe the dependency could be approximated as a project dependency. It does seem to work for me if I change the dependency above into testCompile project(':spring-security-core')
        Kris De Volder (c) made changes -
        Comment [ I think the build path problem is caused by this bit in the XXX.gradle files of the respective projects that have this error:

        {noformat}
           testCompile project(':spring-security-core').sourceSets.test.classes,
                       ...
        {noformat}

        Gradle is translating that for us into a dependency on an output folder that doesn't exist (the output folder is, I think created by running gradle build on the commandline). I'll raise an issue against Gradle tooling API for defining some better way to handle this.

        Maybe the solution is to have gradle actually provide more info on output folders that are supposed to be associated with given source folders (now all are mapped onto the same default output folder).

        Or maybe the dependency could be approximated as a project dependency. It does seem to work for me if I change the dependency above into

        testCompile project(':spring-security-core')
        ]
        Hide
        Rob Winch (c) added a comment -

        Thanks for your work on this Kris. You are correct that the gradle preference is what I needed to get the project names the way I expected them.

        I was curious how realistic or far in the future you thought some of these concepts might be. I had initially thought I was going to post on the forums (as this was an option you had mentioned for communicating such requests), but thought better of it at the last second and posted to JIRA. This is why the JIRA has so many tasks all in one (sorry about that). Given some of the scope of these tasks, I or you may be well served in breaking them off into separate tasks. This is totally up to you, but I thought I would openly endorse that option.

        Thanks again for your hard work.

        PS: If I was able to prioritize these requests I would prefer to focus on getting it so that users can run the samples in STS (i.e. with WTP) as easily as possible. The order would be projects compiling, WTP support, and then AspectJ support.

        Show
        Rob Winch (c) added a comment - Thanks for your work on this Kris. You are correct that the gradle preference is what I needed to get the project names the way I expected them. I was curious how realistic or far in the future you thought some of these concepts might be. I had initially thought I was going to post on the forums (as this was an option you had mentioned for communicating such requests), but thought better of it at the last second and posted to JIRA. This is why the JIRA has so many tasks all in one (sorry about that). Given some of the scope of these tasks, I or you may be well served in breaking them off into separate tasks. This is totally up to you, but I thought I would openly endorse that option. Thanks again for your hard work. PS: If I was able to prioritize these requests I would prefer to focus on getting it so that users can run the samples in STS (i.e. with WTP) as easily as possible. The order would be projects compiling, WTP support, and then AspectJ support.
        Hide
        Kris De Volder (c) added a comment -

        > I was curious how realistic or far in the future you thought some of these concepts might be

        A lot of this depends on Gradle Tooling API being further developed and unfortunately I don't have much control over that. We do have a good connection with the guys over at GradleWare, but they seem to be quite busy with lots of stuff so the API isn't moving ahead as fast as we'd hoped for.

        I did experiment a little with something that I initially didn't think was a very good idea:

        You can try to get a bigger bang for your buck by running the gradle eclipse task before importing with the the STS import wizard. This works surprisingly well. About the only obvious problem I could see was that you get the dependencies duplicated in "Referenced Libraries" (generated by gradle eclipse) and "Gradle Dependencies" (managed by STS tooling).

        But that's about it and is fairly easy to rectify. I added some code to the STS tooling to try and clean that up already.

        I wonder if you'd mind trying a little experiment and tell me how it works for you:

        1) get the latest nightly gradle tooling
        http://dist.springsource.com/snapshot/TOOLS/nightly/gradle (latest development snapshot)

        2) generate eclipse files with gradle
        ./gradlew cleanEclipse eclipse

        3) import with the STS Gradle import wizard.

        BTW, you will notice that I changed the default for the project names, since, I gather it is probably what you want 90% of the time.

        Before you try... I'll warn you of some known problems to expect:

        I'd be interested how well that works for you... (just to get a sense of how badly broken things still are FYI, I was able to get the project imported and compiling without any errors in STS that way.

        I didn't try running tests, WTP apps etc since I'm not all that sure where they are and how you'd run them and what you'd expect to see. (Is there some place that I can read about this?)

        Show
        Kris De Volder (c) added a comment - > I was curious how realistic or far in the future you thought some of these concepts might be A lot of this depends on Gradle Tooling API being further developed and unfortunately I don't have much control over that. We do have a good connection with the guys over at GradleWare, but they seem to be quite busy with lots of stuff so the API isn't moving ahead as fast as we'd hoped for. I did experiment a little with something that I initially didn't think was a very good idea: You can try to get a bigger bang for your buck by running the gradle eclipse task before importing with the the STS import wizard. This works surprisingly well. About the only obvious problem I could see was that you get the dependencies duplicated in "Referenced Libraries" (generated by gradle eclipse) and "Gradle Dependencies" (managed by STS tooling). But that's about it and is fairly easy to rectify. I added some code to the STS tooling to try and clean that up already. I wonder if you'd mind trying a little experiment and tell me how it works for you: 1) get the latest nightly gradle tooling http://dist.springsource.com/snapshot/TOOLS/nightly/gradle (latest development snapshot) 2) generate eclipse files with gradle ./gradlew cleanEclipse eclipse 3) import with the STS Gradle import wizard. BTW, you will notice that I changed the default for the project names, since, I gather it is probably what you want 90% of the time. Before you try... I'll warn you of some known problems to expect: http://issues.gradle.org/browse/GRADLE-1765 => workaround: you can avoid this by setting the gradle distribution on the Gradle preferences page in STS which will override the gradle version for all projects in workspace. http://issues.gradle.org/browse/GRADLE-1766 => workaround as described above, replace sourceset dependency with project dependency I'd be interested how well that works for you... (just to get a sense of how badly broken things still are FYI, I was able to get the project imported and compiling without any errors in STS that way. I didn't try running tests, WTP apps etc since I'm not all that sure where they are and how you'd run them and what you'd expect to see. (Is there some place that I can read about this?)
        Hide
        Rob Winch (c) added a comment -

        Thanks for your response.

        >> You can try to get a bigger bang for your buck by running the gradle eclipse task before importing with the the STS import wizard.

        Is there a benefit to running the command line and then doing the import as apposed to just importing as an existing Eclipse project after doing the build? There might be added value that I am just unaware of.

        Not sure if this is a good idea or if it is even possible, but do you think that you could make it so that Gradle Eclipse plugin can run a gradle task on project import? This might allow for developers to put in a lot of their tweaks that are needed until the Gradle Tooling API's can be updated. This also would help since a lot of users are, unfortunately, reluctant to open a command prompt.

        >> I wonder if you'd mind trying a little experiment and tell me how it works for you:

        I can probably do that this weekend. I will be sure to post back the results.

        >> I didn't try running tests, WTP apps etc since I'm not all that sure where they are and how you'd run them and what you'd expect to see. (Is there some place that I can read about this?)

        I can certainly try this out too, but for your own information...The documentation on running the samples is still a work in progress, but any of the war projects should run in WTP. The best documentation we have for running them in Eclipse exists in these two blog entries. I realize it is not much, but I am hoping to make running the sames as easy as possible in STS with some help from resolving this issue. The only sample application that has integration tests at this time is the cas sample, so likely I will need to click through the applications to validate things are working (I will do that this weekend). Perhaps I can spend a bit of time getting integration tests written for the other samples too.

        Thanks again for your help.

        Show
        Rob Winch (c) added a comment - Thanks for your response. >> You can try to get a bigger bang for your buck by running the gradle eclipse task before importing with the the STS import wizard. Is there a benefit to running the command line and then doing the import as apposed to just importing as an existing Eclipse project after doing the build? There might be added value that I am just unaware of. Not sure if this is a good idea or if it is even possible, but do you think that you could make it so that Gradle Eclipse plugin can run a gradle task on project import? This might allow for developers to put in a lot of their tweaks that are needed until the Gradle Tooling API's can be updated. This also would help since a lot of users are, unfortunately, reluctant to open a command prompt. >> I wonder if you'd mind trying a little experiment and tell me how it works for you: I can probably do that this weekend. I will be sure to post back the results. >> I didn't try running tests, WTP apps etc since I'm not all that sure where they are and how you'd run them and what you'd expect to see. (Is there some place that I can read about this?) I can certainly try this out too, but for your own information...The documentation on running the samples is still a work in progress, but any of the war projects should run in WTP. The best documentation we have for running them in Eclipse exists in these two blog entries. I realize it is not much, but I am hoping to make running the sames as easy as possible in STS with some help from resolving this issue. The only sample application that has integration tests at this time is the cas sample, so likely I will need to click through the applications to validate things are working (I will do that this weekend). Perhaps I can spend a bit of time getting integration tests written for the other samples too. Thanks again for your help.
        Hide
        Kris De Volder (c) added a comment - - edited

        > Is there a benefit to running the command line and then doing the import as apposed to just importing as an > existing Eclipse project after doing the build? There might be added value that I am just unaware of.

        At the moment it isn't really much of an advantage. But there is some.
        1) Gradle Dependencies classpapth container udpates 'dynamically'.

        Now, actually at the moment this 'dynamicity' is still very limited. You need to manually trigger it from the menu. So you could argue it isn't much different from rerunning the eclipse task and refreshing your workspace. Eventually we want to really make that dynamic in the true sense of the word. I.e you change some stuff in your project and it gets automatically refreshed). I'm kind a waiting on Gradle guys to decide with them how this should be triggered via api. But there may be things we could do just in the IDE. E.g. if a XXX.gradle file changes, refresh the model associated with its project. (Any ideas welcome on a good 'refresh trigger'

        2) Import wizard understand project dependencies
        You can import some projects and not others. The wizard will help you to make sure you have the required dependent projects.

        3) Projects follow a flexible naming scheme. You can rename without breaking the project dependencies.
        (And if you change you build scripts, changing the dependencies, a refresh dependencies will still know
        what project is what, even if you changed their eclipse names)

        > Not sure if this is a good idea or if it is even possible, but do you think that you could make it so
        > that Gradle Eclipse plugin can run a gradle task on project import? This might allow for developers to
        > put in a lot of their tweaks that are needed until the Gradle Tooling API's can be updated. This also
        > would help since a lot of users are, unfortunately, reluctant to open a command prompt.

        That doesn't sound like a bad idea at all, and I don't think it would be very hard to implement either.
        Raise a feature request and we can discuss a bit exactly what form it should take (e.g. always run some specific task, if it exists, or should the task be configurable from the UI somehow?)

        Show
        Kris De Volder (c) added a comment - - edited > Is there a benefit to running the command line and then doing the import as apposed to just importing as an > existing Eclipse project after doing the build? There might be added value that I am just unaware of. At the moment it isn't really much of an advantage. But there is some. 1) Gradle Dependencies classpapth container udpates 'dynamically'. Now, actually at the moment this 'dynamicity' is still very limited. You need to manually trigger it from the menu. So you could argue it isn't much different from rerunning the eclipse task and refreshing your workspace. Eventually we want to really make that dynamic in the true sense of the word. I.e you change some stuff in your project and it gets automatically refreshed). I'm kind a waiting on Gradle guys to decide with them how this should be triggered via api. But there may be things we could do just in the IDE. E.g. if a XXX.gradle file changes, refresh the model associated with its project. (Any ideas welcome on a good 'refresh trigger' 2) Import wizard understand project dependencies You can import some projects and not others. The wizard will help you to make sure you have the required dependent projects. 3) Projects follow a flexible naming scheme. You can rename without breaking the project dependencies. (And if you change you build scripts, changing the dependencies, a refresh dependencies will still know what project is what, even if you changed their eclipse names) > Not sure if this is a good idea or if it is even possible, but do you think that you could make it so > that Gradle Eclipse plugin can run a gradle task on project import? This might allow for developers to > put in a lot of their tweaks that are needed until the Gradle Tooling API's can be updated. This also > would help since a lot of users are, unfortunately, reluctant to open a command prompt. That doesn't sound like a bad idea at all, and I don't think it would be very hard to implement either. Raise a feature request and we can discuss a bit exactly what form it should take (e.g. always run some specific task, if it exists, or should the task be configurable from the UI somehow?)
        Hide
        Rob Winch (c) added a comment -

        >> Before you try... I'll warn you of some known problems to expect:

        Unless I am missing something the workaround for GRADLE-1766 works for the IDE, but breaks our actual build. I have commented as such on the JIRA.

        >> Raise a feature request and we can discuss a bit exactly what form it should take (e.g. always run some specific task, if it exists, or should the task be configurable from the UI somehow?)

        That would be wonderful. I logged STS-2059.

        >> I didn't try running tests, WTP apps etc since I'm not all that sure where they are and how you'd run them and what you'd expect to see.

        I'm having some problems getting the samples to deploy using WTP (also see note below the steps). Steps to reproduce include:

        • Setup a workspace as you have described
        • Create a server (I used Tomcat 7.0.16)
        • Add spring-security-samples-jaas to the server and start the server up
        • I got ClassNotFoundException: org.springframework.web.context.ContextLoaderListener
        • If I right click the project and go to Deployment Assempbly and add The Gradle Dependencies everything works. However, this is still not ideal since Eclipse will then deploy my test dependencies too (which it should not)

        Note: I should note that I also have these problems when using Gradle directly. I had to code into our build some fixes that changed the default behaviour of the Eclipse plugins. The relevant issues are GRADLE-116, GRADLE-1426, and GRADLE-1422. You can find the workarounds for these issues in /spring-security/gradle/ide-integration.gradle (there are comments referencing the JIRA's). It is quite possible if they are fixed it would fix the tooling, but I am not certain. This may be yet another reason that STS-2059 is a good idea. Let me know how you would like to proceed.

        >> At the moment it isn't really much of an advantage. But there is some.

        I thought I would mention that another benefit of using the gradle import is I can easily access some of the other projects (i.e. faq, manual). I also like that I only need to import once to get the top level project (spring-security) which I am unable to do using the standard import existing Eclipse projects due to its restrictions on project hiearchy. To me these benefits alone make it worth using.

        Show
        Rob Winch (c) added a comment - >> Before you try... I'll warn you of some known problems to expect: Unless I am missing something the workaround for GRADLE-1766 works for the IDE, but breaks our actual build. I have commented as such on the JIRA. >> Raise a feature request and we can discuss a bit exactly what form it should take (e.g. always run some specific task, if it exists, or should the task be configurable from the UI somehow?) That would be wonderful. I logged STS-2059 . >> I didn't try running tests, WTP apps etc since I'm not all that sure where they are and how you'd run them and what you'd expect to see. I'm having some problems getting the samples to deploy using WTP (also see note below the steps). Steps to reproduce include: Setup a workspace as you have described Create a server (I used Tomcat 7.0.16) Add spring-security-samples-jaas to the server and start the server up I got ClassNotFoundException: org.springframework.web.context.ContextLoaderListener If I right click the project and go to Deployment Assempbly and add The Gradle Dependencies everything works. However, this is still not ideal since Eclipse will then deploy my test dependencies too (which it should not) Note : I should note that I also have these problems when using Gradle directly. I had to code into our build some fixes that changed the default behaviour of the Eclipse plugins. The relevant issues are GRADLE-116 , GRADLE-1426 , and GRADLE-1422 . You can find the workarounds for these issues in /spring-security/gradle/ide-integration.gradle (there are comments referencing the JIRA's). It is quite possible if they are fixed it would fix the tooling, but I am not certain. This may be yet another reason that STS-2059 is a good idea. Let me know how you would like to proceed. >> At the moment it isn't really much of an advantage. But there is some. I thought I would mention that another benefit of using the gradle import is I can easily access some of the other projects (i.e. faq, manual). I also like that I only need to import once to get the top level project (spring-security) which I am unable to do using the standard import existing Eclipse projects due to its restrictions on project hiearchy. To me these benefits alone make it worth using.
        Hide
        Kris De Volder (c) added a comment -

        Thanks for that, probably it is possible to fix it so we add the Gradle Dependencies container to the component assembly automatically. I raised an issue for that here:

        https://issuetracker.springsource.com/browse/STS-2063

        I guess this gets broken when we 'fix' the project up after the eclipse files got generated by Gradle because we replace the raw classpath entries into a classpath container, but without updating any WTP related stuff (i.e. component assembly).

        Show
        Kris De Volder (c) added a comment - Thanks for that, probably it is possible to fix it so we add the Gradle Dependencies container to the component assembly automatically. I raised an issue for that here: https://issuetracker.springsource.com/browse/STS-2063 I guess this gets broken when we 'fix' the project up after the eclipse files got generated by Gradle because we replace the raw classpath entries into a classpath container, but without updating any WTP related stuff (i.e. component assembly).
        Hide
        Kris De Volder (c) added a comment -

        Hey Rob, FYI, a little progress made towards this issue.

        In particular: https://issuetracker.springsource.com/browse/STS-2069

        With latest nightly build (wait until tomorrow if you want to try). It should now not be necessary anymore to replace the sourceSet dependencies. The 'illegal' classpath entries that are created as result of it are recognized and ignored (with a quick 'safety' check to see if there's a corresponding project dependency. For me, this seems enough to make the projects compile without errors.

        Show
        Kris De Volder (c) added a comment - Hey Rob, FYI, a little progress made towards this issue. In particular: https://issuetracker.springsource.com/browse/STS-2069 With latest nightly build (wait until tomorrow if you want to try). It should now not be necessary anymore to replace the sourceSet dependencies. The 'illegal' classpath entries that are created as result of it are recognized and ignored (with a quick 'safety' check to see if there's a corresponding project dependency. For me, this seems enough to make the projects compile without errors.
        Hide
        Rob Winch (c) added a comment -

        Thanks Kris. It appears it has already built (I happened to get the updates just prior to validating the dependencies that needed to be excluded as requested in STS-2063). This worked for me as well.

        Show
        Rob Winch (c) added a comment - Thanks Kris. It appears it has already built (I happened to get the updates just prior to validating the dependencies that needed to be excluded as requested in STS-2063 ). This worked for me as well.
        Andrew Eisenberg (c) made changes -
        Component/s MAVEN [ 11170 ]
        Component/s GRADLE [ 10460 ]
        Andrew Eisenberg (c) made changes -
        Component/s GRADLE [ 10460 ]
        Component/s MAVEN [ 11170 ]
        Hide
        Kris De Volder (c) added a comment - - edited

        Hey Rob,

        I'm closing this issue. I'm sure I didn't yet do all that you were asking for and there are still improvements possible.

        I think however a basic 'import' of spring-security should work now and things such as compiling, deploying the samples etc. should work.

        Things will probably work a little better with more recent version of Gradle also, but I think the spring-security build-script is still requiring M3 so your build script itself may need some work to make that possible.

        Main reason why it will work better is that in more recent Gradle it is possible for STS to reliably determine whether eclipse tasks are available for a project which means that it can turn on running those tasks by default.

        This is important for spring-security because of aspectj natures, WTP natures etc. Right now the only way to get support for those is running the eclipse task.

        Anyhow, I would appreciate very much that if you are trying the tools, you could raise more issues for your most pressing pain points and problems based on the current state of the tools.

        I will also open some separate issues myself based on what I think is still left to do based on your original list.

        Show
        Kris De Volder (c) added a comment - - edited Hey Rob, I'm closing this issue. I'm sure I didn't yet do all that you were asking for and there are still improvements possible. I think however a basic 'import' of spring-security should work now and things such as compiling, deploying the samples etc. should work. Things will probably work a little better with more recent version of Gradle also, but I think the spring-security build-script is still requiring M3 so your build script itself may need some work to make that possible. Main reason why it will work better is that in more recent Gradle it is possible for STS to reliably determine whether eclipse tasks are available for a project which means that it can turn on running those tasks by default. This is important for spring-security because of aspectj natures, WTP natures etc. Right now the only way to get support for those is running the eclipse task. Anyhow, I would appreciate very much that if you are trying the tools, you could raise more issues for your most pressing pain points and problems based on the current state of the tools. I will also open some separate issues myself based on what I think is still left to do based on your original list.
        Kris De Volder (c) made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 2.9.0.M1 [ 11799 ]
        Resolution Complete [ 13 ]
        Hide
        Kris De Volder (c) added a comment - - edited

        Issue raised: https://issuetracker.springsource.com/browse/STS-2342 (maven index integration)
        Existing issue: https://issuetracker.springsource.com/browse/STS-2088 (DSLD support)
        Issue raised: https://issuetracker.springsource.com/browse/STS-1856 (EGit integration)

        Show
        Kris De Volder (c) added a comment - - edited Issue raised: https://issuetracker.springsource.com/browse/STS-2342 (maven index integration) Existing issue: https://issuetracker.springsource.com/browse/STS-2088 (DSLD support) Issue raised: https://issuetracker.springsource.com/browse/STS-1856 (EGit integration)
        Hide
        Rob Winch (c) added a comment -

        Kris,

        Thank you for following up on this. I agree that a majority of my concerns have been addressed. Hopefully I can get some time to update to the latest gradle soon. At that time I will be certain to provide new JIRA's for issues I encounter. Thanks for the excellent support.

        Show
        Rob Winch (c) added a comment - Kris, Thank you for following up on this. I agree that a majority of my concerns have been addressed. Hopefully I can get some time to update to the latest gradle soon. At that time I will be certain to provide new JIRA's for issues I encounter. Thanks for the excellent support.
        Hide
        Kris De Volder (c) added a comment -

        Great... thanks! It is a big help to get feedback like this. Working with spring-security as a 'test project' has been quite helpful to me in figuring out what needs fixing

        Show
        Kris De Volder (c) added a comment - Great... thanks! It is a big help to get feedback like this. Working with spring-security as a 'test project' has been quite helpful to me in figuring out what needs fixing
        Trevor Marshall (c) made changes -
        Workflow jira [ 33482 ] jira with Pivotal Tracker [ 66452 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        180d 15h 32m 1 Kris De Volder (c) 16/Dec/11 12:11 PM

          People

          • Assignee:
            Kris De Volder (c)
            Reporter:
            Rob Winch (c)
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              First Response Date: