Hi guys,
Has there been any further discussion
about the possibility of a core.buildhook
addition to the API for allowing us to hook into pre- and post-build events?
Cheers,
Jon
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On
Behalf Of Paula Gustavo-WGP010
Sent: Friday, February 27, 2009
11:02 AM
To: Mobile Tools for The Java
Platform mailing list
Subject: RES: RES: [dsdp-mtj-dev]
new round of mtj api review
Hi craig,
I understand and share your concern. when
I looked at what is still there, in terms of public api, it is still a little
confusing. So my feeling is that there is still room for some cleaning (move
more classes/interfaces to be internal and do some refactoring). The main
issues that I see are:
- the symbolset api seems to be
duplicated: there are two packages with similar classes / interfaces. We want
see if we can leave just one of them
- clarify the concepts of library and api
classes (core.sdk.deivce.midp.library): there are several classes / interfaces
that are public but it is not clear how to use them
- there are a lot of interfaces that are
public on the mtj.core that can be moved to be internal
I’m trying to leave as public only what
make sense to be public and that we can commit to maintain on the future.
If we fix those 3 issues, I think that we
are going to be ok with our public apis.
Extract isdk from idevice, is something
that we discussed a lot here on the list. This is more an improvement than a
fix. We can postpone it to a future release, but I just thought that it is a
good time to do it J.
in terms of extension points, out current
list is:
- core.externallibrary
- core.deviceimporter
- ui.midlettemplates
- ui.jadeditorpages
- ui.jadattributes
- ui.deviceeditor
The plan is to keep all of that as they
are now. I was also wondering about adding two more that we already have some
discussions about them on the list:
- core.sdkinstall: import an sdk
automatically when MTJ is started (this come from that suggestion sent by
danail. We already have a bug opened for that). this extension point is
associated to the isdk interface
- core.buildhook: hook into mtj build
before and/or after the preverifier builder (this requirements comes from some
discussion we had with RIM. I’m not sure if we can just use the project
nature / builder for that we don’t add any api). I will send a separated
email about that.
J
gep
De: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx]
Em nome de Craig Setera
Enviada em: quinta-feira, 26 de
fevereiro de 2009 20:40
Para: Mobile
Tools for The Java Platform mailing list
Assunto: Re: RES: [dsdp-mtj-dev]
new round of mtj api review
Sorry... this email got lost in my inbox.
My primary concern with *any* API changes at this time is that there is really
no time to get feedback on those changes. The argument in favor of making
the changes now is that it is easier than making them later. With that
said, if we really do lock these things in as API, we will need to support
them.
What is your feeling at this point in terms of things that we are actually
marking as API versus things that are provisional for 1.0?
Craig
Paula Gustavo-WGP010 wrote:
hi craig,
sorry for the late response. it is carnaval here in brazil :)
the change that we want to do now is to create the isdk interface. we didn't have time to do that in the last round :(. besides that there are also changes that we identify, but i'm not sure if we sohuld do it or not.
the idea is to remove imidpdevice and leave only the abstractmidpdevice class. the main motivation is that, if anyone is going to implement a midp device, he can just extend the abstractmidpdevice class and the interface is not necessary. but im not totaly convinced this is a good thing to do. do you think that this make sense?
:)
gep
________________________________
dp-mtj-dev-bounces@xxxxxxxxxxx em nome de Craig Setera
Enviada: qui 19/2/2009 21:32
Para: Mobile Tools for The Java Platform mailing list
Assunto: Re: [dsdp-mtj-dev] new round of mtj api review
Looks pretty good. Do we really want to bite off the IDevice/ISDK interface refactoring? Is that already done? Those seem like API classes that we should get in early in the *next* release so that we can get some burn in and feedback. I have concerns with us putting a lot of API changes in this late in the cycle when there isn't time to validate that those changes are what we want. (with the exception of making things private until we have time to vet them)
Paula Gustavo-WGP010 wrote:
Hi MTJ,
We did a new round of mtj api review and open a list with a several improvements. This list is available on mtj 1.0 plan
http://www.eclipse.org/projects/project-plan.php?projectid=dsdp.mtj <http://www.eclipse.org/projects/project-plan.php?projectid=dsdp.mtj>
under theme / priorities "MTJ API Documentation and Unit Tests". The focus was on the mtj.core plugin.
Please feel free to comment on those bugs and / or add new bugs. We plan to address those improvements on the following builds
:-)
gep
________________________________
_______________________________________________
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
---------------------------------------------------------------------