© Excellent backgrounds/Shutterstock.com
Java Magazin
Interview mit Martin Lippert zu STS 3.0 und 3.1

„Die einzelnen Bestandteile individuell und unabhängig voneinander verwenden“

Java Magazin: Mitte des Jahres ist die SpringSource Tool Suite 3.0 erschienen und hat sich mit dem Release in mehrere Teil-Suites aufgeteilt. Dann folgte im Oktober die Version 3.1. Kannst du uns etwas über die Neuerungen beider Versionen erzählen?

Martin Lippert


Martin Lippert: Das mache ich sehr gerne! Wir sind nämlich sehr stolz darauf, diese Major-Releases ausgeliefert zu haben. Sie stellen einen großen Schritt in der Geschichte der SpringSource Tool Suite dar. Wir haben vor allem mit dem Release 3.0.0 die Tool Suite in zwei wichtigen Bereichen grundlegend überarbeitet. Zum einen liefern wir die Tool Suites jetzt in zwei Varianten aus: Die Spring Tool Suite, die auf Spring- und Java-Entwickler fokussiert ist und alles mitbringt, was man für die Enterprise-Spring-Entwicklung braucht. Und als zweite Variante die Groovy/Grails Tool ­Suite, die ein fertiges Paket für alle Entwickler darstellt, die entweder nur mit Groovy- oder aber mit Groovy- und Grails-Anwendungen implementieren möchten. Dahinter steckt die Idee, für beide Entwicklergruppen eine fertig nutzbare Distribution anzubieten, die jeweils out of the Box nutzbar ist und es erlaubt, nach der Installation in wenigen Minuten eine einfache Spring- oder Grails-Anwendung zu implementieren und im mitgelieferten tc Server laufen zu lassen − ohne zusätzliche Plug-ins oder Runtimes installieren zu müssen. Um diese unterschiedlichen Distributionen überhaupt in dieser Form ausliefern zu können, mussten wir vorher allerdings die komplette SpringSource Tool Suite in kleinere, voneinander unabhängige Komponenten zerlegen. Früher bestand der Kern der SpringSource Tool Suite aus der Spring IDE (dem Kern der Spring-Unterstützung), die schon immer als separates Open-Source-Projekt (unter EPL-Lizenz) zur Verfügung stand und sogar Bestandteil von vielen anderen Eclipse-basierten Tooldistributionen war. Die Erweiterungen der SpringSource Tool Suite, wie beispielsweise der Support für tc Server oder Spring Roo, waren zwar frei nutzbar, selbst aber nicht Open Source und auch nicht ohne die große SpringSource Tool Suite nutzbar.Mit der Version 3.0.0 haben wir die Tool Suite komplett neu strukturiert und in kleinere Projekte zerlegt. Die Idee dahinter war, dass Entwickler die einzelnen Bestandteile individuell und unabhängig voneinander verwenden können. Ein Beispiel: Früher war der Grails-Support eine Erweiterung der SpringSource Tool Suite und somit direkt mit der Spring IDE und dem restlichen Spring Tooling verbunden. Man konnte also das Grails Tooling nicht installieren, ohne auch Spring Tooling installiert zu bekommen − was im Grunde genommen gar keinen Sinn gemacht hat. Das ist jetzt anders. Die individuellen Projekte, beispielsweise die Spring IDE, der Grails-Support, di...

Java Magazin
Interview mit Martin Lippert zu STS 3.0 und 3.1

„Die einzelnen Bestandteile individuell und unabhängig voneinander verwenden“

Java Magazin: Mitte des Jahres ist die SpringSource Tool Suite 3.0 erschienen und hat sich mit dem Release in mehrere Teil-Suites aufgeteilt. Dann folgte im Oktober die Version 3.1. Kannst du uns etwas über die Neuerungen beider Versionen erzählen?

Martin Lippert


Martin Lippert: Das mache ich sehr gerne! Wir sind nämlich sehr stolz darauf, diese Major-Releases ausgeliefert zu haben. Sie stellen einen großen Schritt in der Geschichte der SpringSource Tool Suite dar. Wir haben vor allem mit dem Release 3.0.0 die Tool Suite in zwei wichtigen Bereichen grundlegend überarbeitet. Zum einen liefern wir die Tool Suites jetzt in zwei Varianten aus: Die Spring Tool Suite, die auf Spring- und Java-Entwickler fokussiert ist und alles mitbringt, was man für die Enterprise-Spring-Entwicklung braucht. Und als zweite Variante die Groovy/Grails Tool ­Suite, die ein fertiges Paket für alle Entwickler darstellt, die entweder nur mit Groovy- oder aber mit Groovy- und Grails-Anwendungen implementieren möchten. Dahinter steckt die Idee, für beide Entwicklergruppen eine fertig nutzbare Distribution anzubieten, die jeweils out of the Box nutzbar ist und es erlaubt, nach der Installation in wenigen Minuten eine einfache Spring- oder Grails-Anwendung zu implementieren und im mitgelieferten tc Server laufen zu lassen − ohne zusätzliche Plug-ins oder Runtimes installieren zu müssen. Um diese unterschiedlichen Distributionen überhaupt in dieser Form ausliefern zu können, mussten wir vorher allerdings die komplette SpringSource Tool Suite in kleinere, voneinander unabhängige Komponenten zerlegen. Früher bestand der Kern der SpringSource Tool Suite aus der Spring IDE (dem Kern der Spring-Unterstützung), die schon immer als separates Open-Source-Projekt (unter EPL-Lizenz) zur Verfügung stand und sogar Bestandteil von vielen anderen Eclipse-basierten Tooldistributionen war. Die Erweiterungen der SpringSource Tool Suite, wie beispielsweise der Support für tc Server oder Spring Roo, waren zwar frei nutzbar, selbst aber nicht Open Source und auch nicht ohne die große SpringSource Tool Suite nutzbar.Mit der Version 3.0.0 haben wir die Tool Suite komplett neu strukturiert und in kleinere Projekte zerlegt. Die Idee dahinter war, dass Entwickler die einzelnen Bestandteile individuell und unabhängig voneinander verwenden können. Ein Beispiel: Früher war der Grails-Support eine Erweiterung der SpringSource Tool Suite und somit direkt mit der Spring IDE und dem restlichen Spring Tooling verbunden. Man konnte also das Grails Tooling nicht installieren, ohne auch Spring Tooling installiert zu bekommen − was im Grunde genommen gar keinen Sinn gemacht hat. Das ist jetzt anders. Die individuellen Projekte, beispielsweise die Spring IDE, der Grails-Support, di...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang