[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [dsdp-mtj-dev] Questions about S60 3rd Ed. FP1 SDK support
|
Can you attach your changes to the bug report so that I can also take them and test them. I have also ran into that ZipException.
Thanks.
--
Gorkem
On Thu, May 28, 2009 at 5:29 PM, Paula Gustavo-WGP010
<wgp010@xxxxxxxxxxxx> wrote:
Hi Gorken,
I tested on 6.5 and it worked ok.
I was able to do some workaround on mtj to
import and build. The change was on the StandardPreverifier class (method
constructCommandLine). MTJ always check if there is some invalid classes when
we run the preverifier (-cldc option). This fails with this SDK since it only
provide a lib jar file (and no cldc compliant stubs).
But now I can’t run he MIDlet. There
is an error: Symbian SDK - java.util.zip.ZipException: invalid entry compressed
size (expected 1252 but got 1255 bytes)
It would be nice if we can have this sdk
supported. But, even if we are able to find a solution, I’m also
concerned to do last minute changes that might break something that is already
working.
J
gep
It was tested on NetBeans 6.5 and I am told that WTK 3.0 embedded one is not
the same.
--
Gorkem
On Thu, May 28, 2009 at 4:27 PM, Paula Gustavo-WGP010 <wgp010@xxxxxxxxxxxx> wrote:
Can you detail a little bit which project specific
configuration needs to be done?
I just tried to import this SDK on netbeans (WTK 3.0 that
include netbeans) and it also fails. Do you know which IDE is usually used by
the developers that use this SDK?
J
gep
Only after setting the project specific settings for
preverification also there may be a problem with packaging need to check
On Thu,
May 28, 2009 at 4:16 PM, Paula Gustavo-WGP010 <wgp010@xxxxxxxxxxxx>
wrote:
Hi gorken,
I did some tests with this SDK. I was able to import it
(removing the code to filter CDC devices) but not to build a MIDlet suite. If
gives a preverification error because the stubs seems to be invalid. Were you
able to build the MIDlet Suite and create a package?
J
gep
The change on the MTJ code basically enables
UEIDeviceImporter to import an SDK that does not report a CLDC API. The problem
stems from the workaround to avoid importing SDKs that supports CDC. So the fix
is isolated to removing the workaround. As a side note, I am not sure,
why we want to avoid importing CDC compatible SDKs actually. It is true that
current MTJ does not offer CDC compatible tooling but someone may just want to
provide that on top of it.
Once the SDK is imported everything seems to work fine. There are a few places
where the CLDC API info is used but on those places it just falls back to CLDC
1.0.
--
Gorkem
_______________________________________________
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