Arthur, Out of curiosity, can you site any examples of tools that misbehave when non-Java resources are located in a package of their own?
Thanks, Lawrence Graham Turrell <[EMAIL PROTECTED]> 12/14/2006 06:06 AM Please respond to woden-dev@ws.apache.org To woden-dev@ws.apache.org cc Subject Re: location for standard schema in woden.jar Arthur, You've won me over :) I'll place the schema in org.apache.woden.resolver. This currently contains just the interface class for URI Resolvers, so seems an OK place and avoids any potential tooling issues as you point out. Kind Regards, Graham. _____________________________________________ Graham C Turrell CEng, MBCS Chartered IT Practitioner WebSphere ESB Foundation Technologies DE3F16 / MP 211 IBM Labs Hursley Park Winchester, Hampshire England. SO21 2JN Tel +44-(0)1962-815018 email: [EMAIL PROTECTED] "No army can withstand the force of an idea whose time has come.". -Victor Hugo "Arthur Ryman" <[EMAIL PROTECTED]> wrote on 14/12/2006 02:49:37: > 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] > --------------------------------------------------------------------- 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]
