Graham, Yes, you kill 3 birds with 1 stone. Nice work.
I thought about using a new package for the schemas. However, I'm worried that some tools may behave oddly if they encounter a Java package that has no *.java files. I know from experience that putting schemas in a non-empty Java package works fine. -- Arthur On 12/13/06, Graham Turrell <[EMAIL PROTECTED]> wrote:
Just to clarify, the solution we end up with here should in fact resolve three M7 JIRAs (WODEN-64 [1], WODEN-83 [2] AND WODEN-85 [3]) if its the right solution, so forgive me if I seem to be labouring this a bit :) Arthur, I'm totally fine with a simple solution of storing copies of the schemas in svn in a java package, and updating them manually as and when when the need arises. I may also create an ant target (not part of the build) to help with comparing the svn versions with those on w3c and updating as required. This gives the woden developers full visibility and control over schema versions used in Woden. I'd prefer that the schema had a dedicated package name rather than stick them in an existing package alongside java classes (I'll present my case for this if you like). I'd opt for a new package, probably org.apache.woden.internal.resolver.resources or similar, which would then be the guaranteed location for the standard schema (so It's still possble to locate the schema using a class's classloader, should it be necessary). [1] should be satisfied by this solution (in addtion to [2] and [3]) , since the w3c test-suite copies of the standard schema are not in the woden source tree anyway: there will be a single set of schema in woden svn. Kind Regards, Graham. [1] http://issues.apache.org/jira/browse/WODEN-64 [2] http://issues.apache.org/jira/browse/WODEN-83 [3] http://issues.apache.org/jira/browse/WODEN-85 "Arthur Ryman" <[EMAIL PROTECTED]> wrote on 12/12/2006 03:29:51: > Graham, > > You can get the resource from any class, just create a class object > from the right package. Let's not get hung up on how the schemas are > pulled into the build. Just copy them into the src tree and build from > there. We just need to update them periodically until the spec > finalizes. > > -- Arthur > > On 12/11/06, Graham Turrell <[EMAIL PROTECTED]> wrote: > > Arthur, > > > > I could certainly do that, though the implication with WODEN-85 [1] is that > > we'd be using the ant build to dynamically > > populate java packages, which I'm a lot less comfortable with. > > > > If we're adding the schema to a java package at build time, > > then developers would expect to see those schema in that package in the src > > tree also. If we *store* the schema files in svn under say > > trunk/java/src/org/apache/woden/resolver/resources, we'd avoid that > > concern, but this kind of goes against my reading > > of the requirement of [1] (to pull down the schema files dynamically at > > build time). > > That was my rationale for staying outside of the java package hierarchy. > > > > I think my proposal does meet your needs, but perhaps you could help me > > better understand your requirements through your example? > > (I believe that it would only return an InputStream if wsdl20.xsd was in > > the same package as the calling class, since non-absolute > > resource name arguments to getResource()/getResourceAsStream() are treated > > as relative to the current package name only. > > So simply specifiying an unqualified resource name would seem limited in > > value) > > > > The methods getResource()/getResourceAsStream() will find the resource > > on the classpath if given the qualified package name, so if wsdl20.xsd is > > held in /xmlcatalog/wsdl (in woden.jar), then > > > > InputStream is = this.getClass().getResourceAsStream( > > "/xmlcatalog/wsdl/wsdl20.xsd" ); > > > > would create the InputStream as required (regardless of the calling class). > > Do you have scenarios where this would be insufficient? > > > > Also I wasn't clear why you say we should necessarily use an existing > > package for the schema? > > > > Thanks. > > > > Kind Regards, > > > > Graham. > > > > > > [1] [1] http://issues.apache.org/jira/browse/WODEN-85 > > > > Arthur Ryman <[EMAIL PROTECTED]> wrote on 11/12/2006 19:43:33: > > > > > > > > Graham, > > > > > > The schemas and DTDs should be in a Java package directory so the > > > usual Java class loader can find them and return them as input streams. > > > > > > e.g. > > > > > > InputStream is = this.getClass().getResourceAsStream( "wsdl20.xsd" ); > > > > > > You should pick an existing package. Maybe the one that holds the > > > URI resolver. > > > > > > Arthur Ryman, > > > IBM Software Group, Rational Division > > > > > > blog: http://ryman.eclipsedevelopersjournal.com/ > > > phone: +1-905-413-3077, TL 969-3077 > > > assistant: +1-905-413-2411, TL 969-2411 > > > fax: +1-905-413-4920, TL 969-4920 > > > mobile: +1-416-939-5063, text: [EMAIL PROTECTED] > > > > > > > > > > > Graham Turrell <[EMAIL PROTECTED]> > > > 12/11/2006 01:54 PM > > > > > > Please respond to > > > woden-dev@ws.apache.org > > > > > > To > > > > > > woden-dev@ws.apache.org > > > > > > cc > > > > > > Subject > > > > > > location for standard schema in woden.jar > > > > > > > > > > > > > > > > > > List, > > > > > > I've not had any feedback to my recent comments on Woden-85 [1], so I > > > assume there is nothing contentious therein. > > > > > > For building woden.jar, I plan to change build.xml to copy the xml and > > > wsdl2 schema files from the unzipped w3c test-suite.zip into > > > xmlcatalog/wsdl and xmlcatalog/wsdl respectively (which happens to mirror > > > the structure in downloads/w3c in the w3c test-suite). > > > This also simplifies configuration the developers' enviroment (eg eclipse > > > projects) too, as the schema downloaded from test-suite.zip into the > > > workspace can be used directly when running the test suites. > > > The hard-coded catalog file "system.catalog" (containing URI resolution > > > info for these local schema files) will appear in trunk/java in svn > > > (alongside build.xml, license files etc) and will be copied into the "/" > > > directory of woden.jar at build time. > > > > > > There is a slight alternative to these locations, which is to place the > > > schema and catalog in woden.jar /META-INF. The only proviso is that in > > svn > > > the system catalog would need to appear > > trunk/java/META-INF/system.catalog. > > > If this is prefered to the first alternative and there is no objection to > > a > > > META-INF directory in svn, then I'll do it that way. > > > > > > Please let me know asap if you have a view on this either way. > > > > > > Finally, which is preferred? - copying the schema to woden.jar from w3c > > > test-suite.zip, or directly from their published web locations? I'm in > > > favour of the former, since a built woden.jar should result from a build > > > tested with test-suite.zip's current contents. > > > > > > Again, any views asap please. Thanks. > > > > > > [1] http://issues.apache.org/jira/browse/WODEN-85 > > > > > > Kind Regards, > > > > > > Graham. > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
