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