Tag Archives: Maven

Releasing with Subversion mess

Posted on by
Reply

On my current project we use Subversion 1.4. My MacBook Pro came with a preinstalled Subversion client 1.6.5 (use svn –version to see what clientversion your are running). I had assumed we used 1.6 so I didn’t change my client. I was aware of the troubles you can have mixing svn client and server versions.
I had no trouble synchronizing up untill now since Eclipse uses a build-in client and commandline svn st and up works without any trouble with different Subversion versions. Today I ran into some trouble while releasing with Maven 2.2.0 (preinstalled on the MBP as well). There was no actual error but when I ran mvn release it stalled on download maven-release-plugin-2.0-beta-8.pom. A friend with a Mac remembered he had the same trouble releasing before since it should be using the beta-7 release plugin for svn server version 1.4 and advised me to downgrade my Subversion client.

If you are using this as a setup/tutorial: DON’T FORGET TO COMMIT OR BACKUP YOUR DATA FIRST!

I downloaded an older version of Subversion, 1.5.4 (minor versions should be simlair of the client and server version) and installed it on my MBP. After restarting my terminal svn –version still showed I was using 1.6.5. After some research I found out about the somewhat weird setup:

  • echo $PATH showed me: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
  • cd /usr/local/bin and ls-lrta gave me a symbolic link for svn: svn -> /opt/subversion/bin/svn
  • this symlink was actually pointing to svn 1.5.4 (/opt/subversion/bin/svn –version) (the 1.6.5 was actually moved to an versioned directory in opt subversion_backup.date)
  • in /usr/bin i found that there was another svn client, that actually had version 1.6.5
  • I moved that file to svn.old (so it wouldn’t be found when calling svn), restarted my terminal and svn was now set to 1.5.4

mvn release now used the maven-release-plugin-2.0-beta-7.pom and releasing worked out just fine (well… except for a hanging artifactory problem)

Don’t forget to check out (svn co) your projects again and throw away the old versions since the .svn directories are poluted with the other svn versions stuff. Also think about changing your svn client in your development tool.

Module dependend, annotated, Panel menu

Posted on by
1

I am currently working on a Wicket / Spring e.a. website for a client in Rotterdam. The website serves as a single point of contact to the organization from a customers perspective and therefore we interface with a lot of other systems. The dependency on succes of other projects causes an ever changing scope for this project so we set up a multi module Maven stucture to be able to do ‘last minute’ in- or exclusion of products. To have the least amount of work when in- or excluding modules we were in need of a menu which would auto-adjust to what was packaged in the release. We created an annotation and placed this on all Panel classes that should have a menu item: Continue reading →

Dependency mayhem: Cannot find the declaration of element ‘beans’

Posted on by
3

Last week I ran into this fun problem while fixing our Fitnesse tests (easy to say while looking back ;) ). I had to fix the tests because of an Axis problem on which I’ll possibly blog later on.
The exception thrown while running the Fitnesse tests was:

org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 4 in XML document from class path resource [...-application-context.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element 'beans'.
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:404)

All this is saying is that Spring isn’t able to validate the xml against a dtd or xsd.
A little background on the fine solution the Spring framework supplies to do schema or dtd validation on application configuration files. The code first checks if the xsd or dtd can be located globally, if not it will try to resolve the files locally. Spring has a mapping in its jars META-INF directories called spring.schemas, in which the mapping between the url and local file path is made. Still strange to me is that I had an internet connection, but possibly the proxy was in Springs way.

After a lot of research and trial and error (kuddos to these guys and a clear moment out of coffee and a nicotine shot) I found the actual problem. We had created an assembly for our Fitnesse tests where we included all the unpacked jars referenced in our projects. Because of this Spring and other dependencies got included several times and with that the spring.schemas and spring.handlers files (never knew that a file with the same name and path could be included more than once by the way). This never seemed a problem untill I added a Spring-WS dependency to one of our projects to fix the earlier mentioned Axis problem. Since by now we had around 10 spring.schemas and spring.handlers it was absolutly random which file was read and some of these included only a subset of the info since the jars only cover parts of the framework. After deleting all but one of each (I left the largest in place) my Fitnesse tests got past the point of validation errors.

To actually solve the dependency problem we’ll have to look at a better way to integrate Fitnesse and Maven. Hope to post the solution shortly.