[ http://issues.apache.org/jira/browse/GERONIMO-825?page=all ]
     
David Jencks closed GERONIMO-825:
---------------------------------

    Resolution: Fixed

The schema/ paths are unnecessary, so I removed them.  Also cleaned up assembly 
maven.xml a little bit.

Sending        modules/assembly/maven.xml
Sending        modules/jetty-builder/src/schema/geronimo-jetty-1.0.xsd
Sending        modules/security-builder/src/schema/geronimo-security-1.0.xsd
Sending        modules/tomcat-builder/src/schema/geronimo-tomcat-1.0.xsd
Sending        modules/web-builder/src/schema/geronimo-web-1.0.xsd
Transmitting file data .....
Committed revision 293072.

openejb:
Checking in modules/openejb-builder/src/schema/corba-css-config-2.0.xsd;
new revision: 1.2; previous revision: 1.1
Checking in modules/openejb-builder/src/schema/corba-tss-config-2.0.xsd;
new revision: 1.2; previous revision: 1.1
Checking in modules/openejb-builder/src/schema/openejb-jar-2.0.xsd;
new revision: 1.3; previous revision: 1.2


> schemaLocation attribute values in deployment plans contain problematic 
> "schema\" prefix.
> -----------------------------------------------------------------------------------------
>
>          Key: GERONIMO-825
>          URL: http://issues.apache.org/jira/browse/GERONIMO-825
>      Project: Geronimo
>         Type: Bug
>     Versions: 1.0-M4
>     Reporter: Sachin Patel
>     Assignee: David Jencks
>     Priority: Minor
>      Fix For: 1.0

>
> From IRC conversation...
> [16:33] sppatel: I'm looking at the deployment plan schemas, and noticed 
> something odd.  Could someone explain 
> why the path "/schema" is being included in some the schemaLocations in 
> several of the xsd files  
> where other schemas are being imported.  This looks like an error to me. 
> For example.... geronimo-web.xsd imports  
> <xs:import namespace="http://geronimo.apache.org/xml/ns/security"; 
> schemaLocation="schema/geronimo-security.xsd"/> 
>       
> whereas geronimo-application.xsd references the same schema but its 
> schemaLocation="geronimo-security.xsd" 
>   
> Why is the "schema/" prefix being included?
> [16:45] djencks: sppatel: I think one of those is an error, but I'm not sure 
> which
> [16:46] djencks: it's using an entity resolver in the xmlbeans2 maven plugin 
> that looks in the classpath jars for the xsd file
> [16:46] sppatel: djencks: I'm attempting to generate EMF models for the 
> deployment plans, and was forced to remove the prefix /schema in all 
> scheamaLocations for it to correctly resolve
> [16:46] djencks: what is emf?
> [16:46] djencks: don't think is is electromotive force :-)
> [16:47] sppatel: Eclipse Modeling Framework....:)
> [16:47] sppatel:  I'm working on providing deployment plan editors for the 
> Geronimo Server Adapter
> [16:47] djencks: cool
> [16:47] djencks: where are you getting the schemas from?
> [16:48] sppatel: from the schema folder in a install image
> [16:48] sppatel: since their bundled all togather, the "schema/ prefx doesn't 
> make sense
> [16:48] djencks: can you read them out of a classpath using a classloader?
> [16:49] djencks: not critical, just asking
> [16:49] sppatel: not sure how to do that
> [16:49] djencks: it would be a useful capability I think for the EMF
> [16:50] djencks: well, there are at least 2 solutions I can think of:
> [16:50] djencks: 1. figure out a way so xmlbeans doesn't need the prefix... 
> this may be actually more in line with what xmlbeans wants to do anyway
> [16:51] djencks: 2. modify the copies of the schemas to remove the /schema  
> prefix
> [16:51] djencks: can you file a JIRA issue?
> [16:51] sppatel: sure, np.  2 is fine with me for now... just wanted to bring 
> it up
> [16:52] *** sbailliez has joined #geronimo.
> [16:52] djencks: Is this blocking your progress? Can you remove the prefix by 
> hand until we figure out what to do? I would prefer (1) if it works
> [16:53] sppatel: no its not blocking, i'm changing the refs by hand. yeah 1 
> would be ideal, especially if the scheams are going to be changing in the 
> future
> [16:54] djencks: well, we are hoping that we will have stabilized them by 1.0 
> to a n, n-2 support model :-)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Reply via email to