| I think we can probably remove it for now. I thought there were some ties into the code that actually mattered, but the primary reason it was originally introduced was to support the embedded preverifier. With that gone, it is certainly not as necessary.
In general, I'm in agreement with removing any public API we possibly can for this first release to avoid "lock in" of supporting that API in the long term.
Craig On Feb 11, 2009, at 5:41 AM, Paula Gustavo-WGP010 wrote: Hi craig, I did some tests with diego and MTJ worked the same with or without it (we tested the import of both an UEI sdks and microemu). I’m not sure if we are missing something on the code. And when we looked at this extension in a perspective of a public MTJ API, we could not identify a clear use case that it implements. So following that approach to simplify mtj api, we suggest to remove it. again, this is just a suggestion that is open to discussions. Do you see some scenario where it will be used by someone? What are your thoughts on that? J gep So, the API extension point is now completely gone? I thought that one was staying, but being renamed to something else? On Feb 9, 2009, at 11:30 AM, Paula Gustavo-WGP010 wrote:
Hi, We are working now on the extension points for tomorrow’s build. Initially we plan to have the following extension points defined on MTJ: Core plugin: - org.eclipse.mtj.core.deviceimporter
- org.eclipse.mtj.core.externallibrary UI Plugin - org.eclipse.mtj.ui.vendorattributes
- org.eclipse.mtj.ui.jadeditorpage
- org.eclipse.mtj.ui.deviceeditor Probably it is possible to merge both jad editor extensions, but the impact now is quite high now. We are still evaluation how to do it. J gep
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
|
