Agenda and Minutes

Nokia is struggling with MTJ. It's no longer a central part of their strategy.

Made technical progress on the project, but not so good at building the community. Struggled with openness, transparency, etc.

Recognize the importance of MTJ to the foundation.

Looking for someone else to lead the project. Someone who needs it commercially. Willing to help with the project transition.

Q&A on MTJ

Samir asked about MTJ history, DSDP history

Craig explained the history of EclipseME and his participation in MTJ.

Unclear to him: how much is MTJ a platform for commercial product and how much is it a user-community tool.

Rich: definitely a general topic at the board level: commercial vs. user community.

Craig is not a committer. More of a consultant.

Craig never designed EclipseME to be an extensible platform.

MTJ is at release 0.7. Decent functionality, but not done. A roadmap for 1.0, but no staffing.

Some of Craig's concerns were complexity. Too many extensions points.

Kevin: we have a wonderful architecture underneath, but there are some areas that need to be cleaned up, and we didn't have the flexibility to fix it in the past. We are very close to 1.0. Lots of good potential in the code we have. Also, we have more flexibility to improve and simplify the architecture.

Samir: What are the details in the existing tool? Kevin responds:

MIDP - build a project, generate the resources, jad and manifest.

Hooks to deploy to a device. Only Nokia devices currently.

A little bit of visual editing for MIDP

Cross debugging.

Pre-verify for MIDP

For non-MIDP, no deploy.

No I18N.

Craig: a first release needs to be focused and get out the door.

Christian

UEI sdk - defines how an sdk can be called from an GUI

Mot released a (sort of) UEI compliant sdk, but they had to modify EclipseME to support it. They redistributed EclipseME.

For latest MOTODEV Studio, they looked at both EclipseME and MTJ (1 year ago). MTJ wasn't mature enough, and Mot really just needed basic functionality. They worked to get their sdk to work with an unmodified EclipseME. There are few things he'd like to change, but it's a good start.

Craig: do people really need a visual editor in the first release? We shouldn't play the "let's beat NB game" we should focus on basic user needs.

Samir: What are some of the pain points for mobile Java developers?

Device fragmentation: screen size, memory, etc.

Automated build and testing.

Commercial and open source needs from JME tooling

Sybase

"Unwired Enterprise Initiative"

Deploying devices and figuring out database connectivity strategies. Storage, syncing, push. Looking at how to help customers write these applications.

Want to add extensions to MTJ to address these higher-level app issues.

Original hope for MTJ was for Craig to get out from under EclipseME. It's become a second job for him. Ultimately wants to transition users to MTJ.

IBM

They no longer have a commercial product for JME development. (Web Sphere Studio Device Developer)

MTJ sits at the lower level of device entry. MTJ would be a complement to Lotus Expeditor Device, which focused on the higher level.

Also, their customers do need the low end tooling.

Want to work with the eRCP group.

They've worked hard to make MTJ work beyond CLDC-MIDP. EclipseME doesn't focus on this. Note: CDC-Personal profile can be done fairly easily with the regular Eclipse Platform

Nokia

They want to see Eclipse succeed in general.

As stated above, they no longer need MTJ commercially.

Currently recommend EclipseME or Netbeans to their users.

Symbian

They don't really do any Java development currently, but they are watching closely where Java development for devices are going.

Phone mfg's provide the VM's for Symbian

Mot

(see above)

EclipseME currently used in a product.

Want a project that makes it as easy as possible for user's to develop apps.

Two options

MTJ - dumb down the API's and UI

EclipseME - make it more of a platform

Craig: what are the problem points for extensibility?

Christian: Make it more brandable

Christian: Streamline package and deployment

Pre-verification

EMF and Rational dependency

Craig: some of this just documentation.

Kevin: we finally got this and we're able to do it now. You don't need to completely understand to use and extend the code, though.

Doug to Craig: what do you really want for EclipseME?

It's hard to build a community

I want to remain involved. I want to contribute code. But I'm not comfortable moving EclipseME users over yet. Still, I don't want to maintain EclipseME indefinitely. There needs to be a convergence.

Doug to Christian: I hear you saying that you won't want to transition off of EclipseME

I can't justify putting money towards fixing EclipseME.

I really want to see a convergence inside of an Eclipse project.

Doug to Kevin: what is your opinion on the options

It's hard to comment on EclipseME because I don't know it well.

He likes the platform concept of MTJ, but it needs to be simplified.

Hard to figure out which one would be the better base moving forward.

Craig: it's not an either or. MTJ should be the base, but with EclipseME contributions.

Project leadership and contributors

Mot

We can put partial headcount onto MTJ.

Could get headcount on leadership position on MTJ. Maybe not a good idea for Mot to lead, though, given some of the legal and process.

Nokia

Resources for transition. Perhaps involvement at a later day.

Craig

Will continue to be a consultant and help move EclipseME over.

Can't commit to time and schedule specifics.

RIM

Can't commit yet. Still working on Eclipse strategy.

Still dealing with legal.

Want to be involved in the architecture.

Sybase

Really still exploring.

IBM

Still want to contribute and participate.

Not interested in leading.

Half-time person.

Discussion

Doug: two 1/2 people + Craig is not enough to keep the project alive.

Christian: adding new features to MTJ might help funding justification

Kevin: not sure where the code is at this point. There were some last-minute drops he still needs to analyze.

Kevin and Andrew: ideally, we'd like to keep Kevin on this.

Christian to IBM: how strategic is JME outside of MIDP? IBM: Very. OSGi is important.

Misc

Christian: There is a lack of focus on emulation technology, e.g. harmony. They are working on a WTK replacement, but it would need to be relicensed to EPL. Could be a component of MTJ. Doug commented that this is a good idea, but we really need to finish the base technology first.

Roadmap discussion

Craig: start with MTJ and bring EclipseME into it. Just needs simplification.

Kevin: agrees with Craig, and again simplification of architecture is needed.

MTJ feedback from Mot analysis last week

MTJ is more complete

Most EclipseME features are available somewhere on MTJ, but spread out and confusing.

MTJ documentation is fairly complete.

Recommendation to keep MTJ and simplify.

Focus on CLDC/MIDP

Not sure about device fragmentation implementation. Recommend follow on with this.

Do we really need EMF to do this?

Visual designer and lcd.ui editor - needed, but not for the first version. Not important for their product.

They could contribute signing support now.

Action Items

Christian: will talk to Christy at Mot to see if more staffing is possible

Andrew/Kevin: will get clarity on IBM strategy and possible staffing

Other companies: go back to your companies and explain how close MTJ is to 1.0. Is it strategic enough to step up and contribute?

Due: end of October

Conclusion

Several companies believe they need this tooling, but they cannot commit to further staffing.

The foundation believes this project is needed for NB competition.

Doug believes that without further staffing, we need to kill the project. Otherwise it will just bleed to death. We will decide this after companies make one last staffing push internally.