The focus here is only the javame configurations / profiles (such as
midp). As craig mentioned, there are a limited numbers of them and
they
don't change frequently. So it would not be a problem to have this in
some property file and just do a new release when something change.
:)
gep
-----Mensagem original-----
De: dsdp-mtj-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] Em nome de Danail Nachev
Enviada em: segunda-feira, 9 de fevereiro de 2009 10:54
Para: Mobile Tools for The Java Platform mailing list
Assunto: Re: RES: RES: [dsdp-mtj-dev] Library Information API
I'm not very deep in the discussion, but I want to ask how will this
information be updated/extended? Using properties file has the
drawback
that it cannot be updated/extended, because it is carved in the MTJ
bundles. Did I missed something?
BR,
--
Danail Nachev
Senior Software Engineer/Development Tools
ProSyst Labs EOOD
-------------------------------------------------
stay in touch with your product.
-------------------------------------------------
Paula Gustavo-WGP010 wrote:
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:
Hi craig,
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.
J
gep
------------------------------------------------------------------------
*De:* dsdp-mtj-dev-bounces@xxxxxxxxxxx
<mailto: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
* org.eclipse.mtj.core.api
<http://dsdp.eclipse.org/help/latest/topic/org.eclipse.mtj.doc.isv/html/
reference/extension-points/org_eclipse_mtj_core_api.html>
* org.eclipse.mtj.core.configurations
<http://dsdp.eclipse.org/help/latest/topic/org.eclipse.mtj.doc.isv/html/
reference/extension-points/org_eclipse_mtj_core_configurations.html>
* org.eclipse.mtj.core.profiles
<http://dsdp.eclipse.org/help/latest/topic/org.eclipse.mtj.doc.isv/html/
reference/extension-points/org_eclipse_mtj_core_profiles.html>
and the MIDletlibrary would be renamed to something like
externalLibrary,?
Diego
On Sat, Feb 7, 2009 at 6:11 PM, Craig Setera <craigjunk@xxxxxxxxxx
<mailto: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
<mailto: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
<http://dsdp.eclipse.org/help/latest/topic/org.eclipse.mtj.doc.isv/html/
reference/extension-points/org_eclipse_mtj_core_api.html>
org.eclipse.mtj.core.configurations
<http://dsdp.eclipse.org/help/latest/topic/org.eclipse.mtj.doc.isv/html/
reference/extension-points/org_eclipse_mtj_core_configurations.html>
org.eclipse.mtj.core.library.MIDletLibrary
<http://dsdp.eclipse.org/help/latest/topic/org.eclipse.mtj.doc.isv/html/
reference/extension-points/
org_eclipse_mtj_core_library_MIDletLibrary.ht
ml>
org.eclipse.mtj.core.profiles
<http://dsdp.eclipse.org/help/latest/topic/org.eclipse.mtj.doc.isv/html/
reference/extension-points/org_eclipse_mtj_core_profiles.html>
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 <mailto: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 <mailto:dsdp-mtj-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx <mailto: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 <mailto:dsdp-mtj-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx <mailto: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
_______________________________________________
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
