Hi Craig,
We do have
an issue open for project-level
metadata. This is described in bug 96623. The code is complete and
pending
internal peer reviews here.
This
proposal is for something similar.
Through further investigation, however, I realize that the ability for
an SDK
provider save arbitrary device data is already there. The AbstractMIDPDevice class
offers an IPersistenceProvider through
its loadUsing()and saveUsing() methods.
These methods can be overridden by specific IMIPDevice
implementations.
In my
discussions with other MTJ’ers,
it was suggested this new API would make the act of adding metadata
more clear
and less error prone. But I am a little shy extending the API without
any large
gain in benefit.
Thoughts?
Cheers,
Jon
Do we have a similar
improvement issue open for
project-level metadata? I know we discussed this via the email list,
but
I'm not sure it went any further.
Jon Dearden wrote:
Hi
everyone,
Bug 286675 describes an
API addition for storing
vendor-specific meta data with an MTJ project in the .mtj file. The
benefit is
that the SDK provider can store project level meta data without having
to
manually manage the store. The meta data will automatically be disposed
along
with the project as well. The code is being reviewed and I hope to have
a
submission for this shortly. I would like to present a new and similar
proposal
for device definition data.
Proposal for storing vendor-supplied data with device definitions:
Under Device Management,
you can edit your device
definitions. The stock fields include the description, location of the
emulator
and preverifier, the list of libraries, and a few other items. SDK
providers
supply emulators which have many and varied runtime settings and they
will want
to easily persist user preferences. This proposal is that we offer a
standard
mechanism for storing arbitrary vendor-defined properties in the
device.xml
file where MTJ stores its device settings.
Associating SDK provider properties with a device means that they are persisted with the device and automatically disposed when a device is deleted. Without this capability, a vendor must:
- locate an appropriate folder
- persist the data
- manage the lifecycle of their store file
The proposal is to add the following API methods to IMIDPDevice:
public
Properties getSdkProviderProperties(String
sdkId)
throws
IllegalArgumentException;
public
void setSdkProviderProperties(String
sdkId, final Properties properties)
throws
IllegalArgumentException;
SDK provider properties will be stored in the devices.xml file as follows:
<device0 bundle="com.acompany.mtjtoolkit" class="com.acompany.mtjtoolkit.bigbadphone" id="0">
...
<sdkProviderProperties>
<sdk id=”com.acompany.mtjtoolkit”>
<property name=”binDirectory” value =
“c:\\ACompany\\BigBadPhone\\bin”/>
<property name=”userSetting1” value = “true”/>
<property
name=”userSetting2” value = “42”/>
</sdk>
</sdkProviderProperties>
...
</device0>
There will be no restriction on how many 'sdk' elements that will be allowed under a ‘sdkProviderProperties’ element, though typically there will be only one. If this were not the case, then some other party could overwrite the one and only SDK provider section.
I have opened bug 288549 for this discussion. All comments are most appreciated.
Regards,
Jon
---
Senior Software
Developer, Eclipse Tools
Research In Motion
905-629-4746 x15333 / Mobile:
519 500-23167
jdearden@xxxxxxx
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public
information. Any use of this information by anyone other than the
intended
recipient is prohibited. If you have received this transmission in
error,
please immediately reply to the sender and delete this information from
your
system. Use, dissemination, distribution, or reproduction of this
transmission
by unintended recipients is not authorized and may be unlawful.
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
---------------------------------------------------------------------