Hi craig,
I like the idea of a
properties file with the versions.
About the jad editor, currently
there is no direct association between the sdk import process and the jad
editor page. There are two separated EPs that are not related to each other. Are
you suggesting that we associate those extension points?
J
gep
De: dsdp-mtj-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] Em
nome de Craig Setera
Enviada em: domingo, 8 de
fevereiro de 2009 23:38
Para: Mobile
Tools for The Java Platform mailing list
Assunto: Re: [dsdp-mtj-dev]
Library Information API
I'm thinking something like that anyway.
Thoughts on the fact that the JAD editor dropdowns would have dependencies on a
device having been imported before the values would be available in the
drop-down? Given how rarely the CDC/CLDC/MIDP library versions change, we
could probably just hardcode the available values (or put them into a simple
properties file) rather than an extension point. That would remove
the need for the extension points and their registrations altogether.
Diego Madruga Sandin wrote:
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
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev