Why does the GWT compiler require an X server and how to work around it
Monday, May 12th, 2008Got this error today when trying to build our little GWT application in linux: more…
Jing Xue’s Weblog

Got this error today when trying to build our little GWT application in linux: more…
Ivy 2.0 beta 2 adds an interesting useMavenMetaData switch to its ibiblio resolver. When it’s on (the default actually), Ivy will try and use the maven-metadata.xml for listing the versions available, and for dynamic dependency resolution. This is interesting to me because it makes it a lot easier to run our builds against a proxy repository server like Maven Proxy or Archiva.
Until beta 2, Ivy finds out about the available versions of a module by parsing the directory listing HTML from Ibiblio’s Apache server. That doesn’t work when there is a proxy server sitting in between, because a) the proxy server doesn’t usually proxy directory listing requests, and/or b) the proxy server renders the directory listing in different HTML. Switching to using the structured maven meta data completely eliminated this mess.
Of course, using the maven-metadata.xml files from the official ibiblio repository will subject us to some new hazard - some modules have out-of-date maven-metadata.xml. For instance, by its maven-metadata.xml, the latest version of Hibernate would still be 3.2.0.cr1.
One of those maven proxy servers turns out to be a perfect solution to this problem - we can use them now, remember?
In my case, I run an Archiva server proxying the official maven 2 repository. Whenever I run into a bad metadata file, I simply request the missing version through Archiva, and it will fetch it and update the metadata file. For example, in the hibernate case, I would just open up Firefox and try to download http://archiva-server/repository/internal/org/hibernate/hibernate/3.2.6.ga/hibernate-3.2.6.ga.jar. That only needs to be done once, and afterwards Archiva would have updated its local version of the maven-metadata.xml properly.