Re: [handly-dev] Dependency on org.eclipse.core.resources

[Vladimir Piskarev <pisv@xxxxx>]

I'm attaching a slightly enhanced revision of the prototope, newmodel2.zip. The main change is that IHElementDeltaMirror#getResourceDeltas() can now return null, which can be used as a guard by clients that need to support both Eclipse IDE and other targets (it also allowed to ditch HElementDeltaBase.ResourceDeltaContainer).

So, the prototype demonstrates that, by using some tricks based on the "outward impression" [1] that JVM won't resolve a class reference until absolutely necessary, we could keep the design simple and continue to support Eclipse IDE by still exposing IResource etc. in the Handly core API without introducing additional layers of structure *and* enable other targets by making the dependency on o.e.core.resources optional. This is similar to tricks EMF plays (o.e.emf.ecore has an optional dependency on o.e.core.resources).

With this approach, if a model *implementation* were based on, say, java.nio.file instead of o.e.core.resources and needed to run in a plain Java application, it would work perfectly fine -- #getResource()/#getResourceDeltas() would always return null, so JVM would not attempt to load anything IResource.

Regarding the model's *clients*, there are a few things to consider:

* Exposing IResource etc. in the Handly core API (or in a model-specific API for that matter) doesn't make any difference for clients not interesting in workspace-related information, including such clients as Eclipse RCP or plain Java applications -- they would simply not call #getResource() etc. and work just fine since JVM would not attempt to load anything IResource.

* In theory, at least, there might be some clients that could make use of workspace-related information if it were available. Those clients would call #getResource() etc. and check if the return value is not null -- in case it is null such clients would work just fine since JVM would not attempt to load anything IResource. Of course, such clients need to be careful and use appropriate guards before trying to access IResource etc. (such as the check for null above) if they wanted to support both Eclipse IDE and other targets.

Whether we need/can provide more support for those "other targets" remains to be seen and is specifically not something I was trying to address at this time. If enhanced support were indeed deemed desired, we could probably use the same approach of ensuring that such target-specific dependencies remain optional, without introducing additional layers of structure in the core framework.

Best regards,
Vladimir

[1]  https://dev.eclipse.org/mhonarc/lists/handly-dev/msg00176.html

 

> Hi! 
>
>
> Don't worry about late answers, it wasn't that late and it happens to everybody :-)
>
>
> I see, so the two demo zips are not really related. That makes sense now.
>
>
> If you find a way to abstract out o.e.core.resources, then it would be great. I suppose that the clients would need a way to know what APIs are available and in what form - maybe some kind of ISomethingExtension interfaces? I trust you with this, the Handly APIs are very clean!
>
>
> regards,
> Vlad
>
>
>
>
> On Sun, Feb 7, 2016 at 9:14 AM, Vladimir Piskarev <pisv@xxxxx> wrote:
>
> > Hi Vlad,
> >
> > Thanks for the feedback, and sorry for my delay in responding. My only (lame) excuse for not checking my mail earlier is that I got carried away with choosing and installing a Linux distro to revitalize my good old MacBook Pro.
> >
> > I think that, basically, we have two problems on hand that could, and probably should, be treated as orthogonal: the one described in my original proposal for a new design around the model API and the other, of reducing dependencies, partly described here.
> >
> > The previous newmodel.zip was in fact a bit incomplete in the sense that it was trying to deal only with the former problem and so just abstracted away the dependency on o.e.core.resources as a detail that was not deemed essential in the context of that consideration.
> >
> > Those two problems are indeed quite orthogonal as can be illustrated by the fact that my findings regarding the latter problem could have been incorporated in the existing design as well as in the proposed new one. It was just a bit more convenient to me to investigate that problem and present the results within the framework of a simplified prototype. I'm sorry for the confusion this has probably caused.
> >
> > Please also note that the Eclipse IDE, where the dependency on o.e.core.resources is a given, remains the primary "deployment target" for Handly. The goal here has just been to make this dependency optional, so the project could be used in other contexts such as Eclipse RCP or even plain Java applications. (The latter is possible by replacing the dependency on o.e.core.runtime with o.e.equinox.common, which doesn't require OSGi running.)
> >
> > Speaking of these other contexts, a Handly-based model could be built on top of such diverse "resource models" as o.e.core.filesystem, java.nio.file, or even a custom datasource. I think we needn't "prescribe" in Handly what the "resource model" is in these contexts.
> >
> > Hope this makes a bit more sense now.
> >
> > Thanks,
> > Vladimir
> >
> >
> >
> > > Hi Vladimir,
> > >
> > >
> > > I got some time to look at this, but I'm not sure I get it right (probably it's just a misunderstanding from my part): given your explanation I has assumed that the previous newmodel.zip would have a required dependency on o.e.c.resources, but it doesn't have one at all. Maybe newmodel.zip is incomplete?
> > >
> > >
> > > How useful would be the model without references to resources? There has to be something that allows using files and such in a RPC. Would the o.e.c.filesystem be enough? It only depends on osgi bundles. (I admit I don't know much about the details)
> > >
> > >
> > > best regards,
> > > Vlad
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Fri, Jan 29, 2016 at 1:54 PM, Vladimir Piskarev <pisv@xxxxx> wrote:
> > >
> > > > Just to keep everyone informed,
> > > >
> > > > I was experimenting for a while with whether the dependency on o.e.core.resources could be made optional, so that Handly could be used in Eclipse RCP applications (there appears to be some interest in this, see e.g. a blog comment [1]). First results are encouraging -- I think it would be quite easy to do, thanks to how the JVM works wrt class loading.
> > > >
> > > > I have incorporated my findings into the new design prototype (see the newmodel2 project attached), although it could be implemented in the existing design too. For details, please see the "first strategy" test case (model.test.Test). When o.e.core.resources bundle is not resolved, only testFooElementDelta2 and testFooElementDelta3 tests fail (as expected), all other tests pass.
> > > >
> > > > Best regards,
> > > > Vladimir
> > > >
> > > > [1] https://pisv.wordpress.com/2015/01/19/on-m-theory-and-h-models-or-can-emf-fit-every-nail/
> > > >
> > > > _______________________________________________
> > > > handly-dev mailing list
> > > > handly-dev@xxxxxxxxxxx
> > > > To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> > > > https://dev.eclipse.org/mailman/listinfo/handly-dev
> >
> >
> >
> >
> > _______________________________________________
> > handly-dev mailing list
> > handly-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/handly-dev

Attachment: newmodel2.zip
Description: Binary data