SpringSource and Tool Suite


Just as for JBoss Seam, some validation of Spring XML files can take time, but I find that it doesn't crush Windows the way Seam files seem to. What it does to Linux I don't yet know as all my Seam work and my Spring training has been on Windows so far. I think this "easiness" is because Spring limits itself mostly to Java, XML and usually fairly light JSPs. Of course, I'm a beginner and what do I know?

Downloading the SpringSource Tool Suite

Go to http://www.springsource.com/products/eclipse-downloads and pick to download the SpringSource Tool Suite 2.1.0.SR01 (Win32, Linux, etc.) This download, though the page offers you separate Eclipse models, should contain everything you need.

Of course, by the time you read this, the version may no longer be 2.1.0SR01.

Interestingly, my Spring Core Framework training in San Francisco did not take us through this installation. Instead, we received thumbdrives with all the software already in place. I forgot to press for help installing on Linux and so have had to spend some time figuring out how to do it.

Nota bene: You cannot convert, enhance or otherwise "upgrade" a normal Eclipse installation to endow it with the SpringSource Tool Suite. I was unable to do it, others don't seem to be able to and I found independent comments not to try it here and there on the web.

Downloading the SpringSource Tool Suite to my Linux host, despite my Firefox settings, I found it on /tmp instead of in my download directory (which I expected to choose interactively). This sometimes happens on Linux and is a function of the web site.

	[email protected]:~/downloads> ll /tmp/springsource-tool-suite-2.1.0.SR01-e3.5-linux-gtk-installer.sh
	-r-------- 1 russ users 198581896 2009-10-14 20:43 /tmp/springsource-tool-suite-2.1.0.SR01-e3.5-linux-gtk-installer.sh

Installing the tool suite (openSuSE Linux 10.3)

What happens is probably similar in many respects to Windows, but I'm going to detail the Linux experience only. Some points are obviously Linux-only, but this will be clear to any Windows user and it will be abundantly clear what to do for that platform.

For want of spending more time cogitating this, I decided to put the downloaded script on /home/russ/sts and direct the SpringSource installer in the next step to put the tool suite on /home/russ/springsource, which it suggests itself—knowing that I'll regret this later.

Make the downloaded script executable and execute it. You'll see:

	[email protected]:~/sts> chmod a+x springsource-tool-suite-2.1.0.SR01-e3.5-linux-gtk-installer.sh
	[email protected]:~/sts> sh springsource-tool-suite-2.1.0.SR01-e3.5-linux-gtk-installer.sh

	*                   SpringSource Tool Suite 2.1.0.SR01                        *
	*                                 Installer                                   *
	preparing the installer...
	... done
	starting UI installer. please follow instructions on screen...

...and then a GUI installer. Follow the instructions. Note that you must choose the top-level subdirectory of the Java 1.6 JDK. Mine looked like this:

	[email protected]:~/dev>  ll -d jdk*
	drwxrwxr-x  9 russ users 4096 2008-11-10 04:15 jdk1.5.0_17
	drwxr-xr-x  9 russ users 4096 2009-05-04 04:40 jdk1.5.0_19
	drwxrwxr-x 10 russ users 4096 2009-02-11 15:11 jdk1.6.0_12

...and I chose jdk1.6.0_12 naturally. Ignore the awkward instruction about how what you choose must be a JDK after you've chosen it. The installer won't actually know what it is until later and it's just being stupid at this point (not looking to see if in fact it is a JDK and then retracting the distubing message).

Eventually, choosing to launch the tool suite, you'll see an Eclipse launch splash like this one. Create your first workspace. Remember, at this point, we've used no Eclipse software from eclipse.org or from the Spring download site.

At this point, the initial Eclipse splash page will come up but very Spring-ified. Here you'd expect a control from which to launch to the workbench, but there isn't one. I could not find a way to go into the Eclipse workbench: everything I tried clicking just dropped Eclipse and I had to reinstall, watching ps -ef to detect that the executable to run is:

	[email protected]:~/springsource/sts-2.1.0.SR01> ll STS
	-rwxr-xr-x 1 russ users 52932 2009-08-05 17:39 STS

(...and not eclipse as you might expect). If you launch this by hand, thus:

	[email protected]:~/sts> ./springsource/sts-2.1.0.SR01/STS & 

