I actually think this is pretty common. I don't think that there is a
guarantee of workspace compatibility when you use a newer version of
Eclipse. Although project metadata that is checked in is a bit
different, but I think this is fair given that this is a pre-1.0
version.
Do we need to consider a more "extensible" file format going forward to
avoid having this issue in the future?
Craig
Hildum Eric-XFQ473 wrote:
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
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
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
|