[platform-update-dev] Shared Install versus Shared Configuration

[Mark_Melvin@xxxxxxxx]

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@xxxxxxxx> 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 administrator is 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 to refresh  
> 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 red herring  
> because it looks like the manage
configuration tool scans the features  
> and plugins directories and then
tries to match what it found to active  
> 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.