[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-ocl.dev] MDT/OCL Project Scope
|
Ed,
Apologies for the delayed response.
The scope for the OCL project would have been originally stated in the project proposal which, unfortunately, I've been unable to locate as of yet. However, its purpose has always been to provide a metamodel implementation and _expression_ engine (only); that's why we actually did, at one point, create a separate "OCL Tools" project (which subsequently failed to get through the IP process).
It's OK to have as many examples as you want, but as soon as you start shipping "official" tooling as part of your offering, that's a different story. As I've suggested, if your intention is to broaden the scope of OCL to include exemplary tooling (as opposed to examples), you may well be able to do so, given PMC approval...
Cheers,
Kenn
On Thu, Jun 24, 2010 at 2:30 PM, Ed Willink
<ed@xxxxxxxxxxxxx> wrote:
Hi Kenn
On 24/06/2010 18:27, Kenn Hussey wrote:
Be careful regarding the "Core" vs. "Tools" issue, so that the content you are providing in the project still fits within the project's scope. If it does not, you can either ask the PMC to allow you to change/broaden the scope or create a separate project.
Where is the 'scope' of the MDT/OCL project defined? All the plans and overviews seem to have recently written content that has evolved.
Perhaps the creep from meta-model to meta-model+tools occurred when the OCL Console became an example.
We've had a couple of discussions about whether we should have a separate OCL Tools project and broadly concluded that the extra project would just add to the bureaucratic load without solving any real problem. The only advantage of an OCL Tools project was that its content could be overtly 'incubation' rather than 'example', but then as each generation of tools graduates the code has to have an inter rather than intra-project move.
It seems that emulating MWE's multiple builds and so multiple Update Sites satisfactorily resolves the Core being at +1, while editors and such like have much more substantial dependencies at +3. The Helios builds were consistenly one RC back on their Xtext dependencies, since OCL was +1 and Xtext +3.
Regards
Ed Willink
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
