[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-update-dev] Shared Install versus Shared Configuration
|
Hi Peter,
Thanks again for the reply. It
is good to talk to someone else who uses this stuff!
OK, so I am once again thinking the
*proper* thing we should be doing is using a shared configuration area
just as you describe. However, there is one wrinkle with this approach
that I have encountered. It seems to me that you also cannot update
any existing features located in the shared install area of a "shared
configuration" scenario - even as root - unless you manually specify
the shared configuration area on the command line. I say this because
the way we force a shared configuration (and when I say shared configuration
I am also implying that you are running in cascaded configuration mode)
is to add the following to the config.ini
file in the eclipse/configuration
folder:
# Force a user-writable configuration
location
osgi.configuration.area=@user.home/.eclipse/<productid>_<version>/configuration
# Make the configuration area cascaded
(may not be necessary)
osgi.configuration.cascaded=true
In the course of figuring out how all
of this works, I have noticed that we do not need to explicitly set osgi.sharedConfiguration.area
or osgi.sharedConfiguration.area.readOnly
as they are set automatically when the platform goes into cascaded mode.
In fact, I believe as long as there is a pre-populated (initialized)
configuration area in the eclipse/configuration
folder, as long as you specify a different configuration area (using osgi.configuration.area)
then you probably don't even need to set osgi.configuration.cascaded
either.
So, having the above lines in eclipse/configuration/config.ini,
and assuming the eclipse/configuration
folder also contains an initialized, shared configuration area - if we
want to be able to update features and plugins in the shared installation
you will need to first of all be root or an administrator, and secondly
run Eclipse with the -configuration <path/to/>eclipse/configuration
switch. You may even need to add -vmargs
-Dosgi.configuration.cascaded=false,
I'm not sure. So as I see it - in our case, we would want to add
a second shortcut to our product that adds these command line options that
allows you to install updates via our update site - if you happen to be
an administrator. Otherwise, if you try to run a "check for
updates" operation - it will always tell you there are no updates
(even if there are) because in cascaded mode, whether the directory
is physically writable by you or not - Eclipse sets the shared configuration
area to be non-updateable.
Mark.
----------------------------------------------------------
platform-update-dev-bounces@xxxxxxxxxxx wrote on 06/12/2007
11:58:10 AM:
>
> Hi Mark,
> I've never seen a valid use for the shared
install scenario
> using update manager so would be interested in hearing one. I've
> often wondered why they added that scenario to the docs. The only
> time I have seen it being useful is when you manage the local
> configuration and keeping the shared area as a pool of
> plugins/features. So if you wanted to have each user have a
> different configuration then each would have to manage theirs via
> the Manage Configuration in eclipse update. Since the shared
> install scenario also requires read-only access to the install area
> users can't install anything to it. All a normal user can do is
> enable/disable features. They can't update existing features in the
> shared area.
>
> An admin wanting to use update manager to update the shared area
> would have to specify a separate configuration flag when running
> their eclipse so as not to contaminate
>
> eclipse -configuration <anywhere that isn't the shared configuration>
>
>
> Peter
>
> platform-update-dev-bounces@xxxxxxxxxxx wrote on 06/12/2007 11:06:20
AM:
>
> >
> > Hi Peter,
> >
> > Thanks for the reply. That makes sense and is how I understand
how
> > things work, but you are describing a shared configuration scenario
> > (as opposed to a shared install scenario). I figured this
is what I
> > wanted, but after my last raft of posts to this group I was starting
> > to second-guess things. ;o) We currently are using a shared
install
> > scenario - which is different from what you are describing but
from
> > my interpretation of the docs *should* work. But it seems
either
> > inconsistent/buggy - or we are abusing it in some way resulting
in
> > unexpected/unintended behaviour.
> >
> > Mark.
> > ----------------------------------------------------------
> >
> >
> > platform-update-dev-bounces@xxxxxxxxxxx wrote on 06/12/2007 10:57:57
AM:
> >
> > >
> > > When we create shared installs for the Rational products
we install
> > > the base eclipse and set the permissions to be readonly
by root.
> > > Only root is then allowed to install and mess around with
the
> > > configuration in the shared install area.
> > >
> > > When a user launches eclipse it detects that the shared
install
> > > area is readonly it creates a configuration area in the
users
> > > directory. This configuration has a reference to the shared
> > > configuration. The platform.xml generated int he user space
looks
> > like this.
> > >
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <config date="1175627511645" shared_ur="file:configuration/org.
> > > eclipse.update/platform.xml" transient="false"
version="3.0">
> > > </config>
> > >
> > >
> > > So when root updates the shared area the shared platform.xml
is
> > > updated. When the user starts up eclipse it references the
shared
> > > platform.xml.
> > >
> > > If a user then installs new features they get installed
into a user
> > > writeable area and are referenced only in the user's platform.xml
> > > and not in the base platform.xml which everyone shares.
> > >
> > > The key to sharing an eclipse install is sharing the configuration.
> > > The plugins/features can be anywhere but managing the configuration
> > > is the core part and that is what the Update Manager primarily
does.
> > >
> > > Peter
> > >
> > > platform-update-dev-bounces@xxxxxxxxxxx wrote on 06/12/2007
10:30:16 AM:
> > >
> > > >
> > > > Hi Everyone,
> > > >
> > > > I have one more question which I posted to the Equinox
newsgroup but
> > > > got no response. I know it has been less than
a day...but I am
> > > > trying to get a release together by Friday and I am
in a serious
> > > > time crunch right now so I apologize for all the questions
ahead of
> > > > time. The post is pasted at the end of this email,
but my question,
> > > > in a nutshell, is as follows:
> > > >
> > > > In the case of Scenario #2 from the Eclipse multi-user
installdocs (the
> > > > shared install), how do you go about installing updates
to the
> > > > shared installation area and ensure your users pick
them up? Is it
> > > > supposed to just work? I have run across at least
one machine where
> > > > it doesn't, but perhaps I am doing it wrong. Here
is the problem.
> > > > From the docs, a shared install scenario implies there
is only ever a
> > > > config.ini in the configuration area contained in the
shared install
> > > > area (in other words it is not initialized). OK,
fine. But who
> > > > installs the updates to the plugins when you want to
add features to
> > > > a product? I think the answer to this question
is - it doesn't
> > > > matter as long as they have write access to the shared
installation
> > > > area. However, by what mechanism are these changes
propagated to
> > > > the restricted users sharing the installation? When
a restricted
> > > > user runs Eclipse after the shared install has had
more
> > > > features/plugins installed into it, I assume the changes
aren't
> > > > looked for or detected unless a -clean is issued (although
it
> > > > appears to work strangely enough on all machines I
have tried
> > except one).
> > > > The logical part of my brain tells me that in order
to install
> > > > updates to a shared install, you should run with your
configuration
> > > > area explicitly set to the configuration area contained
in the
> > > > shared install area, but this will force metadata to
be created in
> > > > this area and by definition you are no longer in a
shared install
> > > > mode anymore. In fact, Eclipse seems to detect
that this metadata
> > > > is present and automagically flip into cascaded mode
(or Scenario #3 -
> > > > shared configuration) - which is quite different.
> > > >
> > > > Am I missing something here?
> > > >
> > > > Thanks in advance,
> > > > Mark.
> > > >
> > > >
> > > > On Mon, 11 Jun 2007 18:41:10 -0400, Mark Melvin <mark_melvin@amis.
> > > com> wrote:
> > > >
> > > > > Hi There,
> > > > >
> > > > > I have a problem which is driving me insane. I'm
not sure if this
> > > > > belongs here or if I should be posting this to
the platform
> > newsgroup,
> > > > > but here goes.
> > > > >
> > > > > This is a question about a problem with a product
based on a full
> > > > > platform runtime (3.3RC3), but I need help tracing
through the OSGI
> > > > > stuff. I have a weird bug that is only reproducible
on one
> > machine (it
> > > > > is not reproducible on many other machines that
I have tried). It
> > > > > involves new features installed into an Eclipse
site not being
> > noticed.
> > > > > The features and plugins are there in the features
and plugins
> > > folders -
> > > > > but Eclipse ignores them. I am running a
"shared install"
> where the
> > > > > features and plugins were installed by an administrator
(using the
> > > > > Eclipse command line update mechanism - called
from our
> > installer), but
> > > > > when I log in as a regular user these features
are not
> noticedand my
> > > > > user-specific configuration area goes unmodified.
> > > > >
> > > > > On every other machine I have tried this on, when
I log in as
> > a regular
> > > > > user after performing the "update",
my user-specific
> > configuration area
> > > > > is regenerated with the new information and the
features are
> > there. I
> > > > > cannot for the life of me figure out what the
heck is going
> on here.
> > > > > The failing machine is a ghosted test machine
that is basically
> > > > > completely clean install of WinXP SP2. Why
it works on every other
> > > > > machine is beyond me. The only possible
difference I can
> see is that
> > > > > this old machine is FAT-based and all of the others
I have
> tried are
> > > > > NTFS-based. The only reason I mention this
detail is because
> > > the act of
> > > > > updating (installing the new feature) seems to
create a lot
> ofjunk in
> > > > > the Local Settings\Temp folder of the admin account
(cached
> > versions of
> > > > > the .JAR files), and the configuration area of
the
> > administratoris also
> > > > > modified. But - this should not matter as
far as I
> understandthings.
> > > > > When I fire up Eclipse the next time as a restricted
user -
> > > shouldn't it
> > > > > do some sort of lightweight scan to determine
if the
> > configuration area
> > > > > needs to be refreshed?
> > > > >
> > > > > Oh, an important note. If I execute Eclipse
with -clean, the
> > > feature is
> > > > > detected. But this should not be necessary
in my opinion.
> > > Although now
> > > > > that I think about it...if you do not execute
Eclipse with -
> > clean, how
> > > > > does Eclipse *ever* know you have installed additional
features
> > > when you
> > > > > are running in a "shared install" scenario?
It looks to me
> like the
> > > > > install information goes into the configuration
area of the
> user that
> > > > > installed the features - in this case the
administrator. But this
> > > > > doesn't make sense. How the heck would you
*ever* be able
> to install
> > > > > new features into a shared installation so they
were
> > accessible without
> > > > > doing a -clean? And why the heck does it
work for all of my
> machines
> > > > > except one? I'm very confused... ;o)
> > > > >
> > > > > I guess what I was hoping to find was:
> > > > >
> > > > > 1) More knowledge on exactly how the configuration
areas know when
> > > > > something has been added to the shared install,
and thus need
> > torefresh
> > > > > themselves (in particular, regenerate platform.xml).
> > > > > 2) A way to further diagnose this problem - perhaps
enabling
> > some sort
> > > > > of logging or secret console trick to show me
why a feature may
> > > not have
> > > > > been loaded.
> > > > >
> > > > > I mention point #2 because if I do into Manage
Configuration,
> > and show
> > > > > disabled features - it shows me the feature that
it is
> failingto find
> > > > > and it says it is disabled. However, I assume
this may be a
> > redherring
> > > > > because it looks like the manage configuration
tool scans the
> > features
> > > > > and plugins directories and then tries to match
what it found
> > toactive
> > > > > bundles.
> > > > >
> > > > > Anyway, any enlightenment would be most welcome.
I have
> spentover 2
> > > > > days on this so far.
> > > > >
> > > > > Thanks,
> > > > > Mark.
> > > > AMI Semiconductor - "Silicon Solutions for the
Real World"
> > > > NOTICE:
> > > > This electronic message contains information that may
be
> > > > confidential or privileged. The information is intended
for the use
> > > > of the individual or entity named above. If you are
not the intended
> > > > recipient, please be aware that any disclosure, copying,
> > > > distribution or use of the contents of this information
is
> > > > prohibited. If you received this electronic message
in error, please
> > > > notify the sender and delete the copy you received.
> > > > _______________________________________________
> > > > platform-update-dev mailing list
> > > > platform-update-dev@xxxxxxxxxxx
> > > > https://dev.eclipse.org/mailman/listinfo/platform-update-dev
> > > [attachment "smime.p7s" deleted by Mark Melvin/AMI]
> > > _______________________________________________
> > > platform-update-dev mailing list
> > > platform-update-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/platform-update-dev
> > AMI Semiconductor - "Silicon Solutions for the Real World"
> > NOTICE:
> > This electronic message contains information that may be
> > confidential or privileged. The information is intended for the
use
> > of the individual or entity named above. If you are not the intended
> > recipient, please be aware that any disclosure, copying,
> > distribution or use of the contents of this information is
> > prohibited. If you received this electronic message in error,
please
> > notify the sender and delete the copy you received.
> > _______________________________________________
> > platform-update-dev mailing list
> > platform-update-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/platform-update-dev
> [attachment "smime.p7s" deleted by Mark Melvin/AMI]
> _______________________________________________
> platform-update-dev mailing list
> platform-update-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-update-dev
AMI Semiconductor - "Silicon Solutions for the Real World"
NOTICE:
This electronic message contains information that may be confidential or privileged. The information is intended for the use of the individual or entity named above. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic message in error, please notify the sender and delete the copy you received.