Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 365487 - UML 2.4.1 UML.merged.uml breaks OCL build
Summary: UML 2.4.1 UML.merged.uml breaks OCL build
Status: RESOLVED DUPLICATE of bug 364419
Alias: None
Product: MDT.UML2
Classification: Modeling
Component: Core (show other bugs)
Version: 3.2.0   Edit
Hardware: PC Windows Vista
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: UML2 Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 365520
  Show dependency tree
 
Reported: 2011-12-02 15:55 EST by Ed Willink CLA
Modified: 2011-12-05 13:02 EST (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Willink CLA 2011-12-02 15:55:58 EST 
UML.merged.uml has changed its namespace without providing a mechanism for clients to track the required registrations. Consequently OCL is unable to load it for JUnit tests (https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-core-3.2-master/497/).

An initialisation routine is needed to insulate clients from project evolution.
Comment 1 Kenn Hussey CLA 2011-12-05 11:29:13 EST 
This is a development artifact that isn't intended to be consumed by clients... If clients choose to depend on it (and establish a means of loading it), then I'm afraid they will need to deal with the consequences of changes that occur during development.

That being said, what kind of initialization routine would you expect to be provided? One for stand-alone (i.e., per bug 364419)?
Comment 2 Ed Willink CLA 2011-12-05 11:54:23 EST 
UML.merged.uml is indeed a private artefact, but OCL uses it as just a convenient UML file. The extreme difficulties I have in getting UML models to load standalone is indicative of the problems that many other users may encounter.

As a user, I would like to be able to do:

ResourceSet resourceSet = new ResourceSetImpl();    // or null for global.
PlatformInit.init(resourceSet);
EMFInit.init(resourceSet);
EMFGenModelInit.init(resourceSet);
UMLInit.init(resourceSet);
UMLGenModelInit.init(resourceSet);
OCLInit.init(resourceSet);

and not need to worry if OCLInit helpfully calls UMLInit which calls EMFInit and not need to worry about whether the above code is plugin or standalone.

ProjectMap.initializeResourceSet() is getting close to PlatformInit.
Bug 364419 contribution is heading towards UMLInit.
OCL.initialize is a poor approximation of OCLInit.

So yes this is probably a duplicate of Bug 364419; just a stronger motivation.

The five or six different dimensions of initialization in the Bug 364419 contribution are indicative of the complexities that could be hidden from the user.
Comment 3 Kenn Hussey CLA 2011-12-05 13:02:21 EST 
I like the idea of one initialization routine (preferably on UMLUtil) that could be used regardless of whether the application is running stand-alone. Let's work together to see if we can't iron something out in time for M5.

*** This bug has been marked as a duplicate of bug 364419 ***