XML config support in STS4

[mauromol]

I really hope you'll reconsider the decision to leave XML config support totally off from STS4 (probably related to #96). Otherwise, this really sounds like a deprecation of XML config and of any non-Spring Boot architectural design.

I really think that, still in 2018, XML config has its strengths, especially when you are dealing with specialised namespaces that help to easily define complex configurations in a declarative rather than imperative style (the examples of Spring Security and Spring Integration are the first ones that come into my mind).

Also, I always appreciated the philosophy of "use only what you need" (rather than "all-or-nothing") that has driven the design of the Spring Framework form the beginning, so knowing that the new version of STS is instead pushing towards a "Java config + Spring Boot"-or-nothing solution is unfortunate IMHO.

I'm not saying you're not doing a great work, but I really hope you'll reconsider this.

[martinlippert]

Supporting XML-based Spring configuration files in Spring Tools 4 would mean to re-implement almost everything that is related to that mostly from scratch. "Just" porting over the existing support for XML-based Spring configuration files to the all-new Spring Tools 4 is not possible due to the completely different underlying tooling architectures.

So instead of blindly re-implementing everything related to XML Spring configs from STS3, I would like to understand the developer needs in more detail first (especially since the overall XML config support in STS3 consists out of various pieces).

It would be great if you could help me with that... :-)

So the main question is:

• what exactly do you use from the Spring XML config support in STS3?
• what do you think is the most important piece of the Spring XML config support that you miss most (if using Spring Tools 4 as is)?

[martinlippert]

