Eclipse Community Forums - RDF feed
https://www.eclipse.org/forums/
Eclipse Community ForumsPosible enhacements in the QVT code
https://www.eclipse.org/forums/index.php/mv/msg/620815/1211634/#msg_1211634
we use QVTo for our stack of model transformations in our products. We historically had to modify some plugins to mainly avoid undesirable dependencies in our products and other issues. I'd like to share this improvements here, looking for a chance to contribute them and finally getting rid of them. Im using the Kepler release, btw.
- org.eclipse.m2m.qvt.oml.emf.util.ui. States depends on Java 1.5, but uses Java 1.6 API. This shows compilations errors when using Java 1.5 compliance in the workspace. Probably the original developer had its workspace improperly setup. Affected classes:
* Line 55, ResourceDesintationChooser.
* Line 64, ResourceSourceChooser.
* Line 38, ResourceSourceDestChooser.
Solution -> replace by String.length() == 0
- org.eclipse.m2m.qvt.oml.emf.util.ui. Dependency on org.eclipse.emf.codegen.ecore.ui. It does not actually depend in any specific API of that bundle, but rather depends in reexports. I'd suggest to change to the actual dependencies, however, that would imply breaking clients (unfortunately, it's reexported). If you're still interested, it should be substituted by:
* org.eclipse.emf.ecore.edit;bundle-version="[2.5.0,3.0.0)",
* org.eclipse.emf.edit.ui;bundle-version="[2.5.0,3.0.0)",
* org.eclipse.ui.ide;bundle-version="[3.5.0,4.0.0)"
- org.eclipse.m2m.qvt.oml.editor.ui. We do not include JDT in our products, but this plugins depends on the JDT API, and makes it mandatory to have the whole JDT feature in our RCP, basically just for icons and a view ID. I understand its not desirable duplicate icons, neither hardcode view IDs, but I'd like to put this out, maybe there are better options. For instance, refactoring those dependencies in a new bundle (org.eclipse.m2m.qvt.oml.editor.jdt.ui).
So thats all. If any of the above sounds reasonable, I could provide some patches.
Best Regards!
Víctor Roldán [Open Canarias]]]>Victor Roldan Betancort2013-11-26T14:45:50-00:00Re: Posible enhacements in the QVT code
https://www.eclipse.org/forums/index.php/mv/msg/620815/1211664/#msg_1211664
http://www76.zippyshare.com/v/12605258/file.html]]>Victor Roldan Betancort2013-11-26T15:04:25-00:00Re: Posible enhacements in the QVT code
https://www.eclipse.org/forums/index.php/mv/msg/620815/1213393/#msg_1213393
QVTo is active again. Please supply patches. A Bugzilla is mandatory for
IP purposes.
On 26/11/2013 15:04, Victor Roldan Betancort wrote:
> As per EPL, here I publish the modified sources.
>
> http://www76.zippyshare.com/v/12605258/file.html]]>Ed Willink2013-11-27T08:10:05-00:00Re: Posible enhacements in the QVT code
https://www.eclipse.org/forums/index.php/mv/msg/620815/1213999/#msg_1213999
Quote:
Hi Victor
QVTo is active again. Please supply patches. A Bugzilla is mandatory for
IP purposes.
good to hear, very much necessary for the modeling ecosystem
Alright, I'll create some bugzillas and submit patches.
Best Regards!
Víctor Roldán [Open Canarias]
]]>Victor Roldan Betancort2013-11-27T13:50:09-00:00Re: Posible enhacements in the QVT code
https://www.eclipse.org/forums/index.php/mv/msg/620815/1214055/#msg_1214055
On 26/11/2013 14:45, Victor Roldan Betancort wrote:
> - org.eclipse.m2m.qvt.oml.emf.util.ui. States depends on Java 1.5, but
> uses Java 1.6 API. This shows compilations errors when using Java 1.5
> compliance in the workspace. Probably the original developer had its
> workspace improperly setup. Affected classes:
> * Line 55, ResourceDesintationChooser.
> * Line 64, ResourceSourceChooser.
> * Line 38, ResourceSourceDestChooser.
> Solution -> replace by String.length() == 0
This was fixed by commit 355aa060932b4bfdca1dbdfe896be02dc177d274 on
2013-07-18 15:59:15
> - org.eclipse.m2m.qvt.oml.emf.util.ui. Dependency on
> org.eclipse.emf.codegen.ecore.ui. It does not actually depend in any
> specific API of that bundle, but rather depends in reexports. I'd
> suggest to change to the actual dependencies, however, that would
> imply breaking clients (unfortunately, it's reexported). If you're
> still interested, it should be substituted by:
> * org.eclipse.emf.ecore.edit;bundle-version="[2.5.0,3.0.0)",
> * org.eclipse.emf.edit.ui;bundle-version="[2.5.0,3.0.0)",
> * org.eclipse.ui.ide;bundle-version="[3.5.0,4.0.0)"
This is trivial; no need for a patch; just a Bugzilla for tracking.
>
> - org.eclipse.m2m.qvt.oml.editor.ui. We do not include JDT in our
> products, but this plugins depends on the JDT API, and makes it
> mandatory to have the whole JDT feature in our RCP, basically just for
> icons and a view ID. I understand its not desirable duplicate icons,
> neither hardcode view IDs, but I'd like to put this out, maybe there
> are better options. For instance, refactoring those dependencies in a
> new bundle (org.eclipse.m2m.qvt.oml.editor.jdt.ui).
QVTo already has image registries. It is probably easy to reuse
something already within QVTo to replace JavaUI.getSharedImages(); e.g.
CompletionProposalUtil.getImage(). If you got a few spare moments you
can see how many other equivalent registries have appeared through
diverse development.
The four *.gif files can then be copied to the local icons folder. No
need for an extra plugin.
Regards
Ed Willink]]>Ed Willink2013-11-27T14:18:58-00:00Re: Posible enhacements in the QVT code
https://www.eclipse.org/forums/index.php/mv/msg/620815/1221912/#msg_1221912
Bug 424359 - Make org.eclipse.m2m.qvt.oml.editor.ui not dependant on JDT https://bugs.eclipse.org/bugs/show_bug.cgi?id=424359
Bug 424358 - Unnecesary transitive dependency at bundle org.eclipse.m2m.qvt.oml.emf.util.ui https://bugs.eclipse.org/bugs/show_bug.cgi?id=424358]]>Victor Roldan Betancort2013-12-18T17:20:41-00:00Re: Posible enhacements in the QVT code
https://www.eclipse.org/forums/index.php/mv/msg/620815/1221995/#msg_1221995
Thank you very much for sharing your knowledge. It's nice to improve QVTo bits in a way which helps to utilize it under different circumstances.
I've committed changes for both bugs. Will be available in next milestone (Eclipse Luna M5, January 31, 2014).
As for JDT dependencies in "org.eclipse.m2m.qvt.oml.emf.util.ui" plug-in there were two icons and one string. Not so much.
Regards,
Sergey Boyko.
]]>Sergey Boyko2013-12-19T09:59:41-00:00Re: Posible enhacements in the QVT code
https://www.eclipse.org/forums/index.php/mv/msg/620815/1222018/#msg_1222018
your quick support is much welcome. Regarding the Java 1.5 compatibility, we are using 1.6 so it's not a blocker for us. However, I realised the bundle stated 1.5 and therefore I reported the inconsistency. I was not aware Equinox is switching to 1.6, good to know.
I assume the next QVTo release would be 4.4, right?
Best Regards,
Víctor Roldán [Open Canarias]
]]>Victor Roldan Betancort2013-12-19T12:08:52-00:00Re: Posible enhacements in the QVT code
https://www.eclipse.org/forums/index.php/mv/msg/620815/1222020/#msg_1222020
> I assume the next QVTo release would be 4.4, right?
No, we will stay on 3.x stream so the next release is 3.4.0 (it won't introduce any API breaking changes).
Víctor Roldán [Open Canarias]]]>Victor Roldan Betancort2013-12-19T15:33:26-00:00Re: Posible enhacements in the QVT code
https://www.eclipse.org/forums/index.php/mv/msg/620815/1229079/#msg_1229079
any chances the above fixes could be included in Kepler SR2?
Cheers,
Víctor Roldán [Open Canarias]]]>Victor Roldan Betancort2014-01-08T17:13:12-00:00Re: Posible enhacements in the QVT code
https://www.eclipse.org/forums/index.php/mv/msg/620815/1229090/#msg_1229090
The Kepler build job does not loook in good shape. 4 fails since Kepler
release
a) because the Hudson Job rename has not been accommodated in the scripts
b) the RMAP references are inappropriate for a maintenance build
and probably a general review is needed to ensure that it works as a
maintenance build without crunching the luna builds.
(most of the above can be found by looking at evolution of the QVTd
build that like QVTo is a single job offshoot of the OCL build.)
But since QVTo has not yet moved to a HIPP and upgrade must suffer the
eccentricities of the communal Hudson.
Far from insuperable, but very little on Hudson is trivial.
Regards
Ed Willink
On 08/01/2014 17:13, Victor Roldan Betancort wrote:
> Hi again, Sergey,
>
> any chances the above fixes could be included in Kepler SR2?
>
> Cheers,
> Víctor Roldán [Open Canarias]]]>Ed Willink2014-01-08T17:40:12-00:00Re: Posible enhacements in the QVT code
https://www.eclipse.org/forums/index.php/mv/msg/620815/1229102/#msg_1229102
that's quite unfortunate. I'll interpret your answer as "unfortunately, there's much to do before that could happen, and we are lacking on resources"
Can only hope you guys find some time for the maintenance builds.
Best Regards,
Víctor Roldán [Open Canarias]]]>Victor Roldan Betancort2014-01-08T18:19:53-00:00