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!!!