Closed joercampbell closed 11 years ago
The xsd is included in the code when downloaded... Does it help to point to the checked out version on disk? If so - does it make sense then to make the xsd be a downloadable 'asset' and let people specify as they need?
This is actually beyond my ability to answer; I'm not familiar enough with either XSD or Spring. I just know that this currently causes a problem--I don't know how to fix it. :)
Example page in the wiki was updated to point to a rel path on disk (assuming you have the code downloaded).
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd http://www.fishwife.org/schema/jrugged jrugged-spring/src/main/resources/jrugged.xsd
Unless we 'want' to host this somewhere - I hope that this will solve 90% or so of the problems people may have working with the source code and the examples.
Is the full source path the right way to go? This will only work if the jrugged-spring source is available locally to the implementing code in that location. Perhaps classpath relative is better- just jrugged.xsd vs the fully qualified path to src/main/resources.
I guess my point is that - the user has to move this and configure their IDE correctly to point to the right thing. The examples have a 'pointer' to what I think will work for most people (your mileage may vary) but that it is generally out of my control for how people implement it in their spring in their project.
The documentation on http://code.google.com/p/jrugged/wiki/SpringNamespaceExample shows an XSD schema purportedly located at http://www.fishwife.org/schema/jrugged/jrugged.xsd. However, that file doesn't exist there, and as there isn't actually a webserver running at www.fishwife.org, this causes schema validation to time out horribly in IDEs that attempt validation.
If we are going to have an XSD, let's find a better place to host it than a nonexistent webserver. :)