Eclipse Community Forums: EMF » XsdEcoreBuilder producing an illegal Java package name

Home » Modeling » EMF » XsdEcoreBuilder producing an illegal Java package name

XsdEcoreBuilder producing an illegal Java package name [message #506257]

Wed, 06 January 2010 12:22

Eclipse User

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.

Re: XsdEcoreBuilder producing an illegal Java package name [message #506267 is a reply to message #506257]

Wed, 06 January 2010 12:49

Eclipse User

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, 
 
The package name produced by the XSDEcoreBuilder isn't even a valid
EPackage name. ModelImporter deals with that like this: 

<blockquote> 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); 
 } 
</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. 
 
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:
<blockquote cite="mid:hi2gta$kpj$1@build.eclipse.org" type="cite">Given
a schema with the following namespace URI:
 
 
<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>
 
 
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.
 
</blockquote>
</body>
</html>

--------------090904050904070200060004--

Previous Topic:	Cross Document References persistence customization
Next Topic:	EMF compare and merge

Goto Forum:

-=] Back to Top [=-

Current Time: Sun Jul 13 19:39:12 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter