|
Re: XsdEcoreBuilder producing an illegal Java package name [message #506267 is a reply to message #506257] |
Wed, 06 January 2010 17:49 |
Ed Merks Messages: 33113 Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------090904050904070200060004
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Ben,
The package name produced by the XSDEcoreBuilder isn't even a valid
EPackage name. ModelImporter deals with that like this:
protected void adjustEPackage(Monitor monitor, EPackage ePackage)
{
EPackageImportInfo ePackageInfo = getEPackageImportInfo(ePackage);
String name = ePackage.getName();
if (name == null)
{
name = "null";
}
int index = name.lastIndexOf(".");
if (index != -1)
{
String basePackage = ePackageInfo.getBasePackage();
String namePackage = name.substring(0, index);
name = name.substring(index + 1);
if (basePackage != null && !namePackage.startsWith(basePackage))
{
namePackage = basePackage + "." + namePackage;
}
StringBuffer basePackageName = new StringBuffer();
for (StringTokenizer stringTokenizer = new
StringTokenizer(namePackage, "."); stringTokenizer.hasMoreTokens(); )
{
String packageName = stringTokenizer.nextToken();
basePackageName.append(CodeGenUtil.safeName(packageName));
if (stringTokenizer.hasMoreTokens())
{
basePackageName.append('.');
}
}
ePackageInfo.setBasePackage(basePackageName.toString());
ePackage.setName(name);
}
So it's important that the raw converters convey the fully qualified
package name via the EPackage's name, even though that form is invalid
according to Ecore's constraints. The importer then uses utilities like
CodeGenUtil.safeName(packageName) to make sure that there are no
collisions with Java keywords.
So it's working as designed, because builders don't have access to
CodGenUtil. You could of course specialize the validName method to
mangle keywords...
Ben Tenne wrote:
> Given a schema with the following namespace URI:
>
> http://www.new.HelloWorld.com/int/2010-01-06/12345
>
> XsdEcoreBuilder (EMF 2.4.2) produces an EPackage with name:
>
> com.world.hello.new.int._2010._01._06._12345
>
> It's done a pretty good job of cleansing the name, but has crucially
> failed to eliminate the inclusion of Java reserved words 'new' and
> 'int' therefore making the resulting Java package name illegal.
>
> If I import the same XSD via the UI, using the 'New EMF Project'
> wizard, it additionally suffixes each reserved word with an
> underscore, thus producing a legal name:
>
> com.world.hello.new_.int_._2010._01._06._12345
>
> Is there a reason for the inconsistency? This sound like a bug in
> XsdEcoreBuilder to me (or the NameMangler class that it calls). I've
> not yet located the source that's responsible for the mapping when
> invoked via the UI.
>
> Cheers,
> Ben.
--------------090904050904070200060004
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ben,<br>
<br>
The package name produced by the XSDEcoreBuilder isn't even a valid
EPackage name. ModelImporter deals with that like this:<small><br>
</small>
<blockquote><small> protected void adjustEPackage(Monitor monitor,
EPackage ePackage)</small><br>
<small> {</small><br>
<small> EPackageImportInfo ePackageInfo =
getEPackageImportInfo(ePackage);</small><br>
<br>
<small> String name = ePackage.getName();</small><br>
<small> if (name == null)</small><br>
<small> {</small><br>
<small> name = "null";</small><br>
<small> }</small><br>
<small> int index = name.lastIndexOf(".");</small><br>
<small> if (index != -1)</small><br>
<small> {</small><br>
<small> String basePackage = ePackageInfo.getBasePackage();</small><br>
<small> String namePackage = name.substring(0, index);</small><br>
<small> name = name.substring(index + 1);</small><br>
<small> </small><br>
<small> if (basePackage != null &&
!namePackage.startsWith(basePackage))</small><br>
<small> {</small><br>
<small> namePackage = basePackage + "." + namePackage;</small><br>
<small> }</small><br>
<br>
<small> StringBuffer basePackageName = new StringBuffer();</small><br>
<small> for (StringTokenizer stringTokenizer = new
StringTokenizer(namePackage, "."); stringTokenizer.hasMoreTokens(); )</small><br>
<small> {</small><br>
<small> String packageName = stringTokenizer.nextToken();</small><br>
<small>
basePackageName.append(CodeGenUtil.safeName(packageName));</small ><br>
<small> if (stringTokenizer.hasMoreTokens())</small><br>
<small> {</small><br>
<small> basePackageName.append('.');</small><br>
<small> }</small><br>
<small> }</small><br>
<br>
<small> ePackageInfo.setBasePackage(basePackageName.toString());</small ><br>
<small> ePackage.setName(name);</small><br>
<small> }</small><br>
</blockquote>
So it's important that the raw converters convey the fully qualified
package name via the EPackage's name, even though that form is invalid
according to Ecore's constraints. The importer then uses utilities
like CodeGenUtil.safeName(packageName) to make sure that there are no
collisions with Java keywords.<br>
<br>
So it's working as designed, because builders don't have access to
CodGenUtil. You could of course specialize the validName method to
mangle keywords...<br>
<br>
<br>
Ben Tenne wrote:
<blockquote cite="mid:hi2gta$kpj$1@build.eclipse.org" type="cite">Given
a schema with the following namespace URI:
<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.new.HelloWorld.com/int/2010-01-06/12345">http://www.new.HelloWorld.com/int/2010-01-06/12345</a>
<br>
<br>
XsdEcoreBuilder (EMF 2.4.2) produces an EPackage with name:
<br>
<br>
com.world.hello.new.int._2010._01._06._12345
<br>
<br>
It's done a pretty good job of cleansing the name, but has crucially
failed to eliminate the inclusion of Java reserved words 'new' and
'int' therefore making the resulting Java package name illegal.
<br>
<br>
If I import the same XSD via the UI, using the 'New EMF Project'
wizard, it additionally suffixes each reserved word with an underscore,
thus producing a legal name:
<br>
<br>
com.world.hello.new_.int_._2010._01._06._12345
<br>
<br>
Is there a reason for the inconsistency? This sound like a bug in
XsdEcoreBuilder to me (or the NameMangler class that it calls). I've
not yet located the source that's responsible for the mapping when
invoked via the UI.
<br>
<br>
Cheers,
<br>
Ben.
<br>
</blockquote>
</body>
</html>
--------------090904050904070200060004--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.02106 seconds