[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dsdp-mtj-dev] MTJ Build Hooks requirements
|
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
