[mdt-ocl.dev] Re: OCL Examples build

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi

[The OCL Examples tests pass on Hudson; but not on my laptop; platform M6 CCE nightmare to investigate]

OCL Examples dependencies will be a recurring problem (imagine an OCL example that uses a QVTo transformation), so we might as well plan a solution.

For Helios, I think we can do without transactions; my distant recollection was that they helped unify Platform and EMF Command, CommandStack, OperationHistory so that Undo worked coherently; we can live with a little imperfection in an example editor.

Long term there are clearly many different layers across modeling projects that rationalize interdependencies

Platform
EMF
UML2
OCL, EMFt, EMFv core
QVTo etc
GMF, EMFq, EMFt, EMFv extras
EMF tools, OCL examples, UML2 tools, ...

EMF, UML2 have already recognised this by having separate EMF, UML2 tools.

[The lack of clear EMFt core(basic re-useable transactions)/EMFt extras(OCL query enhancements) partitioning does not affect this discussion.]

Clearly there should be an OCL tools that is built separately with more extensive dependencies than OCL core.

Dependency issues were overlooked when we considered an OCL Tools project last year.

Helios

Therefore subject to Release Reviews:

We avoid EMFt, EMFv dependency and bundle IMP Runtime in the OCL Examples Feature. This should impose no threat to the buckybuild.

After Helios

We partition OCL between:

Core (the minimum functionality required to allow parsing and evaluation of OCL expressions)
- i.e. just the ocl, ocl.ecore, ocl.uml and possibly ocl.examples.modelregistry plugins.

Tools (the rest - all the edit/editor/interpreter/ui functionality)

Then we have a choice

a) Create a new OCL Tools project (possibly Incubation)

b) Do a double OCL build (OCL Core at +1 and OCL Tools at ?+2)

[The OCL 1.4.0 experience demonstrated that two builds are possible; OCL Tools would have completely different names and so provide no conflict.]

I favour a) since the hassle of two projects is very obvious, whereas imperfect manual/automated orchestration of double builds may cause complex problems.

    Regards

        Ed Willink

On 17/03/2010 19:33, Ed Willink wrote:

Hi Alex

I don't think there is any real benefit in the transactional edit domain, so I'm hoping to eleiminate the EMFt and EMFv dependency. I'd hoped to do it at the weekend but time flies. I kept all the multi-page editing that 'needed' transactions in QVTd. Maybe after Helios the OCL dependencies can be migrated.

I'm off tomorrow so may get some stuff done.

    Ed


On 17/03/2010 16:07, Alexander Igdalov wrote:

Hi Ed,

That's great news. However, there's one thing I am worried about - the new
dependencies. We are now having a vicious circle: MDT OCL depends on EMF
Validation & EMF Transaction which in turn depend on MDT OCL.

How are we supposed to build these components? Now MDT OCL will have to
depend on previous versions of EMF Validation & EMF Transaction which is not
generally correct.

Ideas?

Cheers,
- Alex.

-----Original Message-----
From: Ed Willink [mailto:ed@xxxxxxxxxxxxx] 
Sent: Wednesday, March 17, 2010 12:41 PM
To: Alexander Igdalov
Subject: Re: OCL Examples build

Hi Alex

Wow! easier than I expected. A green build with a lot of plausible stuff in
the Update site zip.

Probably ready to add org.eclipse.ocl.examples.tests and generally check
useability and Examples packaging.

All yours (if you want it).

     Ed

On 17/03/2010 08:45, Ed Willink wrote:
  

Hi Alex

I've updated

map file and properties to try to build a full ocl.examples rather 
than limited emf.ocl.examples.

I've kicked off a build, and may have time to do one more before going 
to work.

Feel free to take over.

I know I haven't updated the buildExtra correctly to add the two new 
examples that need zipping.

I suspect that I haven't changed a top feature so nothing happens anyway.

I've deliberately not activated ocl.examples.tests till compile and 
pack works.

buildWindows.properties seem very out of date; perhaps it should be 
deleted.

We're probably ready to strip the old releng project to a 
this-is-obsolete ReadMe.

    Ed