(btw, I updated the wiki here https://github.com/spring-projects/sts4/wiki/STS3-Features to reflect the absence of Spring XML config support in more detail, but if you think something is still missing or misleading, let me know)

[mauromol]

* what exactly do you use from the Spring XML config support in STS3?

First things that come into my mind (consider I'm using Eclipse):

• detection of application context XML files in the classpath, with import following
• code assist in contexts where a bean property and/or method name is required (for instance <property name="myProp[code assist here]"...>)
• code assist for references between beans (for instance: <bean ref="myOtherB[code assist here to find myOtherBean" />)
• navigation support from class names and properties declared in a XML file to the corresponding Java class file (ex.: <bean class="test.MyClass">, F3 over MyClass goes to test.MyClass; or else <bean class="test.MyClass"><property name="myProperty" value="foo" /></bean>, F3 over myProperty goes to test.MyClass.setMyProperty(...))
• navigation between beans defined in the XML config and/or annotations, like in ref attributes or other references supported by specialised namespaces (example: <task:annotation-driven scheduler="myExecutorSer[code assiste here to get to myExecutorService bean declaration]" />)
• validation of beans and references (missing referenced bean, wrong property name, class not found, etc.)
• refactoring support (when I change a class name or member and it's referenced in XML config files, XML config files are updated accordingly)
• integration of Spring-managed beans defined either by annotations or in XML files with other components (like EL expressions in JSP/facelets WTP editors)
• (this is missing in STS3, but works somewhere else in STS4, would be nice to have for XML config too): code assist for property names defined in .properties files (like ... value="${myProp[code assist here]}">)
• easy namespace handling (addition/removal of available namespaces) based on Spring JARs in current classpath

Specialised views for XML editors (like the Integration graph, for instance, available when you add the Spring Integration namespaces) are of secondary importance to me, I usually go straight into XML code and don't use those specialised editors, because of several limits they have.

* what do you think is the most important piece of the Spring XML config support that you miss most (if using Spring Tools 4 as is)?

Honestly, since I read STS4 is missing Spring XML config support, I've not even tried it yet. If you think I can install it alongside the only part of STS3 that provides such support (which plugin exactly should I install?), I may give it a try.

From the above list, if I have to choose my top favourites, I would say that having a link between the XML model and the data model is the most important thing, so that validation, navigation, code assist and refactoring can work. Otherwise I have to just count on the standard XML editor features of Eclipse, which provide validation and code assist only for XML schema elements.

Last note, completely different topic: please, never never never think to remove the Quick Text Search from STS4... it's incredibly comfortable to use!! :-) Why don't you even consider donating it to the Eclipse Platform to be included and maintained as a standard Platform component?

[kdvolder]

never never never think to remove the Quick Text Search from STS4... it's incredibly comfortable to use!! :-)

I'm really happy to hear that :-). It is definitely some of the best time I ever spent on building anything (seeing how little time it actually cost to build and versus how very useful it is :-).

And no that is certainly not going to be removed. I think it fair to say it is one of our own personal favourites. I use it every day myself. And unlike the XML model bits it is relatively quite simple and very, very low maintenance.

[dewthefifth]

This is the exact issue I came here looking for.

We use XML configurations for the vast majority of our configuration. I don't want to get into a holy war of annotation vs XML, but suffice it to say that we intend to hold on to the XML configuration path until spring itself stops being able to load XML configurations. The loss of any sort of intellisence, validation, or code navigation was a non-starter for STS4. However, like mauromol mentioned, refactoring and namespace handling were nice as well.

I never really used the beans graph, integration graph, or beans view because they never really worked correctly across multiple xml files (including classpath imports from jars added to the classpath by maven). However, one of the things that was appealing when I originally read about STS4 was that it was supposed to do a better job of understanding and representing my runtime app context.

For now, I'm still using STS 3.9.1 and looking to 3.9.6. From what I've seen, the team has done an amazing job with STS4 and I appreciate the hard work that goes into STS. Unfortunately for me an my team, saying no support for XML configurations might as well be the same as saying no support for Spring.

[kdvolder]

@dewthefifth Thanks for sharing your thoughts on this. It really helps to get feel for which parts of the old tooling people are actually still using.

On a different note. You mentioned that the 'runtime' features of STS 4 seem appealing. So I thought I'd mention that although we don't build a full distribution that has both the old STS 3.9. and new STS 4 features in one pre-built Eclipse distribution, they are not mutually exclusive and can be installed at the same time.

There is a bit of info in the FAQ about this here: https://github.com/spring-projects/sts4/wiki/STS3-Features#combining-sts3-and-sts4

So at least for the time being you can sort of 'have your cake and eat it too' :-)

[gayanper]

I agree with all the features that are mentioned in this issue that is missing from STS4. This or that i cannot point our which feature is really needed, We still work with XML based configurations and we do need support in STS4 (if you are going to abandon STS3) for working with XML base configurations. Mainly the auto completion for properties and bean references and class name completions would be Top feature that i use a lot.

One more aspect on the label on this issue "community-feedback-wanted", isn't the feedback already given is not sufficient ? I mean did the community asked to rebuild STS4 from the scratch using LSP ?

[martinlippert]

@gayanper The community feedback is still highly welcome and "wanted", not only for providing more input or additional ideas, but also to vote for this, so that we can get a rough overview about how many people from our user base would like to see this in Spring Tools 4. Therefore adding your thumbs-up vote to this is welcome.

[martinlippert]

@gayanper "The community" did not ask to rebuild STS4 from scratch, but it was technically the only reasonable choice moving forward. There are a lot of technical reasons for that and it would go way beyond this issue to enumerate them all, but it was the best viable choice in my opinion. To move forward, the tooling had to be based on a new tooling architecture, one way or the other.

[gayanper]

@martinlippert Totally agree, from a technical point of view yes there is time that comes we need to re-implement things with a clean slate. But here functional point of view, i think we need to support the users that want continue maintains their spring apps (none-spring-boot) using their favorite Free Eclipse IDE. otherwise they have to pay a large sum to get the job done with commercial IDEs like IntelliJ.

[martinlippert]

I've implemented a first step towards supporting Spring XML config files in STS4. This first step enhances the existing symbol infrastructure of STS4 with scanning for Spring XML config files. As a result, you will get nice navigation symbols for your XML bean definitions, much in the same way than you get for the @Bean annotation.

This first step takes only direct bean definitions into account (<bean id="myBean" class="org.test.MyBean"/>), not indirectly defined beans or other namespaces than beans. We can enhance and improve this over time, depending on the feedback that we get.

If you want to give it a try and provide feedback, you can grab the latest nightly distribution build of STS 4.1.1 from here: http://dist.springsource.com/snapshot/STS4/nightly-distributions.html

Feedback, as always, welcome!!!

[mauromol]

Hi Martin, this is very good news, indeed!
I will do my best to try this as soon as possible, although I'm really busy right now and I don't think I will be free enough within at least 3 weeks...

Just for information, what do you mean by "indirectly defined beans", when using just the beans namespace? Do you have an example?

[martinlippert]

Additional note:

The XML scanning is NOT enabled by default, you have to enable it on the preferences for the Spring Boot Language Server and restart STS4 in order for this change to take effect. I am sure we will improve this in future steps, but if you want to give it a try now, this is how it can be switched on.

[martinlippert]

@mauromol "indirectly defined beans" refer to beans that are being created from other namespaces than "beans", for example.

[mauromol]

@mauromol "indirectly defined beans" refer to beans that are being created from other namespaces than "beans", for example.

Yes, this is clear, I was only not sure about a concrete example when a bean is indirectly defined and no other namespace than beans is in use.

[dayu521]

it is helpful to a newer with xml config support...

[TimAtThisCompany]

We have lots of legacy code with XSD's defined in Jar files pointed to using META-INF/spring.schemas. It would be great to have the new tooling recognize this metadata and these schemas automatically. Right now we are stuck with either importing them into the Eclipse XML catalog manually or staying with STS 3.

[palmerwill]

Are plans afoot to re-add the XML config support, or has such been abandoned?
It would be useful to know if I have to abandon STS4 sooner rather than later to re-gain these lost features that are proving increasingly disruptive.

[martinlippert]

@TimAtThisCompany

We have lots of legacy code with XSD's defined in Jar files pointed to using META-INF/spring.schemas. It would be great to have the new tooling recognize this metadata and these schemas automatically. Right now we are stuck with either importing them into the Eclipse XML catalog manually or staying with STS 3.

Yes, that is already on the schedule. We plan to extract this feature and add it to the Spring Tools 4 project in the near future.

[martinlippert]

@palmerwill

Are plans afoot to re-add the XML config support, or has such been abandoned?
It would be useful to know if I have to abandon STS4 sooner rather than later to re-gain these lost features that are proving increasingly disruptive.

The question here which parts of the STS3 xml tooling you are talking about and you would like to continue to use. Can you elaborate on this? We already have support for scanning XML config files for bean definitions. What else would you prioritize to add to the Spring Tools 4 regarding XML support?

For now, you can jump onto Spring Tools 4 for Eclipse and install the STS3 Add-On pack as additional features into that installation, so that you can continue to use the old tooling in combination with the new one.

[palmerwill]

@palmerwill

Are plans afoot to re-add the XML config support, or has such been abandoned?
It would be useful to know if I have to abandon STS4 sooner rather than later to re-gain these lost features that are proving increasingly disruptive.

The question here which parts of the STS3 xml tooling you are talking about and you would like to continue to use. Can you elaborate on this? We already have support for scanning XML config files for bean definitions. What else would you prioritize to add to the Spring Tools 4 regarding XML support?

For now, you can jump onto Spring Tools 4 for Eclipse and install the STS3 Add-On pack as additional features into that installation, so that you can continue to use the old tooling in combination with the new one.

Fair question :)
To clarify, I'm referring to application context XML files, specifically scanning for bean definitions elsewhere in the XML, and the class/attribute auto-complete code assist (neither of which are working for me with STS 4 out of the box).

As per your suggestion however, I have now installed the STS 3 add on pack in the STS 4, which seems to be providing what I need for now. Very much obliged.

[martinlippert]

Early and super limited content-assist features coming to Spring XML config files in Spring Tools 4 (as part of the upcoming 4.2.1 release):

Super limited, just a starting point. Here are more details:
https://github.com/spring-projects/sts4/wiki/Content-Assist#content-assist-for-spring-xml-config-files-new-in-421

[gayanper]

@martinlippert this is really good news :)

