Hi Mike,
Can we ensure the package renamer deals with these changes?
-Tom
Mike Norman wrote:
> As part of the work for bugs 236064 and 236711,
> I have been trying to figure out a simple and consistent naming convention for EclipseLink's schemas.
>
> - rename the EclipseLink native deployment XML schema to eclipselink_persistence_map_1.0.xsd
> - rename the EclipseLink sessions XML schema to eclipselink_sessions_1.0.xsd
> - remove mention of Oracle in the namespace for native deployment XML:
> Index: NamespaceResolvableProject.java
>
> ===================================================================
> --- NamespaceResolvableProject.java (revision 1661)
> +++ NamespaceResolvableProject.java (working copy)
> @@ -25,7 +25,7 @@
> public static final String ECLIPSELINK_PREFIX = "eclipselink";
> public static final String ECLIPSELINK_NAMESPACE =
> - "http://xmlns.oracle.com/ias/xsds/eclipselink";
> ^^^^^^^^^^^^^^
>
> In (the renamed) eclipselink_persistence_map_1.0.xsd file, the namespace is declared as
>
> <!-- Eclipse Persistence Service Project:: Map Schema file for ORM/OXM/EIS -->
> <xsd:schema targetNamespace="http://xmlns.eclipse.org/xsds/eclipselink"
> ^^^^^^
>
> I discussed this with Blaise - it is common practice to make your namespace URI match up to an actual
> URL so that people can download your schemas. The website "http://xmlns.eclipse.org " doesn't exist,
> nor do I think the Eclipse Foundation would want us to 'take over' something like that all by ourselves.
>
> PeterK mentioned that we have complete control of everything under "http://www.eclipse.org/eclipselink", so how about:
>
> native deployment XML schema namespace : "http://www.eclipse.org/eclipselink/xsds/persistence"
> new EclipseLink ORM XML schema namespace : "http://www.eclipse.org/eclipselink/xsds/persistence/orm"
>
> The schema document itself has version information in the name eclipselink_persistence_map_1.0.xsd ,
> eclipselink_orm_1_0.xsd , etc) so I don't think we need a version number in the namespace URI.
>
> Comments?
> Note 1 : the changes are not backwards compatible so once they are 'set' for the 1.0 Release,
> we will have to live with them for a long time!
>
> Note 2: once these changes get checked in, old 'legacy' files will no longer work since by default schema validation is
> turned on. I can scan the SVN repository for any and all files, but it is unlikely that every place will be found on the
> first pass - failures will point the way to where things were missed
I would like to discuss this at today's (080618) Dev meeting. The
package renamer doesn't come into play here.