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

[David Marques <wtv368@xxxxxxxxxxxx>]

Hello Markus,

   You are absolutely right, i must have missed that when ordering the 
states :) Thanks!!

Regards,

David Marques

Markus Sinner wrote:
> 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