Get package ends with: root import package already

[Damir]

Our company uses customised EABase.eap as template for all projects. It has several predefined packages. When project starts, those packages are version controled (Subversion). Let's say we have Project A, B and C made from the same template. I want to use A.Package1 and B.Package1 in Project C and I'm going to put them in C.CustomPackage3. by using Get package command I easily start using A.Package1, but when I try to get B.Package1 I get error: root import package already exists in another location' . (conflicting with the A.Package1, I guess GUIDs are the problem). How to solve this? All other projects' packages are being updated daily through ther own projects so breaking links is not an option. what to do? what to do? :-/

[Eve]

What you'll need to do is export one of the packages created with the same guid to XMI.  (If there are references across packages then you'll need to export the entire model)

Import that file, and check "Strip GUID's". This will recreate everything with new guids.  You can now check this into version control.

Anywhere that already had this package will then need to manually remove the package from there model before re-importing it.

It may be a bit harder with nested controlled packages, but it should still work.

[Damir]

thanks
but that probably means that connectors between elements of such two packages (or re-imported package and other project packages) will be lost. Right?
Damir

[Damir]

Solution would be that EA regenerates GUID-s of existing EABase model elements on creation of new model based on EABase. But then again, that's probably not a good idea for other EA users?

[Damir]

What about "manually" changing GUID?
if Package1 has the same GUID as Package2 which is allready in model, and Package1 as UML element hasn't been used anywhere outside itself (I guess maybe in relationships with elements contained in it), then - IF I make a simple find and replace of its GUID in its xml (I put some other GUID), it should do the trick without loosing conectors of its elements with other elements from other packages.
right?

[Eve]

Yes, what I suggested would lose links across exported packages, which is why I suggested exporting at the root level.  If you can't do that (ie. multiple root nodes) maybe you could temporarily move things into one root node.

Manually changing guids could also work, but is more error prone.

[Damir]

Hm, Ok, we'll fix this somehow.
What would be the right solution for the future not to have such situation? (except requesting teams to manually create initial packages with standarised names etc.) Is it somehow possible to add/change models offered by Model Wizard when new project is started or to fire up some script on project creation that would generate initial structure with new guids?
Thanks!

[Eve]

I think that a good idea would be starting off with a controlled package.  This could then be added to all models necessary and updated easily when it changes.

[Damir]

I think we're not on the same track. Let's describe this in UML terms :
If project template is class model, then I need to use object instances of that class model in different object models. I don't need to use classes from that model in different object models.
In other words I have packages A, B, C in projects 1, 2, 3. Each package under same name (and seems to be under the same GUID) in different projects has different content. I need to use package with the same name from project 1 in project 2 or 3 or both (and perhaps in some cases vice versa).
Hm

[«Midnight»]

Perhaps patterns? Check the docs.

[Damir]

a good idea, unfortunatelly not successful because of several reasons:

• creating patterns out of packages which have subpackages (of which some of them are controlled) doesn't work
  
• packages we need to create are root packages i.e. view packages (under the project root node) and it is not possible to create diagram under the root node into which pattern would be droped so to create view level packages
  
• we don't need any diagrams at that level even if we could create them there.
  

any other ideas? what about scripting or something?
thanks alot for trying

[Paolo F Cantoni]

Hi Damir,

We've taken a different route.

We are modelling a product that is partly bespoke and partly componentized across a number of projects.

A specific instance of a component may be in one, some or all projects.

We have therefore modelled our package hierarchy along similar lines.

We create controlled packages for each component and mix and match to our heart's content (apart from the XMI transport bugs we've reported ).  If a new project re-uses a component used by a previous project exactly, then the component moves from the specific project to the some hierarchy.  If a slightly different version is required, we import a copy of the original controlled package into the new location and strip the GUIDs to get new ones assigned for that project.

We to use a basic skeleton, but it is populated with empty versions of the controlled packages.  It merely serves as a place to assemble the project's individual model...

We also can create a consolidated model across all projects for synchronization, patterning and housekeeping purposes...

So far, it's worked well.

HTH,
Paolo

[size=0]©2006 Paolo Cantoni, -Semantica-[/size]

[Damir]

thanks Paolo for detailed answer. close but not close enough: you are using basic skeleton into which you put new packages. We need parts of that skeleton (not the component packages) to be imported in other projects. for instance data model from project 1 is being used in project 2. complete data model is supposed to be seen in project 2 whenever it changes. People in project 2 who are working on project 2 data model need to know and use/connect to tables of project 1 data model.
But from your answer I see some kind of not-so-elegant solution: to tell people - ok guys, don't put stuff directly into skeleton packages but ruther into a sub-packages of those packages and then version-control those subpackages.
?
thanks
Damir

[Paolo F Cantoni]

thanks Paolo for detailed answer. close but not close enough: you are using basic skeleton into which you put new packages. We need parts of that skeleton (not the component packages) to be imported in other projects. for instance data model from project 1 is being used in project 2. complete data model is supposed to be seen in project 2 whenever it changes. People in project 2 who are working on project 2 data model need to know and use/connect to tables of project 1 data model.

Actually Damir, that's exactly what we can do...  You just need to break the componentry down into shareable units.  The point about the skeleton is that in our source control system we have upto date packages.  We just import the ones we need and replace the skeleton (empty) versions with the ones from the source control system with the same name and GUID.

But from your answer I see some kind of not-so-elegant solution: to tell people - OK guys, don't put stuff directly into skeleton packages but rather into a sub-packages of those packages and then version-control those sub-packages.
?
thanks
Damir

Well, we don't think the solution is so inelegant...  
Paolo

[Damir]

Dear Paolo,
thanks again. I think the following is the problem: you say " We just import the ones we need and replace the skeleton (empty) versions ". In our case, there is no replacement. In addition to "emtpy skeleton" that gets populated with stuff we need to import parts of such skeleton from other projects, also populated but with diferent stuf. So these two skeletons have same GUID-s which give me headaches at the moment. I've read your answers several times but either I just don't get it or we don't understand each other here .

"Well, we don't think the solution is so inelegant...  " - sorry, I meant - from your solution I see not-so-elegant solution for us. I wasn't refering to your solution as not-elegant

?
Damir