[
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 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 install
docs (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 noticed
and 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 of junk 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
understand things.
> > > 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 failing
to 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 spent over 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.
