Rob, I wasn’t talking about runtime download at all. I’m talking
about runtime detection on a folder containing existing servers.
Your suggestion could apply there, too. But it doesn’t scale - what
if I have 5 different servers in the searched directory. Would I then
get 5 new server (simplified) wizards opened?
-Martin
On 26. 3. 2014, at 20:08, Rob Stryker <rstryker(a)redhat.com> wrote:
> I think the proper workflow here is to simply open the new server
> wizard and let the user fill out their choices. There's no point in
> duplicating that workflow.
>
> Currently it downloads in the background, and, when the download is
> complete, unzips it, makes a runtime out of that folder, and then
> makes a server out of it. It probably should unzip it, make a new
> runtime out of that folder, and then open a new server wizard with
> fewer pages (server type already chosen, so we don't need that first
> page).
>
> Runtimes have remained the same and have not changed. Only servers
> have.
>
> But yes, will need to investigate how to do it cleanly.
>
> On 03/27/2014 02:00 AM, Martin Malina wrote:
>>
>> On 26. 3. 2014, at 18:56, Max Rydahl Andersen <manderse(a)redhat.com>
>> wrote:
>>
>>> On 26 Mar 2014, at 17:37, Len DiMaggio wrote:
>>>
>>>> Why not provide both options?
>>>
>>> which two options are you referring to ?
>>
>> I think Len refers to this snippet from my email:
>> "So perhaps we should consider which one should be used for runtime
>> detection in the future. Or even better perhaps to offer both
>> options for runtime detection?"
>>
>> So once runtime detection finds the servers, you could choose which
>> mode to use before clicking OK to add them. But I’m not sure if
>> there’s a way to do it and avoid confusion for the user.
>>
>> -Martin
>>
>>> I think the idea about locking the servers deployment mode
>>> is too strict in context runtime detection.
>>>
>>> We need some way to change these - either allow same flexibility as
>>> before or have a "Recreate this server using same basic info but in
>>> Profile X" instead.
>>>
>>> /max
>>>
>>>>
>>>> -- Len
>>>>
>>>> ----- Original Message -----
>>>>
>>>> | From: "Max Rydahl Andersen" <manderse(a)redhat.com>
>>>> | To: "Martin Malina" <mmalina(a)redhat.com>
>>>> | Cc: "Rob Stryker" <rstryker(a)redhat.com>,
>>>> "jbosstools-dev(a)lists.jboss.org
>>>> | jbosstools-dev" <jbosstools-dev(a)lists.jboss.org>
>>>> | Sent: Wednesday, March 26, 2014 10:32:36 AM
>>>> | Subject: Re: [jbosstools-dev] New server profiles vs. Runtime
>>>> Detection
>>>>
>>>> | I noticed this discrepancy too. Agree need to figure this
>>>> workflow out.
>>>>
>>>> | /max (sent from my phone)
>>>>
>>>> | On 26/03/2014, at 12.03, Martin Malina < mmalina(a)redhat.com >
>>>> wrote:
>>>>
>>>> | | Hi Rob,
>>>> |
>>>>
>>>> | | I have a question. Now that we have more profiles for servers
>>>> ( JBIDE-16721
>>>> | | )
>>>> | | - one that prefers management operations and one that does not
>>>> - what
>>>> | | happens when you add a server using Runtime Detection? I think
>>>> it will
>>>> | | currently use the non-management option. In the past, you
>>>> could change the
>>>> | | server settings later to use management. But you say that
>>>> increasingly
>>>> | | there
>>>> | | will be differences between the two that can’t be changed
>>>> afterwards - one
>>>> | | example is the deployment tab in the server editor.
>>>> |
>>>> | | So perhaps we should consider which one should be used for
>>>> runtime
>>>> | | detection
>>>> | | in the future. Or even better perhaps to offer both options
>>>> for runtime
>>>> | | detection?
>>>> |
>>>> | | What do you think about this?
>>>> |
>>>>
>>>> | | Thanks,
>>>> |
>>>> | | Martin
>>>> |
>>>>
>>>> | | --
>>>> |
>>>> | | Martin Malina
>>>> |
>>>> | | JBoss QA Engineer
>>>> |
>>>> | | Red Hat Czech s.r.o.
>>>> |
>>>> | | Purkynova 99
>>>> |
>>>> | | 612 45 Brno, Czech Republic
>>>> |
>>>>
>>>> | | Tel.: +420 532 294 265
>>>> |
>>>>
>>>> | | _______________________________________________
>>>> |
>>>> | | jbosstools-dev mailing list
>>>> |
>>>> | | jbosstools-dev(a)lists.jboss.org
>>>> |
>>>> | |
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>> |
>>>>
>>>> | _______________________________________________
>>>> | jbosstools-dev mailing list
>>>> | jbosstools-dev(a)lists.jboss.org
>>>> |
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>> --
>>>>
>>>> Len DiMaggio (ldimaggi(a)redhat.com)
>>>> JBoss by Red Hat
>>>> 314 Littleton Road
>>>> Westford, MA 01886 USA
>>>> tel: 978.392.3179
>>>> cell: 781.472.9912
>>>>
http://www.redhat.com
>>>>
http://community.jboss.org/people/ldimaggio
>>>
>>>
>>> /max
>>>
http://about.me/maxandersen
>>
>> --
>> Martin Malina
>> JBoss QA Engineer
>> Red Hat Czech s.r.o.
>> Purkynova 99
>> 612 45 Brno, Czech Republic
>>
>> Tel.: +420 532 294 265
>>
>>
>>
>>
>
--
Martin Malina
JBoss QA Engineer
Red Hat Czech s.r.o.
Purkynova 99
612 45 Brno, Czech Republic
Tel.: +420 532 294 265