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.