...you will get the Eclipse workbench you are looking for with, in the Editor Pane, the SpringSource Tool Suite dashboard, an informational page you may wish to dismiss (for you can easily restore it by bouncing Eclipse or getting it from the Help menu).

Create a launcher for STS, name it "Spring," and use /home/russ/springsource/sts-2.1.0.SR01/icon.xpm as the icon.

Augment the launcher command line by adding -vmargs -Duser.name="Russell Bateman" to it. This will ensure that Javadoc authorship is accurately short-stroked in when you create new doc.

The workbench might appear thus (click to enlarge):

Notice my Spring icon to the left. You are now ready to begin creating projects. You can close the Spring Dashboard since it's easy enough to re-open later if you want it. It mostly contains a gathering of RSS feeds relevant to Spring.

Creating a Spring project

Spring projects have a little S on them to distinguish them from Java projects, Dynamic Web Projects, etc.

More to come here...

Spring training course materials—Linux

This is more of a private note since the Spring course materials are protected by NDA and only available to course subscribers. The materials passed out in class included Windows and Macintosh coverage only. I got the Linux installation file(s) later.

On my first attempt to import saved class projects into STS, I met with failure as reproductions of an e-mailed exchanges between me and the instructor demonstrates. These exchanges were instructive.

 Hi Russ,

 The short answer, is that you're in for a world of work if you don't use the
 prepackaged installer that came on the USB. There are a number of things I
 can point out that will help you, but it would even take me probably hours to
 get a perfect environment up without the installer; that's why we ship it.

 Do you still have those materials?

 I would recommend working the labs from the installer-based world, and then
 any further exploration you want to do can be done from the
 latest-and-greatest STS you just downloaded.

 Hope that helps.

 - C

 > On Oct 26, 2009, at 11:34 AM, Russell Bateman wrote:
 > I hope this is a quick query; I don't feel like you're my support person. Or,
 > if you can just point me in a good direction...
 > In the materials I brought back from Core Framework training in San Francisco,
 > which I'm only now getting time to re-use, I note that I'm getting an error
 > for each pom.xml:
 > Cannot find artifact for parent POM:
 >      com.springsource.training.common...jar:2.0.1.RELEASE at
 >      /home/russ/sts/workspace/aop-1-solution/pom.xml.
 > This looks to be a Maven problem. I wonder what was set up and where on the
 > Windows hosts we used in class. The STS I'm using is one I downloaded from
 > http://www.springsource.com/products/eclipse-downloads, SpringSource Tool
 > Suite 2.2.0.RELEASE (but for Linux). Perhaps it's the later version we used in
 > the course?
 > Second, I note that SimpleData and MonetaryAmount, which are imported from a
 > place called common are missing and give compilation errors. Where is that
 > common place that supplies these (and others still). Is that a cascade of the
 > POM problem that will fix itself once Maven is healthy?
 > Last, a more minor problem is that all my experimentation in Eclipse,
 > including in the new STS noted above, yields the same old "invisible" working
 > set functionality I'm used to. No way can I figure out how to create the cute
 > "super working set" folder that subsumed the two projects (start and solution)
 > in each of our labs in the STS we used in the course. I found the properties
 > file, workingset.properties, describing it, but neither that nor any attempt
 > at manually creating such a thing will work. Is there a plug-in missing that
 > materialized this "folder" in our classroom that isn't in STS as it ships?
 > Thanks,
 > Russ
 > P.S. I considered moving to MyEclipse and have tried out their product, but it
 > has the same problems.

