| Moving class to a sub-package and synchronizing [message #1506229] |
Wed, 10 December 2014 17:39  |
 Ernesto Posse
Messages: 438
Registered: March 2011 |
Senior Member |
|
|
I noticed the following behaviour:
If I have a model with base package p1, and (top-level) class A and a subpackage p2 and move A into p2, the .ecore and .genmodel files get updated correctly, and when I generate code from the .genmodel, then I obtain interface A inside p1.p2 and class AImpl inside p1.p2.impl as expected, but interface A and class AImpl are not removed from the top-level package p1.
Is this behaviour expected or is it a bug? It seems to be a bug, since the package reference to A gets removed from p1, the remaining class AImpl in p1 contains a compilation error:
Description Resource Path Location Type
A cannot be resolved or is not a field AImpl.java /eposse.experiments.ecoretools.ecttest/src/ecttest/impl line 36 Java Problem
I haven't found any reported bugs or forum messages describing this.
Also I noticed that whenever I'm creating a new class, the first time I generate code with that class I get an exception from Sirius:
Unable to load the resouce /.../p1/A.java
Unable to load the resouce /.../p1/impl/AImpl.java
It doesn't seem to have any adverse effects, but should this error be produced?
|
|
|
| Re: Moving class to a sub-package and synchronizing [message #1506364 is a reply to message #1506229] |
Wed, 10 December 2014 20:13  |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Ernesto,
Comments below.
On 10/12/2014 6:39 PM, Ernesto Posse wrote:
> I noticed the following behaviour:
>
> If I have a model with base package p1,
You should note I have many times described nested packages as syntactic
rat poison. If there were one thing I could still remove from Ecore
that would be it...
> and (top-level) class A and a subpackage p2 and move A into p2, the
> .ecore and .genmodel files get updated correctly, and when I generate
> code from the .genmodel, then I obtain interface A inside p1.p2 and
> class AImpl inside p1.p2.impl as expected, but interface A and class
> AImpl are not removed from the top-level package p1.
No generated file is ever removed. It may contain important
documentation or method implementations that you'd be upset to loose.
> Is this behaviour expected or is it a bug?
It's expected. There's no historical knowledge about what's been
generated in the past. So if you rename something the files with the
old name will continue to exist. With Ecore, you should generally do
any important Java refactoring before regenerating.
> It seems to be a bug, since the package reference to A gets removed
> from p1, the remaining class AImpl in p1 contains a compilation error:
>
> Description Resource Path Location Type
> A cannot be resolved or is not a field AImpl.java
> /eposse.experiments.ecoretools.ecttest/src/ecttest/impl line 36
> Java Problem
There are dozens of ways to end up with this type of problem. Without
historical knowledge there's no knowledge about what might need to be
cleaned up.
Note that Xcore supports much nicer refactoring to avoid these kinds of
things, but it does not support nested packages; that's just a mistake I
won't repeat.
>
> I haven't found any reported bugs or forum messages describing this.
It's not specific to your moving between packages example.
>
> Also I noticed that whenever I'm creating a new class, the first time
> I generate code with that class I get an exception from Sirius:
>
> Unable to load the resouce /.../p1/A.java
> Unable to load the resouce /.../p1/impl/AImpl.java
I can't comment on what Sirius is doing....
>
> It doesn't seem to have any adverse effects, but should this error be
> produced?
Perhaps these are exceptions that result from the files compiling with
errors, and of course you should delete the files. I don't think the
exceptions are really appropriate though so perhaps you want to report
that and see what the Sirius folks think.
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
Powered by
FUDForum. Page generated in 0.02054 seconds
] 
Search
Help
Register
Login
Home
