Design of Runtime dectation/migration: Re: Code re-org in o.j.t.runtime
by Max Rydahl Andersen
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
14 years, 10 months
Re: [jbosstools-dev] Design of Runtime dectation/migration: Re: Code re-org in o.j.t.runtime
by 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
>
14 years, 11 months
JBoss Tools 3.2 on Eclipse Marketplace
by Max Rydahl Andersen
I discovered last week that Eclipse Marketplace (available via Help > Eclipse Marketplace) is *super easy* to submit thus I
submitted JBoss Tools 3.2.x (marked as beta) to it:
http://marketplace.eclipse.org/content/jboss-tools-1
On that submission we have to give at least one feature to install to make it easy to install from a "plain" eclipse.
This again give us a problem since including *everything* from jboss tools will for a JEE user grab a non-significant
set of dependencies (i.e. Teeid's UML, Maven tooling m2eclipse and TPTP requires tptp etc.)
Thus for this "first time" I only included the features I know should be able to install on Eclipse JEE and just get
dependencies from our site and I added a comment in the description that to get the "extras" use the updatesite directly.
Suggestion on how we handle this problem of "large bundles" welcome.
Should we simply create a "Web" and "SOA" bundling feature which might have overlap ? (i.e. both will need our AS integration)
And if users insttall such - will they be able to install both without conflicts ?
/max
14 years, 11 months
Re: [jbosstools-dev] Status for VPE/Hibernate
by Maksim Areshkau
Maksim Areshkau wrote:
> Max Rydahl Andersen wrote:
>>>>> Last week
>>>>> • moving to maven build; Is anybody using the build during development?
>>>>>
>>>>>
>>>> got any problems since you ask ?
>>>> /max
>>>>
>>>>
>>>>
>>> #1 Just interesting how stable is it ;-)
>>>
>>
>> its used to build jbosstools every night so i would consider it stable - the intent was to get devs to use it and report if they found issues and
>> we could work any kinks out that is found during dev.
>>
>>
>>> #2 I have builded common component, than remove from my workspace *common* plugins and install it via update site.
>>> Then I restarted eclipse and some plugins from update site haven't been added to eclipse. I have missed plugin errorrs in vpe sources.
>>>
>>
>> I'm not sure I follow what "I have missed the plugin errors in vpe sources" means ? Could you be a bit more specific ?
>> What plugins are missing ? Maybe your or others plugins doesn't declare its dependencies well enough to be installed separately ?
>>
>> /max
>>
>>
> #Maybe your or others plugins doesn't declare its dependencies well
> enough to be installed separately ?
> Possibly yes. I have following errors "The import
> org.jboss.tools.common.text.ext cannot be resolved","The import
> org.jboss.tools.common.resref.core cannot be resolved". Will look into
> possibility to another declaration this dependencies.
Looks like for some reasons, this plugins not loaded when I install from
following update site /trunk/common/site/target/site. I haven't received
any warnings, what can be a reason?
org.jboss.tools.common.el.core
org.jboss.tools.common.gef
org.jboss.tools.common.model.test
org.jboss.tools.common.model.ui
org.jboss.tools.common.projecttemplates
org.jboss.tools.common.resref.core
org.jboss.tools.common.text.ext
org.jboss.tools.common.text.xml
org.jboss.tools.common.ui
org.jboss.tools.common.verification
14 years, 11 months