Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-ocl.dev] OCL Pivot Promotion for M5

Hi

There was an obsolete reference. Fix building now.

    Ed

On 02/01/2015 17:25, Adolfo Sanchez-Barbudo Herrera wrote:
Hi,

...
ERROR: org.eclipse.equinox.p2.director code=0 Missing requirement: OCL Examples Markup Model 1.0.0.v20150101-2118 (org.eclipse.ocl.xtext.markup 1.0.0.v20150101-2118) requires 'bundle org.eclipse.ocl.pivot.internal [1.0.0,2.0.0)' but it could not be foun
...

I suggest removing or closing those dummy projects, and review the remaining ones.

Regards,
Adolfo.

On 02/01/2015 16:57, Ed Willink wrote:
Hi

The OCL N-build is available from downloads.

The QVTd N-build had three test fails (on the AS2CS whitespace).

The build links on the PMI:

http://projects.eclipse.org/projects/modeling.mdt.ocl/developer

are ok. It may be better to redirect to the PMI rather than risk stale
duplicates.

     Regards

         Ed

On 02/01/2015 16:33, Adolfo Sanchez-Barbudo Herrera wrote:
Hi Ed,

Could you please publish the last build in the nightly repository ? I
need to access to the new content to verify that the Oomph file I'm
working on works accordingly.

Where are the builds located now, given our very own hudson instance ?
I'll accordingly update the wiki which seems out of date:
https://wiki.eclipse.org/OCL/Dev/Releng/Buckminster#How_to_Publish_a_Build


Regards,
Adolfo.
--
On 02/01/2015 15:34, Ed Willink wrote:
Hi

On 26/12/2014 22:22, Ed Willink wrote:
org.eclipse.ocl.pivot is the public API, vaguely corresponding to
org.eclipse.ocl.examples.domain
org.eclipse.ocl.pivot.internal is the less public API, vaguely
corresponding to org.eclipse.ocl.examples.pivot
This doesn't work realistically for users.

While ...pivot.internal depends on ...library depends on ...pivot seems
to provide a potential for lightweight reuseable interfaces, it is
unnatural.
and it needs a genmodel tweak to put interfaces and implementations in
different plugins.

PivotPackage, PivotFactory have to be in the internal plugin as does
anything else that creates a Pivot object, so in practice use of just
the public API is useful only for readonly analysis/execution of an OCL
AS tree built elsewhere (e.g. by an editor). No creation is un-EMF.

The intent of the lightweight reuseable interfaces has been to provide
polymorphism for code generated code. Originally with those irritating
DomainXXX classes, now with the partitioned model plugins. The most
important customer is UML2 for which a dependency on OCL is very
undesirable, so the lightweight interfaces probably don't help.

CG for UML2 is closed world, i.e. no ability to extend with extra
Complete OCL documents, so for most UML2 functionality it can be just
linear Java; it is only for oclType()/oclIsKindOf() that a partial OCL
type system is needed. Therefore we can have a closed world CG that will
do most of UML2 with an option to either auto-generate a type system
run-time within the generated artefacts or to reference a shared version
from OCL.

So, since the struggle to provide lightweight reuseable interfaces
doesn't work for the most important use case and creates un-EMF
characteristics for normal users, why bother?

...pivot.internal and ...library are therefore merged into ...pivot
giving a single non-UI plugin within which we can distinguish
public/internal functionality using exports/packages names.

---

Next, splitting off UML support so that it is truly optional. As a
minimum this requires a ...pivot.uml plugin. In more detail it needs
extensibility so that derived UML-specific classes are used when UML is
required and so that UML-specific classes are created automatically.

The key to discovering what the user needs is the Resource class (is it
a UMLResource) for which the ASResourceFactoryRegistry has
sensitivities. Just need to make its population be via an extension
point. Thereafter the ASResourceFactoryRegistrycn create an appropriate
deruved AbstractEnvironmentFactory where new methods such as
createMetamodelManager etc can be found. (I have finally corrected the
"MetaModel" spelling error).

Construction flow is now typically

ResourceSet -> OCL -> EnvironmentFactory -> MetamodelManager

---

I've pruned some of the totally dead confusing functionality and made
some other functionality such as Customizable/Adaptable a bit more
plausible. The old Environment class vanishes completely, which is handy
with a new one on the way.

     Regards

         Ed Willink
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5577 / Virus Database: 4257/8854 - Release Date: 01/02/15



_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5577 / Virus Database: 4257/8854 - Release Date: 01/02/15





Back to the top