I'm about mid-stream on a project built using Maven2 and using the Spring Framework to glue it together.
The cool kids at
Spring Source, recently announce the release of Spring 2.5. It seems best to try to upgrade now while the project is still in development than later (and deal with extra QA requirements).
At first my thinking is this should be easy, go to the
maven repository and see what the latest versions are, edit my pom, and rebuilt the project and see what happens.
For the most part, it is that easy.
But, then there are the 'other' little things.
An issue, unrelated to Spring is
Open Smphony's OSCache. Updating from 2.3 to 2.4 introduces a dependency on JMS that can't be resolved. Why should an object caching system depend on JMS? If it must, why can't they define the damn POM correctly so the dependency can be found? Its the standard JMS api jar for crying out loud.
Anyway, back to Spring 2.5. Changes made:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>2.0.6</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>2.0.6</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>2.0.6</version>
<scope>compile</scope>
</dependency>
Becomes
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>2.5</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>2.5</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>2.5</version>
<scope>compile</scope>
</dependency>
Then:
mvn clean package is run, the test server started, and all appears well and good in the world.
Kudo's to the good folks at Spring Source. Backwards compatibility is a beautiful thing.
Update:I forgot to mention, the namespaces in the configuration files should get updated at some point as well. I didn't encounter any problems with the 2.0 namespaces and the 2.5 libraries. However, there are a few improvements, notably the JndiObjectFactoryBean, that are pretty darned useful.
<beans
xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jee="http://www.springframework.org/schema/jee"
xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:cache="http://www.springmodules.org/schema/oscache"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.springframework.org/schema/jee http://www.springframework.org/schema/jee/spring-jee-2.0.xsd
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.0.xsd
http://www.springmodules.org/schema/oscache http://www.springmodules.org/schema/cache/springmodules-oscache.xsd" />
becomes
<beans
xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jee="http://www.springframework.org/schema/jee"
xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:cache="http://www.springmodules.org/schema/oscache"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/jee http://www.springframework.org/schema/jee/spring-jee-2.5.xsd
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd
http://www.springmodules.org/schema/oscache http://www.springmodules.org/schema/cache/springmodules-oscache.xsd" />
WooHoo!
Now, if the Spring Modules guys could get their act together....
Labels: development, review, spring
Gotta love the high quality work (sic) coming out of Oracle's shop.
So, when you are trying to install the Oracle client and it dies complaining about not being able to find libraries (and you can find them via locate) then it's time to fix the stupid installer.
Note: This could be a zerog problem instead of Oracle. I'm just used to seeing Oracle ship broken software.
So, in the install directory, do the following:
backup the install script
cp cal_linux_904 cal_linux_904.bakand fix the references in it
cat cal_linux_904.bak | sed "s/export LD_ASSUME_KERNEL/#xport LD_ASSUME_KERNEL/" > cal_linux_904The installer should run fine afterwards.
Then you may bask in the beautiful Oracle GUI
:-)FYI: I ripped off this solution from
http://www.nacs.uci.edu/calendar/setup-linux.php
Posted here because student sites tend to be somewhat volitile
Labels: bugfix, calendar, install script, Kubuntu, linux, oracle
Well, the time spent playing with Vista has come to an end.
Though it's a better OS as far as Windows goes, it is not an OS that is conducive to developer productivity.
Time to install a real OS.
I picked Kubuntu, because I like the KDE interface, and the apt-get package management system has, for the most part, been good to me. Most of the hardware auto-discovery stuff has been pretty decent in the past.
At first I tried to use a GParted Live CD to resize the Windows side. I thought I might try dual-booting and give Vista a chance. GParted complained that there were too many partitions. Looks like the Dell/Vista install makes a lot for recovery, etc. Oh well, tried to give them a chance...
On booting from the Kubuntu CD and selecting install, the first thing it did was give an option to resize the existing partitions to make room for Kubuntu. What the heck? I split in half and
it actually freakin worked. Amazing.
The install went smoothly, selected a few options, and let it go on its happy way. After removing the CD and rebooting, I noticed it installed the free NVidia drivers. The display utility actually gives the option to use the NVidia drivers and it even downloads and installs for you. How sweet is that? The only problem, is it seemed to have a hard time getting the correct modelines for the display (1440x900). Not wanting to waste time playing with the GUI tools, a quick google and and xorg.conf edit later and I've got a sweet display.
Usually, when you talk about Linux on a laptop, the big concern is how well the hardware works (if at all). Well, it got the little built in camera working as part of the install (the Dells with Linux pre-installed don't even come with the camera), wifi has been pretty flawless (so far, even when switching though different networks), got my accelerated X (w00t!), bluetooth and all the other goodies seem to be working fine. The only real issue is the sound card didn't configure correctly during install. I think I remember seeing something online about some drivers from Dell but, I haven't invested any time in that yet.
So, how is it for development? Pretty good. Productivity is almost double of that working with windows. Being able to launch a terminal with a keyboard shortcut and ssh to any remote boxes rocks. Having a real bash shell and all of the normal command line goodies, keeps work focused on work (and not trying to beat an app into submission, windows style). Multiple shells with different environmental configurations is nice too (especially when you want to run Java6/Tomcat6 and Java1.4/Resin 1.2 at the same time.
Kubuntu has its annoyances too, what OS/distro doesn't. The best thing is, I can configure it to minimize or eliminate as desired. I know everybody like to bash windows, but, you have too admit, one really big difference with Windows and Linux happens when fixing problems. In Windows, you hear people say, try this and reboot, lets see if that works. In Linux, you just change a configuration and it works.
Like Yoda said, "Do or do not... there is no try."
Labels: inspiron, Kubuntu, review
With the new job, I needed to get a new laptop. The boss said to just tell his right hand (our awesome executive assistant/manager) what I need.
I asked for an Inspiron (with buckets of RAM), as it seemed this model has the best Linux support.
Since my primary focus is development, I mostly need fast IO on the hard drive, and lots of fast RAM. I actually opted for a less than top-end CPU in order to maximize battery life.
The system arrived with Windows Vista pre-installed. I decided to give it a run before wiping it away and just running Linux.
At first, Vista was just painful.
Startup, shutdown, and hibernate are just painfully slow.
The stupid dialogs that pop whenever you try to do anything are an unbelievable pain in the posterior.
Anyway, a bit of googling later, I managed to configure the system so that is usable.
I installed cywin and all of my normal dev tools and was able to be fairly productive.
Vista is much better than XP if you are constantly moving from one wifi spot to another (XP would just require a reboot after a while).
However, its wifi configuration tools are worse than the simple one used in previous windows.
My opinion of Vista so far:
- out of the box, it completely blows chunks
- once configured it's pretty usable (maybe the best windows yet)
- more stable than previous versions
- slower than any previous version
- eye candy is nice for about a week, then you find yourself killing it
Hibernate (and waking up) is so slow, you might as well shutdown, its faster.
Sleep is unreliable. I put it to "sleep" a few times and tossed in the backpack.
After a while I felt a lot of heat coming out of the pack, it woke up even though it was closed (major suck factor).
Because of this, I can't recommend any good reason to use sleep mode at all (this is obviously a Dell not Microsoft issue).
Labels: inspiron, review, vista
