[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [january-dev] IMonitor -> IProgressMonitor?
|
On 10/27/2016 2:13 AM, Matt.Gerring@xxxxxxxxxxxxx wrote:
Hello,
Yes I added IMonitor for no dependency on core runtime from eclipse. That part of January was originally conceived as a standalone jar by Peter and the rest of the team working on it.
I think this ability to compile without eclipse core runtime is important for a project that wants to be a common way to describe data - there are potential users currently evaluating January without that in their project, for instance those with swing or web front ends. They tend to be adverse to putting "eclipse" in their product, which of course is an IDE. (I am aware of how this might sound incorrect considering the modular nature of the bundles.) Ideally all eclipse core dependencies like this would be removed from the January project for that reason.
Hi Matt and Peter. I agree with you that it's useful to avoid
dependencies of any kind for a library like January (or in fact any
library).
However, I also think that there is a balance about this. If the
library begins to acquire classes (like IMonitor) that are duplicated
elsewhere in more established libraries (e.g. IProgressMonitor), and
that begin to enter a whole other realm (e.g. long running
activities/threading/jobs, ui, communications, etc), then I do think it
can make sense to reuse other libraries as dependencies. I don't know
January well enough yet to even have thoughts on that judgment...other
than that I noticed a high degree of similarity between IMonitor and
IProgressMonitor, and IMonitor is one of the core classes of January.
One clarification about org.eclipse.core.runtime. Mostly because of
Eclipse history, this package has a lot of classes, and when Equinox
moved to using OSGi they split this package out into several bundles.
One thing this means is that you don't have to 'pull in' all of
org.eclipse.core.runtime if you have just a few dependencies.
org.eclipse.equinox.common contains the 'core of the core' classes, and
is written to be portable across OSGi frameworks (i.e. it runs without
difficulty on Equinox, Felix, any OSGi framework impl). We (ECF) use
it (IAdaptable, IStatus, etc) and it has proven valuable for us. For
us, it hasn't been worth trying to duplicate this functionality.
One way to deal with such choices can be to break down your own
framework into smaller bundles, where those bundles might have different
dependencies...and are possibly usable in different contexts (in/out of
osgi, in/out of Eclipse, etc) or use cases. Note I'm *not* suggesting
doing split packages...unless you have to...and of course there are
other tradeoffs involved when one does that.
My $0.02,
Scott
All the best,
Matt
-----Original Message-----
From: january-dev-bounces@xxxxxxxxxxx [mailto:january-dev-bounces@xxxxxxxxxxx] On Behalf Of Peter.Chang@xxxxxxxxxxxxx
Sent: 27 October 2016 09:31
To: january-dev@xxxxxxxxxxx
Subject: Re: [january-dev] IMonitor -> IProgressMonitor?
Hi Scott,
I believe the reason for this was to reduce dependencies as much as possible including Eclipse ones(!).
Regards,
Peter
-----Original Message-----
From: january-dev-bounces@xxxxxxxxxxx [mailto:january-dev-bounces@xxxxxxxxxxx] On Behalf Of Scott Lewis
Sent: 26 October 2016 23:41
To: january-dev@xxxxxxxxxxx
Subject: [january-dev] IMonitor -> IProgressMonitor?
Hi Folks,
I noticed the org.eclipse.january.IMonitor interface in January and was
wondering: have you considered using/reusing the
org.eclipse.core.runtime.IProgressMonitor (in org.eclipse.equinox.common
bundle)? There are other classes that may be useful in
org.eclipse.equinox.common...e.g. IStatus, IAdaptable, IAdapterFactory, Path, CoreException, etc.
Despite the name (org.eclipse.core.runtime) these classes are all in org.eclipse.equinox.common, and can be run on Felix or other frameworks (we/ECF do this regularly on/with Karaf [1]).
There is some cost of depending upon other bundles, of course...no matter how established they are...but it might be worthwhile to consider this for parts of January.
Another thought: You could also consider using OSGi services for some
of your factory operations (dataset and metadata creation). It could
help reduce type coupling.
Scott
[1] http://wiki.eclipse.org/EIG:Install_into_Apache_Karaf
_______________________________________________
january-dev mailing list
january-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/january-dev
--
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
_______________________________________________
january-dev mailing list
january-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/january-dev
_______________________________________________
january-dev mailing list
january-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/january-dev
