Spring Framework / Spring Rich Client Library Hell?

[steve_smith]

Hi,

I'm working on a Spring Rich Client app. As you knowing, Spring Rich Client depend on Spring Framework. Also, Spring Framework depend on other 3rd party libraries like commons-beanutils.jar. When I first set up my development environment a few months ago, I got Spring Rich Client from CVS. That CVS project includes Spring Framework libraries but some of the libraries Spring Framework relies on (e.g. commons-beanutils.jar) are not in Spring Rich Client CVS project. So, at the time, I got commons-beanutils.jar from Spring Framework's CVS project. Follow me so far?

Okay, so today I try to call method in the commons-beanutils API -- MethodUtils.isAssignmentCompatible(). But compiler complain that this is protected method. I look at JavaDocs and it says public. So I say what the heck? Looking close, I notice that method used to be protected but is now public is later releases of beanutils.

I check Spring Framework CVS now and this jar was updated on 2005-1-14. It now has public method but previous jar had protected method. So, I am thinking, okay, get this new one. But problem is, Spring Framework core library (spring-core.jar) in Spring Rich Client CVS was last updated on 2004-11-27. So now I reluctant to update to newer commons-beanutils.jar because it may break older spring-core.jar.

So maybe now you saying "hey man, you just need to update to newer spring-core.jar too". But, my friend, problem is, new spring-core.jar may break Spring Rich Client code!

So, how to resolve this issue? There are other libraries that have this version problem too, not just commons-beanutils.jar. I thinking solution is this:
1) Spring Rich Client CVS should have the latest RELEASED Spring Framework libraries that Spring Rich Client can successfully compile with. Example, if Spring Framework is at version 1.1.4 but Spring Rich Client can only compile with Spring Framework 1.1.2, then only the 1.1.2 libraries should in Spring Rich Client CVS.
2) Spring Rich Client CVS should include ALL of the 3rd party libraries that Spring Framework relies on. The version of these 3rd party libraries should be the version that accompanied the Spring Framework version in Spring Rich Client CVS. Example, if Spring Framework 1.1.4 uses commons-beanutils 1.7 but Spring Framework 1.1.2 uses commons-beanutils 1.6 and Spring Rich Client is using Spring Framework 1.1.2, then Spring Rich Client CVS should include commons-beanutils 1.6.

Keith, Ollie and friends, what you thinking about this one?

[Keith Donald]

I completely agree with you, and that is very important. I'm also serious about reducing the dependencies between Spring Rich and other parts of Spring (dao, orm, etc). For the dependencies left, we need to make them very clear in both the lib readme.txt and through the code package structure.

Spring rich doesn't depend on beanutils though :-)

[steve_smith]

Keith, thank you for you comment.

Spring rich doesn't depend on beanutils though :-)

What I saying is:
1) My app depend on Spring Rich Client
2) Spring Rich Client depend on Spring Framework (which version of Spring Framework? I don't know)
3) Spring Framework depend on beanutils
4) My app also depend on a newer version of beanutils (whatever version is in Spring Framework CVS...perhaps 1.7.0?). My app calls MethodUtils.isAssignmentCompatible(), which is only public in newer version of beanutils. It used to be protected.

So, I want to use newer version of beanutils to get public isAssignmentCompatible but I don't want to break older version of Spring Framework that Spring Rich Client depends on.

--------

Anyway, I think is okay. I just try to compile and run my app with newer version of beanutils and it work fine. So I guess I am lucky this time. Buy maybe not next time I have a similar problem.

[Keith Donald]

You just have to keep in mind WHAT in Spring depends on beanutils. The answer is VERY VERY LITTLE (actually, to my knowledge: zero as far as compile time, it's only runtime stuff for the struts 1.x integration.)

Spring integrates with a lot of stuff, no doubt about it, but it carefully manages those dependencies and makes it clear (again through package structure and docs) what parts of the framework depend on what. The core framework depends on nothing but commons-logging.

We need to be as diciplined in Spring Rich, and i think for the most part we have been. The exception I would say is we have some dependencies to other parts of Spring where we probably shouldn't (for example, we reuse some exceptions in orm and dao, which arguably isn't worth pulling in the entire module.)

[ragnarwestad]

Think I'll have to agree with Steve here.

I have just grabbed the lates Spring RCP source from CVS and I don't know what version of Spring etc it depends on, so I can't make it compile.

I have Spring 1.1 and 1.1.2 in addition to the latest CVS source, but Spring RCP does not seem to compile against any of these.

So a clear and unambigous answer would be very nice.

/Ragnar :-)

[Keith Donald]

The jar files in the spring-richclient/lib directory always compiled with the framework as is in CVS; we don't checkin code that doesn't compile.

Code in the core springframework repository, though, primarily unreleased sandbox code has since evolved, and Spring Rich had not yet been updated to reflect those updates (some were incompatible). So folks trying to compile and/or run Spring Rich against the latest code in the Spring sandbox would have issues (which have been noticed already.)

I just now updated all jar files to Spring 1.1.4 and a sandbox snapshot from today. I also made the neccessary updates to Spring Rich classes to bring them in sync with the latest.

Let me know if you still have issues after the updates propogate.

[ragnarwestad]

Thanks for a fast response, Keith.
But I'm still lost here. Here's what I do:

I get both Spring and Spring RCP from CVS using Eclipse CVS integration. I set up the projects and I get 1241 errors, mostly related to unresolved references. The first one is:

"The import org.springframework.rules.UnaryPredicate cannot be resolved".

So I search both projects for "UnaryPredicate" and I get no hits other than where it is used in Spring RCP.

Hm ... strange ... so I think: Well, it may not compile out of the box in Eclipse or any other IDE, but lets give the build.xml file in the top Spring RCP a try. I run it and gets an error saying:

"BUILD FAILED
C:\eclipse\workspace\spring-rcp\build.xml:89: Could not create task or type of type: attribute-compiler.
...."

I try to search Jakarta for the attribute compiler task, but I am unable to find it, despite the fact that I see lots of information about it.

I downloaded the Spring 1.1.4 that you refer to, and make my Spring RCP point to its /dist JAR files instead of the latest Spring CVS source. But the UnaryPredicate error still remains, plus another 1389.

Maybe I'm a little dense and impatient (yes, there has been some incidents throughout my life that points in this direction :-)), but anyway:

Yes, I have incidents Keith and I do need your assistance. I simply cannot make this thing compile.

/Ragnar

[Keith Donald]

You're checking out the old spring-rcp module from the springframework, which is eons obsolete yet sourceforge has still not yet removed. :-(

You want the spring-rich-c repository at sourceforge, spring-richclient module. This is where all current code is hosted.

[ragnarwestad]

JeeeeeeeeeeeeeeeZ!

Well, thanks Keith. The proper CVS code of course compiles out of the box without any further ado.

This problem has put me off getting into Spring RCP for quite som time, and I may not be the only one. Could'nt you at least delete the code there so people would not waste valuable time before they ask?

Now I need some fresh air ...

/Ragnar :?

[Martin Kersten]

Well seams like I will save some time than. I guess I was also checking out the wrong code ... . Thanks for the hint!