I’m currently trying to implement a plug-in for Visual Paradigm that allows committing .vpp files to a Git repository. I have accomplished this through VB.NET, however I need details of what changes were made in each revision. Would this be at all possible?
Even if a report was generated with changes between revisions that would work just as well. My client is very clear about using Visual Paradigm and Git and being able to have exactly what changes were made in the models.
Thanks for your post. We are sorry that our OpenAPI does not support comparing revisions.
I recommend you use our Teamwork Server for merging works on same project from different users. Our Teamwork Server is lightweight and it’s easy to administer and manage. Teamwork Server can be run on Windows, Linux, Mac OS X and Unix.
You can make use of our Teamwork Server for versionning, branching and tagging of project, it also supports conflicts detection and resolution during project commit. More details about Teamwork Server can be found from:
Thank you for your reply. I have already investigated using Teamwork Server as a helpful version tracking tool, however like most repositories it requires that a file must be Checked out/in (centralized). Git (distributed) allows a local copy of the repository on each of the user’s computers and the file(s) can be “pushed” back for everyone to use. I noticed that CVS, Subversion, and Perforce are supported under Teamwork Client… Is there any chance Git will be supported in the near future? I feel that setting up two version tracking tools is somewhat redundant.
Thanks for replying. We are sorry that currently there is no plan to support Git.
By Teamwork Server (or CVS, Subversion and Perforce), you need to checkout the project from server, which is actually copying the project from server to your local computer for modification. Each user will have their own local copy of project.
And when you want to commit changes in project to server, you just need to commit the project to server. Once the changes is committed to the server to merge with the latest revision of project in server, other users can get the changes from server by project update or after committed project to server (commit project to server will update user’s local copy as well).
Lillian, I find your logic flawed here in that the OPs workflow is distributed and you gave him a centralized solution. VP does have visual diff which can work for a distributed solution. I think it would be beneficial to have an API for such control. Look at the uptake on development platforms such as Eclipse that have specific APIs that have allowed for plugins to be created by the community for ALL version control systems.
In the end, I would think it would produce a higher revenue stream than trying to have everyone buy into Teamwork Server; How many people use Visual Source Safe compared to SVN, Hg, Git, and Bzr?
Thank you for your post. We will provide API for executing teamwork operations, but I am unable to give you an exact time frame as we are still planning. But once it get done, or have any news, I will let you know by posting a reply under this thread. Should you have other suggestions, please feel free to let us know.
After my last post I continued to use VB.NET until I hit a roadblock. After investigating the Open API provided on the online javadocs website it seemed as though the solution was not possible. I did not even think to open the openapi.jar to check if there was discrepancies between the two. luckily I found http://forums.visual-paradigm.com/posts/list/5242.html and I did more investigating. It turns out that because you can programatically open vpp files (not shown on the javadocs website) you can gather model elements, diagrams, and diagram elements. With these you can compare one file (using each unique ID) to another for changes in each of these categories. With using the Git binaries and Visual Paradigm I have made customized detailed commit messages stating whether a vpp file has had content added, deleted or changed. The only question that I have is if there would be a way to automatically store ALL of the properties/get methods for model/diagram element(s) into a String array so that I do not have to create an index for each property in a String array programtically.
I was curious if these teamwork functions would contain methods that I have described. Also are there any properties/get methods for model/diagram elements that are not in the open api? If so, is there any possibility of them being available in the near future?
Hello Lillian or any Visual Paradigm Customer Service Representative,
Has there been any update to the status of any of the issues brought up in this post? I know you said you would post once you had any updates. 3 months have passed with no update regarding any issue in this post.
Currently we do not support generate properties into array, but we do have a method for generate the properties into a string (model.toPropertiesString()), you can then token the property string and store in your preferred format. Do you think this help?
That may actually be exactly what I’m looking for. Before I start testing, do you know a delimiter within the string that I can split or tokenize the results? Also, is there a header for each property in the String? The reason I ask this is if I make the variable dynamic (in the sense that it will accomodate new properties as they get populated/added to the method but header information will remain static), it may defy the point of me trying to accomodate dynamic properties.
@MichaelLantz did you ever finish a plugin? I have some developers here looking at Enterprise Architect as an alternative to VP because there is a separate app called LemonTree which allows EA to work with GIT.
I don’t think they would be satisfied with using a standalone repository, because that is essentially what we have with teamwork server. When they create a feature branch in Git, they are hoping to revise the software code and the VP model itself in the same repository, of course using different tools. This will allow them to ensure that the design for any version of software is tightly coupled with that version of the software.
I do think they would accept a solution that excludes the ability the branch/merge within VP itself (external diff/merge), or alternatively, they would accept some other creative limitations. For example, if VP models could only live in a certain location in every branch of the repository and VP could merge/detect conflicts between versions of that specific folder, but every other difference (outside the designated folder) could be ignored.
I’m not sure what a practical solution looks like given the constraints you guys are dealing with. Glad to explore that with you though.