Thanks David.
Can you please provide some rationale or user cases on the
priority? I am not sure I understand how the dynamic of
different SDK providers providing priorities works, and what
the expected behaviour is.
Thanks.
Ken Wallis
Team Lead - Eclipse Tools
Research In Motion
905-629-4746 x14369
*From:* dsdp-mtj-dev-bounces@xxxxxxxxxxx
<mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx>
[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] *On Behalf Of *David
Marques
*Sent:* Tuesday, April 14, 2009 12:03 PM
*To:* Mobile Tools for The Java Platform mailing list
*Subject:* Re: [dsdp-mtj-dev] MTJ Build Hooks requirements
Hello Ken,
Follows some answers to your questions :)
Regards,
David Marques
Ken Wallis wrote:
Unfortunately, Jon is away on vacation this week. I am not in
complete
touch with the work he has been doing, and his complete
thoughts on
requirements, but I would like us to provide feedback on this.
I will
try to be a good proxy. ;)
I think that this approach will, as everyone suggests, be more
flexible,
and allow the build hook implementers to decide what they are
interested
in, and insert functionality into the build process where they
need to.
I believe this will address some of our concerns and answers
some of
Jon's questions through re-design. ;)
I think there are a couple of questions from Jon's email still
outstanding:
1) How is priority used? Is this if an SDK provides multiple
build
hooks, and allows us to control in what order they are
executed? Or is
there some other meaning? Is this global priority for all
build hooks?
This is a global priority between hooks.
2) Does the project reference in the callback provide access to
everything a build hook may require? Here, I am not so sure I can
accurately indicate what we might need versus what is
accessible, but I
guess the question will have to remain outstanding until Jon's
return.
The IMTJProject interface should provide everything a build
hook might require.
3) How do we return errors to MTJ from a build hook callback,
and how
would MTJ handle that? Is it just through CoreException?
In case any exception is thrown by the hook, it should be
threated as if it was an error raised internally by the
builder. This solution of throwing a CoreException follows the
standard way for of raising build errors on
IncrementalProjectBuilder, so I guess the answer to your
question (Is it just through CoreException?) is YES.
Thanks!
Ken Wallis
Team Lead - Eclipse Tools
Research In Motion
905-629-4746 x14369
-----Original Message-----
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
<mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx>
[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Craig
Setera
Sent: Tuesday, April 14, 2009 8:46 AM
To: Mobile Tools for The Java Platform mailing list
Subject: Re: [dsdp-mtj-dev] MTJ Build Hooks requirements
I'm good with it.
It would be nice to get input from the other potential
"stakeholders" of this extension point.
On Apr 14, 2009, at 7:44 AM, David Marques wrote:
Hi Craig,
Well I think it would not help much in case the hook acts
on the
last states of the build process, since it would be called
several
times yet. I think we should keep your initial proposal and
document
that the hook providers should keep their hooks "lightweight".
How does it sound to you ??
Regards,
David Marques
Craig Setera wrote:
David,
I do share your concerns... One possible idea... Have
the callback
return a boolean. If true, we continue to call that
callback for
that particular project/state. If false, we don't call
that hook
for that callback any more. That way the hook is still
completely
in control of what hook state/project combinations the
hook will be
called for.
Just a thought. It may be too complex.
Craig
On Apr 14, 2009, at 7:28 AM, David Marques wrote:
Hi Craig,
I like your idea to generalize the hooks and make
them see the
build system as a "state machine". I have some
concerns regarding
the overhead of calling all registered hooks, but
let's hope hook
providers will do their job right :)
Well if everyone agrees on it, I will do the
suggested changes.
Regards,
David Marques
Craig Setera wrote:
Finally found some time to look through your
documents and look
through Jon's questions. I hate to even make a
suggestion this
late in the game, but I'm going to anyway <grin>
In terms of the filtering, I think that we
should just go ahead
and call the registered hooks every time. We
should leave it to
the hook implementor to query the currently
selected device or
anything else of interest from the MTJ project
instance and
decide if they want to do anything within the
hook. That way we
don't need to depend on a name matching routine
or what the
various SDK's decide they want to use for the
identifiers. In
addition, it is much more flexible for the hook
implementor in
terms of how they decide what they want to do
and when. We
should document (somewhere) that this
determination needs to be
done as quickly as possible in the hook's
implementation.
To answer one of Jon's other questions, I think
it may make sense
to generalize the pre/post build to include the
*possibility* of
more states. (while limiting it for now). In
theory, we have
lots of build states:
- Pre Build
- Pre Preprocessing
- Post Preprocessing
- Pre Compile
- Post Compile
...
- Post Build
If we create the IMTJBuildHook interface to
have a single
callback method that looks something like:
public void buildCallback(IMTJProject project,
BuildStep step,
IProgressMonitor _monitor) throws CoreException
We can then make BuildStep (or whatever we want
to call it) be an
Enumeration. I would suggest that until we
have more time to
work through the details, that there would be
only the two
initial BuildSteps in the enumeration of
PRE_BUILD and
POST_BUILD. With that said, this approach
would be more
extensible in the future and we could add new
steps in the future
for use by interested hook builders. If we do
this, it should be
documented that unexpected callback types
should be *ignored* by
the hook.
Thoughts? I know it is a departure from your
current design, but
I do think it is more flexible and meets some
of the requirements
that I (think I) hear from Jon for their use.
I apologize again
for throwing this into the mix so late... I
will try to do a
better job of staying on top some of this stuff.
Craig
David Marques wrote:
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.
_______________________________________________
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 <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 <mailto: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 <mailto: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 <mailto:dsdp-mtj-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev