[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] [prov] Native touchpoint
|
Although I don't understand all the
details on the new implementation it seems to me you can look at touchpoints
as kind of like common services that can be provided which understand a
particular domain in detail, (eclipse, windows api ,linux,JRE etc) . Install
handlers are basically a "custom" touchpoint that allows you
to write any java code and have it executed during the installs. I would
expect that along with the eclipse and native touchpoints a custom"
touchpoint would need to be created ( 99% there will need to be a custom
touchpoint for the provisioning to be useful in more than trivial
cases and to provide a way to get function before it evolves into a real
touchpoint. A native touchpoint could provide a standard set of services
like unzip,mkdir,chmod ,etc. JRE touchpoint could understand various JRE
implementations, file touchpoint could edit files for configuration etc.
I don't see anything in this list that
touchpoints wouldn't do as well or even better in many cases as they are
domain specific and therefore can use that domain knowledge and can provide
standard methods of error handling and progress indication etc. I would
hope anyway :-)
-Peter
equinox-dev-bounces@xxxxxxxxxxx wrote on 08/08/2007
01:57:11 PM:
> I have no idea how these fit into the new scheme. But I will attempt
> to explain some of the ways we used install handlers and some of the
> real constraints.
>
> - We manage launch parameters through install handlers. This
> includes the management of a global property file and a user
> property file. The user property file is modified during the enable
> phase. For the multiuser case, it is easy to upgrade a user files
> during an enable/disable phase. It is not really possible to do this
> during the install by an admin. There has also been discussion that
> the enable handlers should be immutable (not depend a known state).
>
> - We manage JVM features. This had to be done slightly differently
> because JVM features have so many non-standard properties, We added
> and manage a plugin property file for these. While this has worked
> well for us it has a few thorns. There is a question of how to
> override the JVM properties from the command line or more generally
> how to combine JVM properties coming from this file and other
> places. When we attempt to integrate these features into the tooling
> we have the same questions.
>
> - We manage the branding through the property files modified by
> install handlers.
>
> - To some degree we also manage what gets launched. There may be
> multiple ICONS that represent different launch configurations. The
> ICON command length is limited so there needs to be an abstraction
> to handle this.
>
> - We manage the invocation of native exe's and bat and .sh. These
> are a problem because we usually lose the ability to track
> operations, log errors, etc.
>
> - We have also worked on managing native service states through
> install handlers so that it can be upgraded/installed like any other
> feature/plugin.
>
> Other use cases
> - There is a need to be able to just unzip a platform and run. This
> likely implies that there is a need to do dynamic configuration on
> the first launch for a user.
> - For multiuser there is a need to be able to know if we are an
> admin installing into all the shared spaces or if we are just a user
> launching the platform. The actions performed are different.
>
>
> [image removed] Chris Aniszczyk/Austin/IBM@IBMUS
>
>
> Chris Aniszczyk/Austin/IBM@IBMUS
> Sent by: equinox-dev-bounces@xxxxxxxxxxx
> 08/07/2007 09:07 PM
>
> Please respond to
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>
> [image removed]
> To
>
> [image removed]
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>
> [image removed]
> cc
>
> [image removed]
>
> [image removed]
> Subject
>
> [image removed]
> Re: [equinox-dev] [prov] Native touchpoint
>
> [image removed]
>
> [image removed]
>
>
> James can expand, but some things that I recall from a declarative
> system we built on top of the old installhandler code:
>
> * copying files (ie., we package our own launcher and copy it to a
> proper location... we also package vms as bundles)
> * native operations
> * creating icons in menus or on a desktop if available
> * creating windows registry entries
> * setting environment variables
> * modifying files on disk
> * chmod'ng things
> * running arbitrary scripts (ya, I know, scary) like .bat or .sh's
>
> That's all I can remember off the top of my head.
>
> Cheers,
>
> ---
> Chris Aniszczyk | IBM Lotus | Eclipse Committer | http://mea-bloga.
> blogspot.com | +1.860.839.2465
>
> [image removed] Pascal Rapicault ---08/07/2007 08:56:18 PM---James,
> to enlight us, could you please describe the kind of things that you
>
> [image removed]
> From:
>
> [image removed]
> Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>
>
> [image removed]
> To:
>
> [image removed]
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>
> [image removed]
> Cc:
>
> [image removed]
> equinox-dev@xxxxxxxxxxx, equinox-dev-bounces@xxxxxxxxxxx
>
> [image removed]
> Date:
>
> [image removed]
> 08/07/2007 08:56 PM
>
> [image removed]
> Subject:
>
> [image removed]
> Re: [equinox-dev] [prov] Native touchpoint
>
>
>
>
> James, to enlight us, could you please describe the kind of things
that you
> are doing with install handlers?
>
>
>
> James D Miles
> <jdmiles@xxxxxx.c
> om>
To
> Sent by:
<equinox-dev@xxxxxxxxxxx>
> equinox-dev-bounc
cc
> es@xxxxxxxxxxx
>
Subject
>
[equinox-dev]
[prov] Native
> 08/07/2007 04:41
touchpoint
> PM
>
>
> Please respond to
> Equinox
> development
> mailing list
> <equinox-dev@ecli
> pse.org>
>
>
>
>
>
>
> Please either add javadoc info or wiki info on the design of the
> org.eclipse.equinox.prov.touchpoint.natives and . This appears to
be where
> install handler equivalent functionality would be performed. I don't
need
> extensive docs. I just need to know the plan so I can evaluate how
it can
> be used. We use the install handlers extensively in the current eclipse
and
> I am attempting to locate the home for this functionality. Also is
Rhino
> _javascript_ envisioned to be the main scripting mechanism for the native
> touchpoint?_______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> [image removed] _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
