11:39 a.m.
Hey,
Moved to jbosstools-dev where this topic is for.
> Correct.
> There is a problem when a plugin doesn't export its preferences correctly.
I think the problem is that you're assuming that each of these items are a workspace
preference. They are not. A list of servers is not a workspace preference. A list of
filesets belonging to servers (currently stored in a standalone xml file) is *NOT* a
workspace preference.
These are all things happening for JBoss AS, right ?
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 ?
> WTP doesn't export server definitions when a user exports
preferences. Server definitions are saved in a separate file in the workspace and there is
no way to move them to a new workspace unless the user copies the servers.xml file
manually. This is a bug (or a missing feature) in WTP. I have added exporting WTP server
definitions within the Export/Import action to the runtime plugin.
>
In WTP, the runtimes are stored in workspace preferences, and the servers are not.
However, I have had extreme problems trying to trace through the code. When importing
servertools preferences, including the runtime objects, *NO* runtime lifecycle events are
thrown. It seems simply setting a preference key does not properly work with the WTP
framework. Somehow the runtimes are added, but no lifecycle events are thrown. It would
*SEEM* that simply setting a preference key is not a proper way to import runtimes.
But what happens when Eclipse startsup ? at this point it i just reading preferences...we
should be able to emulate/activate the same.
> jBPM plugin doesn't export its runtime preferences correctly.
There is a workaround in the runtime plugin that probably needs to be moved to the jBPM
plugin.
Please open a jira!
> [sic]
> JBoss AS also doesn't export its preferences.
https://jira.jboss.org/browse/JBIDE-7379 is a bug in JBoss AS. I suppose that this problem
is similar to the problem related to the exporting WTP server definitions. Since
You can go around saying WTP has bugs for not exporting the servers and launch
configurations, or for importing runtime objects wrong, and that AS Tools has bugs for not
exporting filesets and xpaths and things. I on the other hand will say that the preference
page was designed with a very very flawed assumption in mind, an assumption that
doesn't seem to work with *MOST* frameworks.
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 ?
The truth of the matter is that simply setting preference keys does
not work with most APIs, it does not update core models, it does not work with lifecycle
events, and it is flawed in almost every way from design to implementation. The other
assumption, that most or all important metadata is stored in the preferences, is also
flawed. Filesets stored in other files, xpaths stored elsewhere, launch configurations for
servers, there are tons of other metadata locations and assuming that most plugins can
even function at all (let alone function correctly) by just swapping out plugin
preferences seems very very dangerous to me.
But this is just my opinion and what I've noticed.
I understand that AS has this problem - but that doesn't make it *most* frameworks
does it ?
I would suggest moving slowly on this and not rushing into a new
extension point until we have an API panned out. And more discussion. Now that I've
become more familiar with it, I do like the idea of an extension point, but that
individual plugins should be the ones accurately in charge of how they export their
preferences and not the runtime plugin.
That is how it is intended - if there are anything done "outside" that (i.e.
jbpm bug or AS limitations) that should be ironed out.
>>>> btw. how is this hooked up to the installers
mechanism of setting up servers for new workspaces ? (i.e. the properties file that sits
in product root so you don't have to manually import/export)
>>>>
>>>>
>>> The installers mechanism uses the application.properties file that is created
when installing JBDS. When the runtime plugin creates runtimes, their preferences are
created automatically and can be exported/imported either using the standard Eclipse
Export/Import action or using our wizard.
>>
>> Yes, but the beauty of the application.properties is that it works across
workspaces *without* as users having to worry about it....i know its a "hack"
but its a real nice hack now that Eclipse doesn't have a good notion of
"cross-workspace" configuration (beyond the manual import/export of hardcoded
preferences)
>>
>> Which is why I was kinda hoping we would have a ui on this page where we could
add/remove to this application.properties file so it were available even without the
installer.
>>
> There are several issues and they are the following:
>
> 1) application.properties within JBDS are placed at a fixed location: the
<JBDS_HOME>/studio directory. Where to place this file in JBoss Tools? In the
configuration area of the runtime plugin ?
How is it looked up today ? it's looked up relatively to "something". 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.
> 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.
> 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.
> 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.
> 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.
> Would the feature be available in JBDS?
Not sure I understand the question...why wouldn't this be available in JBDS ?
> 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 ?
> 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.
> We could create the *.epf file in the configuration area of the
runtime plugin and read it as JBDS reads application.properties when the user checks the
"Import JBoss Runtimes preferences to a new workspace ?" preference.
> Finally, yet another issue remains:
> If the user starts JBT in two workspaces and changes runtimes independently, which
preferences would we get? The preferences from the workspace in which the last change has
been made?
These preferences are only used on *creation* of a new workspace - not *during* its use.
/max
5:13 p.m.
Max Rydahl Andersen wrote:
Hey,
Moved to jbosstools-dev where this topic is for.
>> Correct.
>> There is a problem when a plugin doesn't export its preferences correctly.
>>
> I think the problem is that you're assuming that each of these items are a
workspace preference. They are not. A list of servers is not a workspace preference. A
list of filesets belonging to servers (currently stored in a standalone xml file) is *NOT*
a workspace preference.
>
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.
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.
>> WTP doesn't export server definitions when a user exports
preferences. Server definitions are saved in a separate file in the workspace and there is
no way to move them to a new workspace unless the user copies the servers.xml file
manually. This is a bug (or a missing feature) in WTP. I have added exporting WTP server
definitions within the Export/Import action to the runtime plugin.
>>
>>
> In WTP, the runtimes are stored in workspace preferences, and the servers are not.
However, I have had extreme problems trying to trace through the code. When importing
servertools preferences, including the runtime objects, *NO* runtime lifecycle events are
thrown. It seems simply setting a preference key does not properly work with the WTP
framework. Somehow the runtimes are added, but no lifecycle events are thrown. It would
*SEEM* that simply setting a preference key is not a proper way to import runtimes.
>
But what happens when Eclipse startsup ? at this point it i just reading preferences...we
should be able to emulate/activate the same.
The runtime plugin emulates this behavior for WTP server definitions and
jBPM runtimes. The plugin delegates the Export/Import Server Runtimes to
WTP plugin, the Seam Runtimes to the Seam plugin, the Drools preferences
to the Drools plugin.
There is a problem related to refreshing Preferences Pages.
Namely, a preference page isn't refreshed automatically when some other
preference page changes its preference. The problem can be reproduced in
the following way:
- call Window>Preferences>Server>Runtime Enironments
- don't close the Preferences dialog
- call the JBoss Tools>Web>Seam preference page
- call the JBoss Tools>JBoss Runtimes preference page
- add a new JBoss EAP server that includes JBoss AS and Seam using the
Search button
Now if you open the JBoss Tools>Web>Seam page or the Server>Runtime
Enironments preference page, you won't see a new Seam Runtime or a new
Server Runtime.
The problem is that the JBoss Tools>Web>Seam preference page and the
Server>Runtime Enironments preference page aren't refreshed.
Close the Preferences dialog and reopen it. The mentioned runtimes will
be present.
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.
>> jBPM plugin doesn't export its runtime preferences
correctly. There is a workaround in the runtime plugin that probably needs to be moved to
the jBPM plugin.
>>
Please open a jira!
OK.
>> [sic]
>> JBoss AS also doesn't export its preferences.
https://jira.jboss.org/browse/JBIDE-7379 is a bug in JBoss AS. I suppose that this problem
is similar to the problem related to the exporting WTP server definitions. Since
>>
> You can go around saying WTP has bugs for not exporting the servers and launch
configurations, or for importing runtime objects wrong, and that AS Tools has bugs for not
exporting filesets and xpaths and things. I on the other hand will say that the preference
page was designed with a very very flawed assumption in mind, an assumption that
doesn't seem to work with *MOST* frameworks.
>
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 ?
> The truth of the matter is that simply setting preference keys does not work with
most APIs, it does not update core models, it does not work with lifecycle events, and it
is flawed in almost every way from design to implementation. The other assumption, that
most or all important metadata is stored in the preferences, is also flawed. Filesets
stored in other files, xpaths stored elsewhere, launch configurations for servers, there
are tons of other metadata locations and assuming that most plugins can even function at
all (let alone function correctly) by just swapping out plugin preferences seems very very
dangerous to me.
>
> But this is just my opinion and what I've noticed.
>
I understand that AS has this problem - but that doesn't make it *most* frameworks
does it ?
> I would suggest moving slowly on this and not rushing into a new extension point
until we have an API panned out. And more discussion. Now that I've become more
familiar with it, I do like the idea of an extension point, but that individual plugins
should be the ones accurately in charge of how they export their preferences and not the
runtime plugin.
>
That is how it is intended - if there are anything done "outside" that (i.e.
jbpm bug or AS limitations) that should be ironed out.
>>>>> btw. how is this hooked up to the installers mechanism of setting up
servers for new workspaces ? (i.e. the properties file that sits in product root so you
don't have to manually import/export)
>>>>>
>>>>>
>>>>>
>>>> The installers mechanism uses the application.properties file that is
created when installing JBDS. When the runtime plugin creates runtimes, their preferences
are created automatically and can be exported/imported either using the standard Eclipse
Export/Import action or using our wizard.
>>>>
>>> Yes, but the beauty of the application.properties is that it works across
workspaces *without* as users having to worry about it....i know its a "hack"
but its a real nice hack now that Eclipse doesn't have a good notion of
"cross-workspace" configuration (beyond the manual import/export of hardcoded
preferences)
>>>
>>> Which is why I was kinda hoping we would have a ui on this page where we
could add/remove to this application.properties file so it were available even without the
installer.
>>>
>>>
>> There are several issues and they are the following:
>>
>> 1) application.properties within JBDS are placed at a fixed location: the
<JBDS_HOME>/studio directory. Where to place this file in JBoss Tools? In the
configuration area of the runtime plugin ?
>>
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.
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.
>> 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 ?
>> 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?
>> 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 ?
>> 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)?
>> 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 ?
>> 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.
>> 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.
>> We could create the *.epf file in the configuration area of
the runtime plugin and read it as JBDS reads application.properties when the user checks
the "Import JBoss Runtimes preferences to a new workspace ?" preference.
>> Finally, yet another issue remains:
>> If the user starts JBT in two workspaces and changes runtimes independently,
which preferences would we get? The preferences from the workspace in which the last
change has been made?
>>
These preferences are only used on *creation* of a new workspace - not *during* its use.
Yes, they would be used only when creating a new workspace. The question
is when to create them.
Snjeza
1:48 p.m.
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
4916
days inactive
4931
days old
jbosstools-dev@lists.jboss.org
2 comments
2 participants
participants (2)
-
Max Rydahl Andersen -
Snjezana Peco