Community
Participate
Working Groups
When opening or importing an existing project who's runtime configurations specifies SDKs or devices that are not installed in the current workspace, those devices are set to null. Instead the user should be able to match them against the installed SDKs and devices in case there are relevant matches. These matches could then be cached so that it happens automatically with subsequent imports. This has been discussed on the mtj-dev mailinglist in http://dev.eclipse.org/mhonarc/lists/dsdp-mtj-dev/msg01253.html.
Created attachment 142311 [details] mtj.core patch
Created attachment 142312 [details] mtj.ui patch
Created attachment 142313 [details] match dialog
Find attached an approach to solve the mentioned problem. When doing loadDevice (in MTJRuntime and MetaData) and the device registry returns null (no device found) the fallback match method is called. 'match' will try to find alternative devices through its extension point, currently it does: 1) from a cache 2) by interacting with the user through a dialog (where the user can choose to put his choice into the cache) There are some issues left that I am currently working on; one is that the changed devices are not directly written to the configuration file (".mtj"). I've done the infrastructure for detecting this but left saveMetaData() commented in MetaData.loadMetaData(), since it does not work as expected. Also, the javaMEClassPathContainer path does not get updated automatically, I have not yet found a way to do that.
Hi Daniel, great job with the patch. I just tested it and everything worked fine as you described. After looking through the code I have some questions that I would like to share with you. 1) Copyright Notices Aren't you contributing this code for SonyEricsson? If this is a personal contribution, the notice is ok to be "Copyright (c) 2009 Daniel Olsson and others." but if you are an employee of Sony Ericsson and you are contributing this code in their name, the notice should be "Copyright (c) 2009 Sony Ericsson". 2) I saw you included new API classes in MTJ. This is really necessary? who will be using this new API externally to mtj itself?. Couldn't it be an internal API? 3) On the matching dialog, do you think that giving the user the option of renaming the configuration to match the newly selected device would be a useful enhancement? 4) If a user sets to remember a match in the matching dialog, and after some time, this matched device is removed. what will happen the next time this cached match occurs? 5) This is your final version of the patch or are you will continue working in this issue? If you will provide more patchs, please, set your "Compiler Compliance Level" to 1.5. MTJ is built over 1.5 and you can accidentally use 1.6 specific apis. Well, I think that's all for now :) Thanks again for you contribution. Diego Madruga
(In reply to comment #5) > 1) Copyright Notices > Aren't you contributing this code for SonyEricsson? If this is a personal > contribution, the notice is ok to be "Copyright (c) 2009 Daniel Olsson and > others." but if you are an employee of Sony Ericsson and you are contributing > this code in their name, the notice should be "Copyright (c) 2009 Sony > Ericsson". Yes, I will fix that. Furthermore, next patch will have another name as contributor (due to an internal SonyEricsson policy). > > 2) I saw you included new API classes in MTJ. This is really necessary? who will > be using this new API externally to mtj itself?. Couldn't it be an internal API? > Yes, they could be internal. If - in the future - anyone want to use them, they could then be made public. > 3) On the matching dialog, do you think that giving the user the option of > renaming the configuration to match the newly selected device would be a useful > enhancement? Good point! Small challenge though, since I've made this part of the DeviceRegistry... I'll think of something. > 4) If a user sets to remember a match in the matching dialog, and after some > time, this matched device is removed. what will happen the next time this cached > match occurs? Null we be returned. The cache just do string substitution, the device registry is still used for getting the IDevice object. > 5) This is your final version of the patch or are you will continue working in > this issue? If you will provide more patchs, please, set your "Compiler > Compliance Level" to 1.5. MTJ is built over 1.5 and you can accidentally use 1.6 > specific apis. I'll work with it until it's fine. Expect an updated patch this or next week. Fixed compiler compliance. > Thanks again for you contribution. Thanks for the feedback
Thanks for the answers. We'll be waiting for you next patch.
Created attachment 144230 [details] mtj.core patch
Created attachment 144231 [details] mtj.ui patch
Created attachment 144232 [details] match dialog
Added updated patches: * Added configuration name as a textbox in the match dialog * Triggered a rewrite of the .mtj file and a rebuild when any matching have been done - to prevent project from opening up with errors Minor issue: The IDeviceMatcher currently have two match functions, I do not think this is ideal. They could as well be replaced by one, but that would in the case of loadDevice() result in unnecessary conversions (IDevice->String->IDevice).
(In reply to comment #11) > Added updated patches: > > * Added configuration name as a textbox in the match dialog > * Triggered a rewrite of the .mtj file and a rebuild when any matching have > been done - to prevent project from opening up with errors > > Minor issue: > The IDeviceMatcher currently have two match functions, I do not think this is > ideal. They could as well be replaced by one, but that would in the case of > loadDevice() result in unnecessary conversions (IDevice->String->IDevice). > Hi Daniel, Thanks for the new patch. I will revise it and get back to you as soon as possible. Diego Madruga
Hi Daniel, great job, everything works as expected. This patch was accepted and will be committed to SVN as soon as you can confirm on Bugzilla that wrote 100% of the code and have the right to contribute the code to Eclipse. You can use the template available in the Developer Resources section of MTJ's wiki pages: http://wiki.eclipse.org/DSDP/MTJ/Developer_Resources/Contributor_Confirmations Thanks again for your contribution. Diego
I, Daniel Olsson have created the patches (attachment 144230 [details],attachment 144231 [details]) solely based on existing (EPL licensed) code in the MTJ project, and wrote all new code 100% myself, without using any other open source or proprietary source code as a basis for my work. I am making my contribution available under the terms of the Eclipse Public License (EPL) to be included in the codebase of the MTJ project.
Thanks for your contribution. It will be available in the N20090821 NB.
Released
