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?
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
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...
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
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
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 projects have a little S on them to distinguish them from Java
projects, Dynamic Web Projects, etc.
More to come here...
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.
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.
> 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
> 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?
> 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.
> 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.
> 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
> When I launched Core Spring Courseware/sts-2.1.0.SR01/STS, it offered 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).
...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...
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.