[dewthefifth]

Very good news indeed Martin.

Out of curiosity, I know you guys have been recommending manual install of STS3 plugins on STS4 to bridge the gap until XML support can be implemented in STS4. However, I can't help but wonder if thereis a reason you don't include those plugins as part of the default STS4 packaging. Are all the plugins included in the STS4 package specifically built for STS4, or are you including other plugins as well? If you're including other plugins as well, then is there a reason the STS3 plugins for XML support couldn't be vetted and included in the default package under the same constraints?

Maybe it's a thing of the past and I've just failed to adapt my thinking, but historically I've had a lot of issues with plugin conflicts making my eclipse unstable. One of the reasons I adopted STS so early was to let the guys like you who understand the platform better than me address those issues for me. STS has historically been very stable, and perhaps it's superstition but I've always believed a contributor to that stability is that I almost never install plugins outside those you initially package. Basically, if it's a low hanging fruit then it might be advantageous to add the plugins for those of us who don't understand the platform as well as the creators do. (obviously just my 2 cents)

[martinlippert]

@dewthefifth First of all, thanks a lot for the feedback, this is much appreciated. Hearing from you that you adopted the STS distribution due to its stability and ready-to-use experience is awesome. Happy to hear that you like it.

Now more details and backgrounds regarding your suggestion/observation... :-)

The Spring Tools 4 were started with a focus on Spring Boot projects and almost completely re-written from scratch, adopting a completely new internal tooling architecture. We then took a fresh look at the Eclipse-based distribution (which is now just one out of three different client environments that we support, in addition to Eclipse it is also Visual Studio Code and Atom at the moment). The goal was to start fresh and come up with a more lightweight and probably more performant Eclipse-based distribution due to not including everything that is included in the Eclipse JEE package for example, or the STS3 package, etc. So we started with a more lightweight and minimal set of features being pre-installed for working with Spring Boot projects. We did include a few, selected features of the STS3 distribution to be included in the Spring Tools 4 Eclipse distribution, but those were focused on Spring Boot projects (like the Spring Boot dashboard and the Spring Initializr wizard). It is always a difficult for us to find the right balance between our goal to keep the distribution lightweight and performant and to include the right set of features to achieve this "ready-to-use" experience.

