RE: [dsdp-mtj-dev] Extension point for defining devices

["Hildum Eric-XFQ473" <XFQ473@xxxxxxxxxxxx>]

Speaking to Sun last week at JMMED, there is apparently a UEI version
1.1 specification under development by Sun. Presumably this addresses
the additional requirements imposed by the new Sun WTK. Unfortunately, I
have no further information than that at this point.


Eric Hildum
Senior Product Manager, Mobile Developer Tools & SDK
Software Platforms and Delivery
Ecosystem and Market Development
Motorola
Direct: +1-408-541-6809
Mobile: +1-510-305-0801
 
809 11th Avenue
Sunnyvale, CA 94089
USA

-----Original Message-----
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Craig Setera
Sent: Monday, January 26, 2009 8:37
To: Mobile Tools for The Java Platform mailing list
Subject: Re: [dsdp-mtj-dev] Extension point for defining devices

Agreed... But the idea of adding "extended" functionality to UEI (UEI+ 
+ ?? ) is still a possibility.

On Jan 26, 2009, at 10:33 AM, Hildum Eric-XFQ473 wrote:

> A critical point to consider is that SDK developers do not have only  
> Eclipse + MTJ as a target. Any plugin/P2 based solution will  
> inherently be Eclipse only, thus will face adoption issues.
>
> SDKs currently use the UEI specification as that is the only one out  
> there that is supported by all major IDEs.
>
> Any proposed solution needs to be IDE agnostic as well as SDK  
> agnostic.
>
>
> Eric Hildum
> Senior Product Manager, Mobile Developer Tools & SDK
> Software Platforms and Delivery
> Ecosystem and Market Development
> Motorola
> Direct: +1-408-541-6809
> Mobile: +1-510-305-0801
>
> 809 11th Avenue
> Sunnyvale, CA 94089
> USA
>
> -----Original Message-----
> From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx 
> ] On Behalf Of Gorkem Ercan
> Sent: Monday, January 26, 2009 0:41
> To: Mobile Tools for The Java Platform mailing list
> Subject: Re: [dsdp-mtj-dev] Extension point for defining devices
>
> Craig,
> I totally understand, I hope that people, who wants to see that
> feature sooner,  will be kind enough to offer help on the
> implementation :)
>
> In any case, it may be a good idea to have an enhancement request open
> for this (if there is not already one)
> --
> Gorkem
>
> On Fri, Jan 23, 2009 at 2:20 AM, Craig Setera <craigjunk@xxxxxxxxxx>  
> wrote:
>> Gorkem,
>>
>> I agree that the end goals are compatible and these should all be  
>> considered
>> together.  We have a pretty serious open issue in terms of our  
>> current
>> API's.  My assumption is that we will need to "finalize" the current
>> importer API for a 1.0 release and then look seriously at some of  
>> these
>> other options as future additions.  I think we probably need to be  
>> looking
>> seriously at controlling what else we sign up for relative to the 3.5
>> release, especially in terms of API's.  In the future, we need to  
>> spend
>> significantly more time working with the community as a whole to  
>> propose and
>> iteratively develop new API's.
>>
>> For those that are not already aware... The API's that currently  
>> exist in
>> MTJ were originally created by me in EclipseME to service my own  
>> needs with
>> no external input.  I won't claim that they are well suited for all
>> situations.  This was one of the discussion points when it was  
>> decided to
>> restart MTJ with the EclipseME code base.  I was convinced by  
>> others at the
>> time that what was there worked "well enough" as a starting point  
>> and that
>> we would work hard to improve the API/platform part of the code  
>> over time.
>> I guess only time will tell! <grin>
>>
>> Craig
>>
>> Gorkem Ercan wrote:
>>
>> Please take a look at the MADK proposal[1] that was proposed in the
>> Eclipse Mobile Industry Working Group [2]. I think the idea is the
>> same on both proposals.
>>
>> Also there is an interesting discussion going on related to
>> downloading packages that are not EPL compatible [3], even when
>> downloading/installing through p2 there may be legal requirements.
>>
>> I think this is a good feature that may lower the barriers for
>> starters and apparently this is a desired feature since it has been
>> voiced through several sources.
>>
>>
>> [1] http://wiki.eclipse.org/EMIWG/MADKQuickStartProposal
>> [2] http://wiki.eclipse.org/EMIWG
>> [3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=246945#c9
>>
>> --
>> Gorkem
>>
>>
>>
>> On Thu, Jan 22, 2009 at 9:00 PM, Adam Abramski <aabramski@xxxxxxx>  
>> wrote:
>>
>>
>> As Paula has explained, this is definitely one of RIM's concerns.
>> Having more flexibility without imposing too much on the plug in
>> implementers is a better approach in my opinion as well.
>>
>> Sincerely,
>> Adam
>>
>>
>>
>> -----Original Message-----
>> From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-
>> bounces@xxxxxxxxxxx] On Behalf Of Paula Gustavo-WGP010
>> Sent: Thursday, January 22, 2009 10:30 AM
>> To: Mobile Tools for The Java Platform mailing list
>> Subject: RES: [dsdp-mtj-dev] Extension point for defining devices
>>
>> Hi danail,
>>
>> Thanks for your interested on mtj!
>>
>> Let me see if i understand your correctly your suggestion.
>> 1- mtj will have a declarative way to describe an sdk / devices
>> 2- this declarative way would be published via an extension point
>> 3- each sdk provider (like nokia, mot or rim) would have a plugin  
>> that
>> implements the EP and describe its sdk. The whole sdk also need to be
>> provided as a set of plugins / binaries
>> 4- the user would just use p2 to find / install / update sdks on his
>> eclipse
>> 5- mtj would automatically find the installed sdks via the EP
>>
>> If that's what you mean, I think that it is great idea. But probably
>>
>>
>> it
>>
>>
>> is hard to make it happen. The main issue that I see is that this
>>
>>
>> would
>>
>>
>> require all sdk providers to change their sdk distribution mechanism.
>>
>>
>> So
>>
>>
>> instead of RIM providing a windows installer they would need to
>>
>>
>> provide
>>
>>
>> a p2 repository. This is a high impact on all providers and I don't
>>
>>
>> know
>>
>>
>> if they want to do that. if they don't them mtj would not be able to
>> support that specific sdk. What I like in the current device importer
>> solution, which was inherited completely from eclipseme, is that it  
>> is
>> really flexible. Mtj can support any sdk once the importer / editor
>>
>>
>> are
>>
>>
>> implemented. So we don't' force anything on the sdk side. There are
>> still some improvements that we can do on this area.
>>
>> Maybe we can talk about proposing that, but we would still need to
>> support the current solution to be compatible with the sdks that are
>> already available.
>>
>> Any thoughts?
>>
>> :)
>> gep
>>
>>
>> -----Mensagem original-----
>> De: dsdp-mtj-dev-bounces@xxxxxxxxxxx
>> [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] Em nome de Danail Nachev
>> Enviada em: quarta-feira, 21 de janeiro de 2009 13:07
>> Para: dsdp-mtj-dev@xxxxxxxxxxx
>> Assunto: [dsdp-mtj-dev] Extension point for defining devices
>>
>> Hi guys,
>>
>> First, I want to say that the work you are doing with MTJ has been
>>
>>
>> long
>>
>>
>> awaited and MTJ will nicely complement the existing Eclipse tools
>> covering large portion of the software development.
>>
>> So, straight to the point:
>>
>> I couldn't find a way for a plugin to define new devices. There is a
>>
>>
>> way
>>
>>
>> to define importer, which can be used to detect new types of SDKs and
>> there is an API, which can be called to add new devices to the
>>
>>
>> registry,
>>
>>
>> but there is no way for a plugin to state:
>>
>> I'm a SDK for this and this device.
>>
>> If a plugin can declaratively specify new devices:
>>
>> * p2 can be used for Java ME SDK installation/update
>> * a vendor-specific IDE/extension can easily define the supported
>> devices (w/o complex code)
>>
>> What do you think?
>>
>> BR,
>> --
>> Danail Nachev
>> Senior Software Engineer/Development Tools
>> ProSyst Labs EOOD
>> -------------------------------------------------
>> stay in touch with your product.
>> -------------------------------------------------
>> _______________________________________________
>> 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
>>
>>
>> ---------------------------------------------------------------------
>> 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
>> 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
>>
>>
> _______________________________________________
> 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

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