For checking the package is locked we can use the API pacakge.Element.locked but for model which is also an package doesn't have an element .So how can we check whether the model is locked using automation in EA.
The root package has no lock. You can see that on locking only the views below have the red exclamation mark.
I would not be astonished if you could rename the root package with the API in spite of the security being turned on.
P.S. Yes. Altering the root worked.
P.P.S. Not only via API but also the GUI lets you rename the root package.
Related
Is there a way to make a user created class/package to be read only in Modelica preferably through annotations? Make Modelica class read-only in Dymola gives a Dymola option, I am using OpenModelica and is required to verify a package across its two different versions, since both these versions are editable I am unknowingly making modifications in the older version. Thanks in advance.
I tried to search OpenModelica documentation to see if any OM specific annotations are available. But I couldn't spot them. I am pretty much sure that I have missed it in them, probably used a bad keyword.
In OMEdit there are two ways to open a library: either use "File->System Libraries" or "File->Open Modelica/Library File(s)".
The system libraries only shows packages installed at $HOME/.openmodelica/libraries (on Linux; other path in Windows). These are installed by the package manager or installed there manually. When loading libraries through "File->System Libraries", they are always read-only.
If you load the same library by pointing out the package.mo file, it is opened writable.
You can mark a class read-only in the filesystem by not making the file writable (and if you use a hierarchical file structure instead of the whole library in one file, you can restrict editing to only certain parts in this way).
When loading an encrypted library, it is possible to prevent certain operations on the package using annotations, but editing is always restricted.
I'm trying to learn about Package interfaces and use access.
I have 2 hierarchies of packages
1:
ZAVG_TRAINING-PACKAGE1 containing
...
ZAVG_TRNG_SUBPKG3
2:
ZAVG_TRNGPKG_2_STRUCT_SUBPKG_1 containing
ZAVG_TRAINING_PACKAGE2 containing
ZAVG_TRNGPKG2_SUBKPG_1
In the first hierarchy, all the packages are not main packages.
In the second, the base package is a structure package, the next is a main package and the third is a non-main package.
In ZAVG_TRNG_SUBPKG3 (in the first hierarchy), I have a view ZAVG_V_MARA and a program ZAVG_DELETE_THIS_8. I also have a package interface exposing the program, and no use accesses granted.
My problem is that from a program contained in the package ZAVG_TRNGPKG2_SUBKPG_1 I can access both the objects contained in ZAVG_TRNG_SUBPKG3 with no restrictions.
As far as I see from the documentation, in order for a development object to be visible from packages outside the current package (except the outer package). I should have to add them all to the package interface and also create use accesses for the packages that should be allowed to use that interface.
What am I doing wrong?
As long as you're not planning to build something as complex as, let's say, the Enterprise Core Components, and planning to sell it to hundreds and thousands of anonymous customers who are in the mood of suing you if you change published interfaces, I wouldn't bother with the package access control. I know that doesn't answer your question, but all you'll end up with is a lot of wasted time and no advantages whatsoever. You'll have to tweak the package structure in illogical and really counter-intuitive to get things working.
In your case, there are quite a number of things that could have gone wrong - for example, the system-wide package checking switch might be turned off. Then, you'll have to remember that the checking only ever takes place at design time and never when running the program. Finally, as far as I remember, the check is not performed automatically - you'll have to execute it either manually or using some automated tool.
To manually check the package you can do it from the menu in the ABAP workbench:
Or by right-clicking on the object list:
However, as vwegert said: it is very likely that the package check is just not turned on in your system (I have not worked on a single system that had it turned on).
This is my situation: We have a third party feature in our Eclipse environment. The feature contains several plugins. The plugin contains a bunch of classes. One of the classes contains a bug.
We have been able to find a solution to the bug, so we have a working version of the class with the bug.
Unfortunately this plugin is covered by a 55 page long EULA (by IBM) so I think it's pretty safe to assume that decompiling the jar, exchanging class files, recompiling and distribute is legally out of the question. I'm no legal expert, but I'd guess we cannot tamper with the jar files in any way.
So this means I have a single class file that I want to be loaded instead of a class in a plugin, is this at all possible?
This page suggests using fragments, but this requires modifying the manifest in the plugin.
This question has the same problem as me, but in that case there is access to the source code and he is able to build a plugin.
This blogpost shows how use feature patches, but they require that I'm able to build my own plugin, which I cant since I have just the one class.
I would not try using a fragment. In my experience, the cleanest thing to do would be to use a feature patch. I have successfully used feature patches to do exactly what you are looking to do. It's not simple, but it is robust. You need to do the following.
create a plugin that encapsulates your single class file
create a feature patch that includes your new plugin and that patches the feature that you are targeting.
export your feature patch and create the p2 metadata (to create an update site).
Install into your Eclipse using the install manager
Rejoice!
(optional) Feature patches by default only target a single version of the target feature. So, if the target feature bumps up its version number, the feature patch will silently no longer be applied. However, it is possible to relax the version constraints on the feature patch. This process is described in detail here: http://aniefer.blogspot.com/2009/06/patching-features-part-2.html
More information:
http://aniefer.blogspot.com/2009/06/patching-features-with-p2.html
http://aniefer.blogspot.com/2009/06/patching-features-part-2.html
The benefit of using a feature patch over a fragment is that anyone can install the patch and get the patch working, but things are more difficult with a fragment in that end users must muck with manifests.
So this means I have a single class file that I want to be loaded instead of a class in a plugin, is this at all possible?
Your first sentence is the answer. You can use a fragment, but that requires modifying the manifest in the plugin. Otherwise, Eclipse would have no idea which class to load.
My suggestion is that you write IBM with all of this information, including the patch. IBM should be able to release a maintenance fix which would solve your problem.
In the mean time, you could pursue the fragment option, which would require you to unpack the jar, add your fragment, modify the manifest, and repackage the jar. Whether or not this is legal is beyond my ability to determine.
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
We're still developing a bunch of our application in Clarion 6 Enterprise. I was wondering if anyone knows of a sourcecontrol system that works well with Clarion 6?
I'd be surprised if the standard source control systems weren't just fine, e.g., Subversion. Is there something special about Clarion 6 enterprise?
I believe Rick Martin has tools that allow Clarion to work with subversion and tortise version control systems. They allow you to export the changed procedures to TXA's and import the changes back into the application.
One of the things I like about his system is that when a procedure is checked back into the Source Control System his tools will build a current version of your product so you can verify that the changes don't create compile errors.
The tools are not for sale though. They come with your buying his consulting services.
You're free to rename the modules in Clarion - so you're not bound to the existing generated names.
However that's not the root problem. the root problem is that you don't want to be editing CLW and INC files, you want to be editing the APP file. Otherwise your changes will be lost when the app regenerates.
You can use Subversion, or any other system, with app files - they're just binary files. From a rollback point of view this is fine.
Unfortunately though when you checkout an app you get the whole app. So no one else on the team can work on any other procedures in the app at the same time. If your apps are small then this is no big deal, but if you have a single-app system, or a system comprising of large apps, then it can become a hindrance.
The other disadvantage is that, being a binary file, it's not possible for the version control to merge files together - it's an all-or-nothing situation.
You can also try TDC. It's more than just a VCS for Clarion because you also have a Tracking System.
By the way, TDC is written with Clarion.
Look on Rick Martin presentation it's very useful, but not for sale :(
http://www.clarionlive.com/images/stories/videos/webinar11.wmv