Re: [gmf-dev] GMF runtime complexity makes it hard for clients to benefi

[Anthony Hunter <anthonyh@xxxxxxxxxx>]

Hi There,

Service and Provider tracing is available.

If you turn on Eclipse tracing for the
common.core.service plug-in, you can enable tracing for services.

The following are available:

debug/services/activate - Provider <service
provider> activated
debug/services/config - Provider of
<service extension> configured from <extension point>
debug/services/execute - Operation <operation
on a service provider> executed using strategy <strategy>

Examples for the Icon Service:

Provider of 'org.eclipse.gmf.runtime.common.ui.services.iconProviders'
configured from extension 'org.eclipse.gmf.runtime.diagram.ui.geoshapes.iconProviders'.
Provider of 'org.eclipse.gmf.runtime.common.ui.services.iconProviders'
configured from extension 'org.eclipse.gmf.runtime.diagram.ui.providers.iconProviders'.
Provider of 'org.eclipse.gmf.runtime.common.ui.services.iconProviders'
configured from extension 'org.eclipse.gmf.runtime.emf.type.ui.iconProviders'.
Provider of 'org.eclipse.gmf.runtime.common.ui.services.iconProviders'
configured from extension 'org.eclipse.gmf.tests.runtime.common.ui.services.provider.iconProviders'.
Provider of 'org.eclipse.gmf.runtime.common.ui.services.iconProviders'
configured from extension 'org.eclipse.gmf.tests.runtime.common.ui.services.provider.iconProviders'.
Provider of 'org.eclipse.gmf.runtime.common.ui.services.iconProviders'
configured from extension 'org.eclipse.gmf.tests.runtime.common.ui.services.provider.iconProviders'.
Provider 'org.eclipse.gmf.runtime.diagram.ui.providers.internal.DiagramIconProvider@5ca05ca'
activated.
Provider policy 'org.eclipse.gmf.tests.runtime.common.ui.services.provider.internal.policies.TestExceptionThrowingIconPolicy@2c392c39'
activated.
Provider 'org.eclipse.gmf.tests.runtime.common.ui.services.provider.internal.providers.TestExceptionThrowingIconProvider@3e6e3e6e'
activated.
Provider 'org.eclipse.gmf.runtime.emf.type.ui.internal.providers.ElementTypeIconProvider@625f625f'
activated.
Operation 'org.eclipse.gmf.runtime.common.ui.services.icon.GetIconOperation@6b246b24'
executed using strategy 'First'.
Provider 'org.eclipse.gmf.runtime.diagram.ui.geoshapes.internal.providers.GeoShapeIconProvider@61fb61fb'
activated.
Operation 'org.eclipse.gmf.runtime.common.ui.services.icon.GetIconOperation@4fe64fe6'
executed using strategy 'First'.

Hope this helps.

Cheers...
Anthony
--
Anthony Hunter mailto:anthonyh@xxxxxxxxxx
Manager - Software Developer, 
IBM Rational Software: Aurora Core Common / Modeling Tools
Phone: 613-591-7037

Henrik Rentz-Reichert <hrr@xxxxxxxxx>
Sent by: gmf-dev-bounces@xxxxxxxxxxx

11/08/2005 10:46 AM

Please respond to
"GMF Project developer discussions." <gmf-dev@xxxxxxxxxxx>

To	"GMF Project developer discussions." <gmf-dev@xxxxxxxxxxx>
cc
Subject	Re: [gmf-dev] GMF runtime complexity makes it hard for        clients        to        benefit from its power

Hi Mindaugas,

what you suggest here with your "activation explanation" is pretty
much
what I had in mind.

@GMF-runtime staff: is something like that already existing or is it
feasible to implement it?

Thanks,

Henrik

Mindaugas Idzelis wrote:

>
> I also had to go through a long ramp-up period to understand all of
> GMF. The best way to learn, IMHO is through trial and error,
> persistence, and heavy use of the debugger :-) Of course, that's the
> way I've learned most of swt, gef, platform, jdt, etc.  I don't
think
> this ramp-up period is unique to GMF, but to all large software bases.
>
> One thing that I think will be extremely valuable is to have some
kind
> of "activation explaination" built into the Service infrastructure.
It
> would be great if there were debug switches available that for a given
> service will trace every provider that is consulted and why or not
it
> was chosen. There are many layers that services use... execution
> strategies, enablement, policies, and it is pretty daunting at first
> to debug. Luckily, I've figured out strategic places to put
> breakpoints ;-) Nevertheless, some debug support for Service
> activation would go a long way in understanding the various types
of
> extensibility.
>
>
> Thanks,
>
> Mindaugas Idzelis
> IBM Rational Middleware
>
>
> *Steven Shaw <steveshaw@xxxxxxxxxx>*
> Sent by: gmf-dev-bounces@xxxxxxxxxxx
>
> 11/08/2005 09:56 AM
> Please respond to
> "GMF Project developer discussions."
>
>
>                  
> To
>                  "GMF
Project developer discussions." <gmf-dev@xxxxxxxxxxx>
> cc
>                  
> Subject
>                  RE:
[gmf-dev] GMF runtime complexity makes it hard for clients    
 
>  to        benefit from its power
>
>
>
>                  
>
>
>
>
>
> Note:  In case people weren't aware, there are a number of tutorials
> currently available in the SDK and a "How-to" document that
are fairly
> comprehensive.  
>  
> See org.eclipse.gmf.runtime.doc.isv / html / howto
>                    
                     
                     
     /
