Sorry… my mistake J i misunderstood
your first email.
I agree that the best
option is that the drop down contents of profiles and configurations on the JAD
editor come from this property files.
J
gep
De:
dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] Em nome de Craig Setera
Enviada em: segunda-feira, 9 de
fevereiro de 2009 09:46
Para: Mobile
Tools for The Java Platform mailing list
Assunto: Re: RES: [dsdp-mtj-dev]
Library Information API
See below...
On Feb 9, 2009, at 6:42 AM, Paula Gustavo-WGP010 wrote:
I like the idea of a
properties file with the versions.
I do too... I'm not sure why I felt the need to put
that into an extension point at the time... It definitely feel like overkill at
this point.
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?
I'm not suggesting that. I haven't looked at this code in a
while, so things may have changed since EclipseME. In the last EclipseME
release of the code, the options in the configuration and profile drop-downs
were populated by the values from the above extension points. If we had
chosen to derive that information from the associated "external libraries"
information (rather than a simple properties file), that would have implied
that there would be no values available until a device had actually been
imported. If we just use a properties file, that association is no longer
necessary and we don't have an issue.
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
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
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
--
Diego Madruga Sandin
Linux User #416542
--
Diego Madruga Sandin
Linux User #416542
_______________________________________________ dsdp-mtj-dev mailing list dsdp-mtj-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
|