I agree
I don't think we should confused application type (there can be
several like ejb, web) with packaging of such applications.
I am not sure I understand why it is so important for NB to display
per packaging type, they should just use list-applications and then
reorder the way they want. It seems to me that we should either
display per application type (ejb, web) OR you display per application
name and have the containers under.
On Apr 10, 2009, at 11:23 AM, Kedar Mhaswade wrote:
> 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
>>>>>
>>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>