Hello All,
The behaviors described by Craig sounds nice. The build state
machine collects all statuses from the exceptions thrown by the hooks
(if no error status is sent of course) and after changing to the
POST_BUILD state throws a CoreException with a MultiStatus containing
all statuses collected. The build framework will display all statuses
grouped on the error log view. In cases where an ERROR status is thrown
by any hook the state machine will throw it to the eclipse build
framework which will interrupt the build process and show a message
dialog with the error description. All these behaviors are default to
eclipse. Does anyone disagree with implementing that way ??
Regards,
David Marques
Jon Dearden wrote:
Yes, that
makes sense. I just don’t want
to leave the user with a puzzled look on their face.
If you throw an exception with status of
WARNING from your SDK
provider, you will have stopped doing anything more in your hook.
Thus,
it is "fatal" to you at that point. But, the exception will be
caught and logged by the builder so that the user can see something
happened.
In theory, we could also attach a warning "Marker" to the
Eclipse resource, assuming we actually have one at that point. If we
did
that, it would also show up in the problems view.
What it boils down to is this:
Error Status == Something really bad that
should kill the build
completely. Not normal in this case, but should be allowed for.
Warning Status == Something bad happened, but
the rest of the build
should continue. Probably the "normal" error case for hooks
Info Status == Something happened that you
would like logged, but
otherwise things are ok. Not likely thrown until the end of your build
hook if at all
On Apr 27, 2009, at 10:17 AM, Jon Dearden
wrote:
It seems to
me that an “error” may not be
fatal to the whole process, but would be considered fatal to a
particular SDK.
If an SDK experiences a major issue and cannot continue, it still needs
a way
to tell the user what happened. How is this accomplished by throwing a
CoreException with IStatus.WARNING or IStatus.INFO?
In what
circumstances should an SDK throw
out an IStatus.ERROR? Is there ANY reason an SDK should be able to stop
the
whole process?
Hi Craig,
This solution look pretty good for me, I will open a bug to
implement that if no one disagrees of course.
Regards,
David Marques
Craig Setera wrote:
OK. After
taking more than 10
seconds to think about this, I believe I have the appropriate solution
for
handling this.
If you look at
CoreException, it wraps
around an IStatus instance. Each IStatus instance has an associated
severity. The only status severities that should cause the build to
*fail* would be ERROR. Warnings, INFO and OK statuses should not stop
the
build. Thus, the builder should do something like:
- Create an
empty list to hold non-fatal
statuses from the hooks.
- Call the
hooks, catching CoreException
instances
- If an
exception occurs, the IStatus
instance is retrieved from the exception
-- An IStatus
may also take the form of a
MultiStatus which contains more statuses. For these, the
"worst" severity is the overall severity of the exception
- If the
exception status severity is
ERROR, the build is stopped and the exception is thrown out from the
MTJ
builder to the Eclipse framework
- If the
exception status severity is
WARNING or INFO, the status instances are added to the running list of
non-fatal statuses
- If the build
completes without an ERROR
status and there are non-fatal status instances... a MultiStatus is
created to
hold those non-fatal instances and a CoreException is thrown from the
builder.
- I believe the
Eclipse
infrastructure will deal correctly with the CoreException that is
thrown based
on the status values in that exception.
I have not
implemented this, so there may
be some holes in there, but I believe the concept is sound. It
essentially boils down to allowing all hooks to execute unless they
declare
something is so broken that the entire build should fail. This puts
the
responsibility on the hook writer to set the appropriate status
severity
dependent on what needs to happen. This also implies we would need to
be
*very clear* in the documentation.
Let me know what
you think.
On Apr 24, 2009,
at 2:14 PM, Craig Setera
wrote:
I wonder if we
should be returning IStatus
objects instead?
On Apr 24, 2009,
at 2:07 PM, Jon Dearden
wrote:
I have two
runtimes associated with a
project. If I throw a CoreException during one
call back, MTJ does not appear to allow the other
SDK(s) to have a go. But one SDK should not be able to bring the whole
house
down.
A scenario
is that one SDK vendor or user
makes an installation error and a critical component is missing in the
SDK. The
only way the implementer of the hook can respond is to quietly fail
(and the
user does not know why), or pop up a message (which may interfere with
the MTJ
UI flow), or throw an exception resulting in the above.
Senior
Software Developer, Eclipse Tools
905-629-4746
x15333 / Mobile:
519 500-23167
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
|