[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] P2 and installHandlers
Thanks for the additional information. It looks like we are going to stick
with using Update Manager for this release, and work on migrating to P2 in
a future (post-Eclipse 3.4) release.
Our install handlers went a bit beyond unzipping the files. We actually
extracted from .JAR files, but this had only one small benefit below. We
1. set permissions on files based on attributes in the .JAR file manifest.
The native touchpoint appears to support the "chmod" command, but a quick
look at the code suggests that this will only work on platforms that
actually have a "chmod" executable. We are installing on Windows, so
"chmod" is only there if we put it there.
2. reference count and version the files installed in this way. If we use
the default native touchpoint, we will have to restructure our product so
that the native IUs do not overlap, meaning more IUs and more dependency
management. This will take some time, but can be done.
3. we are using the Windows Shell API in one case to find the path to
C:\Program Files\Common Files. Obviously this is a pretty special case.
4. we are poking some data into the Windows registry. Again, a bit of a
It sounds like we will really need to provide our own Touchpoint. The
problem with this is that, at least now, we will have the same problem as
we do with InstallHandlers. In particular, our update process becomes a
Stage one: update the "platform" feature/IU that contains the
Restart Eclipse or apply changes
Stage two: update the remaining features/IUs.
This is a burden on our customers becuase they need to hit the update site
twice, not just once. We had to release an app note to explain how to
update, which should not be the way.
A while back Doug Schaefer started a discussion about marking an IU
containing an Eclipse plug-in in some way to indicate that it should be
activated before installing other IUs. This would allow you to activate
the plug-in containing your Touchpoint as part of a single-step update
containing many other IUs. I tried to follow the thread in the archive,
but it doesn't look like it ever got resolved. For us, this would be a
very useful feature.
The other problem that I am trying to sort out is how to generate metadata
for native IUs. It seems like one might need to author this manually. Is
there any way to integrate this into a metadata generator build? In
particular, all of the dependency information from features and plug-ins
needs to get into the metadata, plus we need to integrate the metadata for
native IUs and the dependencies among all of these components. Absent any
better way, it looks like we will have to write a script to mash together
the output from the metadata generator and our own metadata, or maybe
write our own variant of the metadata generator.
Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx> wrote on 06/20/2008
> p2 does not handle UM install handlers and the behavior you get is
> as best as it gets for 3.4.
> That said if your install handler was only unzipping files into the
> install folder, then this should be doable with p2 as is (for
> example the installation of eclipse unzip the eclipse.exe at the
> root of the install). Of course it would require some additional
> work, but it may still worth it.
> Let us know if you need any help.
> From: David_Kennedy@xxxxxxxx
> To: equinox-dev@xxxxxxxxxxx
> Date: 06/06/2008 12:51 PM
> Subject: [equinox-dev] P2 and installHandlers
> Hi Folks,
> What is the current plan (if any) w.r.t. feature installHandlers and P2?
> We are currently using installHandlers to install and update our
> The installHandler is responsible for extracting non-Eclipse files (e.g.
> compilers, headers and libraries) to the product installation directory.
> By using the installHandler, we have a single package that can be used
> the installer, but also can be posted to an update site to deliver
> tools along with our Eclipse plug-in updates.
> We are currently investigating migrating the entire setup to use P2 and
> touchpoints, but have encountered a number of challenges, one of which
> time. As a short term solution, we considered simply generating the P2
> metadata for our update site, then using the P2 console to install our
> features (instead of the old update manager command-line interface), and
> deploying the P2 metadata to our update site so that P2 could also
> the updates. In the short term, we would simply keep the existing
> structure for our Eclipse plug-ins and features, including the existing
> I can generate the P2 metadata for our update site successfully. The
> metadata even includes the references to the installHandlers, so
> some portion of P2 is aware of their existence.
> I run into problems when I try to install the features:
> If I use the GUI, it displays the following error:
> A feature that you have selected uses install procedures that are not
> compatible with the current installation support. This feature can only
> installed by the older Update Manager. Do you want to launch the older
> Update Manager?
> I can launch the older Update Manager, and it runs and installs the
> feature correctly, including executing the installHandler. Once
> P2 is aware that the feature is present, but is unable to manage it
> (uninstall). I would need to launch the "Manage Configuration..."
> but that menu item is gone.
> If I use the P2 director app to install the feature, it runs without
> and correctly installs the features and plug-ins, but does not run the
> installHandler at all, and does not indicate that this has not run.
> I recall reading information on the wiki indicating that P2 would be
> backward compatible with update sites, and would support installHandlers
> with "some restrictions".
> Question: Are there any plans to support installHandlers directly in P2
> for the Eclipse 3.4 release, or ever?
> If not, then it looks like we will need to migrate our entire
> plan to P2, and I have many more questions about that. Given time
> constraints, we will likely disable P2 on our next product release, even
> though we have moved to Eclipse 3.4.
> David Kennedy
> Senior Member of Technical Staff, Software Tools Development
> Medical Division
> ON Semiconductor
> +1 519 884 9696 ext 2289 | office
> +1 519 884 0228 | fax
> equinox-dev mailing list