My feeling is that we should definitely try to have an
automatic update of project files when the files are opened with a newer
version. We need not support the reverse case, where a newer project is opened
by an older IDE.
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
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
|