I am trying to take a copy of the XMI files for an Enterprise Architect model and then import them into a new EA project. The "Bulk Import" option doesn't seem to do what is says on the tin.
By figuring out now the package hierarchy is mapped into the EA xml files I could do this by importing the one file at at time starting from the root package, but this is implausibly time-consuming given the number of files involved. I have tried using the "ImportPackageXMI" method on the API to automate the manual approach, but this requires the parent package GUID to be known. For the root package(s) the parent is a "Model", which is created in the new EAP (maybe it has a GUID - but not that I can figure out) and there seems no simple way of recreating the package hierarchy in any case. (I was hoping that if I imported the xmi files - using a specially created root package - then EA would work out the package structure somehow, but this was not the case!)
This seems like it should be a trivial task that should be directly supported from the tool: export model, then import model. Maybe I'm missing something or there is a simple solution for this?
For clarity, I'm using the Desktop Edition (so no scripting available).
My actual goal was to create a copy of project (EAP) that was not associated with any source control settings : my attempts via export/import of the xml it seems was not the best way to achieve this!
A simple way I have found to is to create a new (project) EAP and then open the original EAP in another window (by clicking on the EAP file in Windows explorer). Once this is done the top level packages from a model in the original can simply be copied and then pasted - using the standard shortcuts - into a model in the new EAP, which is not associated with the original source settings. Hence new source control settings can be applied and the model controlled by a new source control technology.
You could simplify this task by using Project/Data Management/Project Transfer. This way a complete copy is done, which also includes the so-called reference data. XMI does only ex-/import elements and connectors (not for example image data, glossary, etc.).
The right way to do that is firstly create a Controlled Model Branch
Then you can Import this Model Branch and it will reconstruct your complete model (branch) from all the xmi files involved.
Related
I programmatically generated an XML format .bpmn file with no BPMN Diagram elements. I want to use Eclipse BPMN2 Modeler to generate the diagram elements automatically for me. But when I open the file using the Eclipse Bpmn2 Diagram Editor, it only shows me empty pools with nothing in it. I cannot see any detail of my processes.
Could anyone tell me why it is so and how to fix the problem to make it display all the information of my processes?
Due to character number limit, I cannot paste my bpmn file here
Below is the link for you to download my original bpmn xml file and the wrongly generated picture:
https://drive.google.com/drive/folders/1_A_UydpVTsUYPbZT0zHazegLVc4ihGbI?usp=sharing
Thank you!
Your BPMN is not valid.
I tried to load it into an online BPMN editor at https://demo.bpmn.io/
, But below is the error.
I suggest to validate your BPMN manually or try to add some tasks to your process and re-try.
Update:
As per the official docs of Eclipse BPMN2 Modeler, this feature is NOT stable.
BPMN2 Modeler has the ability to import files that do not contain DI
metadata and will generate it using an auto layout algorithm. This
algorithm is still in the experimental phase as of this version – it
does a fair, but not optimal job of arranging the business logic
elements. If, after importing such a BPMN file, any elements that
appear “out of place” or not optimally placed can simply be dragged
around on the canvas for more visually pleasing configurations. Once
these changes have been saved, the DI metadata is added to the file
and the new layout is restored next time the file is opened.
In Enterprise Architect 10 I removed much of packages from the model (actually there was some large JAR imported by mistake) but the EAP file is still as large as before removal. Seems like EA stores a sort of history or controls versions. Is there a way of removing those in order to get the EAP file storing only the actual model?
Try accessing the following menu before saving the file:
Tools -> Data Management -> Manage .EAP File -> Compact .EAP File
In case the file is still big you may check whether elements on the Project Browser are used or not by pressing Ctrl + U on each selected element. You can also refer to this question & answer.
Export your model as XMI then import to the new project.
Just stumbled upon this question today:
"Is there a way to know that MPP published to the project server is not created using a template available on the server?"
Basically this comes from the point that how to find out compliance of the project plans to the standard templates.
I am not aware how it can be done?
Actually there is no way to identify by one field that this project was created using that template.
You may assume that by Enterprise Project Type, but again there is a way to change EPT for existing project.
The only way I know is to compare a template and a project by tasks, by structure, etc. it works like finger print recognition: you select several points which the most probably tell that the project was created from the template.
The worst case I can imagine: a user creates a project by a template and after that removes everything from the project. Formally the project was created by the template but in real there is nothing from the template left in the project.
For my current project, every time I set up a new workspace, I need to import hundreds of existing projects scattered in 20+ different directories. Is there a way to automate this step in Eclipse?
These projects are all checked into ClearCase.
This answer shows how to import an arbitrary set of projects into Eclipse using a custom plugin.
If I understand your question correctly, you would simply need to specify the paths of all the projects to import in the newprojects.txt file in the workspace root. You may want to remove the part that deletes existing projects though.
Could you import them all into a SCCS and then check them out all at once? You might try this as an experiment using cvs, not because you want to start using cvs in 2009, but because it has the best Eclipse support. If cvs can't do it, the others probably can't either.
For snapshot views, we have a "template" workspace which reference the .project and .classpath files in a "standard" way:
c:\ccviews\projectA\vob1\path\...
c:\ccviews\projectB\vob1\path\...
c:\ccviews\projectC\vob2\path\...
So by copying that workspace, we are able to quickly setup the projects for a new member of the team.
Each colleague will define their own snapshot views with:
a unique name (
colleague1_projectA_snap,
colleague1_projectB_snap,
...)
the same root directory for each view referring to a given project
(c:\ccviews\projectA for:
colleague1_projectA_snap or
colleague2_projectA_snap or
colleague3_projectA_snap...)
Since a snapshot view can be located anywhere you like on your disk, you can:
define a standard path
scale that to a large number of snapshot views.
Of course, that would not be possible with dynamic views, since their paths would by:
m:\aUniqueName\vob1\path
You could ask for each user to associate a view to a drive letter, but that do not scale for a large number of views.
Anyway, dynamic views are great for accessing and consulting data, not for compilation (the time needed to access any large jar or dll through the network is just too important)
Eclipse as the concept of project sets, but I'm pretty sure that's tied to using CVS. My team used this feature and it's how we shared the set of projects between us.
Another 2 alternatives I know of:
Buckminster
It's an Eclipse project which does component assembly, and one part of that is projects. Documentation was a bit crappy last time I played with it, but it does work. No idea if they have support for ClearCase, though it is extensible.
Jazz
Costs money and is also built on Eclipse. Covers similar ground to Buckminster but goes a whole lot further in team-orientated stuff.
I have created some scripts to do this for SVN. Currently, the scripts are run from Vagrant, but you could run them standalone. The process for clearcase should be similar.
See the answer here, which provides links to the source code: https://stackoverflow.com/a/21229397/1033422
My client is migrating from Source Safe to Clearcase. They need to list all the link files in the Source Safe database so the links can be carried over to Clearcase, as apparently all the source must be checked into Clearcase on day 1, losing any existing links.
Are there any tools for creating this report, or perhaps even doing the full import into clearcase ?
My plan is to write a powershell script to recurse Source Safe the SS folders, findings links using COM.
Thanks.
As I have mentioned in this question, clearexport_ssafe should be used for import from Source Safe to ClearCase.
However, the documentation for that tool explicitly mentions:
Shares. There is no feature in Rational ClearCase equivalent to a Visual SourceSafe share. clearexport_ssafe does not preserve shares as hard links during conversion. Instead, shares become separate elements
So your script would need to list all links, and create soft links between their initial directory and the newly created separate element.
But I believe you may want to consider another organization for the target ClearCase repository, one in which all share files are no longer directly used, as illustrated by this answer (for SVN repository in this instance):
We have eliminated all of our linked files. All class files that were previously linked have been placed into class libraries which are shared to our other projects as shared project references in the solution. So in essence you share libraries, not class files.
There was a bit of an adjustment process getting used to this, but I haven't missed links since then. It really does promote a better design practice by having your code setup like this.
I work mainly with UCM, and all those "share" are natural candidate for UCM component, with UCM baselines to refer to their different version, and you can then make your own "configuration" (list of labels) in order to select the different components you need, making them easily reusable across projects.
As VonC mentioned, the import from VSS to ClearCase is truly atrocious as:
The export/import takes forever to complete, so much so we open a PMR against IBM for it (that didn't help, btw)
The Source Safe shares are transformed into files, which is creating duplicates all over the place (the horror !).
I work on ClearCase UCM myself, and we took the same decision as you (which, in my 10 years of experience in CM, is ALWAYS the best decision): leave the history behind for reference and import at most a couple of versions one on top of the others, by hand (like current in development ; current in test ; current in live).
The way we solved the shares' problem is as follow:
The "shares" where isolated from the source-tree, to be imported independantly from the other sources
The other sources where imported (without the history and without the shares) from scratch. Let say in a component called MAIN_SRC
The shares where imported (without the history) from scratch. Let say in a component called SHARE_SRC
A project was created containing both components: MAIN___SRC, and SHARE_SRC.
Now, the problem is not solved because your shares are living aside your main source code, when your IDE (e.g. Visual Studio) fully expects them to be in the same folders they were before (i.e. in Visual all your projects become wrong if you don't solve this issue, and all the files would need to be relinked from within Visual itself, etc... A lot of work).
This is resolved by using ClearCase VOB symbolic links:
Let says in MAIN___SRC you need to use a file called myShared file in SHARE_SRC.
From within the folder needing to use the myShared file, use the command line interface and run:
cleartool ln -s ..\..\SHARE_SRC\(myPath)\mySharedFile .
You need as many ..\.. as necessary to go up to the component folder level in ClearCase, and then down following your path (myPath) in the SHARE_SRC component folder.
Remember the ClearCase path is composed of:
M:\View_name\VOB_name\Component_name\Your first level of files and folders
( VOB_name\Component_name is the "root" of the component, apart if you have single component VOB, in this case VOB_name\Component_name becomes just VOB_name)
The easiest way is to have a mapping of all the VOB symbolic links that need to be created, and put all necessary "cleartool ln -s" command lines in a script to run once.
After that, you should be fine, and your IDE think the sources are where they used to be.
Cheers,
Thomas