Jump to: navigation, search

Difference between revisions of "DSDP/MTJ/Phone Meeting 17-June-2008"

< DSDP‎ | MTJ
m (Conference Call Details)
 
(5 intermediate revisions by one other user not shown)
Line 5: Line 5:
 
|-
 
|-
 
| Date & Time:  
 
| Date & Time:  
  11 AM PDT [[http://timeanddate.com/worldclock/fixedtime.html?month=6&day=17&year=2008&hour=11&min=0&sec=0&p1=224|Click here for you local time]]
+
| 11 AM PDT [[http://timeanddate.com/worldclock/fixedtime.html?month=6&day=17&year=2008&hour=11&min=0&sec=0&p1=224| Click here for you local time]]
|
+
 
|-
 
|-
 
| US Toll free:
 
| US Toll free:
Line 43: Line 42:
  
 
* Other items as added by participants on call
 
* Other items as added by participants on call
 +
 +
 +
Minutes:
 +
 +
== Discussion about Scope & Requirements ==
 +
 +
Targeted development platforms (Craig proposal): Windows, Linux, MAC
 +
 +
 +
==== Pre-verifier: ====
 +
 +
* We implemented support for "Mpower" preverifier.
 +
* (Craig) MPower is a good long term requirement to support MAC development
 +
* Not clear if we need embedded preverifier if we can allow external preverifiers
 +
 +
 +
* Pro-guard support is implemented (by Gustavo), but not commited to SVN yet.
 +
 +
Summary:
 +
  current code supports MAC/Lin/Win development by using external preverifier
 +
 +
 +
==== Which SDK's should we support ====
 +
 +
Currently there is several old (non-UEI) SDK's supported.
 +
Proposal is to move those "legacy" code into a unsupported status.
 +
 +
 +
IF in the future we want to refactor the code to simplify the implementation of a "device importer" support, we would not modify all of this code.
 +
 +
(Craig) We need to maintain a balance - and e.g. leave some (MicroME and Mpower) supported.
 +
 +
Currently, MTJ cannot be easily modified to change the build process. This may be a future requirement.
 +
 +
 +
--
 +
(Ken) How would we need to change the build process to support RIM build.
 +
* RIM uses JADs similar to MIDP
 +
* Signing
 +
* Support for Runtime library
 +
 +
(Craig) Blackberry is almost a post-build step. He can use Jad/Jar to generate a RIM deployable file
 +
 +
 +
--
 +
Question:
 +
How do we support i18n? (localization of the resources of a Midlet)
 +
Could be considered part of the SDK.
 +
Post 1.0 discussion?
 +
 +
--
 +
Regarding: how to include libraries in Midlets.
 +
There is extension points to define the set of libraries to create custom device profiles.
 +
 +
 +
Sybase Usecase: include a JAR file in the build/deploy is already supported in the MTJ toolkit.
 +
currently - we can/need to mark them as "exported", which will include them in the generated JAR file.
 +
 +
 +
Sybase Question:
 +
How can we better integrate / support Device capabilities in MTJ? Netbeans seems to have very tight/good integration of this.
 +
(Gustavo) We may need JDT changes? More analysis needed.
 +
(Eric) This, and the support for multiple targets, could be post 1.0 features.
 +
 +
 +
Documentation:
 +
Currently - the MTJ documentation is based on EclipseME documentation.
 +
This would be sufficient for End-User documentation for 1.0
 +
 +
Testing:
 +
Craig mentioned that it is necessary to write some user level test cases to validate MTJ
 +
Gustavo commented that once the requirements are closed, we will start working in a test to do that.
 +
 +
==== Next Steps ====
 +
 +
Goal for 1.0 release is functional equivalent to EclipseME.
 +
 +
Problem:  How will we do testing for the 1.0 release?
 +
Gustavo:  the automated (unit) tests will not be available before end of year.
 +
For now - lets do manual tests?
 +
 +
 +
Changes requests:
 +
Several bugs and feature request were discussed during the call. below is a list of all the ones that we could capture
 +
* update / close requirements
 +
* write test cases
 +
* enable button to set preverifier
 +
* write FAQ for MTJ developers
 +
* document build process
 +
 +
* refactoring the api (focus on build)
 +
* include runtime lib on create project
 +
* i18n tool
 +
* remove unused sdks
 +
* write MTJ SDK dev guide
 +
* review current MTJ documentation (check if it is updated and  follow eclipse standards)
 +
 +
short term roadmap:
 +
 +
Until end of July, finish preprocessing, create a release candidate, start collecting test-cases on wiki.
 +
 +
 +
Next conference call planned in end of July.  Try to accommodate China Timezone.

Latest revision as of 11:30, 23 June 2008

Conference Call Details

Meeting Title: Mobile Tools for the Java Platform Conference Call
Date & Time: 11 AM PDT [Click here for you local time]
US Toll free: +1-877-825-8522
Int'l or US Toll: +1-770-615-1247
Finland: 0800770232
Brazil: 0800-891-6245
Passcode: 9190565826#

Proposed Agenda

Conference Agenda:

  • Confirm the current scope as documented on the Wiki pages.
  • Go through the status and assign a responsible party for each of the activity
  • Understand the next steps to do the official release (moving from a nightly build to an integration build, stable build and finally the release after a few release candidates? In between the releases there may be maintenance builds. We should also set dates for each of the intended builds â you can see an example here, for Ganymede: http://wiki.eclipse.org/Ganymede_Simultaneous_Release, see Milestones and Release Candidates)
  • Preverifier status summary
  • Proposals for a MTJ roadmap items in the 2008/2009 timeframe
  • Integration of Non-UEI SDKs, is it possible, what are the missing pieces (documentation?)
  • Supported platforms?
  • GUI builders:
    • Should we have one?
    • Does anyone actually use LCD UI?
    • Can we integrate with commercial ones?
    • How would we deal with generated code?
  • Other items as added by participants on call


Minutes:

Discussion about Scope & Requirements

Targeted development platforms (Craig proposal): Windows, Linux, MAC


Pre-verifier:

  • We implemented support for "Mpower" preverifier.
  • (Craig) MPower is a good long term requirement to support MAC development
  • Not clear if we need embedded preverifier if we can allow external preverifiers


  • Pro-guard support is implemented (by Gustavo), but not commited to SVN yet.

Summary:

  current code supports MAC/Lin/Win development by using external preverifier


Which SDK's should we support

Currently there is several old (non-UEI) SDK's supported. Proposal is to move those "legacy" code into a unsupported status.


IF in the future we want to refactor the code to simplify the implementation of a "device importer" support, we would not modify all of this code.

(Craig) We need to maintain a balance - and e.g. leave some (MicroME and Mpower) supported.

Currently, MTJ cannot be easily modified to change the build process. This may be a future requirement.


-- (Ken) How would we need to change the build process to support RIM build.

  • RIM uses JADs similar to MIDP
  • Signing
  • Support for Runtime library

(Craig) Blackberry is almost a post-build step. He can use Jad/Jar to generate a RIM deployable file


-- Question: How do we support i18n? (localization of the resources of a Midlet) Could be considered part of the SDK. Post 1.0 discussion?

-- Regarding: how to include libraries in Midlets. There is extension points to define the set of libraries to create custom device profiles.


Sybase Usecase: include a JAR file in the build/deploy is already supported in the MTJ toolkit. currently - we can/need to mark them as "exported", which will include them in the generated JAR file.


Sybase Question: How can we better integrate / support Device capabilities in MTJ? Netbeans seems to have very tight/good integration of this. (Gustavo) We may need JDT changes? More analysis needed. (Eric) This, and the support for multiple targets, could be post 1.0 features.


Documentation: Currently - the MTJ documentation is based on EclipseME documentation. This would be sufficient for End-User documentation for 1.0

Testing: Craig mentioned that it is necessary to write some user level test cases to validate MTJ Gustavo commented that once the requirements are closed, we will start working in a test to do that.

Next Steps

Goal for 1.0 release is functional equivalent to EclipseME.

Problem: How will we do testing for the 1.0 release? Gustavo: the automated (unit) tests will not be available before end of year. For now - lets do manual tests?


Changes requests: Several bugs and feature request were discussed during the call. below is a list of all the ones that we could capture

  • update / close requirements
  • write test cases
  • enable button to set preverifier
  • write FAQ for MTJ developers
  • document build process
  • refactoring the api (focus on build)
  • include runtime lib on create project
  • i18n tool
  • remove unused sdks
  • write MTJ SDK dev guide
  • review current MTJ documentation (check if it is updated and follow eclipse standards)

short term roadmap:

Until end of July, finish preprocessing, create a release candidate, start collecting test-cases on wiki.


Next conference call planned in end of July. Try to accommodate China Timezone.