Comments on: First Spring Framework 3.0 milestone released

By: Robert Glover

Robert Glover — Fri, 30 Oct 2009 16:49:18 +0000

I have attended 3 SpringSource (now SpringSource2GX) conferences. At the 2008 conference in Florida, someone asked a Spring presenter why the sudden push for annotations instead of XML. The Spring presenter was flusterred and muttered, "because a lot of our clients don't like to use XML". I also remember hearing a Spring presenter tell us candidly not to worry about the rumors about coming deprecations, that it was simply the Spring lead developers being "over zealous".
Well well well. So what do I do now with my library of expensive Spring books that are now obsolelete. Oh, wait. I mean, my library of expensive Spring books that are obsolute in some parts but it's not certain which parts are obsolete and which parts are not obsolete. Take the book "Expert Spring MVC and Web Flow". Should I just throw out the book? Which chapters am I supposed to skip, and which am I supposed to read?
This is just crazy. Can you imagine trying to explain this sudden deprecation of a company's entire inventory of Spring web applications to a manager? Has Spring considered the maintenance headaches this will cost and cause in future years to corporate developers whose old web applications will stop compiling if they upgrade Spring?
It's hard to believe, but at one time Spring was very easy to use and it's simplicity was a very attractive reason to use it. Ah, those were the days. Sigh.

By: Webservices with Spring and Castor « Java, Flex and JavaFX

Webservices with Spring and Castor « Java, Flex and JavaFX — Mon, 17 Aug 2009 09:33:28 +0000

[...] Spring 3.0.0 M3 or higher [...]

By: IT Technology And Something » Spring 3.0 Quartz Batch With Maven2

IT Technology And Something » Spring 3.0 Quartz Batch With Maven2 — Thu, 19 Mar 2009 06:13:36 +0000

[...] in the main Maven repositories, we will need to add custom repositories to our pom.xml (Thanks to Chris Beams for his instructions). We are particularly interested in org.springframework.context.support, which [...]

By: Stripes: A Succesful First Project at Carbon Five Community

Stripes: A Succesful First Project at Carbon Five Community — Thu, 26 Feb 2009 19:13:08 +0000

[...] Spring 3.0 M1 Features and Spring 3.0 M2 Features « Carbon Five and Hot Studio at SXSW in March [...]

By: allen sanico catadman

allen sanico catadman — Wed, 18 Feb 2009 14:50:12 +0000

juergen, ur a genius! as a developer, u make our life easier..

By: Pages tagged "manifest"

Pages tagged "manifest" — Fri, 13 Feb 2009 11:34:20 +0000

[...] bookmarks tagged manifest Comment on First Spring Framework 3.0 milestone re… saved by 5 others positiveinc bookmarked on 02/13/09 | [...]

By: Brian Topping

Brian Topping — Thu, 12 Feb 2009 20:40:30 +0000

Paul is probably right about OSGi. Here's some more information for those looking in, and it matters as much to Ant/Ivy-based developers as it does Maven-based developers.

The issue with OSGi is that the transitive closure of Spring dependencies don't always have the proper manifest entries, and developers aren't stepping up fast enough to add the proper manifests to their own code. Without the library support, all the work of SpringDM was in jeopardy. So the SpringDM developers had to do it themselves. That's reasonable and admirable. I'm a big fan of OSGi and was really impressed with the SpringDM repo when I used it last summer. But there needs to be more thought in how this is done. I found the Spring repository very difficult to work with because of these renames and don't think it's wise.

The problem is SpringSource cannot release artifacts in a dependency namespace that is not their own. Even if they could, they would make a mess of a developer's versioning scheme. I don't have an answer to this problem, but from my personal experience working with the Spring repo, the answer they came up with is a stopgap at best.

Experienced Maven developers know what a hassle a duplicated namespace is. The original groupId namespace was flat in Maven 1, and some of the projects that were thriving during this time decided to be good neighbors and upgrade their groupId to the new hierarchical model within a major version number. A good case study is Ant's artifacts. When they changed groupId from 'ant' to 'org.apache.ant' without a major version change, they all but assured that there would be duplicated jars, since transitive dependencies on ant still used the older library groupId. If the groupId does not change, Maven figures it out by graph distance and does the right thing, but it can't do that if the artifactId or groupId are changed. This led to lots of time debugging builds and adding to dependencies that eventually pulled in artifacts with the old groupId (and there are usually a lot of them).

A lot of developers swear by Maven, and if Ivy is any indication, so do a lot of Ant developers. Breaking the Maven/Ivy repository with critically important artifacts like Spring is a Really Bad Thing. Whether one likes Maven or not, this kind of tweak now affects Ant developers as well.

So while I understand the need generated by OSGi, I hope the Spring developers will spend the time necessary to work with people like Oliver to make sure that Maven repository is not trashed like this.

Cheers, Brian

By: Paul Sundling

Paul Sundling — Thu, 05 Feb 2009 00:07:14 +0000

I'm going to guess the new artifact Ids in maven might be something to do with osgi. I think their bundles had notation like that.

By: Stéphane Nicoll’s Thoughts » Blog Archive » Spring 3.0 M1 breaks Maven projects

Sat, 03 Jan 2009 03:59:09 +0000

[...] first entry in the 3.0 M1 changelog has announced here is revised project layout and build system with module-based [...]

By: Olivier Lamy

Olivier Lamy — Fri, 02 Jan 2009 09:55:35 +0000

Agree with Stephane.
It will be a REAL NIGTHMARE for maven users when upgrading due to all artifactIds change !!
This will break a lot of builds for people who wants to upgrade !!
Please any chance to revert to this non backward compatible change ????
–
Olivier
Maven PMC