| Re: [science-iwg] e3 or e4 |
My experience is that API consumers who are reluctant to take on e4 target because they are completely e3 target based are generally reluctant taking on any new technology. These are very conservative organisations because e3 hasn't been updated in years now, and, for example, running old SWT on new OS can be problematic.
Therefore I would recommend an e4 target platform as e3 target platform consumers probably won't take on the new project anyway.
Hopefully if someone on this list is still using e3 target platform and is interested in this project they will speak up!
Jonah
(Note that above I am not talking about e4 vs e3 programming model. However if your code base can really use e3 or e4 style APIs, perhaps consider making the core API neither and providing some adapters to make it compatible with the UI system, allowing the code to be reused in other frameworks too?)
Thanks I know all that, my question is if in making an API I should be using e3 since that works in any RCP product..?
M
From: science-iwg-bounces@eclipse.
org [mailto:science-iwg-bounces@eclipse.org ] On Behalf Of Philip Wenig
Sent: 05 September 2016 13:01
To: science-iwg@xxxxxxxxxxx
Subject: Re: [science-iwg] e3 or e4
Matt,
you could try to use the mixed modus, like we do with ChemClipse.
* The product definition contains a link to an own Application.e4xmi
* UI parts are defined via the Application.e4xmi or fragment.e4xmi files
* Dependency Injection and the EventBroker can be used
* 3.x parts can be re-used too
PhilAm 05.09.2016 um 11:41 schrieb Matt.Gerring@xxxxxxxxxxxxx:
Hello,
I am working on a new project* which will be part of the science working group and might eventually be used at sites other than ours by using the feature as a component in a different product. On our site all RCP-based applications now use an e4 target. I have to make a decision on some of the user interface classes as to if I allow a dependency on e4. If I stick with everything as e3 it all runs on our e4 targets and is fine but I am limited with a few features. If I make e4 dependencies I restrict reuse to only those organisations with e4 targets.
What do you think I should do? Keep things e3 or allow e4 dependencies which might limit those still on e3? There may be some people on long term support whom will stick with e3 for long periods… but whether they would every need to use a scanning API is not clear.
Matt
* for scanning hardware, basically a truly open version of the Generic Data Acquisition software which Diamond Light Source has been using for some time.
--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
_______________________________________________ science-iwg mailing listscience-iwg@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/science-iwg
--~~~~~~~~~~~~~~~~~~~~~~~~OpenChrom - the open source alternative for chromatography / mass spectrometryDr. Philip Wenig » Founder » philip.wenig@xxxxxxxxxxxxx » http://www.openchrom.net~~~~~~~~~~~~~~~~~~~~~~~~
--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
_______________________________________________
science-iwg mailing list
science-iwg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/science-iwg