make Spring Tools 4 features available for non-boot Spring apps

[martinlippert]

The idea is to make certain Spring Tools 4 features available for non-boot Spring projects.

[martinlippert]

things that should be relatively easy to realize:

• making quick navigation work for regular Spring projects

things that are hard or impossible:

• live hover/code lenses due to missing actuator endpoints in the app (so we don't get information out of the running apps) - we could solve this by having something like the actuator JMX endpoints in core Spring, but I don't think that will happen anytime soon

[mauromol]

So, is STS4 right now totally inactive for a classical webapp (or stand alone app) using Spring support but not Spring Boot? That's something I had not understood clearly.

I really hope you'll end up with something that does not push users to lock in with Spring Boot-only...

[martinlippert]

@mauromol The current version of the Spring Tools 4 is solely focused on Spring Boot applications when it comes to the Spring-specific features that we have implemented.

Of course you can continue to use Spring Tools 4 for Eclipse (for example) to develop non-boot Spring projects using the standard Java tooling of Eclipse - or install the STS3 Add-On Extension into an existing Spring Tools 4 for Eclipse distribution. More details on this relationship can be found here: https://github.com/spring-projects/sts4/wiki/STS3-Features

The intent here is not a strategic one (like we are trying to push developers to Spring Boot). The reason for this focus is completely based on the fact that we almost completely started from scratch and based the Spring Tools 4 on a completely new tooling architecture (due to various technical reasons). This "starting-from-scratch" meant that we couldn't (and even if we could, we probably should not) blindly re-implement everything again that we had in the past. We had to start with a clear focus (Spring Boot applications in our case) and iterate from there.

If there is strong demand for adding support for non-boot Spring applications, we are completely open to that. The same applies to the XML config support. But there has to be strong demand for those features. So the more votes we get from the community for those enhancement requests, the better.

[mauromol]

Maybe the "problem" here is that you're not providing a new tool targeted at Spring Boot, but replacing an all-round tooling with many more features for Spring users (even non-Boot ones) and you're retiring the old one. If you had created a new tool alongside the old one, it would have been another story. But I'm not naive, and it's perfectly understandable that you have not the manpower to support two huge and parallel efforts shipped as free products and with many overlapping features, so in a real world STS4 is replacing STS3 (full stop) and the concrete result is that many technologies supported by STS3 and not STS4 are indeed penalised and in some way "deprecated", any Spring developer will have to take this into account, in one way or the other. Unless you reconsider some choices, of course.

I'm just concerned on how the community could really bring their voice here. GitHub does not have votes, or stars, or anything like that (correct me if I'm wrong), should they fill this request with useless "+1" messages? This is one of the reasons I don't like GitHub issue tracking (compared to some good old alternatives, like JIRA was). I'm also very sceptical that many seasoned Spring developers using STS3 and non-Boot technologies will ever come here to complain: they will use STS3 until available, then stop using it and all our everyday life to maintain legacy (or even non-legacy... until you explicitly deprecate XML config and non-Boot architectures) code and applications will just become harder.

By the way, I read https://github.com/spring-projects/sts4/wiki/STS3-Features, but I still have some questions on how to install STS3 over STS4. More precisely:

• if I have my own Eclipse installation (so not using the STS4 installer/bundle) and I install STS4 on top of it through its STS4 update site, then can I also install parts of STS3 using its own STS3 update site, expecting things to work? Or must I use the mentioned "STS3 Add-On Extension" from the marketplace? If so, how will the end result differ?
• while some STS3 components are quite isolated (like Spring Security support, Spring Data support, Spring Integration support and so on), it's not clear to me whether general XML config support is in the "core" plugin called "Spring IDE"; isn't it?
• in any case, I'm quite confident that the other STS3 components (like Spring Security support, Spring Data and so on) will required "Spring IDE (required)" plugin, so this one will be installed in any case, for whichever STS3 component I install, right?
• if what I said till here is correct, I expect that STS3 installed on top of STS4 will bring many features already in STS4 by virtue of the general core "Spring IDE" plugin and hence I'm just a bit concerned that my Eclipse installation will be somewhat cluttered with different plugins interfering with each other

Also it's not clear to me on what happens to Eclipse projects with the "Spring Nature" and builder: will STS4 use this nature? Or either does it introduce a new one (so a project must have either a "STS3 Spring Nature" or "STS4 Spring Nature")? If I install both plugins, do I have to add to my projects both natures/builders?

[martinlippert]

Lets split this conversation up into the different pieces.

(1) I would suggest to use the 👍 emoji reaction (as someone already did on the summary of this item) to let the community express their votes. It is a simple way to collect some data.

(2) lets collect and cover the improvements for the "how to use STS3 features in STS4 and vice versa" in this separate item: #113 - it doesn't fit into the topic of this issue.

(3) continue to use this issue here to collect items that are implemented in Spring Tools 4 for Spring Boot projects, but that should be opened-up for non-boot projects, too.

(4) have separate items for STS3 features that people suggest to be re-implemented in Spring Tools 4, like this one: #108

