eclipse-ocl-bot
commented
5 hours ago By Christian Damus on Nov 01, 2008 21:00
The namespace URIs of the standard library packages are now published as OCL_STANDARD_LIBRARY_NS_URI constants in the EcoreEnvironment and UMLEnvironment classes.
The plug-in IDs are not similarly published because I don't think it makes sense, for a few reasons. First, the value of an Eclipse plug-in ID is API, so it doesn't ever change. Therefore, any references to the literal ID are stable. Moreover, the plugin IDs are identical to the root Java package names in these bundles, which names already appear all over the text of client code. Wouldn't it be a bit like doing this:
Package.getPackage("org.eclipse.ocl.ecore").getName()\
\in client code? It seems somehow a chicken-and-egg thing. Also, it doesn't seem to be common (or at least consistent) in the Eclipse environment to publish these IDs in Java API. In fact, it is usually via the string ID that the Bundle representing a plug-in is retrieved from the Platform in the first place ... I think it is entirely safe (and acceptable) for a client application to define its own constants for these IDs, as they are stable API.
May I ask how it would even be useful in a stand-alone application to use the plug-in ID?
If you feel strongly about this, feel free to re-open the bug, but I'm afraid that the org.eclipse.ocl.ecore plug-in doesn't have a good fit for any class that would declare these constants. The UML plug-in does have an OCLUMLUtil class.
| --- | --- | | Bugzilla Link | 252600 | | Status | CLOSED FIXED | | Importance | P3 enhancement | | Reported | Oct 29, 2008 11:06 EDT | | Modified | Jan 06, 2012 10:31 EDT | | Version | 1.2.0 | | Reporter | Laurent Goubet |
Description
There currently is no way of accessing
without either hard-coding the Strings or accessing discouraged classes. There may be more than these Strings but I didn't need (and couldn't think of) others. Having a "clean" way of accessing all these would be a nice addition (mostly for standalone use).