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

[Vladimir Piskarev <pisv@xxxxx>]

Hi Vlad,

 

Thanks for the input!

 

It seems I was not quite correct in interpreting the results of my experiments. My initial approach depends on lazy resolution of symbolic references and although it does work on a HotSpot VM, the JVM Spec apparently provides no guarantees about lazy resolution, so the code appears to be in violation of the spec. It's all too easy to be fooled by such things. I need to take a deeper look at this when I have some time, but the problem starts to look much harder than I initially thought.

 

An approach with "isolating" the dependency on o.e.core.resources in a separate layer, along the lines you have suggested, would come with a cost wrt additional complexity both in the framework and for model implementations and clients (more "parts and pieces" to be aware of).

 

Need to decide whether the increase in complexity would be worthwhile and, to begin with, if it's really a problem to be solved, given that the Eclipse IDE remains the main target for the foreseeable future. The proposed redesign around the model API is a much more pressing need now.

 

Best regards,

Vladimir

 

 

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