Re: [dsdp-mtj-dev] MTJ preprocess content assist support

[Feng.Wang@xxxxxxxxxx]

If Metada#save() method will not erase
other element (other than device, signing, configurations), if we add new
element into .mtj file in future, it will have backward compatibility.
I will do this.

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

Craig Setera <craigjunk@xxxxxxxxxx>
Sent by: dsdp-mtj-dev-bounces@xxxxxxxxxxx

2008-11-10 07:31

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

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

---

From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx]
On Behalf Of Feng.Wang@xxxxxxxxxx
Sent: Tuesday, November 04, 2008 18:31
To: Mobile Tools for The Java Platform mailing list
Cc: Mobile Tools for The Java Platform mailing list; dsdp-mtj-dev-bounces@xxxxxxxxxxx
Subject: RE: [dsdp-mtj-dev] MTJ preprocess content assist support


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

---

_______________________________________________
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