Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-update-dev] Install/Update API 
Peter Manahan wrote:
How would you be able to tell if the install was shared? I don't think you can, even if there was a way then don't think you can expect the Update Manager to help enforce license requirements. The user must accept the license before installing. If the user does so and it is a single person license then it is the user's responsibility. If there a need to prevent more than one user running then the plugin needs to use a license manager to handle that.
I believe if you read the posting I replied to, it was a use case (one of the many) requesting explicit support for shared and site-managed updates.
Your reply falls in the category "If you can't do a perfect job, don't do anything at all." I am not interested in the Update Manager enforcing license requirements. If some future version of Update Manager knows it is doing a shared installation, then it can easily provide a hook for features that object to a shared installation to notify the user. That seems like a modest enough request.
Piracy, in general, has little to do with open source. The only piracy prevention that works is a society in which property rights are enforced. In such a society, a "cursory check to prevent inadvertant piracy" is a useful and practical tool. 

Bob Foster
We've looked at the piracy before and it shows one of the open source holes. There is no way to prevent piracy when the base platform you are sitting on provides the source to work around any security it may provide. Even if update manager attempted to prevent this a patch could be made available to update manager (a completely legal patch) that worked around the issue. Additionally there is nothing preventing a user from downloading the jar's themselves and applying them to eclipse manually its fairly easy to do so.
So what you are left with besides a bad taste is the ability to do a cursory check to prevent inadvertent piracy. The real pirates will walk around the check quite easily anyway. 



Thanks,

-----------------------------------
Peter Manahan
WebSphere Tools
Build/Install and
Product Architecture
------------------------------------
manahan@xxxxxxxxxx


*"Bob Foster" <bob@xxxxxxxxxx>*
Sent by: platform-update-dev-admin@xxxxxxxxxxx

01/12/2003 08:03 AM
Please respond to
platform-update-dev


	
To
	<platform-update-dev@xxxxxxxxxxx>
cc
	
Subject
	Re: [platform-update-dev] Install/Update API


	





Long latency on this, I know, but I hope some consideration is given to
allowing plug-ins to selectively "opt out" of shared installs when the
plug-in license only covers single-person use. A plugin should/must be able
to require that it not be installed in a shared eclipse unless its license
permits. IOW, the update feature should not facilitate piracy.

Bob Foster

----- Original Message -----
From: "Mark Kralj-Taylor" <mark.kralj-taylor@xxxxxxxxx>
To: <platform-update-dev@xxxxxxxxxxx>
Sent: Thursday, October 16, 2003 3:05 AM
Subject: Re: [platform-update-dev] Install/Update API


Message
I needed to code against the Eclipse 2.1 update API to facilitate deployment
of Eclipse, WSAD and a mix of open source and in-house extension
features/plugins to a read-only file system accessed by Widows, Linux and
Solaris desktops.
Before writing this code I exchanged some emails with the
platform-update-dev mail group (answered by Christophe Eleck).

We are really hoping that Eclipse 3.0 will avoid the need for our code
entirely, so this sounds a good point to explain our use case again:
- To reduce deployment and maintenance costs we avoid local installs.
- Instead we provide applications like Java and Eclipse on a global,
READ-ONLY file system.
- Users do not install Eclipse on their local machine, nor do we want users
to download features from an update site.
- We want to provide everything centrally.
- To deploy an application we first package it to a read-write 'dev' area,
it is then turned-over to the read-only 'dist' area.
So there is a difference in path prefixes between where an application is
packaged, and where it is run from. It is important to us that this doesn't
cause problems for the 'eclipse -install' process (e.g. storing full paths
in platform meta-data)
- Each user has their own read-write Eclipse workspace directory under their
home directory.

The Eclipse update mechanism is important to us because it lets users pick
which extra features they opt-into, in 'their' Eclipse experience.

To make the Eclipse update mechanism work in our read-only 'dist'
environment, I added an 'Add local extension install site' action to the
'Eclipse Platform' object in the 'Install Configuration' tree view. This
lets you add a pre-existing extension directory.

Eclipse 2.1 has several extension site types, tagged by dot files. I found
that an update manager site, tagged with a '.eclipseUM' file worked best.
However because the update manager checks that .eclipseUM update sites are
writeable, I had to cut-paste-modify code, rather than simply call the
update manager API.

For the user it is a 2 step process to use a feature from a read-only
extension install site:
1) add read-only extension install site
2) enable desired feature(s) from the extension install site
      (remembering to press the 'show disabled features' button first)

There is a problem with our approach. Where we have provided several
features in one extension install site, intending that users can
enable/disable features within the site independently. After restarting
Eclipse all features from the extension site can be enabled, not just the
ones the the user actually selected.

I hope Eclipse 3.0 will provide better support for shared installs of
Eclipse, so we don't need the code I have attached.
Specifically:
- Continued support for shared install of Eclipse in a read-only
file-system.
    (with no absolute paths embedded in any platform meta-data, so we can
copy from 'dev' to 'dist' areas)
- Support for users adding (importing) shared extension sites from a
read-only file system (without copying).
- Externalising platform configuration  information, to a user
visible/editable/copyable XML file in user's Eclipse workspace. This file
would include what extension sites the user has added and which features
from them are enabled.
(we find that Eclipse workspace can get corrupted, and some want multiple
workspaces, in both cases want to minimise time taken to duplicate a
workspace setup)
-- Other information could be provided in human readable/editable files in
workspace dir:
 - locations of project directories
 - eclipse startup and JVM options - handled by Eclipse boot launcher
executable, this would be more user friendly than using long command line.
 - how long would it take to auto export .epf preferences on a clean
shutdown, so if workspace gets corrupt, a user always has a recent copy to
restore preferences from?

Mark.

       [platform-update-dev] Install/Update API

   a.. From: Dejan Glozic <dejan@xxxxxxxxxx>
   b.. Date: Mon, 6 Oct 2003 16:24:56 -0400
   c.. Delivered-to: platform-update-dev@xxxxxxxxxxx

----------------------------------------------------------------------------
--


Poll:

The Eclipse Install/Update team would like to know of any and all cases
where the current (2.1) Update API is used. Note that we are only
interested in programmatic uses (i.e. referencing any of the non-internal
classes in org.eclipse.update.core plug-in) and not actually using features
and/or update sites.

Please send your answers to platform-update-dev mailing list only.

Regards,

Dejan Glozic, Ph.D.
Manager, Eclipse Platform Components
D2/MY7/8200/MKM
IBM Canada Ltd.
Tel. 905 413-2745  T/L 969-2745
Fax. 905 413-4854

Back to the top