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)
-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
>>>
>>
>