Hi Craig,
Are you talking about org.eclipse.debug.core.IStatusHandler ? I
think i could work, although i can not see a good reason for calling
the hook in order to treat an error that it *should* already know that
occurred. Maybe I am missing something...
Regards,
David Marques
Craig Setera wrote:
I thought we were going to honor IStatusHandler's that
might be registered?
On Apr 28, 2009, at 3:17 PM, David Marques wrote:
Hello All,
If no one disagrees with the solution i proposed on the last
comment bellow i will commit the code tomorrow. So if anyone has any
more comments, please do it as soon as possible.
Regards,
David Marques
David Marques wrote:
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
_______________________________________________
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
|