[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [dsdp-mtj-dev] EmptyAPIGenerator and Embedded Preverifier

Hi Guys,

I also agree with the proposal. Just to keep the discussions/suggestion
about the default preverifier for Java Emulators, Diego and I discussed
some improvements in the Device Manager, that will separate information
concerning the SDKs and Devices (nowadays everything is mixed up in
devices). We believe that this solution will decrease the confusion
raised by Craig when the user changes the preverifier to be used with a
specific SDK.

Hugo

-----Original Message-----
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Paula
Gustavo-WGP010
Sent: Monday, August 04, 2008 1:45 PM
To: Mobile Tools for The Java Platform mailing list
Subject: RE: [dsdp-mtj-dev] EmptyAPIGenerator and Embedded Preverifier

I agree with the proposal that you made. This is easier to implement in
our first release... More opinions? 

:)
gep 

-----Original Message-----
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Craig Setera
Sent: domingo, 3 de agosto de 2008 19:59
To: Mobile Tools for The Java Platform mailing list
Subject: Re: [dsdp-mtj-dev] EmptyAPIGenerator and Embedded Preverifier

I finally found some time today to take a look at where things are at
with the current MTJ code.  I wrote up a few bugs and fixed a couple of
them.  There are two outstanding bugs that I wrote that are related to
this discussion:

Can't import Microemu 2.0.3 snapshot 37
https://bugs.eclipse.org/bugs/show_bug.cgi?id=243000

Embedded preverifier fails with NPE
https://bugs.eclipse.org/bugs/show_bug.cgi?id=243001

While I'm concerned with the removal of all of the empty API stuff and
the related loss of functionality, I think it is a reasonable thing to
do for the first release.  I'd like to see how it goes in the future
without that support.  In order for this to work, it seems to me that at
least two things need to happen:

- The user needs a place in the preference to point to a default
preverifier to be used for the Java emulators.  Without that option, the
user is forced to alter each device that is imported. 
- The system needs to automatically associate the configured default
preverifier whenever the user imports a Java-based emulator.  Otherwise,
it is way too confusing and leads to bugs like the above.

I did not write up specific bugs for this functionality, because I
thought it was worth discussing via the email list before deciding on a
final solution.  What are others thoughts on this topic?

Thanks,
Craig

Raniere Hugo-wha006 wrote:
>
> Hi Craig,
>
>  
>
> MicroEmu has Skeletons for all API that it supports. The problem with 
> MicroEmu was that their CLDC stubs had a corrupted bytecode, 
> preventing it to work properly with WTK preverifier. This problem is 
> already fixed and will be released in version 2.0.3 of MicroEmu 
> (current is 2.0.2).
>
>  
>
> I do not think we really need this skeletons distributed with MTJ, as 
> they are supposed to be part of a device SDK. If initial your 
> intention was to provide a better out-of-the-box experience, I still 
> think that the skeletons should come of the SDK and providing only 
> them will not improve the OOTB experience. If we really need to 
> improve it, we can think about, in the future, distributing and entire

> SDK within MTJ (one of this JavaSE based SKD, ME4SE, MicroEmu or
MPower).
>
>  
>
> Lets try to keep this discussion in order to have an agreement soon 
> and decide what to do with the CQs
>
>  
>
> J
>
> Hugo
>
>  
>
>
_______________________________________________
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