On 4/10/09 1:18 PM, Peter Williams wrote:
> Hi Jerome,
>
> I think you raise a really good point and I like the general direction
> of this idea...
Me too... I guess it is time to change this static, predefined UI
representation in the NetBeans tree node and offer a much more generic
way of displaying apps. Who knows what would be the next type, added by
a GlassFish container we don;t even know yet...
So we need to display the app name as a node and then either in tool
-tip or sub node or properties in the node, the list of all containers
that understand this app.
Ludo
>
> I have some thoughts I need to collect and I'll write something short
> up we can discuss. Not sure if it belongs on this list or not, but as
> good as a place as any.
>
> -Peter
>
> Jerome Dochez wrote:
>>
>> On Apr 10, 2009, at 12:20 PM, Nitya Doraisamy wrote:
>>
>>> Jerome Dochez wrote:
>>>> 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.
>>> For NB, the plugin display orders the deployed apps by application type
>>> (ears, web apps, ejbs, appclients, connectors). For this the code was
>>> using the 'nb-engine' value in the MessagePart.
>>>
>>> But this list for an ear containing a web app contains just <web>. So
>>> how can the plugin identify this an ear vs a stand alone web module?
>>> Anissa suggested chcking the isComposite property. But then, what
>>> about
>>> the case of ejb in web app? If the list in this case is <web, ejb> and
>>> the plugin can safely assume that the first value will always matche
>>> the
>>> type of app, then it would work.
>>> Will that be the case?
>>>
>>> The plugin uses this info to identify the type of app and decorate it
>>> with appropriate icons. ie. an EAR in the deployed list will have the
>>> same icon as an ear project in NetBeans project view.
>>>
>>> My understanding is that Hong suggested the additional property in
>>> order
>>> to provide this info. If 'nb-engine' is going to have the appropriate
>>> info, then this is not needed. At this point it does not. And if the
>>> plan is to remove 'nb-engine' then the plugin needs some way of
>>> identifying if the deployed app is an ear, web app, ejb app,
>>> appclient etc
>>
>> that's not the point.
>> why do you need to know the archive type ?
>> do you want to have 3 levels display in NB :
>>
>> war:
>> foo: web, ejb
>> bar:
>> web, webservices
>> jar:
>> boo:
>> ejb, webservices.
>>
>> and then with ear you have 4 levels ?
>>
>> ear:
>> war:
>> foo module:
>> ejb, web
>>
>> jar:
>> bar module:
>> web. webservices.
>>
>> this would also be extremely confusing. My point is that you should
>> stop caring about the application packaging type when displaying the
>> application tree in NB and just display the application name, module
>> list and then containers in which applications or modules are deployed.
>>
>> Jerome
>>
>>>
>>> - Nitya
>>>>
>>>>
>>>>
>>>> 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
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>