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.
Craig
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:
Hi David,
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.
Any thoughts on this?
Regards,
Jon
---
Senior Software
Developer, Eclipse Tools
Research In Motion
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
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev