Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » XsdEcoreBuilder producing an illegal Java package name
XsdEcoreBuilder producing an illegal Java package name [message #506257] Wed, 06 January 2010 17:22 Go to next message
Ben Tenne is currently offline Ben TenneFriend
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.
Re: XsdEcoreBuilder producing an illegal Java package name [message #506267 is a reply to message #506257] Wed, 06 January 2010 17:49 Go to previous message
Ed Merks is currently offline Ed MerksFriend
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 &amp;&amp;
!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/
Previous Topic:Cross Document References persistence customization
Next Topic:EMF compare and merge
Goto Forum:
  


Current Time: Fri Mar 29 14:23:02 GMT 2024

Powered by FUDForum. Page generated in 0.02106 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top