The STS3 Add-On pack was meant as an intermediate solution for people still depending on the features of the old tooling that didn't have an equivalent in the Spring Tools 4 yet, like the support for Spring XML config files, at the beginning. We will try to close this gap as good as possible, allowing almost everybody to jump to the Spring Tools 4 and go from there. And in the meantime, we tried to make it as easy as possible to add the old features to a Spring Tools 4 installation via the Eclipse marketplace entry.

Closing this gap between Spring Tools 4 and the old STS3 features will take a while and requires re-implementing features of the STS3 world on the new tooling architecture - and we will certainly not re-implement everything that STS3 had for Spring Tools 4. We have to pick and choose what to re-implement and what not, what the priorities are, etc. And this will be based on your feedback: what are you missing from Spring Tools 4 from the STS3 world most urgently? What is super important, what not? So some features will make it into Spring Tools 4, others not.

I understand your observations about the conflicts among plugins and the difficulty of finding the right set of plugins to be installed without causing any conflicts and instabilities. We experienced that ourselves quite a lot, so I know what you are talking about... :-) I think installing a fresh Spring Tools 4 for Eclipse distribution and adding the STS3 Add-On pack from the Eclipse marketplace should always work and produce a working set of features without any conflicts. If that is not the case, please let us know, that is clearly a bug that should be addressed.

If you want to, I could setup a build pipeline to produce the all-in-one distribution packages for you to download, but I don't think we should offer that as the default distribution for the reasons explained above.

Hope that explains the background and all the details a bit. What do you think?

[martinlippert]

The upcoming 4.2.2 release of the Spring Tools 4 will include a major step forward in supporting Spring XML configuration files across the board. With that release, we will have:

• project-based XSD resolution (based on the spring.schemas files, including support for https lookup)
• content-assist for packages, class and interface types
• content-assist for property names
• content-assist for bean references
• navigation for types
• navigation for property names
• navigation for bean references (across XML and Java source files)

With that, we have implemented many of the requested features and I will close this issue now. There is still a lot of room for improvements across the various features and some of the features mentioned in the comments above haven't made it into the Spring Tools 4 yet, so if you are urgently missing anything in the support for Spring XML config files, please raise a separate issue, so that we can discuss and work on that from there.

[mauromol]

Hi Martin, just to understand it better: does content-assist and navigation support imply the presence of a model that also supports refactoring? Or is refactoring support a separate beast?

I mean, once my XML contains a reference to a class name or property name, will a class name or property name change (respectively) cause an update to that XML file?

[martinlippert]

@mauromol dedicated refactoring support is a different beast and not yet included. For changing class and interface names, Eclipse already provides support for XML files out-of-the-box, you can choose to scan additional files (like *.xml) for references to the renamed type and Eclipse will propose the corresponding change and include that in the refactoring. I think this is not yet supported for refactorings in VSCode, Atom, or Theia. Support for refactoring property names and bean IDs is still missing.

[mauromol]

@martinlippert yes, I know that in Eclipse I can check the flag to scan other files to change FQNs of class names I'm refactoring, I just have to remember to do it :-) and, of course, if there's no actual link, this is just a text "search and replace" facility that requires to scan all non-Java files, so possibly it's a bit slow.

Anyway, thanks a lot for listening our voice and for pushing STS4 up to this point, I will consider the creation of new issues if needed. For sure, I can now proceed to upgrade our projects to STS4! :-)

[martinlippert]

@mauromol Great to hear and looking forward to hear from you about your experiences using the Spring Tools 4 distribution. And please feel free to raise new issues for additional important features necessary or for improvements of existing ones. Your feedback is always welcome.

[gayanper]

@martinlippert Do you have a special XML editor which supports spring completions for xml files ? Because i have 4.3.2 installed there is not xml completions, and i don't see a completion contributor under the standard xml editor either.

[martinlippert]

There is a bug in the latest CI builds of STS 4.3.2 for Eclipse that prevents the spring boot language server from being activated for Spring XML config files. Once that is fixed, the content-assist should appear again. Please note that there is also a preference to enable the XML support inside of the language server. This doesn't have any effect at the moment due to the bug mentioned, but once that bug is fixed, you should be able to enable the feature in the preferences again. Sorry for the inconvenience.