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