Hey Achim,
Correct me if I'm wrong, but as far as I can see Yoxos is used for a
consistent Eclipse setup on each client computer. So it would be a
great tool to provide 5 different setups for our users to choose from,
which then gets installed on their computer. That is fine for a Windows
environment, but in our case no user shall install anything. There is
only one installation of the software on the server. All Solaris
workstation share this global installation.
You are likely looking at Yoxos OnDemand. That is just one example--Yoxos works in a number of different modes depending on the scenario at hand.
Looking at your usecase description it seems that you want bundles to be shared and have each user's configuration info written in their home dir. In p2 (and Yoxos) terms, you have a shared "bundle pool" on an NFS mount and a local or individual p2 "data area" (typically in the Eclipse configuration dir). Each user may run a different configuration of bundles but no users actually end up with bundles copied to their machine or home dir or... Does that match your situation?
Tim pointed out the bundles.info file. That is indeed the root of a modern Eclipse install's configuration. It lives in the org.eclipse.equinox.simpleconfigurator directory of the configuration area. The file format is relatively simple and in fact, this function sits below p2. That is, you don't have to have any p2 around for the simple configurator and bundles.info to work. In essence, p2 is a really (really) powerful mechanism for editing the bundles.info file :-) So if you have a set of bundle locations around and know exactly what bundles need to be installed etc, then you can craft a bundles.info on the fly and run Eclipse. This is probably the fastest path given what you already have.
Eventually there may be some issues with plugins and features that expect various configuration information to be setup when they are installed. For example, some bundles may want to be started at a particular start level or have some files chmod'd or ... Without actually running p2 to do the install (e.g., create the bundles.info) that information may be lost. If your environment is closed/constrained then you can likely figure out what these issues are and setup something manually.
If you need to go a step further then check out the "director application". That is p2's command line installer (don't be thrown off by the word "installer"). Its got lots of different options and settings that could well help.
Where things like Yoxos help is in - the management of the bundle pool (garbage collecting, ensuring it is consistent, ...), - the definition of consistent configurations that individual users use. (e.g., what do C developers have in their tool chain? What about Java devs, ... and ensuring that these configurations are consistent) - the seamless and transparent running of the configurations for individual users based on various criteria you define (role, dataset, update policy, ...). Yoxos essentially runs the p2 setup code to create the bundles.info and associated structure.
Hope that helps.
Jeff
Actually, what we need is no "provisioning" for the end user. He/She
shall never be bothered with updates, plugin dependencies etc.
Everything is done only once by the system administrator.
It works fine now the way I described, all we need is a way (that does
not cost weeks of work) to achieve the same result with Eclipse 3.5.
-Achim
Jeff McAffer wrote on 2009-10-21 04:10:
Hey Achim,
This is a great usecase that I see quite frequently. p2 offers
a number of infrastructure pieces that facilitate the behaviour you
want but, as a "provisioning platform", does not directly offer a
solution for this scenario. I can say that Yoxos ( http://eclipsesource.com/yoxos)
is built on top of p2 and does offer solutions from IDE lockdown to
workspace- and role-based provisioning -- the kinds of enterprise level
provisioning problem you outline. Drop me a line if you want to know
more. If you are going to be at ESE next week then check out the Yoxos
talk and demo sessions on Wed. Feel free to grab me then.
Jeff
Jeff McAffer | CTO | EclipseSource | +1 613 851 4644
On 2009-10-20, at 9:48 AM, Achim Bursian wrote:
Hi guys,
first of all: I hope this is the right place to ask this question, if
not, please give me a hint where to go and bear with me.
In our company, we are currently running an Eclipse 3.4 installation
for several hundred software developers on Unix workstations. The
installation is shared from a network location via NFS. The needs of
the different developers are very different, some are C++ guys, some
are into Java or other stuff.
To provide the different groups an uncluttered IDE, I did NOT use p2 up
to now, I removed it manually as described on the Wiki. But now, as we
want to move on to 3.5, there is no way without p2, right?
To give a better understanding of our setup, this is what we did up to
now: There is a main installation directory for the platform. Then,
there is a separate directory for CDT, and one for JDT, and some more.
The individual user shall NOT fiddle with these install directories,
they are read-only for him. In our startup script, for each user a
special Eclipse configuration directory inside the user's homedirectory
is created, with a platform.xml that contains references to all
the extension locations that this particular user needs. This way, one
user only gets the CDT features, while another one only gets the Java
IDE, all with the same platform install.
Bottom line: The user must not configure anything manually. Our
launcher script analyzes the user's environment and creates the
corresponding Eclipse configuration (platform.xml) on the fly, without
any user interaction (and, of course, without any GUI). Only if that is
done, Eclipse itself gets launched.
Is there a way to achieve the same with Eclipse 3.5?
I'd be very thankful for any pointers or hints.
-Achim
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
|
