Re: [january-dev] IMonitor -> IProgressMonitor?

[<Matt.Gerring@xxxxxxxxxxxxx>]

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.

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