[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [dsdp-mtj-dev] Possible MTJ Contribution
|
Hi again and sorry,
I didn't identify myself too well.
I am Mika Hoikkala from Nokia.
Project lead for MTJ.
Email: mika.hoikkala@xxxxxxxxx
GSM: +358 50 56 350 56
mho
>-----Original Message-----
>From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
>[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx]
>Sent: 03 August, 2006 15:13
>To: dsdp-mtj-dev@xxxxxxxxxxx
>Subject: RE: [dsdp-mtj-dev] Possible MTJ Contribution
>
>Hi,
>
>Nice to hear about you.
>
>We are definitely interested in to co-operate those areas you
>mentioned.
>Fragmentation especially is a problem in mobile space and we
>are not sure if we have even vision of "perfect" solution yet.
>
>So views how things should be solved,
>contribution/implemtation of it are all welcome.
>
>Do you have something in your mind how to take next steps?
>
>Can you provide a bit more information what you have currently?
>
>mho
>
>>-----Original Message-----
>>From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
>>[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of ext Sebastian
>>Sickelmann
>>Sent: 03 August, 2006 14:39
>>To: dsdp-mtj-dev@xxxxxxxxxxx
>>Subject: [dsdp-mtj-dev] Possible MTJ Contribution
>>
>>Hi,
>>
>>I am the CTO from Four2B GmbH (in Germany) and we are developing
>>JavaME-products in various fields (games, showrooms,
>>informationservices, etc). So we have first-hand expirence on the
>>difficulties which come along with porting Java applications
>to various
>>JavaMe Devices.
>>
>>Our first choice has been J2ME-Polish as our buildsystem and
>Eclipse as
>>IDE. After using some refactoring functions we soon hit the hard
>>reality of JavaMe-Development. Most of the markup-code we used for
>>automatic builds was not usuable anymore.
>>YES. Refactoring breaks your "preprocessor-spiked"-code.
>>
>>AspectJ and other AOP-Frameworks are in most cases to unhandy or
>>oversized to substitute the comment-based preprocessor-approach.
>>
>>We have started a project to fix this problem, in order to keep the
>>code more readable and refactorable.
>>
>>If there is any interesst in contributions on your side, we could
>>imagine to contribute to the following usecases:
>>
>>- Execute the application (at least taking part in the specification
>>process)
>>- Manage fragmentation (code contributions)
>>- Localize the application (code contributions)
>>
>>We are not sure about the licence-type we should use (open, closed,
>>splitted).
>>My personal point of view is that we should bring some development
>>force back to the eclipse-community.
>>
>>If there is any interesst in exchanging the "comment-style"
>>preprocessor-approach with an alternative, i will ask our
>management to
>>open-source our solution (including localization support).
>>
>>Hope to hear some positive response
>>
>>Kind regards
>>Sebastian Sickelmann
>>_______________________________________________
>>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
>