Community
Participate
Working Groups
We are taking advantage of the org.eclipse.ocl.core.sdk feature in our application. The application has used org.eclipse.ocl since Eclipse OCL version 1.0. We used to use org.eclipse.ocl.sdk but in Helios we bring in a XText dependency that we do not want to bring into our application for this release. Everything looks great, except that we are missing the org.eclipse.ocl.doc feature in the core SDK. We are exporting org.eclipse.ocl in our API and included the OCL documentation in previous releases of our application. Would it be possible to include the org.eclipse.ocl.doc to the org.eclipse.ocl.core.sdk feature?
Is there any reason why you can't just add the dic feature to your usage? I can understand that Xtext is very new in Heklios, so you may not need it, however I suspect that Xtext will be widely used in ?Indigo?, and the MDT/OCL editors will be non-example, so I think that dodging Xtext in a with-doc feature is only temporarily relevant. Therefore I'm inclined to WONTFIX. [Bug 289763 remains unresolved if you care to comment there.]
Ed, Anthony, I'm creating some documentation for our wiki to have a clearer idea about all the features we have, how they are organized etc. In principle, I'm inclined to include the doc feature into the Core SDK. IMO, documentation makes really sense in a SDK. Let's wait Alex's opinion to decide this. Cheers, Adolfo.
Hi all, In the absence of general guidelines (other than Anthony's blog ;-) ) specifying what should be in SDK features and what shouldn't be there, we are prone to regularly get requests like this. Some would like to add/remove examples to SDK, others would like to have docs there, some would want editors, source code, etc... The amount of combinations is 2^N, right? We can follow EMF SDK feature which contains docs. But on the other hand, it also contains example installer, which then goes well with our o.e.ocl.all.sdk feature. To sum up, I agree with Ed, I am inclined to WONTFIX... Finally, I'd like to remind that M7 was our feature freeze so now we shouldn't change anything other than related to critical bugs.
Anthony, Two -1 (including PL), so definitely WONTFIXing. BTW, org.eclipse.ocl.all.sdk feature doesn't include examples, so maybe this one is what you need. In case you were using ocl.eclipse.org.master feature (The SDK from the downloads web page), I would reconsider unsing it instead of the buggy Core SDK (https://bugs.eclipse.org/bugs/show_bug.cgi?id=313124). Otherwise, your client would miss the useful "interpreter" example. Any further discussion about MDT/OCL features's organization may be done at https://bugs.eclipse.org/bugs/show_bug.cgi?id=289763, as Ed pointed out. I've recently done an analysis of the current features organization there, and I'v also created a wiki page (waiting for reviewing) which may be found here: http://wiki.eclipse.org/MDT/OCL/Dev/Releng/Features_Organization Cheers, Adolfo.
(In reply to comment #1) > Is there any reason why you can't just add the doc feature to your usage? Unfortunately, one of our product build teams only knows how to consume zip files, and they have an application built on the "old" stuff. So they do not really want the new XText work. Maybe in the future, but not today. We can extract the doc feature out of the existing zip. I will have to talk to Steve and Dusko about this further.
Until recently the MDT/OCL build was using ZIPs, but we were rightly told off by Nick Boldt for using such evil technology. Since switching to repositories many of our intermittent build problems have gone away. (Bug 309900, Bug 308759).
Hi all, I have raised a cross-project request for general guidelines on SDK feature contents and build artifacts in bug 313244.
Closing
