Home » Modeling » EMF » Creation of DataType references to existing classes
| Creation of DataType references to existing classes [message #414614] |
Thu, 15 November 2007 08:57  |
 Tobias Langner
Messages: 17
Registered: July 2009 |
Junior Member |
|
|
Hey,
we're currently working on customizing the import of Rational Rose models
into EMF. The model we try to import often contains structural features of
types that are not part of the model. For example, an operation declares
to throw SQLException while no datatype SQLException is defined.
Is there a way to represent this situation in the ECore model, i.e. to add
an exception to an operation without having to manually create a datatype
for the exception in the model and reference this datatype then? Because,
if we do so by creating a datatype for java.sql.SQLException along with
its containing packages and add it to the model, the generated code for
our original model references generated code of the java.sql-package
which, in my opinion, should not be the case. What we want is basically
something like a EDataTypeReference referencing a datatype that is not
part of the model.
Thanks in advance for your replies, cheers,
Tobias Langner
|
|
|
| Re: Creation of DataType references to existing classes [message #414615 is a reply to message #414614] |
Thu, 15 November 2007 13:11  |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------070400040008050906090903
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Tobias,
You should just be able to define an EDataType to wrap
java.sql.SQLException. It sounds like maybe you are trying to model it
as an class in its own package which would result in an EClass that will
be generated. If you look at Ecore's .mdl/.cat file you'll see it
defines many data types like this:
Tobias Langner wrote:
> Hey,
> we're currently working on customizing the import of Rational Rose
> models into EMF. The model we try to import often contains structural
> features of types that are not part of the model. For example, an
> operation declares to throw SQLException while no datatype
> SQLException is defined.
> Is there a way to represent this situation in the ECore model, i.e. to
> add an exception to an operation without having to manually create a
> datatype for the exception in the model and reference this datatype
> then? Because, if we do so by creating a datatype for
> java.sql.SQLException along with its containing packages and add it to
> the model, the generated code for our original model references
> generated code of the java.sql-package which, in my opinion, should
> not be the case. What we want is basically something like a
> EDataTypeReference referencing a datatype that is not part of the model.
>
> Thanks in advance for your replies, cheers,
>
> Tobias Langner
>
--------------070400040008050906090903
Content-Type: multipart/related;
boundary="------------050609020301020200010400"
--------------050609020301020200010400
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Tobias,<br>
<br>
You should just be able to define an EDataType to wrap
java.sql.SQLException.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Creation of DataType references to existing classes [message #414620 is a reply to message #414615] |
Thu, 15 November 2007 15:21 |
Tobias Langner
Messages: 17
Registered: July 2009 |
Junior Member |
|
|
Ed,
thanks for your quick reply.
> You should just be able to define an EDataType to wrap java.sql.SQLException.
That is what we were doing :)
> It sounds like maybe you are trying to model it as an class in its own
package > which would result in an EClass that will be generated.
No no, we create EDataType instances with appropriate instanceClassNames
set. Our mistake probably was, that we created this EDataTypes in an
EPackage structure corresponding to the package structure of the
referenced java type. For example, the EDataType for "Exception" was
created in the EPackage "lang" in the EPackage "java". When we then tried
to generate code from our imported model, we got several syntax errors,
mostly referring to illegal exports of "java.*" in MANIFEST.MF. Apart from
that, we wondered why there was generated code for the package "java.lang"
because we only wanted to reference the type "Exception" without actually
creating code for (since it obviously already exists).
What we do now is that we create the EDataTypes in their appropriate
package structure in a sub package "unresolved" which works perfectly for
us. Do you see any problems with that?
Thanks again, cheers, Tobias
|
|
|
| Re: Creation of DataType references to existing classes [message #414622 is a reply to message #414620] |
Thu, 15 November 2007 15:25 |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Tobias,
That seems fine too. Typically we just put the data types in the same
package as were they are used since their only impact on the XyzPackage
and the XyzFactoryImpl.
Tobias Langner wrote:
> Ed,
> thanks for your quick reply.
>
>> You should just be able to define an EDataType to wrap
>> java.sql.SQLException.
> That is what we were doing :)
>
>> It sounds like maybe you are trying to model it as an class in its own
> package > which would result in an EClass that will be generated.
> No no, we create EDataType instances with appropriate
> instanceClassNames set. Our mistake probably was, that we created this
> EDataTypes in an EPackage structure corresponding to the package
> structure of the referenced java type. For example, the EDataType for
> "Exception" was created in the EPackage "lang" in the EPackage "java".
> When we then tried to generate code from our imported model, we got
> several syntax errors, mostly referring to illegal exports of "java.*"
> in MANIFEST.MF. Apart from that, we wondered why there was generated
> code for the package "java.lang" because we only wanted to reference
> the type "Exception" without actually creating code for (since it
> obviously already exists).
>
> What we do now is that we create the EDataTypes in their appropriate
> package structure in a sub package "unresolved" which works perfectly
> for us. Do you see any problems with that?
>
> Thanks again, cheers, Tobias
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Creation of DataType references to existing classes [message #414626 is a reply to message #414623] |
Thu, 15 November 2007 15:45 |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Tobias,
Certainly defining it in a reusable base package makes very good sense.
This does imply a dependency on UnresolvedPackage but if you have lots
of uses of this in different packages that you'd like to keep
independent, it's a good approach. Some might argue that the
EModelElement and the rest of the Ecore model proper should have been
kept in a separate package from all the data types for things like int,
boolean and so on....
Tobias Langner wrote:
> Ed,
> maybe I explained things a bit too vague :) Let me just give a brief
> example. We have a class TestClass in package org.eclipse.emf.test
> that somehow references the classes java.sql.SQLException and
> java.lang.Exception. The structure of our model is as follows:
>
> org
> + eclipse
> | + emf
> | | + test
> | | | + Test
>
> unresolved
> + java
> | + lang
> | | + Exception
> | + sql
> | | + SQLException
>
> The advantage using this structure is in my opinion, that the datatype
> is only created once and can be reference from every occurence in the
> same manner. With the method you proposed, it would have to be created
> in every package where it is used, right?
>
> Thanks for your help, keep up the good work, cheers,
>
> Tobias
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Sat Sep 21 16:04:37 GMT 2024
Powered by FUDForum. Page generated in 0.04378 seconds |
] 
Search
Help
Register
Login
Home
