8:26 a.m.
On Oct 25, 2010, at 14:55, Rob Stryker wrote:
On 10/25/2010 05:39 PM, Max Rydahl Andersen wrote:
> Rob - I'm only seeing AS having the problem right now ? Am I wrong on that ?
> btw. would make perfect sense to import/export most of
these settings via preferences, would it not ?
>
Max: Yes, you are very very wrong here. As was said earlier, WTP servertools keeps the
server objects in one file, but, if you change a setting in the workspace, it actually
keeps each server object in its own file. Either way, it *never* stores server objects in
"plugin preferences". So already Servertools is a counter-example. Snjezana
characterized this as a bug in servertools. I characterize this as a design decision, so
that users can copy such files around.
This only covers the *server* part of WTP which is something different than runtime
definitions.
Also, Snjezana characterized that Jbpm not storing its runtimes in
its plugin preferences as a bug as well. I characterize not storing runtimes in the plugin
preferences, but rather providing an API to handle it, as a design decision by Koen.
Which is a bad one if these are pure runtime references - we should fix that - I actually
thought it was fixed since this is not an old problem with jbpm.
AS-Tools does not store filesets in the plugin preferences. The
"fileset" I'm referrng to is in the Server's view, expand a server, you
see "Filesets", and you can make your own fileset. This is stored in
.metadata/plugins/o.j.i.e.as.core/server_name/filesets.xml. XPaths are stored in a similar
location. At one time some of these were stored in the server objects, but as I said
above, server objects are not stored in preferences anywhere. I assume Snjezana would
characterize this as a bug in exporting my settings. I characterize it as a design
decision in where to store my metadata.
okey - so how are users to copy their settings for use in a new workspace ?
The eclipse Debug plugin stores launch configurations as launch
configuration files, in the debug plugin metadata. It does *NOT* serialize them into a
plugin preference key. I am quite sure this is not a bug. This is a design decision.
Hibernate Tools does the same - but these (just like eclipse debug launch config and WTP
server configs) are sharable into users project workspace so they show up.
> I understand that AS has this problem - but that doesn't make
it *most* frameworks does it ?
I would think if you polled every a large majority of plugins available and expected
everything to be stored as a plugin preference, you would find many many plugins that
simply do not work this way.
The plugins that does not do it that way have other means of sharing their configs...
The assumption that most plugins work this way is a very very bad
one. Plugins have metadata, yes, but not all the metadata is stored in the Plugin
preference object.
Anything that should be sharable/migratable are.
Some pieces are often extracted into separate files (launch configs,
wtp servers, filesets and xpaths). Those plugins that *do* keep data in plugin preferences
might not be prepared to respond to a changed value at all. You'd then have to find a
way to force that plugin to re-load from plugin preferences. Good luck with that....
Unless you want to shut down and re-start bundles or something.
That is fine - can be a known limitation.
btw. launch configs actually do get refreshed so does preferences that are exposed to
users since good plugins listen to preference changes.
I'd say those four examples are enough to declare that there are
enough exceptions to the "rule" that it's not a "rule" at all but
rather a mistake... and that any API must be designed assuming there is other metadata and
*NOT* assuming all metadata is stored in plugin preferences. These should not be called
"bugs" but we should recognize them as design decisions.
Again, *runtimes* are listed in preferences - launch config are not - that is fine, they
are not meant to be transferred over.
That is why I like the approach we got with JBDS installer where we pick up the list of
server locations we want to have configured on a new workspace startup (and by consequence
have automatically recognize containing runtimes).
It's also enough for me to declare that even in the plugins that
*do* have their metedata stored in plugin preferences, we still have to carefully handle
the situation and not simply copy preference key / value pairs into the new workspace...
Unless our 'import settings' action forces a workbench restart afterwards.
Which is fine to tell users about for this case. We can't solve *all* problems with
this.
/max
5141
days inactive
5141
days old
jbosstools-dev@lists.jboss.org
0 comments
1 participants
participants (1)
-
Max Rydahl Andersen