Re: [dsdp-mtj-dev] MTJ Build Hooks requirements

[Markus Sinner <sinner@xxxxxxxxxxxx>]

PRE_PREPROCESS and POST_PREPROCESS should occur before PRE_COMPILE and 
POST_COMPILE, the other way it does make no sense.

David Marques schrieb:
> Hello Guys,
>
> Craig is right about the PRE_BUILD and POS_BUILD. Follows a short 
> description of the states in order:
>
>     * PRE_BUILD [Before build process starts]
>     * PRE_COMPILE [Before JDT builder starts]
>     * POST_COMPILE [After JDT builder ends]
>     * PRE_PREPROCESS [Before preprocessing]
>     * POST_PREPROCESS [After preprocessing]
>     * PRE_LOCALIZATION [Before localization]
>     * POST_LOCALIZATION [After localization]
>     * PRE_PREVERIFICATION [Before preverifying]
>     * POST_PREVERIFICATION [After preverifying]
>     * POST_BUILD [After build process ends]
>
> Answering to Ken's question about obfuscation it is only done on "Full 
> Builds" (When create package is selected). Is there any other state that 
> we should be including ??
>
> Regards,
>
> David Marques
>
> Craig Setera wrote:
> > Actually...
> >
> > I think PRE_BUILD and POST_BUILD should bracket the entire set of 
> > build steps... for a hook that really only cares about the overall 
> > build.  While you *could* base that on PRE_BUILD and 
> > POST_LOCALIZATION, that presupposes that that will always be the order 
> > of things and we won't add new steps before or after.
> >
> > Thus, we probably need PRE_COMPILE and POST_COMPILE.  I should have 
> > caught that.  I would suggest the following:
> >
> >     * PRE_BUILD
> >     * PRE_PREPROCESS
> >     * POST_PREPROCESS
> >     * PRE_COMPILE
> >     * POST_COMPILE
> >     * PRE_PREVERIFICATION
> >     * POST_PREVERIFICATION
> >     * PRE_LOCALIZATION
> >     * POST_LOCALIZATION
> >     * POST_BUILD
> >
> > That should make it clear exactly what is going on and allows new 
> > steps to be added in the flow without disturbing the overall build status.
> >
> > Craig
> >
> > On Apr 14, 2009, at 2:34 PM, Ken Wallis wrote:
> >
> > > Just to clarify, PRE-BUILD and POST-BUILD refers to the Java 
> > > compilation step only, correct?
> > >
> > > I agree ordering can come later as a use case is determined.
> > >
> > > Thanks guys.
> > >
> > >
> > > ------------------------------------------------------------------------
> > > *From*: dsdp-mtj-dev-bounces@xxxxxxxxxxx 
> > > <mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx> 
> > > <dsdp-mtj-dev-bounces@xxxxxxxxxxx 
> > > <mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx>>
> > > *To*: Mobile Tools for The Java Platform mailing list 
> > > <dsdp-mtj-dev@xxxxxxxxxxx <mailto:dsdp-mtj-dev@xxxxxxxxxxx>>
> > > *Sent*: Tue Apr 14 13:44:21 2009
> > > *Subject*: Re: [dsdp-mtj-dev] MTJ Build Hooks requirements
> > >
> > > Hello All,
> > >
> > >     Just one more thing :) We will already have the following states 
> > > being sent to the hooks:
> > >
> > >     * PRE_BUILD
> > >     * POST_BUILD
> > >     * PRE_PREPROCESS
> > >     * POST_PREPROCESS
> > >     * PRE_PREVERIFICATION
> > >     * POST_PREVERIFICATION
> > >     * PRE_LOCALIZATION
> > >     * POST_LOCALIZATION
> > >
> > > I think it is all for now!
> > >
> > > Regards,
> > >
> > > David Marques
> > >
> > >
> > > Craig Setera wrote:
> > > > I agree.  I think we should take the ordering out for now.  As I 
> > > > said, if it becomes necessary in the future, it could be added as a 
> > > > new optional element of the extension point XML.
> > > >
> > > > On Apr 14, 2009, at 12:37 PM, David Marques wrote:
> > > >
> > > > > Hi Craig,
> > > > >
> > > > >     I think that the ordering between hooks will not be a problem 
> > > > > anymore since we have the build state (step) being sent to the 
> > > > > callback. So for example if hook A implements something on step 2 
> > > > > which depends on something implemented by hook B on step 1, it will 
> > > > > be already done since all hooks will have had the chance to run 
> > > > > their step 1. So i think the priorities does not make much sense now.
> > > > >
> > > > > Did I make myself clear ?? Any thoughts ??
> > > > >
> > > > > Regards,
> > > > >
> > > > > David Marques
> > > > >
> > > > > Craig Setera wrote:
> > > > > > I was thinking about this a bit on my run this morning.  A few of 
> > > > > > the MTJ API's had a priority that was used when searching for a 
> > > > > > "match" for something.  For instance, the device importer has 
> > > > > > priorities with the idea that the most general device importer 
> > > > > > should be consulted last.  I'm not entirely sure of the goal in 
> > > > > > this particular extension point for the priority, although I can 
> > > > > > see the *potential* for wanting to have some sort of ordering 
> > > > > > amongst the registered build hooks.  For instance, hook XYZ must 
> > > > > > called after hook ABC because ABC does something that XYZ is 
> > > > > > dependent on.  The problem with using priority for something like 
> > > > > > this is that we don't have any way to control the priorities being 
> > > > > > used by various SDK's.
> > > > > >
> > > > > > *IF* there is a need to order hooks from various SDK providers, do 
> > > > > > we need some way to have an *optional* "call before" or "call 
> > > > > > after" kind thing?  This would be an optional element inside of 
> > > > > > the extension point.  It could look something like these:
> > > > > >
> > > > > > <after hook="hook-id" />
> > > > > > <before hook="hook-id" />
> > > > > >
> > > > > > This would imply that one SDK would know the identifier of a 
> > > > > > different SDK hook and that they must be called "before" or 
> > > > > > "after" that particular hook.  If unspecified (the normal I 
> > > > > > believe), no particular order would be enforced amongst the build 
> > > > > > hooks.   In my example above, this would be declared for plugin 
> > > > > > XYZ's registration:
> > > > > >
> > > > > > <after hook="ABC" />
> > > > > >
> > > > > > Because I believe that this is a fairly unlikely case and it would 
> > > > > > be optional, I think we could also defer it to a future release 
> > > > > > without much issue.
> > > > > >
> > > > > > Thoughts on this approach?
> > > > > >
> > > > > > Craig
> > > > > >
> > > > > > On Apr 14, 2009, at 11:53 AM, Ken Wallis wrote:
> > > > > >
> > > > > > > Thanks David.
> > > > > > >  
> > > > > > > Can you please provide some rationale or user cases on the 
> > > > > > > priority?  I am not sure I understand how the dynamic of 
> > > > > > > different SDK providers providing priorities works, and what the 
> > > > > > > expected behaviour is.
> > > > > > >  
> > > > > > > Thanks.
> > > > > > >  
> > > > > > > Ken Wallis
> > > > > > >
> > > > > > > Team Lead - Eclipse Tools
> > > > > > > Research In Motion
> > > > > > > 905-629-4746 x14369
> > > > > > > *From:* dsdp-mtj-dev-bounces@xxxxxxxxxxx 
> > > > > > > <mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx> [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] *On 
> > > > > > > Behalf Of *David Marques
> > > > > > > *Sent:* Tuesday, April 14, 2009 12:03 PM
> > > > > > > *To:* Mobile Tools for The Java Platform mailing list
> > > > > > > *Subject:* Re: [dsdp-mtj-dev] MTJ Build Hooks requirements
> > > > > > >  
> > > > > > > Hello Ken,
> > > > > > >
> > > > > > >     Follows some answers to your questions :)
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > David Marques
> > > > > > >
> > > > > > > Ken Wallis wrote:
> > > > > > > Unfortunately, Jon is away on vacation this week.  I am not in complete
> > > > > > > touch with the work he has been doing, and his complete thoughts on
> > > > > > > requirements, but I would like us to provide feedback on this.  I will
> > > > > > > try to be a good proxy.  ;)
> > > > > > >  
> > > > > > > I think that this approach will, as everyone suggests, be more flexible,
> > > > > > > and allow the build hook implementers to decide what they are interested
> > > > > > > in, and insert functionality into the build process where they need to.
> > > > > > > I believe this will address some of our concerns and answers some of
> > > > > > > Jon's questions through re-design.  ;)
> > > > > > >  
> > > > > > > I think there are a couple of questions from Jon's email still
> > > > > > > outstanding:
> > > > > > >  
> > > > > > > 1) How is priority used?  Is this if an SDK provides multiple build
> > > > > > > hooks, and allows us to control in what order they are executed?  Or is
> > > > > > > there some other meaning?  Is this global priority for all build hooks?
> > > > > > >   
> > > > > > > This is a global priority between hooks.
> > > > > > >
> > > > > > >  
> > > > > > > 2) Does the project reference in the callback provide access to
> > > > > > > everything a build hook may require?  Here, I am not so sure I can
> > > > > > > accurately indicate what we might need versus what is accessible, but I
> > > > > > > guess the question will have to remain outstanding until Jon's return.
> > > > > > >   
> > > > > > > The IMTJProject interface should provide everything a build hook 
> > > > > > > might require.
> > > > > > >
> > > > > > >  
> > > > > > > 3) How do we return errors to MTJ from a build hook callback, and how
> > > > > > > would MTJ handle that?  Is it just through CoreException?
> > > > > > >   
> > > > > > > In case any exception is thrown by the hook, it should be 
> > > > > > > threated as if it was an error raised internally by the builder. 
> > > > > > > This solution of throwing a CoreException follows the standard 
> > > > > > > way for of raising build errors on IncrementalProjectBuilder, so 
> > > > > > > I guess the answer to your question (Is it just through 
> > > > > > > CoreException?) is YES.
> > > > > > >
> > > > > > >  
> > > > > > > Thanks!
> > > > > > >  
> > > > > > > Ken Wallis
> > > > > > >  
> > > > > > > Team Lead - Eclipse Tools
> > > > > > > Research In Motion
> > > > > > > 905-629-4746 x14369
> > > > > > >  
> > > > > > > -----Original Message-----
> > > > > > > From: dsdp-mtj-dev-bounces@xxxxxxxxxxx <mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx>
> > > > > > > [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Craig Setera
> > > > > > > Sent: Tuesday, April 14, 2009 8:46 AM
> > > > > > > To: Mobile Tools for The Java Platform mailing list
> > > > > > > Subject: Re: [dsdp-mtj-dev] MTJ Build Hooks requirements
> > > > > > >  
> > > > > > > I'm good with it.
> > > > > > >  
> > > > > > > It would be nice to get input from the other potential "stakeholders"  
> > > > > > > of this extension point.
> > > > > > >  
> > > > > > >  
> > > > > > > On Apr 14, 2009, at 7:44 AM, David Marques wrote:
> > > > > > >  
> > > > > > >   
> > > > > > >
> > > > > > >     Hi Craig,
> > > > > > >
> > > > > > >      
> > > > > > >
> > > > > > >       Well I think it would not help much in case the hook acts on the  
> > > > > > >
> > > > > > >     last states of the build process, since it would be called several  
> > > > > > >
> > > > > > >     times yet. I think we should keep your initial proposal and document  
> > > > > > >
> > > > > > >     that the hook providers should keep their hooks "lightweight".
> > > > > > >
> > > > > > >      
> > > > > > >
> > > > > > >     How does it sound to you ??
> > > > > > >
> > > > > > >      
> > > > > > >
> > > > > > >     Regards,
> > > > > > >
> > > > > > >      
> > > > > > >
> > > > > > >     David Marques
> > > > > > >
> > > > > > >      
> > > > > > >
> > > > > > >     Craig Setera wrote:
> > > > > > >
> > > > > > >         
> > > > > > >
> > > > > > >         David,
> > > > > > >
> > > > > > >          
> > > > > > >
> > > > > > >         I do share your concerns... One possible idea... Have the callback  
> > > > > > >
> > > > > > >         return a boolean.  If true, we continue to call that callback for  
> > > > > > >
> > > > > > >         that particular project/state.  If false, we don't call that hook  
> > > > > > >
> > > > > > >         for that callback any more.  That way the hook is still completely  
> > > > > > >
> > > > > > >         in control of what hook state/project combinations the hook will be  
> > > > > > >
> > > > > > >         called for.
> > > > > > >
> > > > > > >          
> > > > > > >
> > > > > > >         Just a thought.  It may be too complex.
> > > > > > >
> > > > > > >          
> > > > > > >
> > > > > > >         Craig
> > > > > > >
> > > > > > >          
> > > > > > >
> > > > > > >         On Apr 14, 2009, at 7:28 AM, David Marques wrote:
> > > > > > >
> > > > > > >          
> > > > > > >
> > > > > > >               
> > > > > > >
> > > > > > >             Hi Craig,
> > > > > > >
> > > > > > >              
> > > > > > >
> > > > > > >              I like your idea to generalize the hooks and make them see the  
> > > > > > >
> > > > > > >             build system as a "state machine". I have some concerns regarding  
> > > > > > >
> > > > > > >             the overhead of calling all registered hooks, but let's hope hook  
> > > > > > >
> > > > > > >             providers will do their job right :)
> > > > > > >
> > > > > > >              
> > > > > > >
> > > > > > >             Well if everyone agrees on it, I will do the suggested changes.
> > > > > > >
> > > > > > >              
> > > > > > >
> > > > > > >             Regards,
> > > > > > >
> > > > > > >              
> > > > > > >
> > > > > > >             David Marques
> > > > > > >
> > > > > > >              
> > > > > > >
> > > > > > >             Craig Setera wrote:
> > > > > > >
> > > > > > >                     
> > > > > > >
> > > > > > >                 Finally found some time to look through your documents and look  
> > > > > > >
> > > > > > >                 through Jon's questions.  I hate to even make a suggestion this  
> > > > > > >
> > > > > > >                 late in the game, but I'm going to anyway <grin>
> > > > > > >
> > > > > > >                  
> > > > > > >
> > > > > > >                 In terms of the filtering, I think that we should just go ahead  
> > > > > > >
> > > > > > >                 and call the registered hooks every time.  We should leave it to  
> > > > > > >
> > > > > > >                 the hook implementor to query the currently selected device or  
> > > > > > >
> > > > > > >                 anything else of interest from the MTJ project instance and  
> > > > > > >
> > > > > > >                 decide if they want to do anything within the hook.  That way we  
> > > > > > >
> > > > > > >                 don't need to depend on a name matching routine or what the  
> > > > > > >
> > > > > > >                 various SDK's decide they want to use for the identifiers.  In  
> > > > > > >
> > > > > > >                 addition, it is much more flexible for the hook implementor in  
> > > > > > >
> > > > > > >                 terms of how they decide what they want to do and when.  We  
> > > > > > >
> > > > > > >                 should document (somewhere) that this determination needs to be  
> > > > > > >
> > > > > > >                 done as quickly as possible in the hook's implementation.
> > > > > > >
> > > > > > >                  
> > > > > > >
> > > > > > >                 To answer one of Jon's other questions, I think it may make sense  
> > > > > > >
> > > > > > >                 to generalize the pre/post build to include the *possibility* of  
> > > > > > >
> > > > > > >                 more states.  (while limiting it for now).  In theory, we have  
> > > > > > >
> > > > > > >                 lots of build states:
> > > > > > >
> > > > > > >                  
> > > > > > >
> > > > > > >                 - Pre Build
> > > > > > >
> > > > > > >                 - Pre Preprocessing
> > > > > > >
> > > > > > >                 - Post Preprocessing
> > > > > > >
> > > > > > >                 - Pre Compile
> > > > > > >
> > > > > > >                 - Post Compile
> > > > > > >
> > > > > > >                 ...
> > > > > > >
> > > > > > >                 - Post Build
> > > > > > >
> > > > > > >                  
> > > > > > >
> > > > > > >                 If we create the IMTJBuildHook interface to have a single  
> > > > > > >
> > > > > > >                 callback method that looks something like:
> > > > > > >
> > > > > > >                  
> > > > > > >
> > > > > > >                 public void buildCallback(IMTJProject project, BuildStep step,  
> > > > > > >
> > > > > > >                 IProgressMonitor _monitor)  throws CoreException
> > > > > > >
> > > > > > >                  
> > > > > > >
> > > > > > >                 We can then make BuildStep (or whatever we want to call it) be an  
> > > > > > >
> > > > > > >                 Enumeration.  I would suggest that until we have more time to  
> > > > > > >
> > > > > > >                 work through the details, that there would be only the two  
> > > > > > >
> > > > > > >                 initial BuildSteps in the enumeration of PRE_BUILD and  
> > > > > > >
> > > > > > >                 POST_BUILD.  With that said, this approach would be more  
> > > > > > >
> > > > > > >                 extensible in the future and we could add new steps in the future  
> > > > > > >
> > > > > > >                 for use by interested hook builders.  If we do this, it should be  
> > > > > > >
> > > > > > >                 documented that unexpected callback types should be *ignored* by  
> > > > > > >
> > > > > > >                 the hook.
> > > > > > >
> > > > > > >                  
> > > > > > >
> > > > > > >                 Thoughts?  I know it is a departure from your current design, but  
> > > > > > >
> > > > > > >                 I do think it is more flexible and meets some of the requirements  
> > > > > > >
> > > > > > >                 that I (think I) hear from Jon for their use.  I apologize again  
> > > > > > >
> > > > > > >                 for throwing this into the mix so late... I will try to do a  
> > > > > > >
> > > > > > >                 better job of staying on top some of this stuff.
> > > > > > >
> > > > > > >                  
> > > > > > >
> > > > > > >                 Craig
> > > > > > >
> > > > > > >                  
> > > > > > >
> > > > > > >                 David Marques wrote:
> > > > > > >
> > > > > > >                           
> > > > > > >
> > > > > > >                     Hi Craig,
> > > > > > >
> > > > > > >                      
> > > > > > >
> > > > > > >                      I see your point, although mtj does not use the ISDK interface  
> > > > > > >
> > > > > > >                     anywhere yet, so for now it would not work. How about doing this  
> > > > > > >
> > > > > > >                     change latter when the ISDK interface is used by MTJ ??
> > > > > > >
> > > > > > >                      
> > > > > > >
> > > > > > >                     Regards,
> > > > > > >
> > > > > > >                      
> > > > > > >
> > > > > > >                     David Marques
> > > > > > >
> > > > > > >                      
> > > > > > >
> > > > > > >                     Craig Setera wrote:
> > > > > > >
> > > > > > >                                 
> > > > > > >
> > > > > > >                         Sorry... As usual lately, I'm swamped.  I guess I have a  
> > > > > > >
> > > > > > >                         concern with the SDK name being used as the identifier in the  
> > > > > > >
> > > > > > >                         general case... in particular when we get the new SDK extension  
> > > > > > >
> > > > > > >                         point up and going.  It seems to me that we likely need to add  
> > > > > > >
> > > > > > >                         a getIdentifier() method to the SDK object and that that name  
> > > > > > >
> > > > > > >                         will be the SDK name by default for "imported" Devices/SDKs.
> > > > > > >
> > > > > > >                          
> > > > > > >
> > > > > > >                                       
> > > > > > >
> > > > > > >                 _______________________________________________
> > > > > > >
> > > > > > >                 dsdp-mtj-dev mailing list
> > > > > > >
> > > > > > >                 dsdp-mtj-dev@xxxxxxxxxxx <mailto:dsdp-mtj-dev@xxxxxxxxxxx>
> > > > > > >
> > > > > > >                 https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
> > > > > > >
> > > > > > >                           
> > > > > > >
> > > > > > >             _______________________________________________
> > > > > > >
> > > > > > >             dsdp-mtj-dev mailing list
> > > > > > >
> > > > > > >             dsdp-mtj-dev@xxxxxxxxxxx <mailto:dsdp-mtj-dev@xxxxxxxxxxx>
> > > > > > >
> > > > > > >             https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
> > > > > > >
> > > > > > >                     
> > > > > > >
> > > > > > >         _______________________________________________
> > > > > > >
> > > > > > >         dsdp-mtj-dev mailing list
> > > > > > >
> > > > > > >         dsdp-mtj-dev@xxxxxxxxxxx <mailto:dsdp-mtj-dev@xxxxxxxxxxx>
> > > > > > >
> > > > > > >         https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
> > > > > > >
> > > > > > >               
> > > > > > >
> > > > > > >     _______________________________________________
> > > > > > >
> > > > > > >     dsdp-mtj-dev mailing list
> > > > > > >
> > > > > > >     dsdp-mtj-dev@xxxxxxxxxxx <mailto:dsdp-mtj-dev@xxxxxxxxxxx>
> > > > > > >
> > > > > > >     https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
> > > > > > >
> > > > > > >         
> > > > > > >
> > > > > > >  
> > > > > > > _______________________________________________
> > > > > > > dsdp-mtj-dev mailing list
> > > > > > > dsdp-mtj-dev@xxxxxxxxxxx <mailto:dsdp-mtj-dev@xxxxxxxxxxx>
> > > > > > > https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
> > > > > > >  
> > > > > > > ---------------------------------------------------------------------
> > > > > > > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
> > > > > > > _______________________________________________
> > > > > > > dsdp-mtj-dev mailing list
> > > > > > > dsdp-mtj-dev@xxxxxxxxxxx <mailto:dsdp-mtj-dev@xxxxxxxxxxx>
> > > > > > > https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
> > > > > > >   
> > > > > > >  
> > > > > > > --------------------------------------------------------------------- 
> > > > > > > This transmission (including any attachments) may contain 
> > > > > > > confidential information, privileged material (including material 
> > > > > > > protected by the solicitor-client or other applicable 
> > > > > > > privileges), or constitute non-public information. Any use of 
> > > > > > > this information by anyone other than the intended recipient is 
> > > > > > > prohibited. If you have received this transmission in error, 
> > > > > > > please immediately reply to the sender and delete this 
> > > > > > > information from your system. Use, dissemination, distribution, 
> > > > > > > or reproduction of this transmission by unintended recipients is 
> > > > > > > not authorized and may be 
> > > > > > > unlawful. _______________________________________________
> > > > > > > dsdp-mtj-dev mailing list
> > > > > > > dsdp-mtj-dev@xxxxxxxxxxx <mailto:dsdp-mtj-dev@xxxxxxxxxxx>
> > > > > > > https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
> > > > > >
> > > > > > ------------------------------------------------------------------------
> > > > > > _______________________________________________
> > > > > > dsdp-mtj-dev mailing list
> > > > > > dsdp-mtj-dev@xxxxxxxxxxx
> > > > > > https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
> > > > > >   
> > > > >
> > > > > _______________________________________________
> > > > > dsdp-mtj-dev mailing list
> > > > > dsdp-mtj-dev@xxxxxxxxxxx <mailto:dsdp-mtj-dev@xxxxxxxxxxx>
> > > > > https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
> > > >
> > > > ------------------------------------------------------------------------
> > > >
> > > > _______________________________________________
> > > > dsdp-mtj-dev mailing list
> > > > dsdp-mtj-dev@xxxxxxxxxxx
> > > > https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
> > > >   
> > >
> > > ---------------------------------------------------------------------
> > > This transmission (including any attachments) may contain 
> > > confidential information, privileged material (including material 
> > > protected by the solicitor-client or other applicable privileges), or 
> > > constitute non-public information. Any use of this information by 
> > > anyone other than the intended recipient is prohibited. If you have 
> > > received this transmission in error, please immediately reply to the 
> > > sender and delete this information from your system. Use, 
> > > dissemination, distribution, or reproduction of this transmission by 
> > > unintended recipients is not authorized and may be unlawful.
> > > _______________________________________________
> > > dsdp-mtj-dev mailing list
> > > dsdp-mtj-dev@xxxxxxxxxxx <mailto:dsdp-mtj-dev@xxxxxxxxxxx>
> > > https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > dsdp-mtj-dev mailing list
> > dsdp-mtj-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
> >   
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> dsdp-mtj-dev mailing list
> dsdp-mtj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev

--

*********************************
sinner@xxxxxxxxxxxx
http://www.psitronic.de

psitronic IT-Solutions
Markus Sinner
W-Rathenau-Str. 14 - 68642 Bürstadt
Tel.: (+49)6206 / 963513
Fax:  (+49)6206 / 963514