Bugzilla – Full Text Bug Listing
| Summary: | Missing CUs when launcher appears in the osgi.bundles list | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Ian Bull <irbull> | ||||||||||||||||
| Component: | p2 | Assignee: | Andrew Niefer <aniefer> | ||||||||||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||||||||||
| Severity: | normal | ||||||||||||||||||
| Priority: | P3 | CC: | aniefer, dj.houghton, pascal | ||||||||||||||||
| Version: | unspecified | Flags: | aniefer:
review+
aniefer: review+ |
||||||||||||||||
| Target Milestone: | 3.4 RC3 | ||||||||||||||||||
| Hardware: | PC | ||||||||||||||||||
| OS: | Windows XP | ||||||||||||||||||
| Whiteboard: | |||||||||||||||||||
| Attachments: |
|
||||||||||||||||||
|
Description
Ian Bull
btw, I did this with: I20080523-0100 This worked for me using the p2 admin UI from head. Ian can you give more detail about the resulting shape of your install? - Where is the pool relative to the exe? - what does the eclipse.ini say? (is the --launcher.libary a valid path?) - also confirm the dll exists in the pool, something like plugins\org.eclipse.equinox.launcher.win32.win32.x86_1.0.100.v20080509-1800\eclipse_1114.dll (In reply to comment #2) > This worked for me using the p2 admin UI from head. > > Ian can you give more detail about the resulting shape of your install? > - Where is the pool relative to the exe? > - what does the eclipse.ini say? (is the --launcher.libary a valid path?) > - also confirm the dll exists in the pool, something like > plugins\org.eclipse.equinox.launcher.win32.win32.x86_1.0.100.v20080509-1800\eclipse_1114.dll > Where is the pool relative to the exe? I put them both on my Desktop (windows) under example, so c:\Documents... <path to desktop>/example/install c:\Documents... <path to desktop>/example/pool What does the eclipse.ini Say? This may be the problem as there is no eclipse.ini file. Also, I just tried this with another product (that has an eclipse.ini file) and this didn't work either, this ini file didn't have a --launcher.library flag (although it did have a -startup that pointed to the launcher). DLL Files: Yep, these are here. I can try this with the launcher from head if you want. What plug-ins do I need? Can you post your content.xml? The missing eclipse.ini is the problem, a --launcher.library is absolutely required with a bundle pool. In my results, the product requires an IU "toolingorg.eclipse.equinox.launcher.win32.win32.x86". This IU contains instructions "addProgramArg(programArg:--launcher.library);addProgramArg(programArg:@artifact);" which add the argument to the eclipse.ini file. You already have the latest version of the metadata generator which is where the source of any problems is likely to be. Created attachment 102168 [details]
content.xml
Here is the content.xml file from the repository.
There doesn't seem to be a:
"addProgramArg(programArg:--launcher.library);addProgramArg(programArg:@artifact);"
Just to be sure, all I am doing is selecting "Eclipse Product Export Wizard" from the product file, and selecting "Generate metadata repository". Everything in the product config file is the default.
Some other things that may help (From my eclipse configuration details)
eclipse.ant.noInput=true
eclipse.buildId=I20080523-0100
eclipse.commands=-os
win32
-ws
win32
-arch
x86
...
java.runtime.name=Java(TM) SE Runtime Environment
java.runtime.version=1.6.0_03-b05
java.specification.name=Java Platform API Specification
java.specification.vendor=Sun Microsystems Inc.
java.specification.version=1.6
Created attachment 102242 [details]
patch to generator & frameworkadmin
2 problems:
1) When generating metadata for products where all bundles are listed on the osgi.bundles list, we end up getting conflicting CUs for the launcher fragments: 1 for the --launcher.library property, one to get it started at default level 4.
2) Framework admin when installing to the bundle pool is actually deleting the eclipse.ini file immediately after writing it.
Fix :
1) don't generate start level information for the launcher fragments. We know they don't need to be started and we know they need programArg entries for --launcher.library
2) frameworkadmin, after saving the eclipse.ini, only delete the previous one if it is not the same file we just saved.
Created attachment 102259 [details]
plugins containing fix
Ian, we are having trouble reliably reproducing this to test the fix. If you can reproduce and you please try the attached jars.
What's the best way to use these plugins (now with P2). I dropped them in my droppin folder, but I still get the same error. (i.e. no addProgramArg in the content.xml). I also tried just placing them in my plug-ins folder, which is of course how I would have worked pre-p2, and that didn't seem to fix it either. I also tried on another machine (still Windows, but a 1.5 VM), and I could reproduce the error without problems. There must be something else going on here, i'll attach the eclipse project that causes the problems. Created attachment 102279 [details]
project that demonstrates the error
Here is the project I used, (In a clean workspace with a clean version of RC2) that causes the problem. All I did was:
1. Select "Eclipse product export wizard" from the config.product file
2. Select "Include source"
3. Select "Generate metadata repository"
DJ, Using Ian's attached project I reproduced by: 0) On a fresh I20080527-2000 with p2 from HEAD. 1) Import the project 2) export the .product file with metadata Inspect the resulting content.xml shows toolingorg.eclipse.equinox.launcher.win32.win32.x86 with start level touchpoint data instead of --launcher.library program args. 3) Install the product using a bundle pool Resulting install did not contain an eclipse.ini file and won't start. Apply patch & repeat with fresh workspace. content.xml has proper addProgramArg(programArg:--launcher.library);addProgramArg(programArg:@artifact); Install contains an eclipse.ini and works. Ian, I tried to match the versions of the jars I attached to what would already be in your install, you could just replace the jars that were already in your plugins folder. Ah... I think I see the problem. the metadata.generator in plugins.zip is 20080514-1900, but my current Eclipse (I20080523-0100) is 20080523-0001. Also, the meta data generator (in the zip) is much smaller (125kb) than my existing one (160kb). Which I wouldn't expect this late in the game. I changed the version numbers to match (by just renaming the file, although now that I think about it there is probably some manifest that needs to be updated too). Anyways, this still didn't work, but the old update manager returned, so I guess Eclipse didn't like that :-). Ian, try changing the qualifier in the artifacts.xml file at the root of your install. I reviewed the patch and it looks safe to release from visual inspection. I am still unable to reproduce the original problem myself after several attempts and would feel better if Ian was able to verify that running with the new JARs fixes his problem. I am trying right now, but I can't seem to get eclipse to resolve metadata.generator v20080514, even when I changed the qualifier in the artifact file. I noticed that the bundle is referenced in a few other xml files too (namely a content.xml file in rollback and configuration\org.eclipse.osgi\bundles\109\data\-254163376). Created attachment 102544 [details]
plugins
Plugins exported with version numbers matching I20080523-0100.
Just overwrite existing plugins. The difference in size from I20080523-0100 is attributed to missing signature files.
The metadata.generator is missing the 'v', but I was able to drop this one in (and delete the other one) and it looks like we might be getting somewhere :-). The content.xml file now has: <instruction key="configure">addProgramArg(programArg:--launcher.library);addProgramArg(programArg:@artifact);</instruction> I will do some testing tonight to make sure it will actually install with a bundle pool. Thanks for all the work guys! Same as DJ. Andrew, once you have Ian's go, please release. You guys are really going to start to hate me soon, :-) First the good news. This does seem to add the "addProgramArg" instruction to the content.xml file, however (the bad news) this doesn't seem to solve the original problem. I don't know if any of these changes need be applied to the p2 agent, so here is what I did: 1. Created the repository with the patched plugins installed 2. Got the following bundles from head a. org.eclipse.equinox.p2.ui b. org.eclipse.equinox.p2.ui.admin c. org.eclipse.equinox.p2.admin.rcp 3. Used these three plugins (plus what was in RC2 + the two patched plugins) to launched the p2 agent 4. Used this agent to install my application (using both a bundle pool and install location) This still results in the same error (The Eclipse executable launcher was unable to locate its companion shared library.). I will attach both the new context.xml file and my repository. Created attachment 102567 [details] Updated context.xml here is the updated context.xml file. Also, here is the diff between the two: 3c3 < <repository name='file:/C:/Documents and Settings/irbull/Desktop/example1/repository - metadata' type='org.eclipse.equinox.internal.p2.metadata.repository.LocalMetadataRepository' version='1.0.0'> --- > <repository name='file:/C:/Documents and Settings/irbull/Desktop/example2/repository - metadata' type='org.eclipse.equinox.internal.p2.metadata.repository.LocalMetadataRepository' version='1.0.0'> 6c6 < <property name='p2.timestamp' value='1212028024000'/> --- > <property name='p2.timestamp' value='1212028775328'/> 1160a1161,1163 > <filter> > (& (osgi.ws=win32) (osgi.os=win32) (osgi.arch=x86)) > </filter> 1171c1174 < setStartLevel(startLevel:-1); --- > removeProgramArg(programArg:--launcher.library);removeProgramArg(programArg:@artifact); 1174c1177 < setStartLevel(startLevel:4); --- > addProgramArg(programArg:--launcher.library);addProgramArg(programArg:@artifact); 2777c2780,2784 < <required namespace='org.eclipse.equinox.p2.iu' name='toolingorg.eclipse.equinox.launcher.win32.win32.x86' range='[1.0.100.v20080509-1800,1.0.100.v20080509-1800]'/> --- > <required namespace='org.eclipse.equinox.p2.iu' name='toolingorg.eclipse.equinox.launcher.win32.win32.x86' range='[1.0.100.v20080509-1800,1.0.100.v20080509-1800]'> > <filter> > (& (osgi.ws=win32) (osgi.os=win32) (osgi.arch=x86)) > </filter> > </required> Created attachment 102571 [details]
Here is the repository created with the patched plugins.
(In reply to comment #20) > 2. Got the following bundles from head > a. org.eclipse.equinox.p2.ui > b. org.eclipse.equinox.p2.ui.admin > c. org.eclipse.equinox.p2.admin.rcp Ian, I am not convinced you are running with the changes to org.eclipse.equinox.frameworkadmin.equinox I would suggest getting that bundle from head, apply the patch attached here. Then run the p2 agent with those changes and try to install again. You don't need to recreate the repository. I will grab that and try again. I should point out that that the eclipse.ini is now being created, but it doesn't have the --launcher.library arg. current eclipse.ini file: -startup ../pool\plugins\org.eclipse.equinox.launcher_1.0.100.v20080509-1800.jar -configuration C:\Documents and Settings\irbull\Desktop\e4\install\configuration But I will try with this patch and see how that works. With the patch it is still creating the eclipse.ini file (which it wasn't doing earlier this week), but the --launcher.library arg is missing.
Quickly looking at the source, it seems that
EclipseLauncherParser.needsPathResolution(String, String, String)
...
if ("--launcher.library".equalsIgnoreCase(entry))
return launcherFolder;
...
This particular condition is never executed (i.e. there is never an entry that equals --launcher.library). Would this be a problem, or is there another place where this argument is processed?
Also, in the agent, When I created the profile I gave it a profile ID, install folder, and bundle location. I left Name and Description blank, and left the others as default. (I don't know what Flavor is).
I have spent a good chunk of today getting all the p2 bundles from CVS and trying to figure out why the --launcher.library is not getting set in my eclipse.ini file. (Not to mention why this only happens to me). It seems that the LauncherData is not being populated with the programArgs. If you point me to the place where the context.xml file is actually parsed, maybe I can see what is going on. Thanks, Ian Put a breakpoint in Phase.mainPerform at the call to getActions(). You want the Configure Phase, the list of operands should contain the org.eclipse.equinox.launcher.win32.win32.x86 IU, (the tooling IU containing the addProgramArg is a fragment of that IU). The action class itself is AddProgramArgumentAction WOW! Ok, I now know more about InstallableUnitPhases, ProvisioningActions, GeneratorInfo, and the context.xml file than I have ever wanted to know :-). After a day of hacking through this trying to figure out why the --launcher.library flag was not being set, I finally decided to blow away the metadata directory for p2 agent. It seems even though I didn't have any other repositories listed, some old ones were being cached. (This is probably a bug). Anyways, with the patch attached here I was able to create proper context.xml file (see the updated one attached), and use this repository to *finally* install with a bundle pool. Sorry Ian, I should have thought of that. This has happened to me in the past, I turned on "Clear the configuration area before launcher" on the settings tab of my launch configuration for the admin UI. No worries Andrew, I learned a lot about the inner workings of reading context.xml files. The important thing is that I was able to get the fix to work. Let me know if this makes it into RC3. Thanks for all the work guys, Ian Pascal reviewed and released. This actually made it into last nights build I20080529-1806. Note that the changes in the patch for framework admin were actually released in I20080529-1300 as the fix for bug 234520, Verified in 3.4 RC3 (I20080530-1730). Thanks again everyone. |