[jbosstools-dev] Design of Runtime dectation/migration: Re: Code re-org in o.j.t.runtime

[Max Rydahl Andersen]

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
>