Skip to main content

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


Back to the top