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

[Max Rydahl Andersen]

This seem to have stalled, so I tried write up my thoughts/issues into jira.

https://jira.jboss.org/browse/JBIDE-7524

I know we are close to codefreeze so can't do all of these fixes but would like to outline what I originally and still envisioned for the jboss tools runtime detection.

I'll edit/comment the below in context of the jira above and especially https://jira.jboss.org/browse/JBIDE-7527 which have my mockup suggestion.

I'm on irc to discuss this further.

>> These are all things happening for JBoss AS, right ? 
> 
> That is happening for WTP servers, jBPM runtimes and JBoss AS preferences. Those plugins have some preferences that can't be copied from one workspace to another unless files are copied manually. That is a bug a missing feature. The request is to copy those preferences between workspaces automatically. The runtime plugin contains a workaround for a WTP server definition and jBPM runtimes, but doesn't contain a workaround for JBoss AS preferences.

JBIDE-7528  - we really should limit as much as possible the need for any custom tweaks - at least within our own plugins. Its better to leave import/export out for runtimes we can't reliably support it.
Please link any open or new issues concerning import/export to this issue so we can keep track.

>> What does "a list of filesets belonging to servers" mean ?
>>  
>>> They *ARE* metadata, but designing a preference page around the idea that all important metadata is stored in workspace preferences is very very flawed.
>>>    
>> 
>> Not *really* since they in most cases should be .. at least it makes things much more uniform.
>> 
>> I would like to know what other plugins store their Preferences *outside* of the preferences ? 
> 
> The debug and datatools plugin create their preferences in separate files, but they have their Export/Import actions. The debug plugin uses the standard Export/Import>Run/Debug>Launch Configurations/Breakpoints. The datatools plugin has these actions in the Data Source Explorer view.

Good point - so we really should implement proper import/export for those missing this (best of course is that preferences were used as much as possible ;)

> 
> Since we can't ensure preference pages to be refreshed autmatically, the best solution for this problem is to move the JBoss Runtimes preference page to a wizard.

Ok - or just have the "JBoss Tools Runtimes" import/export "wrapper" only available from the standard import/export wizards.

My suggestion still uses a preference page since it introduces a seperate notion of "automatic detection" paths.

>> How is it looked up today ? it's looked up relatively to "something".
> 
> <JBDS_HOME>=<ECLIPSE_HOME> for JBDS. The application.properties file is placed to the <JBDS_HOME>studio directory.

So that is something we just need to support if the installer keeps doing that (or fix the installer?)

> 
>> I assume the eclipse instance ? We could do the same in JBoss Tools...or as we do for Usage preferences, in the Eclipse Configuration instance area ?
>> Or simply as a file in the root of eclipse instance...
>> 
>>  
>>>> What if the user doesn't want to have the same runtimes in different workspaces ?
>>>>      
>> 
>> Then he doesn't put the file there or he doesn't setup the server this way.
>> 
>>   
> How to ask the user if he wants or doesn't want this behaviour? We could add a dialog similar to the Usage dialog, but adding such dialogs would be annoying to the users.

See my suggestion - the dialog won't show up unless there are actual new runtimes to be added/defined.

>>>> Do we need to add a global preference "Import JBoss Runtimes preferences to a new workspace?"
>>>>      
>> 
>> No, since the existence of the file and elements in there makes up for that preference.
>>  
> 
> How to determine if we will create the file ?

See my suggestion - need to store it in eclipse configuration preferences somehow; or read it from user home directory ?

>>>> 2) application.properties in JBDS is created in a strictly defined time: when installing JBDS
>>>> It isn't changed when the user changes some runtimes.     
>> 
>> Which is why I mentioned in the early time of the o.j.t.runtime that we should find a way to do similar things as we do in the installer from inside JBoss Tools.
>> 
>> 
> 
> JBDS has an installer, JBT doesn't. We have added the Search dialog for JBDS when installing it (the application.properties file is created in Step 5 of 9 "Select Platforms and Servers"), but how to do that for JBT?

See my suggestion - its covered there.

>>>> For example: when the user starts JBDS in a new workspace (workspace A), he will have runtimes defined when installing JBDS. Let's assume the user changes some runtimes (adds new runtimes, changes the preferences of the existing runtimes ...). When staring JBDS in a new workspace (workspace B), he will have the runtimes defined when installing JBDS, not the runtimes defined in the workspace A.
>>>>      
>> 
>> Yup - that is what the installer feature does - produces a *clean* slate based on the directories setup.
>> 
>>  
> 
> JBT doesn't have an installer and we can't add runtimes to JBT without any user intervention. When and how to add "the directories setup" to JBT ?

See my suggestion ;)

>>>> When to create this file in JBoss Tools? After adding/changing some runtime?
>>>>      
>> 
>> That is what I wanted the preference page to handle.
>> 
>> Changes to the runtime/server config is not what the JBDS installer is meant to handle/automate.
>>   
> 
> OK. The question is how to change global properties, when changing local (workspace) properties ? What if two users change runtimes (and use the same Eclipse instance/configuration)?

For automatic detection its just about having the automatic detection not pickup already configured runtimes.

I don't understand when you will have overlap between two users - if you are on a multiuser install the eclipse config data is stored in users home directory afaik ?

>>>> Would the feature be available in JBDS?
>>>>      
>> 
>> Not sure I understand the question...why wouldn't this be available in JBDS ?
>> 
>>  
> 
> Currently, if the user changes/adds/deletes some runtime that doesn't change application.properties. If we change this behaviour, will that change be available to JBDS ?

My suggestion doesn't have this problem afaics.

>>>> 3) It isn't easy to create application.properties based on the preferences in the current workspace. The application.properties file is created on the basis of some default values (JRE, the name of a runtime ...). The user can change some preferences and/or add new preferences. The application.properties file doesn't recognize all the Runtime preferences (JRE or the deploy location of a Server Runtime, for instance).
>>>>      
>> 
>> application.properties does not reference JRE's - it should simply be using the default execution environment (or possibly reference specific execution environments if need to setup for Java5 & Java6).
>> deploy location of server runtime - why should it care ? The creation of the server is/should be handled mostly by the AS anyway, right ? 
>>  
> The creation of the server offers the default values that the user can change. The application.properties file contains just a few properties to create a server runtime (location, version, type). It has some additional properties (JRE, a deploy location, Runtime name, ...). If we want to transfer this runtime to another workspace, we would need to transfer all the properties.

My intent was not to transfer *all* settings - but I can see the benefit of the import/export options.

My intent was to have automatic detection of the runtimes at new workspaces.

>>>> In my opinion, it would be better to use Eclipse preferences file (*.epf) than the application.properties file.
>>>>      
>>>>  
>> 
>> But these aren't shared automatically...
>> if you mean that the format of application.properties should be like an eclipse preference file..i'm find with that.
>> 
>>  
> 
> Yes, *epf format includes more properties than the application.properties file. There is also the standard Eclipse API to handle *epf files.

yes, which is great and for actually physical copying of settings. That's not the intent here.

/max