(5) the current expected EOL for STS3 is mid 2019, pushing out regular updates of STS 3.9.x for Eclipse 2018-12, Eclipse 2019-03, and Eclipse 2019-06. So you are safe to continue to use STS 3.9.x for your day-to-day development until at least fall or end of 2019. In case you are not able to migrate to Spring Tools 4 by the end of 2019 and you need important updates for STS 3.9.x after fall 2019 (for important fixes in Eclipse, for example, or something like that), let us know and I am sure we will find a solution for that. Until then, I would prefer to focus on the questions of what you are urgently missing in Spring Tools 4 and how we can improve Spring Tools 4 until then.

[Spark4J]

We can delete outdated thing like ant even if there was glory days for it. But like foundation for java should not be delete. Come on, next version.

[gayanper]

@martinlippert shouldn't this issue must be tagged with sts3-feature-request ?

[Spark4J]

Give us "dynamic web project", please!

[martinlippert]

@gayanper No, this issue is about enabling features that we implemented in Spring Tools 4 for Spring Boot projects (see here for an overview) available for non-Spring-Boot projects. And this would focus in annotation-driven Spring configs rather than XML config Spring apps.

[martinlippert]

As a first step here, you can now use the super quick "go to symbol" features for regular, non-boot Spring projects. The indexing now takes regular spring projects into account and scans for the usual Spring annotations.

The symbols are still generated from Spring annotations and source-code, we do not scan Spring XML config files for this.

Hope this is useful. If you want to try out an early access version, please download a nightly distribution from here: http://dist.springsource.com/snapshot/STS4/nightly-distributions.html.

Feedback welcome.

[gayanper]

May be it would be nice if the XML configuration scanning can be a optional feature which must be enabled from project settings. The reason is that spring still supports xml scanning, so one day spring drops support for xml scanning we might be able to remove it from the tooling as well.

[gayanper]

@martinlippert the "go to symbol" actually shows all symbols it found in the work-space right ? Not for a specific project like in STS3 Project Explorer ?

[martinlippert]

The "go to symbol" infrastructure indexes all the projects in your workspace and provides two different views for that: "symbols in file" and "symbols in workspace", there is no "symbols in project" yet. If you would like to see and access "symbols in project" as a third option (would make a lot of sense from my point of view), please file a separate enhancement request.

[gayanper]

@martinlippert done 😄

[martinlippert]

OK, so quite a bit has been implemented for this already:

• symbol infrastructure works for regular Spring projects, scanning Java source files for Spring annotations
• symbol infrastructure is populated with symbols for beans defined in Spring XML config files (alpha version)
• live hovers show up for regular Spring projects when launched with the live beans flag
• STS4 distribution got additional m2e-wtp extensions installed by default, this allows to work with war-packaged Spring Boot apps as well as regular (non-boot) Spring web apps and deploy them to a locally installed Tomcat server.

So I am closing this issue now as done.

If you think some of the new STS4 features are not yet working for your non-boot Spring projects that you would love to see, please file a new enhancement request.

[mimendo]

One question:
Is support for non-boot projects (dynamic web projects) included in STS "standalone" distribution or only installing it onto an eclipse JEE?
I have imported a spring non-boot project into STS 4.2.0 and I don't see any way to deploy it into a tomcat or to activate the dynamic web project facet.
Thank you!

[martinlippert]

Both STS distributions (STS 3.9.8 as well as STS 4.2.0) contain support for dynamic web projects. The STS 3.9.8 distribution comes with all the goodness of the JEE package pre-installed whereas the STS 4.2.0 distribution has only a limited set of features installed. But working on a war-packaged boot (or non-boot) app should work including deploying apps to local Tomcat servers, for example.

[mimendo]

I'm afraid it does not work for me.
I just installed again STS 4.2.0, to make sure I didn't break anything, and I'm still unable to handle dynamic web projects.
Please, see the attached screen captures.
Thanks a lot.

[kdvolder]

Is your project a maven or gradle project? I have recently tried spring boot maven war-style project and, though I didn't use the facet dialogs that you are screenshotting... m2e seemed to configure them correctly so that I could drag-drop deploy the project to TcServer without issue.

I don't think that, if your project are correctly setup through their pom file, you would need to manually fiddle with the facets, but m2e should set it up automatically.

[mimendo]

It is a maven project. It's working fine on Eclipse JEE with no need to fiddle with the facets.
I show those screenshots to illustrate the problem, as otherwise I'm not very sure how to show that the project does not get autoconfigured.

[martinlippert]

@mimendo You are absolutely correct about the fact that the STS4 distribution does not come with the same set of pre-installed features than the Eclipse JEE package. We tried to create a somewhat lighter and smaller distribution for STS4, focused on Spring Boot projects. We can re-evaluate this and add more features to the distribution on a per-request base for sure. Can you let us know what exactly you are looking for? I understand that you are missing the "Dynamic Web Projects" wizard and the facets around that, but for what purpose? What are the benefits/features that are connected to that and that you would like to use?

