Re: [e4-dev] Some random thoughts after browsing the e4 code base

[Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>]

Hi Phil,

Thanks for the feedback.  I see Jeff already started a thread on #1,
let me answer a few others:

> 2. Why are you still using Require-Bundle in almost every bundle when
a
> I-P would do just fine? And then the CSS core bundle is requiring
the
> batik bundle which it does not use one class from, does it?

In the CSS case, we do actually reference one of the
classes but through reflection.  The use of reflection is legacy issue
wrt. the way the code was structured in its previous project (TK-UI), allowing
a number of different engines to be pluged in, but TK-UI was not OSGi based.
 

WRT Require-Bundle vs. I-P, I tend to use Require-Bundle,
well to be honest, because that's what we always do. I've seen some of
the pro/con discussions, this is something definitely worth discussing
post 0.9 as a general e4 architectural decision.

> 3. The CSS bundles are too tightly coupled with each other. As far
as I
> understand the concept, there are handlers for CSS elements. Couldn't
> those handlers and other components that make up a CSS engine
> implementation be contributed by extensions?

Absolutely agree!  See bug
263785.
Again, this is a side effect of the CSS origins being
non OSGi based.  There has been discussion over the need to maintain
a non-OSGi version which has complicated things.  But this is a high
priority item for post 0.9.

> 4. What is the use of OSGi services in e4? So far I have seen there
is
> an IEclipseContext which allows you to fetch services like the old
> IServiceLocator in 3.x does. What about putting more services directly
> into OSGi (that are not local to any part of the workbench)? I would
put
> my declarative services to more use depending on the workbench services
> available. For instance, now in 3.5 I export the IWorkbench as a service
> myself and have my other services consume it. Similar to the
> ISelectionService, IProgressService and others.

The long term goal is to eliminate global access to
workbench facilities (as you listed, things like selection).  We do
this via the IEclipseContext, providing encapsulation so that parts can
be reused in new ways (e.g. multi user shared server workspace).  These
can be OSGi service based but don't need to be. There is no plan to, for
example, make everything you get from the context be an OSGi service. 

I'm not sure if that answered your question.

> 5. I actually like the idea of being able to define the layout of
RCP
> applications. Currently I have gone through great pain to have a custom
> view on top of each perspective that you can not close/move or whatever.
> It provides a kind of "startbar" with custom gradient background.
See here:

Yes!  We think this is very important as well,
one of the driving design points.

> Please understand my points not as criticism purely, I am sure for
a lot
> of things there are good reasons just unknown to me.

All feedback and discussion welcome!

> Said that, I am more than willing to contribute to e4 if possible
after
> I got more insight on the processes going on.

Well there's lots to do.  If you indicated an
area of interest we could discuss more concretely possible ways to contribute.

Regards,
Kevin