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

[Gorkem Ercan <gercan@xxxxxxx>]

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
>
>