Community
Participate
Working Groups
I can check a runtime in Server -> Installed Runtime to designate it as default. The label above the list box says that this will be used to pick the runtime at project creation. However, when I go to create a project the setting is ignored. We should do one of two things for 1.0: 1. Make it work. 2. Remove the check boxes and the explanatory label from the above preferences panel.
Let's make it work in 1.0 if possible. Otherwise, add it to the Known Problems list. No UI changes should be made now. I'm assigning this to wst.server.
Missed this one since it was assigned to the wrong owner. Transferring.
Back to you, Kosta. This is a regression caused by moving to the facet framework. The way this worked before was that ServerCore.getRuntimes() returned a sorted list and the J2EE team always preselected the first element in the list in the new project wizards. The current problems are: * There is no formal guarantee that the facet runtimes returned from RuntimeBridge.getExportedRuntimeNames() will be returned from other facet API in the same order. * There is no way to update/reorder the facet runtimes when changes occur, either in ordering or in new/removed facet runtimes. (gets back to the facet management issue) * We'll have to confirm that the new project wizard still preselects the first element. The changes need to happen in facets first. Once this is complete I assume it will impact server tools and I'll need to react via this or another bug.
It's not clear how to fix this issue. The runtime bridge architecture is getting in the way. May need to defer to 1.5 to give time for more consideration.
Because the bridge architecture supports multiple bridges there is no clean way to propagate the notion of a default runtime through the bridge. I think we have three alternatives: 1. I can add setDefaultRuntime/getDefaultRuntime methods to facet framework's runtime manager. The server runtime management ui can then call these methods based on the checkboxes that the user selects. This is probably the cleanest way to handle this, but is probably too much work for 1.0.1. 2. Remove the checkboxes from the server runtime management ui. 3. Have the project creation wizards refer to wst.server api in order to determine which runtime should be the default. This is rather hacky and I'd rather avoid this option, if possible. My feeling is that we should go for #2 in 1.0.1 release and implement #1 in 1.5 release. Tim, what's your opinion?
It doesn't look like there will be any action on this for the 1.0.1 release. Changing target milestone to 1.5.
I propose that we get rid of the notion of the "default runtime" in favor of having the runtime selection widget (or the project wizards) remember the last runtime that was used. Thoughts?
Checked, and it doesn't look like this was exposed as API anywhere. If we go forward with this plan, we'll need a second defect for me to remove the text/support from server tools.
Chuck, could you comment on this proposal? Thanks.
Chuck, could you comment on the proposed solution? We need to resolve this issue for the 1.5 release. Thanks.
Sure - so it sounds like we are leaning toward having no default runtime pre-selected - but adding "sticky" support to this field? I'm ok with this, and it removes complexity - If the initial default is very important - we could just add this to the list of product configurations? Tim I'm not sure what you meant by removing your text support? We should open another defect against my team for the module 1st page selection.
Chuck - I meant on the Server preference page, where this was previously done. I'll need to remove/edit the text at the top of the page and remove the checkboxes. One more thing - sticky selection should probably keep a short history and try them in order. For instance, the user might create an EJB project and select JBoss (sticky is now JBoss), then create a static Web project (sticky becomes some HTTP runtime), and finally creates an EAR project. When creating the EAR project the user would expect JBoss to be selected, even though the most recent sticky was for an HTTP runtime (which isn't in the list this time). There are other ways of doing this (e.g. keeping a sticky for every project/facet type) but I think users would expect the sticky to be the "last applicable runtime".
I agree with Tim's overview in Comment #12 that the default runtime should be the the first applicable runtime in LRU order. Chuck, let's use this bug to track the project wizards part of the change. Please route as appropriate. I will open another one for Tim.
Opened a bug to track the removal of the checkboxes in the server runtimes panel. https://bugs.eclipse.org/bugs/show_bug.cgi?id=131630
Created attachment 44182 [details] patch I changed the preference store's ID and changed it to take a String [] of the most recently used server targets. Some changes were also necessary to the model in order to ensure the correct runtime was pushed down. This included a change to NewProjectDataModelFacetWizard where it was clearing and resetting the runtimes. While I was in the code, I also fixed a bug which allowed a Runtime not supported by EARs to be set on an EAR.
Please do further testing, e.g. on imports as you suggested.
Created attachment 44285 [details] patch without formatting This is the same patch as before without formatting changes. I tested tested the various import scenarios and all seem fine.
Thx for testing. +1 for WTP 1.5 RC5
+1
+1 1.5
code checked into cvs.
(In reply to comment #21) > code checked into cvs. I'm wondering if this broke something in RC5. See bug 148203.
Verified WTP 1.5.1 RC driver.
