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