[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RES: RES: RES: [dsdp-mtj-dev] Library Information API
|
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
