Here we go again, output of command execution == app server API!
Shouldn't you be just listing the applications *by name* and then
get/process additional meta-data separately? The field "nb-engine" sounds
like a hack.
Let's not add something like --displayPackagingType (i.e. ~20 characters
with camel case), on "asadmin list-applications", please.
Let's not make miserable, the life of command line users.
-Kedar
Nitya Doraisamy wrote:
> Hong Zhang wrote:
>>
>>>>>>> I deployed a ear application containing one web module to the v3
>>>>>>> server. The list-applications command shows this deployed app as
>>>>>>> 'testApp1 <web>'.
>>>>>>> For a webapp containing enb, the sniffer list returned was <ejb,
>>>>>>> web>. Shouldn't this be <web,ejb> ?
>>>>>>>
>>>>>>> The NetBeans plugin code calls list-applications and uses the
>>>>>>> response to list the deployed components in a tree.
>>>>>>> The engine list is used to identify the type of app. The
>>>>>>> expectation is that the engine sniffer list will be returned and
>>>>>>> the first engine would be the type of app. The 'nb-engine field'
>>>>>>> returned was to help the plugin identify the type of app.
>>>>>>>
>>>>>>> In a conversation with Jerome & Ludo, it was brought up that the
>>>>>>> deployed applications will not be identified as ear, war etc
>>>>>>> instead the tools should show the engines associated with each
>>>>>>> deployed app.
>>>>>>> But for a NetBeans developer, it makes more sense if when they a
>>>>>>> deploy an ear application or a web app, the deployed list in the
>>>>>>> runtime tree clearly identifies the ear, web apps with
>>>>>>> appropriate icons.
>>>>>>
>>>>>>
>>>>>> I kind of agree with you on this one. While in v3, we have the
>>>>>> concept of converaged application where the application could
>>>>>> contain more than one components, it still might be easier (and
>>>>>> more compatible looking as previous releases) if we categorize the
>>>>>> applications by their packaging types instead of the component
>>>>>> types inside them. So ejb in war case will be categorized as war
>>>>>> and ear case as an ear..
>>>>>>
>>>>> Yes, it would be great if there was some property which could be
>>>>> leveraged to identify the type of app? Do you have any suggestions.
>>>>
>>>> Maybe we can add an option to the list-applications command, say,
>>>> something like "--displayPackagingType=true/false". When it is set
>>>> to true, it will display packaging type instead of components type.
>>>> And the default value can be true or false depending what people
>>>> think..
>>>>
>>> So with -displayPackagingType=true, the engine list will list the
>>> package type and on -displayPackagingType=false, the engine list will
>>> list the components?
>> Yes, this is what I was thinking about..
>>> Or will there be a separate property that provides that package type ?
>> Last time I talked with Jerome, he really did not like the idea of
>> special property for NB, so we will probably remove it when making
>> this change.
>>>>> Currently the plugin is coded to use the first engine as the type
>>>>> of app If we want to change this to something else, we need to
>>>>> figure this out soon as NetBeans 6.7 schedule is ahead of v3's.
>>>>
>>>> Can you give a date here?
>>>
>>> * Apr 15 - NB 6.7 *Beta Clone*
>>> * Apr 20 - NB 6.7 *Beta Release*
>>> * May 25 - NB 6.7 *Code Freeze*
>>> * Jun 01 - NB 6.7 *RC 1 release*
>>>
>> So May 25th is the date we need to have the changes happen?
>>
> No, I would like to get this change in happen asap, if possible in the
> next week or so. So changes that may be needed in the plugin can be
> flushed out.
>
> Nitya
>
>> - Hong
>>
>>> *
>>>
>>>
>>>>
>>>>> - Nitya
>>>>>
>>>>>> - Hong
>>>>>>
>>>>>>> I don't think they should have to identify it using the name of
>>>>>>> the app.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Nitya
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>
>
>