On Apr 15, 2009, at 11:00 AM, Nitya Doraisamy wrote:
> Following up, see inline
> Jerome Dochez wrote:
>>
>> On Apr 10, 2009, at 3:59 PM, Peter Williams wrote:
>>
>>>
>>>
>>> Jerome Dochez wrote:
>>>>
>>>> On Apr 10, 2009, at 2:11 PM, Nitya Doraisamy wrote:
>>>>
>>>>> Anissa Lam wrote:
>>>>>>
>>>>>>
>>>>>> Ludovic Champenois wrote:
>>>>>>> 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.
>>>>>> Agree. Thats exactly what GUI is doing now. (see attached
>>>>>> screen). As I mentioned earlier, I am thinking that we may
>>>>>> have different icons depending on isComposite property, but I
>>>>>> really don't know what advantage this gives to user by knowing
>>>>>> that its packaged as an ear. Vivek has requested that GUI to
>>>>>> display different icon of the app depending on the ruby
>>>>>> framework, or application type, eg Rails, Merb, etc. I haven't
>>>>>> looked into that yet.
>>>>>>
>>>>> That's true. It would be ideal to move away from the previous
>>>>> representation. But the sticky point is the in allowing for
>>>>> displaying a different icon of the app depending on the ruby
>>>>> framework, or application type. For this you would need to know
>>>>> the application type. So should we even try to differentiate
>>>>> using icons or just use generic icons?
>>>> I think you should associate those icons with the container type
>>>> (web, ejb, webservices). For the top level application icon, I
>>>> suppose we could use a generic project/bundle icon no ?
>>> Generic icons really don't look very good, especially if the node
>>> in question is for an application (e.g. ear)
>> ok you can always know that a deployed artifacts is an application
>> or a module so you could segregate there.
>>
>> once at the module level, knowing it can be deployed in 1 to n
>> containers I think you have to use a generic icon. The item under
>> (the container) should have specific icons.
>>
>> I suppose you could have a feature where you order your view
>> according to a setting (sort by name, or sort by container).
>>
>> Jerome
> Yes, that would work. So how do we identify an application? What
> property can be added that provides this data? The 'nb-engine' list
> was going to provide this info. Can this be done?
not sure what the situation is today but if it does not exist, Hong
should add a isComposite flag to the Application config object in the
domain.xml.
jerome
>
> - Nitya
>>
>>>
>>>
>>> -Peter
>>>>
>>>> jerome
>>>>
>>>>>
>>>>> - Nitya
>>>>>> Anissa
>>>>>>> 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
>>>>>>>>>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>> <mime-attachment.png>
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>