A later exchange turned this up:

 Aha. The native Linux installer is a work in progress as we speak. I just tried today
 to prioritize it and get somebody working on it as soon as possible. It may be a few
 days or more before it's done, however.

 In all honesty, your best (read: least painful) bet is to wait for the linux installer
 (to which I'll send you a link) and if possible, use a Mac or Windows machine in the

 Let me know what you decide, and if you haven't heard back from me by the end of the
 week, please email me again.


 - Chris

 > On Oct 26, 2009, at 1:04 PM, Russell Bateman wrote:
 > I still have the materials, but I'm trying to work on Linux. The prepackaged
 > installer is an .exe.

On the 29th, he sent me Linux (32- and 64-bit) installer files. I tried the new file out and had this to say. He interleaves comments.

 > Chris,
 > All appears well, but I'm going to detail my experience in case any of it
 > interests you (for posterity, etc.). There might be something you wish to correct,
 > but I can't know what is relevant, so here goes.
 > I am confused about how some things are marked 2.1.0 and others 2.0.1 here and the
 > in working with Spring.

 2.1.0: This refers to the version of STS
 2.0.1: This refers to the version of the Core Spring Courseware
 2.5.6: The version of Spring that is in use throughout the modules

 > I installed it on my openSuSE Linux 10.3 host. I set, during install, to point at
 > /home/russ/dev/jdk1.6.0_12.
 > When I launched Core Spring Courseware/sts-2.1.0.SR01/STS, it offered workspace
 >     /home/cbeams/springsource/core-spring-workspace

 Good to know; I'll fix that for future versions.

 > I made it /home/russ/springlinux/core-spring-workspace (because I happened to be
 > using subdirectoy springsource already).
 > I immediately got an alert warning me that
 >     ...Maven integration requires that Eclipse be running in a JDK, because a number
 >     of Maven core plugins are useing jars from the JDK.
 >     Please make sure the -vm option in eclipse.ini is pointing to a JDK and verify
 >     that Installed JREs are also using JDK installs.
 > I clicked on eclipse.ini, nevertheless vim was not launched on the file itself,
 > but naked. Searching for eclipse.ini under Core Spring Courseware/sts-2.1.0.SR01, I
 > found none and so, making an assumption, I edited STS.ini by hand to add
 >     -vm /home/russ/dev/jdk1.6.0_12/jre/bin

 It is important that it [be] a full JDK that you point to, not a JRE. Judging from
 the above, it looks like you were pointing to a JRE. You can get by with this, but
 you will get the warnings from the Maven tooling.

 [Russ' note: Of course, as noted, that's exactly what I was using.]

 > Then, I returned to STS and the warning alert. I clicked on Installed JREs and
 > got the Installed JREs Preferences, currently set to the system JRE which is Java 1.6,
 > but not a JDK, to which I therefore added /home/russ/dev/jdk1.6.0_12/jre. I then
 > selected that as my default (or "checked" JRE).

 Right, see above. My recommendation would be to change that to a full JDK
 installation. However, if you're up and running at this point, don't sweat it.

 > Then I saw all sorts of blue and red messages fly by in the Console view that I
 > could only see partially. I dismissed the Maven Integration warning alert by clicking
 > OK. I scrolled back to see one of the red, error messages, for example:

 >     10/28/09 2:24:08 PM MDT: Build errors for mvc-1-solution: org.apache.maven.lifecycle. \
 >         LifeCycleExecutionException: Failed to construct build plan for: mvc-1-solution \
 >         ID: com.springsource.training.module:mvc-1-solution:war:2.0.1.RELEASE \
 >         task-segment: [process-test-resources]. Reason: Failed load plugin descriptor \
 >         for: org.apache.maven.plugins:maven-source-plugin:2.0.4:test-jar. Cannot discover \
 >         it's duplicate phase, specified in its plugin descriptor.

 > The remaining red messages were for other projects. The blue messages were
 > (ant-looking) Maven status including warnings about failing to "load plugin descriptor
 > for org.apache.maven.plugins:maven-source-plugin." I figure this should be enough to
 > clue you into what's going on. Maven competence is still in my future, so while I
 > understand what it's saying, I don't understand what, if anything, to do about it.
 > It's probably the case that the build is broken to turn these projects into
 > executables, though there are no compilation errors.

 The red error messages that show up in the Maven console during workspace setup are
 all benign. You can ignore them.

 > Then, I resized the STS workbench to maximize it to my (lovely Dell 24") monitor
 > and beheld with great joy all the course lab projects neatly embedded in magic working
 > space "folders" just as was the case in class (love that organization--never seen it
 > before and I must learn how to make working sets do that). There were no errors
 > anywhere (as there had been all over the place in my previous attempts without the
 > courseware core-spring-2.0.1.RELEASE-installer.sh you just sent).


Learning Maven is a must...

...because there are too many repositories to handle when using Spring. And, Maven has got real problems with repositories. For instance, Sun's contributions may not be consumed directly since their JARs require an interactive EULA acceptance when accessed (off the web, that is). Here's what I did to overcome these nightmares.

This section to grow as I figure it all out...

Integrating Spring and FLEX

This is tempting—create interface elements using FLEX, but use Spring to do all the hard work. Use Granite Data Services as a sort of confluence to tie FLEX to the world of JEE.