Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » QVT-OML » Posible enhacements in the QVT code
Posible enhacements in the QVT code [message #1211634] Tue, 26 November 2013 14:45 Go to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Hi all,

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]
Re: Posible enhacements in the QVT code [message #1211664 is a reply to message #1211634] Tue, 26 November 2013 15:04 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
As per EPL, here I publish the modified sources.

http://www76.zippyshare.com/v/12605258/file.html
Re: Posible enhacements in the QVT code [message #1213393 is a reply to message #1211664] Wed, 27 November 2013 08:10 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4154
Registered: July 2009
Senior Member
Hi Victor

QVTo is active again. Please supply patches. A Bugzilla is mandatory for
IP purposes.

https://github.com/eclipse/qvto seems to be working at the moment. No
Gerrit (yet).

Regards

Ed Willink

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
Re: Posible enhacements in the QVT code [message #1213999 is a reply to message #1213393] Wed, 27 November 2013 13:50 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Hi Ed,

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 Smile

Quote:

https://github.com/eclipse/qvto seems to be working at the moment. No
Gerrit (yet).


Alright, I'll create some bugzillas and submit patches.

Best Regards!
Víctor Roldán [Open Canarias]
Re: Posible enhacements in the QVT code [message #1214055 is a reply to message #1211634] Wed, 27 November 2013 14:18 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4154
Registered: July 2009
Senior Member
Hi

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
Re: Posible enhacements in the QVT code [message #1221912 is a reply to message #1214055] Wed, 18 December 2013 17:20 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Bugzillas submitted:

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
Re: Posible enhacements in the QVT code [message #1221995 is a reply to message #1221912] Thu, 19 December 2013 09:59 Go to previous messageGo to next message
Sergey Boyko is currently offline Sergey BoykoFriend
Messages: 162
Registered: July 2009
Senior Member
Hi Victor,

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.

As for Java 1.5 compatibility - we're planning to switch BREE to Java 6 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=424052). I think this will happen till Luna M6 milestone (see http://wiki.eclipse.org/Luna/Simultaneous_Release_Plan).


Regards,
Sergey Boyko.
Re: Posible enhacements in the QVT code [message #1222018 is a reply to message #1211634] Thu, 19 December 2013 12:08 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Sergey,

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]

Re: Posible enhacements in the QVT code [message #1222020 is a reply to message #1222018] Thu, 19 December 2013 12:19 Go to previous messageGo to next message
Sergey Boyko is currently offline Sergey BoykoFriend
Messages: 162
Registered: July 2009
Senior Member
Victor,

> 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).

Project's link: http://projects.eclipse.org/projects/modeling.mmt.qvt-oml/releases/3.4.0
Downloads: http://www.eclipse.org/mmt/downloads/index.php?project=qvto&showAll=0&showMax=5
Re: Posible enhacements in the QVT code [message #1222065 is a reply to message #1211634] Thu, 19 December 2013 15:33 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Sergey,

I actually mistyped the version, wanted to refer to 3.4.0, sorry. Thanks for the info!

Víctor Roldán [Open Canarias]
Re: Posible enhacements in the QVT code [message #1229079 is a reply to message #1222065] Wed, 08 January 2014 17:13 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Hi again, Sergey,

any chances the above fixes could be included in Kepler SR2?

Cheers,
Víctor Roldán [Open Canarias]
Re: Posible enhacements in the QVT code [message #1229090 is a reply to message #1229079] Wed, 08 January 2014 17:40 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4154
Registered: July 2009
Senior Member
Hi

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]
Re: Posible enhacements in the QVT code [message #1229102 is a reply to message #1229090] Wed, 08 January 2014 18:19 Go to previous message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Hi Ed,

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]
Previous Topic:Plz help me [ QVT Relational]
Next Topic:Transforming two model instances into a single model instance
Goto Forum:
  


Current Time: Fri Nov 28 17:11:25 GMT 2014

Powered by FUDForum. Page generated in 0.02830 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software