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

Help

Home

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

Show: Today's Messages :: Show Polls :: Message Navigator

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

Wed, 06 January 2010 17:22

Ben Tenne

Messages: 50
Registered: October 2009

Member

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.

Report message to a moderator

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: 30653
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, 
 
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--

Report message to a moderator

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

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Nov 21 11:39:57 GMT 2019

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter