Bob's example is likely a separate problem. Please file a bug report
so it doesn't get lost. All new elements get created in the user
project's extent, but currently buildAssociation arbitrarily picks the
"from" end's namespace to place the new Association in. When it tries
to add an element from one extent to the composition
Namespace.ownedElements in the other extent, the closure violation is
thrown. The buildAssociation method needs to be made aware of
read-only extents and try the other end's namespace if it finds its
first choice is read-only. There are likely other similar places in
the Model subsystem.
If we really want to be serious about preventing modifications to the
profile, I should probably re-enable the veto code which is currently
commented out. I'm sure there are many ways to create elements in the
profile indirectly.
I found an Eclipse launch definition for the C++ tests, so I didn't
need to resort to Linus' suggestion of renaming directories. At first
glance I'd say that the tests are probably creating multiple projects
(and associated extents) and not being careful to keep all related
elements in the same project (ArgoUML still has lots and lots of
places that assume a single project, so it probably should only be
using a single project for now). I can improve buildClass(element) so
that it creates the new Class in the same extent as target (instead of
the default extent as it does now), which may help, but probably won't
fix the root cause.
Tom
On Sat, Aug 2, 2008 at 8:03 AM, Bob Tarling <[EMAIL PROTECTED]> wrote:
> I've just seen this in standard ArgoUML
>
> Drag a class from java profile to a diagram.
>
> Add a new class to the diagram
>
> Draw an association from the profile class to the new class - BOOM!
>
> Draw the assoication in the opposite direction and all is fine.
>
> Bob.
>
>
> 2008/8/1 Tom Morris <[EMAIL PROTECTED]>:
>> I can't seem to run the command line Ant based tests using the Eclipse
>> project directory layout. Is this expected to work? I really don't
>> want to have to check out an entirely new source tree just to test
>> this.
>>
>> Tom
>>
>> On Fri, Aug 1, 2008 at 10:59 AM, Tom Morris <[EMAIL PROTECTED]> wrote:
>>> As a guess, without looking at the code, I'd speculate that you're
>>> trying to put an element from one extent into a namespace in another
>>> extent which is likely legal in MDR (I presume compositions need to be
>>> resolved entirely within a single extent).
>>>
>>> You probably want to review your code to make sure that the
>>> assumptions that it's making about user models, profile models, and
>>> projects are valid. I'll try and have a look in a little while if
>>> you're still stuck.
>>>
>>> Tom
>>>
>>> On Fri, Aug 1, 2008 at 5:38 AM, Luis Sergio Oliveira <[EMAIL PROTECTED]>
>>> wrote:
>>>> Hi,
>>>>
>>>> recently (I think that after the changes related to extents in MDR) I have
>>>> some errors while executing the C++ module automated tests.
>>>>
>>>> Some of the tests fail, others don't. I have some tests that are executed
>>>> without errors consistently because (AFAIK) they are part of a certain
>>>> TestCase class (for instance TestPersistencyWithNormalProfileCpp). An
>>>> example where there are errors is in some of the fixtures of
>>>> TestCppFileGeneration like the one bellow. Here I thought that this was
>>>> caused by creating a class not contained in a model by using
>>>> Model.getCoreFactory().buildClass("AClass"), but, after changing it, the
>>>> exception just kicked in sooner!
>>>>
>>>> javax.jmi.reflect.ClosureViolationException
>>>> at
>>>> org.netbeans.mdr.storagemodel.StorableObject.setComposite(StorableObject.java:279)
>>>> at
>>>> org.netbeans.mdr.storagemodel.AssocEndIndexSet.add(AssocEndIndexSet.java:150)
>>>> at
>>>> org.netbeans.mdr.storagemodel.StorableAssociation.addLink(StorableAssociation.java:370)
>>>> at
>>>> org.netbeans.mdr.handlers.AssociationHandler._handleLocalAdd(AssociationHandler.java:161)
>>>> at
>>>> org.netbeans.mdr.handlers.AssociationHandler._handleAdd(AssociationHandler.java:150)
>>>> at org.omg.uml.foundation.core.ANamespaceOwnedElement$Impl.add(Unknown
>>>> Source)
>>>> at org.omg.uml.foundation.core.ANamespaceOwnedElement$Impl._add(Unknown
>>>> Source)
>>>> at
>>>> org.netbeans.mdr.handlers.InstanceHandler._handleSetR(InstanceHandler.java:149)
>>>> at org.omg.uml.modelmanagement.UmlPackage$Impl.setNamespace(Unknown
>>>> Source)
>>>> at
>>>> org.argouml.model.mdr.CoreHelperMDRImpl.setNamespace(CoreHelperMDRImpl.java:2929)
>>>> at
>>>> org.argouml.model.AbstractCoreHelperDecorator.setNamespace(AbstractCoreHelperDecorator.java:502)
>>>> at
>>>> org.argouml.model.mdr.UndoCoreHelperDecorator.setNamespace(UndoCoreHelperDecorator.java:704)
>>>> at
>>>> org.argouml.language.cpp.generator.TestCppFileGeneration.setUpNamespaces(TestCppFileGeneration.java:304)
>>>> at
>>>> org.argouml.language.cpp.generator.TestCppFileGeneration.testLocalIncludes(TestCppFileGeneration.java:403)
>>>> (...) --> Eclipse and JUnit part of the stack trace.
>>>>
>>>> Regards,
>>>>
>>>> Luís
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
