|Re: [mdt-ocl.dev] OCL Pivot Promotion for M5|
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.pivotThis 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
Back to the top