[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [dsdp-mtj-dev] MTJ preprocess content assist support
|
I think we can deal with the issue of 0.9 opening a 0.91 file
by documentation (essentially, "don't operate mixed teams"). As MTJ is in the
early stages, I expect we are going to change the project data formats more
frequently, and we should not have many project files scattered about. Instead,
we should document the compatibility breaks, and have the forward/backward
compatibility as discussed below.
Eric Hildum
Senior Product Manager, Mobile Developer
Tools & SDK
Software Platforms and
Delivery
Ecosystem and Market
Development
Motorola
Direct: +1-408-541-6809
Mobile: +1-510-305-0801
809 11th Avenue
Sunnyvale, CA 94089
USA
Hi all,
I would like to explain how I deal with metadata file
compatibility and the Configurations management UI. 1. Forward and backward compatibility.
What I do is just keep all xml element as it is (in old
version) in the new version metadata, and add new information about
configurations. I don't use version info in .mtj metadata file to do migration. So if old version MTJ open new version Midlet project (which contains a
new version .mtj metada file), it just ignore the configurations
information. If new version MTJ open an old version
Midlet project (which contains a old version .mtj metada file), it will create a
configuration automatically according the top level <device> xml element.
And then will ignore the top level <device> element, use the device in
active configuration for current device. So we have the
backward compatibility, and limited forward compatibility. A known issue is that if user use MTJ 0.9 to open MTJ 0.9.1 project, and
do save metadata operation, all configurations information in .mtj file will
disappeared. A big problem is that if a team work on a Midlet project, someone
use 0.9.1 and someone use 0.9, configurations information will be deleted by
guys use 0.9. If we persist Configurations infromation in a separate file (not
in .mtj) file, we can avoid this. But this lead to a new metadata file in
project, and if in future when we need to add some other metadata, we may again
create a new metada file in project. A Midlet project may have to many matedata
files. Do you guys think it's worth for us to store
Configurations in a separate file?(Now I store them in .mtj file and I guess
it's not hard to store them in another file) Bellow
is the old version .mtj file format and new version .mtj file format:
Old version: <?xml version="1.0" encoding="UTF-8"?>
<mtjMetadata jad="
Test.jad" version="0.9.0.qualifier"> <device group="Sun Java(TM) Wireless
Toolkit 2.5.2 for CLDC" name="MediaControlSkin"/> <signing
signProject="false"/>
</mtjMetadata> New version: <?xml version="1.0" encoding="UTF-8"?>
<mtjMetadata
jad="Test.jad" version="0.9.1"> <device group="Series 40 5th Edition
SDK, Feature Pack 1" name="S40_5th_Edition_SDK_Feature_Pack_1"/>
<signing
signProject="false"/> <configurations> <configuration
active="true" name="A910"> <device group="Series 40
5th Edition SDK, Feature Pack 1"
name="S40_5th_Edition_SDK_Feature_Pack_1"/>
<symbolSet> <symbol
name="JSR172" value="1.0"/> <symbol
name="screen.bitDepth" value="16"/> <symbol
name="version.configuration" value="CDLC-1.1"/>
<symbol name="JSR75" value="1.0"/>
</symbolSet> </configuration> <configuration
active="false" name="DefaultColorPhone"> <device
group="Sun Java(TM) Wireless Toolkit 2.5.2 for CLDC"
name="DefaultColorPhone"/> <symbolSet>
<symbol name="J2ME-WS" value="1.0"/>
<symbol name="CLDC" value="1.1"/>
</symbolSet> </configuration>
</configurations>
</mtjMetadata> 2.
For Configurations management UI.
The workflow is not complex. User can
add/edit/remove/switch-active configuration with that UI. When user change the
checked element in the Configurations CheckboxTableViewer, and do save in
Application Descriptor editor or click Finish on project properties page, active
configuration will switch. Active SymbolSet and current device will
change.
Best
Regards,
Feng(Marvin) Wang(王峰)
Sybase Software (China) Co.,
Ltd
Room 1202-1203, Building One,
Zhangjiang Semiconductor Industry
Park
3000 Longdong Avenue
Pudong, Shanghai 201203
Tel: +8621-38657441
or 258-7441
email: feng.wang@xxxxxxxxxx
"Hildum Eric-XFQ473"
<XFQ473@xxxxxxxxxxxx> Sent by: dsdp-mtj-dev-bounces@xxxxxxxxxxx
2008-11-05 04:33
Please respond
to Mobile Tools for The Java Platform mailing list
<dsdp-mtj-dev@xxxxxxxxxxx> |
|
To
| "Mobile Tools for The
Java Platform mailing list" <dsdp-mtj-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| RE: [dsdp-mtj-dev] MTJ
preprocess content assist support |
|
Okay, I am convinced. The version of MTJ is sufficient for our
purposes. Eric
Hildum Senior Product Manager, Mobile
Developer Tools & SDK Software Platforms
and Delivery Ecosystem and Market
Development Motorola Direct: +1-408-541-6809 Mobile:
+1-510-305-0801 809 11th Avenue Sunnyvale, CA
94089 USA
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Craig
Setera
Sent: Tuesday, November 04, 2008 12:24
To: Mobile
Tools for The Java Platform mailing list
Subject: Re: [dsdp-mtj-dev]
MTJ preprocess content assist support
That is the intention of the version in the file... you just need to know
what version boundaries the format changed occurred...
if x > y then migrate1 if x >
z then migrate2 The problem with a single version
number for the file format is that there may be more dependencies on why you
would want to do the migrate.... not to mention that the version number is
already there in this way. On Nov 4, 2008, at 2:18
PM, Hildum Eric-XFQ473 wrote: Yes, we could use that; however that means we need to keep a list of
which versions of MTJ wrote what version of the file. I was actually thinking of
a version number for the project file itself that updates only when the project
file format/content changes. Eric Hildum Senior Product
Manager, Mobile Developer Tools & SDK Software Platforms and Delivery Ecosystem and Market Development Motorola Direct:
+1-408-541-6809 Mobile:
+1-510-305-0801 809 11th Avenue Sunnyvale, CA
94089 USA
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Sandin Diego-WDS057
Sent:
Tuesday, November 04, 2008 11:43
To: Mobile Tools for The Java
Platform mailing list
Subject: RE: [dsdp-mtj-dev] MTJ preprocess
content assist support
The .mtj metadata
file has the version of MTJ used to create that project.
<?xml version="1.0"
encoding="UTF-8"?> <mtjMetadata jad="LibSupport.jad" version="0.9.0.qualifier"> <device group="Sun Java(TM)
Wireless Toolkit 2.5.2 for CLDC" name="MediaControlSkin"/>
<signing
signProject="false"/> </mtjMetadata> |
We can use this info to automatically run a migration
job. Diego
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Hildum Eric-XFQ473
Sent:
Tuesday, November 04, 2008 4:37 PM
To: Mobile Tools for The Java
Platform mailing list
Subject: RE: [dsdp-mtj-dev] MTJ preprocess
content assist support Automatically migrating forward is a better idea I think. If we
establish a policy in the code that we propagate old versions forward
automatically (from X versions back) and ignore with warnings unrecognized
fields to handle fall back situations, we should be able to maintain good
forward and backward compatibility. Do we have a major/minor version number in
the project file we can use to trigger conversions? Eric Hildum Senior Product
Manager, Mobile Developer Tools & SDK Software Platforms and Delivery Ecosystem and Market Development Motorola Direct:
+1-408-541-6809 Mobile:
+1-510-305-0801 809 11th Avenue
Sunnyvale, CA 94089 USA
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Paula Gustavo-WGP010
Sent:
Tuesday, November 04, 2008 4:55
To: Mobile Tools for The Java Platform
mailing list
Subject: RE: [dsdp-mtj-dev] MTJ preprocess content assist
support hi gang, thanks for the detailed requirements... they look
great! below are some
comments FR001 - Configuration
data format & persistence:
if the user already has a MTJ project
created with 0.9 what will happen when he opens it with 0.9.1? you mention that
the the .mtj file format will be changed. probably it would be important that the code checks if the project is
in the 0.9 format and automatically convert it to the new format (then we would
keep workspace compatibility). other options is to have the configurations on
another file and keep the .mtj file as it is to have a backword compatibility.
not sure if it better. the last option is to just break the workspace
compatibility, but i'm not sure if it is a good ideia to do that.
the change on the format also means that
a 0.9.1 project will not be opened with MTJ 0.9 isn't it? Multi-Config: FR003 - manage configurations
do you have some suggestion on the UI
workflow for that? besides that, how is the user going to set the current active
configuration? Multi-Config:
FR007 - Preprocess symbols content-assist are we also going to do some kind of validation based on the symbol
type? for instance mark the core with "error" if teh develoeprs enter something
like //#if screenwidth > "gustavo". not sure if this is necessary (or even
possible), but might be good for the user :) gep
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf OfGang.Ma@xxxxxxxxxx
Sent: terça-feira, 4 de novembro de 2008
07:54
To: Mobile Tools for The Java Platform mailing
list
Subject: [dsdp-mtj-dev] MTJ preprocess content assist
support
Hi all,
I have
updated the wiki page to add detail information about the preprocess content
assist support, please see it at:http://wiki.eclipse.org/DSDP/MTJ/Requirements/Multi-Configuration_Support, from "Multi-Config: FR006" to "Multi-Config:
FR009"
I also create some bugzilla entries for it:
1.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=253648 ([multdevice]: Preprocess directive content-assist),
describe how to show preprocess directive proposal
2. https://bugs.eclipse.org/bugs/show_bug.cgi?id=253653 ([multdevice]: Preprocess symbols content-assist),
describe how to show preprocess symbol proposal
3. https://bugs.eclipse.org/bugs/show_bug.cgi?id=253162 ([multdevice]: Preprocess Template content-assist),
describe how to show preprocess template proposal
4. https://bugs.eclipse.org/bugs/show_bug.cgi?id=253645 ([multdevice]: Preprocess template configuration),
describe how to configure preprocess template.
any comments
and suggestions are welcome.
Best Regards
Gang(Allen)
Ma
Sybase Software (China) Co., Ltd _______________________________________________
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