Home » Modeling » UML2 » How to upgrade version of applied profile
| |
Re: How to upgrade version of applied profile [message #471660 is a reply to message #471658] |
Mon, 19 March 2007 15:11 |
Dave Carlson Messages: 402 Registered: July 2009 |
Senior Member |
|
|
Kenn Hussey wrote:
> Dave,
>
> Yes, just reapply the profile and the data should be automatically
migrated.
>
Thanks, Kenn. This works, and raises another question. In my profile,
I modified a stereotype that previously extended Classifier, so that it
instead extends both Class and DataType. The reason is that UML editors
(e.g. RSA 7) offer the stereotype on too many other Classifiers where it
is not applicable. This change causes a NullPointerException when
migrating a model from the previous version of the profile (the
base_Classifier eReference is missing). I expected this to be OK
because the base_Class and base_DataType properties in the new
Stereotype version are filled when the stereotype is created.
This raises a question about the expected/desirable behavior when
migrating to a new profile version. Should properties removed from the
stereotype be silently ignored when copying data to the new stereotype,
instead of throwing NPE?
More specifically, it is unnecessary to copy any of the base_*
references to the new stereotype. Is the "base_" prefix reserved so
that it can be reliably tested? I tried the following modification to
PackageOperations.StereotypeApplicationCopier and it fixes the above
error, the migrated profile with modified metaclass extension looks
good. Could this change be included?
protected void copyReference(EReference eReference, EObject eObject,
EObject copyEObject) {
// TODO modified
if (eReference.getName().startsWith("base_"))
return;
Thanks,
Dave
|
|
|
Re: How to upgrade version of applied profile [message #471726 is a reply to message #471660] |
Mon, 19 March 2007 17:31 |
Kenn Hussey Messages: 1620 Registered: July 2009 |
Senior Member |
|
|
Dave,
Deleted references are "ignored" (the exception is not propagated), but the
exception is logged to indicate that data may have been lost. Although in
this case, as you point out, data hasn't really been lost, I'd rather keep
the implementation generic for now. Note that we'll be revisiting profile
migration as part of https://bugs.eclipse.org/bugs/show_bug.cgi?id=163556;
perhaps you could add a comment to that bug so that we also revisit how
potentially "lost" data is reported (or not).
Kenn
"Dave Carlson" <dcarlson@xmlmodeling.com> wrote in message
news:etm963$jmm$1@utils.eclipse.org...
> Kenn Hussey wrote:
> > Dave,
> >
> > Yes, just reapply the profile and the data should be automatically
> migrated.
> >
>
> Thanks, Kenn. This works, and raises another question. In my profile, I
> modified a stereotype that previously extended Classifier, so that it
> instead extends both Class and DataType. The reason is that UML editors
> (e.g. RSA 7) offer the stereotype on too many other Classifiers where it
> is not applicable. This change causes a NullPointerException when
> migrating a model from the previous version of the profile (the
> base_Classifier eReference is missing). I expected this to be OK because
> the base_Class and base_DataType properties in the new Stereotype version
> are filled when the stereotype is created.
>
> This raises a question about the expected/desirable behavior when
> migrating to a new profile version. Should properties removed from the
> stereotype be silently ignored when copying data to the new stereotype,
> instead of throwing NPE?
>
> More specifically, it is unnecessary to copy any of the base_* references
> to the new stereotype. Is the "base_" prefix reserved so that it can be
> reliably tested? I tried the following modification to
> PackageOperations.StereotypeApplicationCopier and it fixes the above
> error, the migrated profile with modified metaclass extension looks good.
> Could this change be included?
>
> protected void copyReference(EReference eReference, EObject eObject,
> EObject copyEObject) {
>
> // TODO modified
> if (eReference.getName().startsWith("base_"))
> return;
>
> Thanks,
> Dave
|
|
|
Re: How to upgrade version of applied profile [message #471741 is a reply to message #471726] |
Tue, 20 March 2007 17:45 |
Dave Carlson Messages: 402 Registered: July 2009 |
Senior Member |
|
|
Kenn,
Ah, I was running in debugger so hit a breakpoint for each
NullPointerException. I did not complete the execution to notice that
all valid references are successfully migrated.
However, it would be very helpful if the log message were more concise
and more helpful than a complete NPE stack trace. E.g. a message:
<stereotype::property> does not exist in profile: <name> version <x>.
I migrated the profile version for a relatively small model, and my log
file contained 340K of completely redundant (and mostly useless) stack
traces for the same null pointer...
Dave
Kenn Hussey wrote:
> Dave,
>
> Deleted references are "ignored" (the exception is not propagated), but the
> exception is logged to indicate that data may have been lost. Although in
> this case, as you point out, data hasn't really been lost, I'd rather keep
> the implementation generic for now. Note that we'll be revisiting profile
> migration as part of https://bugs.eclipse.org/bugs/show_bug.cgi?id=163556;
> perhaps you could add a comment to that bug so that we also revisit how
> potentially "lost" data is reported (or not).
>
> Kenn
>
|
|
| |
Re: How to upgrade version of applied profile [message #599657 is a reply to message #471658] |
Mon, 19 March 2007 15:11 |
Dave Carlson Messages: 402 Registered: July 2009 |
Senior Member |
|
|
Kenn Hussey wrote:
> Dave,
>
> Yes, just reapply the profile and the data should be automatically
migrated.
>
Thanks, Kenn. This works, and raises another question. In my profile,
I modified a stereotype that previously extended Classifier, so that it
instead extends both Class and DataType. The reason is that UML editors
(e.g. RSA 7) offer the stereotype on too many other Classifiers where it
is not applicable. This change causes a NullPointerException when
migrating a model from the previous version of the profile (the
base_Classifier eReference is missing). I expected this to be OK
because the base_Class and base_DataType properties in the new
Stereotype version are filled when the stereotype is created.
This raises a question about the expected/desirable behavior when
migrating to a new profile version. Should properties removed from the
stereotype be silently ignored when copying data to the new stereotype,
instead of throwing NPE?
More specifically, it is unnecessary to copy any of the base_*
references to the new stereotype. Is the "base_" prefix reserved so
that it can be reliably tested? I tried the following modification to
PackageOperations.StereotypeApplicationCopier and it fixes the above
error, the migrated profile with modified metaclass extension looks
good. Could this change be included?
protected void copyReference(EReference eReference, EObject eObject,
EObject copyEObject) {
// TODO modified
if (eReference.getName().startsWith("base_"))
return;
Thanks,
Dave
|
|
|
Re: How to upgrade version of applied profile [message #601780 is a reply to message #471660] |
Mon, 19 March 2007 17:31 |
Kenn Hussey Messages: 1620 Registered: July 2009 |
Senior Member |
|
|
Dave,
Deleted references are "ignored" (the exception is not propagated), but the
exception is logged to indicate that data may have been lost. Although in
this case, as you point out, data hasn't really been lost, I'd rather keep
the implementation generic for now. Note that we'll be revisiting profile
migration as part of https://bugs.eclipse.org/bugs/show_bug.cgi?id=163556;
perhaps you could add a comment to that bug so that we also revisit how
potentially "lost" data is reported (or not).
Kenn
"Dave Carlson" <dcarlson@xmlmodeling.com> wrote in message
news:etm963$jmm$1@utils.eclipse.org...
> Kenn Hussey wrote:
> > Dave,
> >
> > Yes, just reapply the profile and the data should be automatically
> migrated.
> >
>
> Thanks, Kenn. This works, and raises another question. In my profile, I
> modified a stereotype that previously extended Classifier, so that it
> instead extends both Class and DataType. The reason is that UML editors
> (e.g. RSA 7) offer the stereotype on too many other Classifiers where it
> is not applicable. This change causes a NullPointerException when
> migrating a model from the previous version of the profile (the
> base_Classifier eReference is missing). I expected this to be OK because
> the base_Class and base_DataType properties in the new Stereotype version
> are filled when the stereotype is created.
>
> This raises a question about the expected/desirable behavior when
> migrating to a new profile version. Should properties removed from the
> stereotype be silently ignored when copying data to the new stereotype,
> instead of throwing NPE?
>
> More specifically, it is unnecessary to copy any of the base_* references
> to the new stereotype. Is the "base_" prefix reserved so that it can be
> reliably tested? I tried the following modification to
> PackageOperations.StereotypeApplicationCopier and it fixes the above
> error, the migrated profile with modified metaclass extension looks good.
> Could this change be included?
>
> protected void copyReference(EReference eReference, EObject eObject,
> EObject copyEObject) {
>
> // TODO modified
> if (eReference.getName().startsWith("base_"))
> return;
>
> Thanks,
> Dave
|
|
|
Re: How to upgrade version of applied profile [message #601896 is a reply to message #471726] |
Tue, 20 March 2007 17:45 |
Dave Carlson Messages: 402 Registered: July 2009 |
Senior Member |
|
|
Kenn,
Ah, I was running in debugger so hit a breakpoint for each
NullPointerException. I did not complete the execution to notice that
all valid references are successfully migrated.
However, it would be very helpful if the log message were more concise
and more helpful than a complete NPE stack trace. E.g. a message:
<stereotype::property> does not exist in profile: <name> version <x>.
I migrated the profile version for a relatively small model, and my log
file contained 340K of completely redundant (and mostly useless) stack
traces for the same null pointer...
Dave
Kenn Hussey wrote:
> Dave,
>
> Deleted references are "ignored" (the exception is not propagated), but the
> exception is logged to indicate that data may have been lost. Although in
> this case, as you point out, data hasn't really been lost, I'd rather keep
> the implementation generic for now. Note that we'll be revisiting profile
> migration as part of https://bugs.eclipse.org/bugs/show_bug.cgi?id=163556;
> perhaps you could add a comment to that bug so that we also revisit how
> potentially "lost" data is reported (or not).
>
> Kenn
>
|
|
|
Goto Forum:
Current Time: Thu Mar 28 10:29:59 GMT 2024
Powered by FUDForum. Page generated in 0.03487 seconds
|