> tutorials
>  
> Regards,
>  
> Steve.
>  
> /Tuesday, November 08, 2005 9:45 AM
> To: "GMF Project developer discussions." <gmf-dev@xxxxxxxxxxx>
> cc:
> From: Doug Schaefer <DSchaefer@xxxxxxx>
> Subject: RE: [gmf-dev] GMF runtime complexity makes it hard for
> clients to   benefit from its power/
>
> Thanks Steve, I think a document would be immensely helpful for people
> trying to get their feet wet. The barrier to entry is pretty high
and
> I keep bouncing off. J.
>  
> Cheers,
> Doug
>  
>
> ------------------------------------------------------------------------
>
> *From:* gmf-dev-bounces@xxxxxxxxxxx
> [mailto:gmf-dev-bounces@xxxxxxxxxxx] *On Behalf Of *Steven Shaw*
> Sent:* Tuesday, November 08, 2005 9:13 AM*
> To:* GMF Project developer discussions.*
> Cc:* GMF Project developer discussions.; gmf-dev-bounces@xxxxxxxxxxx*
> Subject:* Re: [gmf-dev] GMF runtime complexity makes it hard for
> clients to benefit from its power
>  
>
> Hello Henrik,
>
> Thanks for your feedback.  The complexity certainly can be
> overwhelming due to the power of the infrastructure for extensibility
> and as a platform across domains.  There is a programmers guide
for
> the diagram plugins under construction that hasn't been published
yet
> in the SDK.  This would include some basic interaction diagrams
> describing how the creation process invokes the different services
> (View, EditPart, EditPolicy etc.).  This should be available
in M4.
>
> There is also some planned investigation on simplifying the service
> schema to avoid some of the complex XML tags that are needed to define
> providers.  These are currently necessary to avoid loading a
plugin
> simply to determine enablement or provides criteria for a provider.
>  With the introduction of the OSGI bundles some of this complexity
> could be potentially eliminated allowing the logic to be centralized
> in the java source.  (This needs to be investigated further...)
>
> Re: log --> There is advanced tracing option available that can
be
> activated that should let you see trace data logged by services.  In
> the Debug dialog, if you navigate to the "Tracing" tab and
turn on
> "Enable tracing for the selected plug-ins".
>
> Regards,
>
> Steve.
> ________________________________________
> Steven R. Shaw
> Rational Modeling Platform Diagram Layer Lead
> Rational Software | IBM Software Group
> 770 Palladium Drive, Kanata, ON, Canada, K2V 1C8
> tel: 613.591.7979
> steveshaw@xxxxxxxxxx
>
> *Henrik Rentz-Reichert <hrr@xxxxxxxxx>*
> Sent by: gmf-dev-bounces@xxxxxxxxxxx
>
> 11/08/2005 04:46 AM
>
>
> Please respond to
> "GMF Project developer discussions."
>
>
>                  
> To
>                  "GMF
Project developer discussions." <gmf-dev@xxxxxxxxxxx>
> cc
>                  
> Subject
>                  [gmf-dev]
GMF runtime complexity makes it hard for clients to benefit
> from its power
>
>
>  
>
>
>                  
  
>
>
>
>
>
>
> Hi all,
>
> currently I'm implementing a simple example using the GMF runtime.
>
> I tried to follow the lines of the logic example (which is fairly
> complex though). Obviously the framework is extremely powerful. But
> its complexity also puts a high burden on its clients. My experience
> up to now is that it is very difficult to trace problems back to their
> origin. This is partly due to the complex interactions of the
> framework with the providers defined by the client. Especially
> registering the clients via extension points is very error prone and
> problems are hard to detect.
>
> Some examples:
>
>     * it took me quite a long time to realize that the DiagramKind
of
>       the Wizard page has to be in sync with the corresponding
entry
>       in the ViewProvider
>     * I missed to derive an EditHelper from MSLEditHelper
which led to
>       an exception in a context that was extremely
hard to analyze
>     * in general declarations in the plugin.xml interact
via services
>       and service providers with user written code.
There are many
>       places where strings here and there have to coincide
literally
>       which can lead to subtle errors which are typically
very hard to
>       detect for a GMF runtime novice
>
> Now my questions:
>
>     * Is there a document (sequence diagrams would be great)
that
>       illustrates the interaction of framework instances
with user
>       defined code?
>     * Is a log file written with registry information of
the GMF
>       runtime services? Or alternatively: can I get
information of
>       this kind using certain tracing switches? This
kind of
>       information could be extremely helpful
>
>
> Kind regards,
>
> Henrik
>
> -- 
> ..................................................
>  
> Dr. Henrik Rentz-Reichert  _mailto://hrr@protos.de_
> <mailto://hrr@xxxxxxxxx/>
>
> Hafnerstr. 1               fon
+49-7533-9342-43
> D-78476 Allensbach         fax      
       -44
> _______________________________________________
> gmf-dev mailing list
> gmf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/gmf-dev_______________________________________________
> gmf-dev mailing list
> gmf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/gmf-dev
>
>------------------------------------------------------------------------
>
>_______________________________________________
>gmf-dev mailing list
>gmf-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/gmf-dev
>  
>

-- 
..................................................
   
 Dr. Henrik Rentz-Reichert  mailto://hrr@xxxxxxxxx

 Hafnerstr. 1               fon +49-7533-9342-43
 D-78476 Allensbach         fax      
       -44

_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev