[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dsdp-mtj-dev] MTJ Build Hooks requirements
|
Hi Craig,
I see your point, although mtj does not use the ISDK interface
anywhere yet, so for now it would not work. How about doing this change
latter when the ISDK interface is used by MTJ ??
Regards,
David Marques
Craig Setera wrote:
Sorry... As usual lately, I'm swamped. I guess I have a concern with
the SDK name being used as the identifier in the general case... in
particular when we get the new SDK extension point up and going. It
seems to me that we likely need to add a getIdentifier() method to the
SDK object and that that name will be the SDK name by default for
"imported" Devices/SDKs.
On Apr 13, 2009, at 2:26 PM, David Marques wrote:
Hello everyone,
I would like to know if someone has any more comments on it since i
am planning to finish the code and commit it tomorrow.
Regards,
David Marques
David Marques wrote:
Hello Graig,
It is based on the device's SDK name returned by the
IDevice.getSDKName method. It seems to be the device's sdk id, isn't
it ??
Regards,
David Marques
Craig Setera wrote:
Is the hook filter really based on "name" or is it based on id's?
On Apr 13, 2009, at 7:36 AM, David Marques wrote:
Hi Jon, follows the answers to your questions.
Hope i could make it clear enough...
Regards,
David Marques
Jon Dearden wrote:
Hi David,
Thank you for your work on this. I have a few questions...
1. How is the SDK filter used?
Does each SDK provider get one call-back in total? One call-back for
each SDK provided? Or, one call-back for each device? How does MTJ
identify the SDK? The reason I ask is that it appears the regular
expression approach is somewhat loser than an approach where MTJ can
identify which specific SDK a device belongs to.
The SDK filter is used in order to define to which SDKs the hook
will be attached. For example, if i define a hook for Motorola.*
all SKDs which name starts with "Motorola" will have the hook
attached to all it's devices during their build process.
2. How does MTJ make use of the priority attribute?
The priority attribute is used to order the hooks' execution. For
example if hook 1 has priority 1 and hook 2 has priority 2 the
hook 1 will be called before hook 2 both in the pre and pos build
callbacks.
3. Does the IMTJProject reference in the pre/postBuild call-backs
supply
access to everything a SDK provider may need?
For our needs, as a start, we require the location of the
device/deployed folders for our devices, the root directory of
our SDK
(so we can get bin, simulator, etc), the names of the JAR and
JAD, the
libraries associated with the SDK, and such. The basic concern
here, of
course is, is IMTJProject the portal that will give an SDK provider
everything they may need?
From IMTJProject the developer has access to both IJavaProject and
IProject instances and all the reosurces that may be needed.
4. What exactly is meant by "build"?
Is this the whole series of actions that takes place when the user
clicks "Create Package"?
The "build" process that i have been talking about, is the project
build (both incremental and full build). During incremental build
only the active configuration is built, although the build hooks
DO act upon this build also, and as you expect, the hooks act on
all configurations during the full build (when the user clicks
"Create Package").
What "sub steps" are included? Does it make any
sense to notify the SDK provider at the beginning and end of each of
this steps?
What do you mean by "sub steps", are you considering for example
each builder attached to a project one step ??
5. Is it possible that we might want to return a value from the
preBuild
call to indicate to MTJ that we would like a step to be skipped?
No, since we do NOT have a "build step" concept implemented on our
build solution.
One example use case is where an SDK provider has some post-build
step
(such as signing) that should only be taken after everything and
does
not want that action taken during the build phase. That may not be a
great example, but perhaps there is a need for an SDK provider to
influence the process in this way?
Well i guess the pre/pos build hooks will be enough on most
situations, although i think the worst case would be if for some
reason some SDK provider has some specific requirements (such as
when signing), it would have to do some extra work after the
default signing action during the build process (such as
implementing a post build hook).
6. How can we meaningfully report back to MTJ that an error has
occurred
on our part during the pre or postBuild call? Should an error
value be returned? An exception thrown? Will these
exceptions be defined in the API? If we can report an error, then
MTJ
can present some meaningful message to the user, rather than a
general
"some error occurred" result.
The hook's callbacks interface throw CoreException which is the
same exception thrown by the builders for errors during build.
Cheers,
Jon Dearden
Research In Motion
-----Original Message-----
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of David Marques
Sent: Tuesday, April 07, 2009 2:13 PM
To: Mobile Tools for The Java Platform mailing list
Subject: [dsdp-mtj-dev] MTJ Build Hooks requirements
Hello All,
I have started to define the requirements on the pre/pos build
hooks. The initial version is already on our WIKI
(http://wiki.eclipse.org/DSDP/MTJ/Requirements/MTJ_Build#ID:_build:FR007
_-_MTJ_shall_define_an_extension_point_for_build_hooks). Does
anyone have any comment to add on this ?
Hope the requirements are clear enough.
Regards,
David Marques
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
---------------------------------------------------------------------
This transmission (including any attachments) may contain
confidential information, privileged material (including material
protected by the solicitor-client or other applicable
privileges), or constitute non-public information. Any use of
this information by anyone other than the intended recipient is
prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this
information from your system. Use, dissemination, distribution,
or reproduction of this transmission by unintended recipients is
not authorized and may be unlawful.
_______________________________________________
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
_______________________________________________
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
