[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [dsdp-mtj-dev] Library Information API
|
So, the deviceLibrary would merge
and the MIDletlibrary would be renamed to something like externalLibrary,?
Diego
On Sat, Feb 7, 2009 at 6:11 PM, Craig Setera
<craigjunk@xxxxxxxxxx> wrote:
Ahh... That was not at all clear to me given our current
documentation. I would agree that there are two concepts at play
here. Maybe what we need is something along the lines of
"deviceLibrary" and "externalLibrary"?? (Not sure I like the naming of
the second one). Device library could be an amalgamation of the
current API, configuration and libraries extension points?
Diego Madruga Sandin wrote:
Hi
Craig,
the MIDletLibrary is not used to declare jsr`s it used to declare some
library to be used in a MIDlet that is not provided by the device
itself. For example, we have the library used for unit testing, the
JMunit. This library is declared using the MIDletlibrary E.P. This E.P,
its not related at all with jsr and the API E.P. they serve for
different purposes, so i don`t agree on merging it with the API E.P or
remove it.
I believe we must keep both E.P, but document them better. I agree
that the MIDletLibrary naming is odd and we can change the name to be
more clear.
Cheers
Diego
On Sat, Feb 7, 2009 at 3:47 PM, Craig Setera
<craigjunk@xxxxxxxxxx>
wrote:
We currently have 4 core
extension points that are all pretty related
and probably a bit confusing at this point. This is my primary API
concern and I'd like to see if we can get it nailed down. The current
extension points are:
org.eclipse.mtj.core.api
org.eclipse.mtj.core.configurations
org.eclipse.mtj.core.library.MIDletLibrary
org.eclipse.mtj.core.profiles
The "API" extension point was originally provided to help out with the
preverification functionality (internal preverifier). It provided
access to the "stub" libraries for use during preverification. Taking
internal preverification out of the equation as we have at this point,
I believe this extension point can just go away for now. If we need
similar functionality in the future, we can always add it back. I'm
assuming that the MIDletLibrary "name" attribute specifies the JSR name?
The configurations and profiles extension points were added in
EclipseME to support selection within the UI of the profile or
configuration. If we add a "type" indicator to the MIDlet library, the
UI can be driven by the available profiles and configurations in the
list of libraries and remove these extension points as well. The only
concern I can see with this approach is that it means that you must
have SDK/devices imported in order to have profiles/configurations in
the JAD editor selector. I'm not entirely sure how to deal with that.
Thoughts?
The MIDletLibrary extension point seems a bit odd in naming. I can't
think of another example that I've seen with an extension point
starting with capital letters. I don't see it as a huge issue, but if
we don't change it before calling it "done", we can't change it after.
Thoughts on this?
Thanks,
Craig
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
--
Diego Madruga Sandin
Linux User #416542
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
--
Diego Madruga Sandin
Linux User #416542