This content has been marked as final. Show 13 replies
Have you tried your install scenario from scratch without using the -configuration parameter? There is nothing that OEPE or any other plugin can do to disable another plugin.
I tried the following sequence...
1. Started with Eclipse IDE for Java EE Developers (Indigo SR2 / 3.7.2).
2. Installed C/C++ Development Tools from http://download.eclipse.org/releases/indigo repository.
3. Installed OEPE from http://download.oracle.com/otn_software/oepe/indigo repository. It's version 22.214.171.124.1 now.
4. Confirmed that C/C++ perspective and views are still accessible.
So I didn't see any problems in this scenario. I wonder if you are hitting Eclipse plugin install/management glitch with how you are managing your Eclipse configuration. I left it all alone. No configuration switch, no trying to re-use plugins across installations, no multi-user install sharing, etc. All of those scenarios get far less use than the default approach and bugs in Eclipse platform have been common.
You can also try moving up to Juno SR1 release. Perhaps the bugs you are hitting have been fixed in that release.
Sometimes conflicts in plugin dependencies can cause things to not start. You could try debugging by:
1) Looking for .log files in the configuration subdirectory of your eclipse install directory. This is where the launcher normally reports osgi startup problems. (Note that these logs are separate from and do not appear in the "Error Log" view).
2) Launch eclipse from the command line with "-debug -console -consoleLog" (opens a new DOS window if you are running windows). This will spit a lot of additional information into the console. If there's too much try removing "-debug".
3) With the "-console -consoleLog" you can also use the osgi> prompt to try to debug which bundles are starting. The Plugins and Plugins Registry views in the Eclipse UI provide similar functionality.
Also, you could try starting eclipse with "-initialize -clean" after installing OEPE. I think the restart after installing normally invokes one or both of these, but sometimes it helps to run them again.
This is exaclty what I have thought about Eclipse - until now ;-)
Yes I tried, and with "Running as administrator" it worked. Installation Folder is write protected for normal users.
Unfortunately running without "-configuration" is no option for several reasons.
This feature is well tested, an works with lots of other plugins.
thanks for your effort.
1. No .log file at all
2. console window provided only some configuration info (like install dir, configuration dir etc) and
file:/C:/Program Files/Eclipse372/.options not found
osgi> Time to load bundles: 16
Starting application: 15038
Application Started: 22714
3. Plugin Registry view showed no oracle.* and no org.eclipse.cdt.* plugin, just like "About Eclipse / Installation Details / Plug-ins".
But I can see them under "About Eclipse / Installation Details / Installed Software"
-initialize and -clean also showed no effect.
This feature is well tested, an works with lots of other plugins.Well... You aren't the first to report various glitches with Eclipse's handling of shared installs. A variety of problems with a variety of plugins. Shared installs is relatively new Eclipse feature and doesn't get a lot of use by developers working on the platform, so all the bugs haven't been flushed out. You are really are on the cutting edge by choosing this route. I suggest trying to find a way not to use shared installs. You can also report the problem on bugs.eclipse.org and see if you can get someone from Eclipse platform to work with you to debug the issue.
I just tried without -configuration, and letting Eclipse - due to missing write permission to install directory - create a configuration in <userprofile>\.eclipse
The problem still remains.
So I am only able to install OEPE when I have write access to Eclipse installation folder.
And I have tried several other plugins, all without any problem - so I´m afraid Eclipse guys will also feel not responsible
OEPE plugins carry Eclipse provisioning system instructions for modifying eclipse.ini file. Adjusting memory, setting various system properties, etc. I don't know what Eclipse provisioning system would do when it sees these instructions and Eclipse install is not writable. Maybe corrupt itself? Who knows what other factors are at play. Eclipse provisioning is a highly complex system and numerous bugs still remain. It's one of the reason that we provide a pre-bundled Eclipse distro with OEPE. My recommendation remains not to waste your time on trying to get this to work...
thanks for your efforts.
But in fact you tell me that Oracle Enterprise Pack is only working if you have administrative rights.
Because even if we don´t use -configuration Eclipse creates these files in the user profile (see above).
Usually (or lets say it is not an exception) in an Enterprise environment common users don´t have these.
And Windows default on C:\program files is that standard users are not allowed to write.
So our request is not that exotic.
I made a file compare between Eclipse372 with OEPE installed to Eclipse home directory, and a completely new Eclipse372:
The only difference in the eclipse.ini was
No memory settings, no system properties etc.
I added this to my test environment (with "-configuration"), did not change anything.
All other changes made to Eclipse home were also done to the "-configuration" folder - at least on the first sight.
To be honest I did not compare hundreds of xml entries character by character.
But exactly the same files are modified, for me this fits very well.
obviously you need to be administrator to use OEPE.
Not very satisfying for enterprise environment - or is the "Enterprise" Pack designed for home office use ????
OEPE does not require administrative rights, write access, etc. to the Eclipse folder. No OEPE code is running when you are installing it. Only the Eclipse Provisioning System (p2) is in control of what happens during installation and what plugins start on Eclipse start. While running in this mode is nominally a feature of Eclipse, it is not a feature that has been robustly tested, so it is not at all surprising that you are running into problems. It is also not at all surprising that some plugins install fine and some don't in this mode.
If your goal is to enable regular users to install OEPE when the installation is in restricted rights mode, then we cannot help you further. Oracle recommendation is to install Eclipse in an area that user will have full rights to avoid issues with plugin installation.
If your goal is to put together an Eclipse install that is subsequently used in restricted rights mode, then you could try putting together your install in a full access area and then moving it into a restricted area like "Program Files". It is safe to move the Eclipse install folder around or copy it between systems. You can also try downloading one of the pre-packaged Eclipse distros with OEPE that are provided on OEPE download pages. I just tried one of these distros (I used the latest version: Eclipse 3.8.1 Juno SR1 and OEPE 126.96.36.199). After unzipping the distro, I made the install folder and all of its content read-only. All plugins started fine. I then moved the read-only folder to "Program Files", where admin rights are necessary. All plugins started fine.
thanks again for your efforts, BUT:
I believe Oracle is designing Software for company/enterprise use.
I believe Eclipse is also intended not only to be used by single home users who can do whatever they want.
We have an enterprise environment, be are bound to variuos restrictions, and we cannot decide to
provide a certain kind of access, always the newest version, and many other things you suggest.
We have many many different environments in production which cannot be changed that easily.
THERE IS DEFINITELY A NEED TO USE "-configuration", and there is definitely a need to provide OEPE to existing Eclipse instances.
We cannot make a new package and throw everything away.
Maybe the term "requires admin rights" is not fully correct. My experience is whenever user has no write access to Eclipse home problem occurs.
If official statement of Oracle is "you have to have full rights" this - imho !!! - goes far away from reality.
Sure - if 2 things are not compatible you can always discuss which one "is guilty".
But my expectation to a company like Oracle, to a product called "enterprise" pack, would be that it is taken care about that this RUNS in an enterprise environment.
Not only in a test lab installation where you can do whatever you want.
And if it is really the failure of eclipse (I obeyed you suggestion and opened a thread there) then I think Oracle would be well advised to push Eclipse to make their own product run there.
Many other companies seem to do this as well ........
We will take your input into consideration. In the meantime, you know what works and what doesn't, so you can proceed accordingly.