[
http://issues.apache.org/jira/browse/GERONIMO-825?page=comments#action_12329713
]
Sachin Patel commented on GERONIMO-825:
---------------------------------------
Based on Aaron's comments the maven.xml of the assembly module can be fixed to
use the following regexp to remove the "weird directories" when processing the
schemas
for packaging in the schema's directory.
<replaceregexp file="${schema}" match="schemaLocation="(.*/)(.*xsd)"
replace="schemaLocation="\2" byline="true"/>
> 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
> 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
