[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-update-dev] State of update for M5
|
Pat, see answers below ...
I'm going to be needing to make use of the custom install handling. We'll
be downloading some zip files, and unpacking inside an Eclipse-based
product directory. Really, all I need to do is unzip a file (in a
particular location). When I look at the IInstallHandler and
BaseInstallHandler, I'm kind of scared; I'd really prefer to not have to
deal with any of this. What I would really prefer is to have an ant script
invoked at all the appropriate times.
<vk>there is no chance for getting "native" ant support in the 2.0 cycle,
but this is a good requirement to tackle after
</vk>
If you can't do it, can I write a handler that does this? I'm not sure if
I can, since the IInstallHandler will only have visibility to the update
plugin (and pre-reqs), and I supposed ant isn't one of those.
<vk>we can add ant to the plugin path for update ... this seems like a good
idea. Would org.eclipse.ant.core be enough?
</vk>
In lieu of this, a much simpler interface would be welcome which would
require me to have a large chunk of eclipse loaded just to build the
handler. Basically, an interface that includes nothing but base java
Classes, as opposed to org.eclipse.update.core classes.
<vk>I am not sure what to do with this one ... the handler runs in the
context of the update operations, so it is essentially part of update. For
your development you can have the handler call classes that actually do the
work and pass it whatever context they need. The work classes can be
written and tested using a simpler setup.
</vk>
When do the configure/unconfigure hooks run?
<vk>the update UI has unconfigure and (re)configure operations. The handler
is called in case it wants to do anything.
</vk>
I assume completeXXX() is called after xxxInitiated() and before
xxxCompleted()? And that xxxInitiated() and xxxCompleted() are really just
notifications, whereas the completeXXX() methods are intended to be where
you would do real work (like unpacking a zip file). The naming on these is
odd. It seems like you should be consistent and call it xxxFinish() or
something. Unless there is something else going on here I don't see.
<vk>method naming aside, we have defined a single interface
(IInstallHandler) and single base implementation (BaseInstallHandler) for
the install handler. The thought was that although there are currently 4
operation scenarios (install, uninstall, configure, unconfigure) there is
just 1 handler supplied by the feature. For each of the operation
scenarios, the handler is called to initialize (this is where the operation
type comes in) and then is called at various points during the operation.
The xxxInitiated() calls happen before the operation starts, eg. you may do
checks for anything you need on the local system and fail the operation
right away if you determined you could not complete anyways. The
completeXXX() calls are where the install handler work would happen. But in
the case is the install operation there are additional points where
notification is given and work could be performed (eg. verifying downloaded
non-plugin data). The xxxCompleted(boolean) is an opportunity to undo in
case the operation failed.
</vk>
How would completeXXX() indicate problems? Throw a CoreException? Talk to
the IMonitor somehow?
<vk>all the methods are declared to throw CoreException. This reports a
problem and terminates the operation
</vk>
Why does initialize() indicate the 'type' - (un)configure / (un)install,
AND there are type-specific methods. Shouldn't you just do one or the
other? It seems like it would be cleaner to not have all the type-specific
methods; just initiated/complete/completed.
<vk>we thought about having operation-specific interfaces, and then decided
to go with one, and a base implementation (so you do not need to implement
methods you do not need). The 'type' is there in case you do any
operation-type-specific initialization.
</vk>
What is the purpose for having IPluginEntry and INonPluginEntry knowing
about ws/os/arch, but the feature know this also. Do all the features get
downloaded, then the handler decide which one actually gets installed? I
read the feature.xml description as only those features that match the
description get downloaded.
<vk>your interpretation is correct. You should use the "environment"
settings on the feature
</vk>
Patrick Mueller
patrick_mueller@xxxxxxx
klicnik@xxxxxxxxxx
Sent by: To:
platform-update-dev-admin@ecli platform-update-dev@xxxxxxxxxxx
pse.org cc:
Subject: Re:
[platform-update-dev] State of update
05/03/2002 09:02 AM for M5
Please respond to
platform-update-dev
Pat, M5 has a bug we caught too late that messes up the configuration state
of an installed feature. However, the attached does not sound like that is
what you are running into. It sounds like you failed to package a
downloadable feature. Can you please supply a bit more detail and we'll try
to get you going.
Patrick_Mueller@xxxxxxx
Sent by: To:
platform-update-dev@xxxxxxxxxxx
platform-update-dev-admin@e cc:
clipse.org Subject:
[platform-update-dev] State of update for M5
05/02/2002 01:23 PM
Please respond to
platform-update-dev
What is the state of update at the M5 level of Eclipse, Someone in my
group tried to build a downloadable feature, but didn't have much luck.
Before spending more time, I thought I'd see what what can expect to work.
Patrick Mueller
patrick_mueller@xxxxxxx
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-update-dev
