Home » Eclipse Projects » Equinox » Additional plugin model considerations
| Additional plugin model considerations [message #10638] |
Sat, 08 March 2003 19:32  |
Eclipse User |
|
|
|
Originally posted by: joerg.schaible.web.de
Hi,
apart from the current discussion about the update and dependecies between
plugins,
there are some other topics, that have to be considered in the plugin model.
1) Clear model to separate between default settings, project dependent
settings and
local settings.
Currently it is not really possible to share a project's settings with the
CVS (...), because
a lot of the settings are in the workspace and will not be shared among the
developers (e.g.
the compiler warnigns, code formatting, etc.). But the workspace will also
include rwo other
kind of settings: Individual ones like key bindings and default settings.
So, if you have to ensure that a team works with the same settings for a
project, it is
currently a major process: Adjust the default settings like code formatter,
ensure that
everyone use the project individual settings (at least for the settings,
that provide this option).
When a project setting should be shared, the a plugin should be capable of
saving all its
non-individual default settings into a project settings file kept with the
project. Settings of
individual choice should not be considered for saving there (e.g. font or
colors). Basically
every team member should be able to build the project with the same settings
getting the
exaclty same result as everyone else.
2) The support for external contexts/environment.
Problem: When I start Eclipse with my notebook offline, some of my plugins
come really into
trouble, because of the missing external net ressource causing several
errors in Eclipse.
Basically they should be informed by a context provided from the core at
initialization, what
ressources are currently available. They should be deactivating or sleeping,
if they cannot run,
but without having Eclipse deleting all the according views. Such contexts
might be provided
by the core itself (e.g. am I (Eclipse) running in debug mode, do I have net
access, is a printer
available, is a DB available a special plugin in needs, ...) or by user
defined XML profiles
with this resources provided at startup, so I can have two startup scripts
for Eclipse that I use
in the different environment.
Regards,
J
|
|
|
| Re: Additional plugin model considerations [message #10708 is a reply to message #10638] |
Sat, 08 March 2003 22:37  |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"Joerg R. Schaible" <joerg.schaible@web.de> wrote in message
news:b4e2vh$is6$1@rogue.oti.com...
> Hi,
> 1) Clear model to separate between default settings, project dependent
> settings and local settings.
I have seen several bug reports relating to this in the past while. It is a
great idea but a deceptively hard problem. My hope is that it will be
addressed in scope of the Eclipse platform project rather than in Equinox.
> 2) The support for external contexts/environment.
>
> Problem: When I start Eclipse with my notebook offline, some of my plugins
> come really into
> trouble, because of the missing external net ressource causing several
> errors in Eclipse.
>
> Basically they should be informed by a context provided from the core at
> initialization, what
> ressources are currently available. They should be deactivating or
sleeping,
> if they cannot run,
> but without having Eclipse deleting all the according views. Such contexts
> might be provided
> by the core itself (e.g. am I (Eclipse) running in debug mode, do I have
net
> access, is a printer
> available, is a DB available a special plugin in needs, ...) or by user
> defined XML profiles
> with this resources provided at startup, so I can have two startup scripts
> for Eclipse that I use
> in the different environment.
Can you be more specific as to what plugins are failing/views disappearing?
I am assuming that all your plugins are local and some of those have not
gone missing?
The profile idea is intriguing. It is a way of the user telling the plugins
not to expect certain things and that it is ok. Individual plugin writers
will still have to know about the profile values and handle the various
settings. Alternatively, plugin could be more resilient to cases where some
resource was there and now it is not. This is especially true of networked
resources. For example, if the network goes down for a while, a database
plugin should not start failing.
Jeff
|
|
|
| Re: Additional plugin model considerations [message #10802 is a reply to message #10708] |
Sun, 09 March 2003 09:30 |
| Eclipse User |
|
|
|
Originally posted by: joerg.schaible.web.de
Hi Jeff,
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> schrieb im Newsbeitrag
news:b4ed4j$mur$1@rogue.oti.com...
>
> "Joerg R. Schaible" <joerg.schaible@web.de> wrote in message
> news:b4e2vh$is6$1@rogue.oti.com...
> > Hi,
> > 1) Clear model to separate between default settings, project dependent
> > settings and local settings.
>
> I have seen several bug reports relating to this in the past while. It is
a
> great idea but a deceptively hard problem. My hope is that it will be
> addressed in scope of the Eclipse platform project rather than in Equinox.
Well, but configurations and settings are also inherited by the dependency
between the plugins. Even more - a plugin can offer a replacement for core
settings (e.g. Jalopy rules as general code formatter, any assistent would
use
this plugin to reformat generated code before pasting it to the editor).
Possibly this leeds away from the pure configuration level to a
service-oriented
view: A plugin just says, well give me the Java-code-formatter or give me
the XML parser or give me the configured browser. There are definatly such
mechanisms in Eclipse, but I am not sure about the generality.
Think of installing Debian - you can define a dependency on a general mail
processing component without explicitly defining "I need sendmail". See the
mess
such a missing concept leeds looking at the browsers. Everyone claims to be
another
in their HTTP header, instead of just saying - well, I am DOM compliant or
CSS1
or CSS2 aware.
Regarding the persistance of the configuration each plugin has to separate
between
its current settings on project or individual level and should be able to
answer
a request for them.
> > 2) The support for external contexts/environment.
[snip]
>
> Can you be more specific as to what plugins are failing/views
disappearing?
> I am assuming that all your plugins are local and some of those have not
> gone missing?
I had bad experiences with the p4eclipse 0.0.8. If you're offline, you
cannot
edit a single file even if they are checked out. While this is not the fault
of Eclipse
at general, I am quite sure, that the plugin developer might have been more
carefull if the API would have told him "hey - currently no network".
> The profile idea is intriguing. It is a way of the user telling the
plugins
> not to expect certain things and that it is ok. Individual plugin writers
> will still have to know about the profile values and handle the various
> settings.
Sure, but they need a chance. And even if every net-aware plugin would take
care
on its own for available network services ... normally everything is on halt
until the
network timeout occurs.
>Alternatively, plugin could be more resilient to cases where some
> resource was there and now it is not. This is especially true of
networked
> resources. For example, if the network goes down for a while, a database
> plugin should not start failing.
Yes, that would be extremly helpful. In case of p4eclipse you cannot even
save
your edited file if it happens.
Regards,
J
|
|
|
| Re: Additional plugin model considerations [message #12063 is a reply to message #10802] |
Mon, 10 March 2003 09:35 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Behing that idea of profiles... showing what is there or not...
isn't it where a dynamic service-oriented framework would help.
I know Java is poorly structured in that regard, but if those things
were modelled as service, and that service users would be
dynamically notified of services appearing and disappearing,
it would "strongly suggests" plugin writers to handle the case.
I believe that is one of the most valuable aspects of service
frameworks, like OSGi. However, it does mean that the
programming model for plug-ins is altered. It also means that
some JRE functionality, like java.net or jdbc, would have to be
surfaced as services rather than their current library-like API.
Best regards,
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"Joerg R. Schaible" <joerg.schaible@web.de> wrote in message
news:b4fjcf$e2p$1@rogue.oti.com...
> Hi Jeff,
>
> "Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> schrieb im Newsbeitrag
> news:b4ed4j$mur$1@rogue.oti.com...
> >
> > "Joerg R. Schaible" <joerg.schaible@web.de> wrote in message
> > news:b4e2vh$is6$1@rogue.oti.com...
> > > Hi,
> > > 1) Clear model to separate between default settings, project dependent
> > > settings and local settings.
> >
> > I have seen several bug reports relating to this in the past while. It
is
> a
> > great idea but a deceptively hard problem. My hope is that it will be
> > addressed in scope of the Eclipse platform project rather than in
Equinox.
>
> Well, but configurations and settings are also inherited by the dependency
> between the plugins. Even more - a plugin can offer a replacement for core
> settings (e.g. Jalopy rules as general code formatter, any assistent would
> use
> this plugin to reformat generated code before pasting it to the editor).
>
> Possibly this leeds away from the pure configuration level to a
> service-oriented
> view: A plugin just says, well give me the Java-code-formatter or give me
> the XML parser or give me the configured browser. There are definatly such
> mechanisms in Eclipse, but I am not sure about the generality.
>
> Think of installing Debian - you can define a dependency on a general mail
> processing component without explicitly defining "I need sendmail". See
the
> mess
> such a missing concept leeds looking at the browsers. Everyone claims to
be
> another
> in their HTTP header, instead of just saying - well, I am DOM compliant or
> CSS1
> or CSS2 aware.
>
> Regarding the persistance of the configuration each plugin has to separate
> between
> its current settings on project or individual level and should be able to
> answer
> a request for them.
>
> > > 2) The support for external contexts/environment.
> [snip]
> >
> > Can you be more specific as to what plugins are failing/views
> disappearing?
> > I am assuming that all your plugins are local and some of those have not
> > gone missing?
>
> I had bad experiences with the p4eclipse 0.0.8. If you're offline, you
> cannot
> edit a single file even if they are checked out. While this is not the
fault
> of Eclipse
> at general, I am quite sure, that the plugin developer might have been
more
> carefull if the API would have told him "hey - currently no network".
>
> > The profile idea is intriguing. It is a way of the user telling the
> plugins
> > not to expect certain things and that it is ok. Individual plugin
writers
> > will still have to know about the profile values and handle the various
> > settings.
>
> Sure, but they need a chance. And even if every net-aware plugin would
take
> care
> on its own for available network services ... normally everything is on
halt
> until the
> network timeout occurs.
>
> >Alternatively, plugin could be more resilient to cases where some
> > resource was there and now it is not. This is especially true of
> networked
> > resources. For example, if the network goes down for a while, a
database
> > plugin should not start failing.
>
> Yes, that would be extremly helpful. In case of p4eclipse you cannot even
> save
> your edited file if it happens.
>
> Regards,
> J
|
|
|
Goto Forum:
Current Time: Fri Oct 31 08:16:09 EDT 2025
Powered by FUDForum. Page generated in 0.03345 seconds |
Home