As a workaround, you don't need to start with an Eclipse JEE distribution and install STS4 as an add-on to it (certainly one option), you could also do it the other way around: start with STS4 and add the missing features via Install New Software (from the main Eclipse update site, which is pre-configured in STS4 distributions).

To make this easier, I use a scripted approach for this. I have a small shell script that installs a bunch of features from an update site (even from various update sites) into an existing install (Eclipse or STS3/4) via the command line. Quite useful if you would like to re-create an install with all your favorite set of features. An example for that is here: https://gist.github.com/martinlippert/5155155 (I bit outdated, but I am sure you get the gist of it).

[kdvolder]

It is a maven project. It's working fine on Eclipse JEE with no need to fiddle with the facets.
I show those screenshots to illustrate the problem, as otherwise I'm not very sure how to show that the project does not get autoconfigured.

Okay thanks for clarifying that. I guess the question is why spring-boot style war project works okay, but your project does not. What is really missing here in STS? And what makes your project different from a spring-boot war project? Any chance you can provide a sample project? Without an actual concrete example to reproduce the issue its kind of hard to know what is going wrong.

[mimendo]

@mimendo You are absolutely correct about the fact that the STS4 distribution does not come with the same set of pre-installed features than the Eclipse JEE package. We tried to create a somewhat lighter and smaller distribution for STS4, focused on Spring Boot projects. We can re-evaluate this and add more features to the distribution on a per-request base for sure. Can you let us know what exactly you are looking for? I understand that you are missing the "Dynamic Web Projects" wizard and the facets around that, but for what purpose? What are the benefits/features that are connected to that and that you would like to use?

As a workaround, you don't need to start with an Eclipse JEE distribution and install STS4 as an add-on to it (certainly one option), you could also do it the other way around: start with STS4 and add the missing features via Install New Software (from the main Eclipse update site, which is pre-configured in STS4 distributions).

To make this easier, I use a scripted approach for this. I have a small shell script that installs a bunch of features from an update site (even from various update sites) into an existing install (Eclipse or STS3/4) via the command line. Quite useful if you would like to re-create an install with all your favorite set of features. An example for that is here: https://gist.github.com/martinlippert/5155155 (I bit outdated, but I am sure you get the gist of it).

Thanks a lot for clarifying. My projects are war maven projects and I only need to be able to deploy them onto a tomcat. I don't actually care about the wizard or the facet, it was just to illustrate there's something missing. Should this be working out of the box?

[mimendo]

It is a maven project. It's working fine on Eclipse JEE with no need to fiddle with the facets.
I show those screenshots to illustrate the problem, as otherwise I'm not very sure how to show that the project does not get autoconfigured.

Okay thanks for clarifying that. I guess the question is why spring-boot style war project works okay, but your project does not. What is really missing here in STS? And what makes your project different from a spring-boot war project? Any chance you can provide a sample project? Without an actual concrete example to reproduce the issue its kind of hard to know what is going wrong.

My project is a non-boot maven war project. I cannot share the actual project, but I will try to make a dummy test project to reproduce the problem.

[martinlippert]

My project is a non-boot maven war project. I cannot share the actual project, but I will try to make a dummy test project to reproduce the problem.

That would be awesome, since I tried a standard Spring maven war project a while ago (a classical Spring MVC project, also non-boot) and I was able to deploy that via drag&drop on a local Tomcat, so that is something that should definitely be supported in the recent versions of the Spring Tools 4.

[mimendo]

My project is a non-boot maven war project. I cannot share the actual project, but I will try to make a dummy test project to reproduce the problem.

That would be awesome, since I tried a standard Spring maven war project a while ago (a classical Spring MVC project, also non-boot) and I was able to deploy that via drag&drop on a local Tomcat, so that is something that should definitely be supported in the recent versions of the Spring Tools 4.

Are there any requirements about minimum Spring or Web project version?

[martinlippert]

I don't think so. Just attach your sample project and we will take a look. Maybe there is indeed something missing on the tooling install side, certainly possible.

[mimendo]

Here you are. I have included the autogenerated project config in case it's useful.
test-war.zip

[mimendo]

More info: I just tried with STS 4.1.2 and it works just fine. It fails with 4.2.0.

[martinlippert]

@mimendo Ok, thanks a lot for attaching the sample project and you are completely right, there are a few features missing in the latest Spring Tools 4.2.x releases that prevent the full list of facets to show up and to configure the project properly. Thank you very very much for pointing this out and letting us know.

I fixed this for the next Spring Tools 4 release (4.2.2, coming in late May 2019), unfortunately this didn't made it into the just releases 4.2.1 version.

Nevertheless, the fix is relatively easy to apply to an existing STS 4.2.x installation. Go to Install New Software, select the main Eclipse update site for 2019-03, and search for m2e-wtp. There are four extensions showing up and you should install the ones you prefer. Once installed, it will bring back all the nice facets and drag&drop deploy features back into your STS 4.2.x install.

[mimendo]

Thanks a lot, @martinlippert