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

["matthew.gerring" <matthew.gerring@xxxxxxxxx>]

This is very useful feedback. Will certainly discuss with pete. Thanks :-)

Sent from my Huawei Mobile

Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:

>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
>
>
>_______________________________________________
>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