Craig, Any chance you could retest this with 2.2.7-SNAPSHOT?
I added some code to escape the URL's better (convert spaces to %20 and other fun things) last week some time. Thus, this may now be fixed already. That said, I took the example off the jira again and reran it in a directory with a space and with my m2 repo moved into a director with a space and didn't have any issues. I did a grep for "classpath" and didn't really see anything other than in your spring beans. Thus, I'm not sure where that protocol would have come from. Is there a full stack trace? Dan On Thu February 4 2010 7:03:09 pm Craig Tataryn wrote: > ... when XSDs are held within jar files that have a space in their path. > > Here is the scenario: Dan did a patch for an issue I logged [1] > involving the proper resolution of XSDs held in a separate maven > module (or any jar on the classpath for that matter) instead of the > XSDs existing directly in the module where cxf-codegen-plugin is being > invoked. It worked great for me, but oddly enough only when I invoked > an "mvn clean install" from the parent project. If I went down into > the actual module that was setup for cxf-codegen-plugin and try to > clean install, it would bomb with: > > --------------------------------------------------------------------------- > ------------------ org.apache.maven.lifecycle.LifecycleExecutionException: > Thrown by JAXB > > : unknown protocol: classpath > > . > . > Caused by: java.net.MalformedURLException: unknown protocol: classpath > at java.net.URL.<init>(URL.java:574) > at java.net.URL.<init>(URL.java:464) > at java.net.URL.<init>(URL.java:413) > at > org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source) > at > org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown > Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown > Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown > Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at > org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at > org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) > at > com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:394) > > --------------------------------------------------------------------------- > --------------------- > > I debugged like crazy, found where things were going wrong. I found a > bug [2] which kind of described the problem, i.e. a jar on the > classpath you are trying to get a resource URL for has a space in it's > path. So what I did was I changed my Maven repo from D:\Documents and > Settings\.... to D:\m2repo, a path without spaces. Lo and behold, > everything worked peachy after that. > > So, attached is an attempt at a patch to URIResolver in order to fix > the problem. That being said, I have no way to test this patch in > order to see if it works. Why? Because if I make the fix myself to > the 2.2.6 code on my system, then mvn clean install a new version into > my local repo, then run a debug session when it gets to > AbstractWrapperWSDLLocator.getImportInputSource, the parentLocation > parameter doesn't include a classpath:/ prefix, instead it just > contains the relative path found within the XSD, and I get a > "FileNotFound" type error. No clue why. > > People on Windows (because of the m2 repo being under Documents and > Settings by default; a path containing spaces) would definitely face > the problem I'm trying to solve. I'm not completely sure if it's JDK > vendor related, but on my project I'm using IBM jvm, here's my > environment: > > ----------------------------------------- > $ mvn --version > Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500) > Java version: 1.6.0 > Java home: D:\Program Files\IBM\RAD75\jdk\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows xp" version: "5.1 build 2600 service pack 3" arch: > "x86" Family: "windows" > ----------------------------------------- > > So, if anyone would be so kind as to try to replicate the problem, > then apply the patch and see if the problem is resolved, that would be > great. > > Steps to reproduce: > 1) download the sample project from the JIRA issue [1] > 2) crack open the pom.xml file from CXFSchemaRefProblemPom, update the > cxf versions to 2.2.6 > 3) crack open the pom.xml from CXFSchemaRefProblemWar and comment out > all the extraargs except for -verbose > 4) "mvn clean install" from CXFSchemaRefProblemPom, should build cleanly > 5) "mvn clean install -e" from CXFSchemaRefProblemWar, you should get > the classpath protocol error > 6) apply my patch, install the change locally, try step 5 again. > > Thanks, > > Craig > > [1] - https://issues.apache.org/jira/browse/CXF-2599 > [2] - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6506304 -- Daniel Kulp [email protected] http://www.dankulp.com/blog
