RES: [dsdp-mtj-dev] Extension point for defining devices - Back onTrack

["Paula Gustavo-WGP010" <wgp010@xxxxxxxxxxxx>]

Hi craig,

I looked at JDT extension point. Roughly what is does is define a way
that eclipse can automatically find a JRE location (path on the file
system) and "import" it into JDT. 

So if we transfer this concept to MTJ, the extension point will also
have some like:

* SDK Name
* SDK Path
* class that implements ISDK interface (similar to what you described
below)

Then mtj will automatically import all SDKs that are registered via this
EP.

But to be honest, I only see this working if the whole SDK is delivered
via p2 and placed in some "pre-defined" folder. Then it makes sense to
have to have a plugin that automatically says where the sdk is installed

Motorola does something like that, but I think that it is the only sdk
provider that does it.

More thoughts???

:)
gep

-----Mensagem original-----
De: dsdp-mtj-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] Em nome de Craig Setera
Enviada em: quinta-feira, 29 de janeiro de 2009 22:14
Para: Mobile Tools for The Java Platform mailing list
Assunto: Re: [dsdp-mtj-dev] Extension point for defining devices - Back
onTrack

The basic idea that I have in my head goes something like this:

* Introduce a new ISDK interface into the MTJ models. 
** ISDK has a name
** ISDK manages a list of IDevice instances
** There are likely other things to go here and I believe that Diego is 
already proposing this interface
* The current device importer implementations is altered to implicitly 
create a new ISDK with the created devices
* All of the UI is updated to use the SDK's within the IDE (the device 
selector primarily)
* A new extension point is added to register an ISDK instance.
** This extension point would specify the "name" of the SDK
** The extension point would specify the implementing class for the ISDK

instance

There is likely more to it, but this seems like the basics.  The 
implication here is that an ISDK is entirely responsible for the devices

being managed.  How and where those devices come from is not part of the

system.  The instances can be generated "on the fly" as necessary by the

SDK, or stored away some where.  The core MTJ functionality would not 
attempt to persist or resurrect device that are owned by an SDK.  This 
also implies that the current implementations for UEI and such would 
need to be altered to do the device persistence themselves.

This is the basic idea I've been pondering for this.  In the end, it 
isn't well formed enough to be considered for Galileo in my mind.... We 
need to continue the discussion to figure out if this works at all and 
what would need to be done to make it work.  I haven't looked seriously 
at the JRE extension points to see how close or far this proposal is 
from the JRE definition.

Thanks,
Craig

Christian Kurzke wrote:
> Hildum Eric-XFQ473 wrote:
>> This would probably impact projects, which associate one or more 
>> devices with the projects. How would we reestablish these
associations?
>>   
>
> This raises an interesting question:
>
> Should a project be associated with an "SDK" or with a "Device".
> e.g. If a project is associated with a Device, and there is more than 
> one SDK providing (posible updated) support for the same Device, how 
> would this be handled.
> Or, when an updated SDK is providing support for the same devices, 
> should the project be automatically using the newer SDK?
>
> This may lead to problems where a developer wants to temporarily try 
> out multiple SDKs for the same device.
>
> My recommendation is that the project association is with a 
> combination of "SDK ID and Device ID", and no behind the scenes 
> changes to surprise the developer.
> I think something like the JDT VmInstall ID.  see: 
>
http://help.eclipse.org/stable/topic/org.eclipse.jdt.doc.isv/reference/e
xtension-points/org_eclipse_jdt_launching_vmInstalls.html 
>
>
> Btw, Danail, thanks for the idea with the JDT VM registration analogy,

> i think this is a very good reference for how we can solve this.
>
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev