Community
Participate
Working Groups
Our product Beta2 has Eclipse 3.6.0 and Beta3 - Eclipse 3.6.1 Now when updating from Beta2 to Beta3, user is getting following exception: session context was:(profile=studioProfile, phase=org.eclipse.equinox.internal.p2.engine.phases.Unconfigure, operand=[R]org.eclipse.equinox.p2.reconciler.dropins 1.1.0.v20100525 --> [R]org.eclipse.equinox.p2.reconciler.dropins 1.1.0.v20100525, action=org.eclipse.equinox.internal.p2.touchpoint.natives.actions.RmdirAction). Could not remove directory /Applications/Zend Studio.app/Contents/Resources/Java/dropins. This is happening only on Mac, not on Windows, or Linux. There's no such directory as /Applications/Zend Studio.app/Contents/Resources/Java/dropins Why reconciler wants to remove that directory and why it fails if there's no such directory?
Since this product is already in users hands, I'd love to see a way to get rid of it via update mechanism. So is there a way to disable update, unconfigure phase, or ignore RmdirAction failure just by using p2 powers?
What does the IU metadata look like for the org.eclipse.equinox.p2.reconciler.dropins bundle? It is found in the profile registry. eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile If you search the metadata in the profile, do you see the mkdir or rmdir commands? How is the product installed/updated? We had a similar case (bug 311769) in which the product was being installed via a separate install application and it wasn't installing in a manner such that the appropriate metadata commands (to create the dropins folder - this metadata was on the sdk.ide IU) was run so it wasn't creating the dropins directory so it had to be modified.
looking in "/Applications/Zend Studio.app/Contents/Resources/Java/p2/org.eclipse.equinox.p2.engine/profileRegistry/studioProfile.profile/BIGNUMBER.profile" I can see rmdir/mkdir (see details below). The old product version (aka Beta2) was being generated with p2.director from repository produced by pdebuild's product build. Product build had old generate.p2.metadata=true property in build.properties. New version (aka Beta3) is generated directly by pdebuild and with p2.gathering=true. On Mac product is repackaged a little to look more like Mac app: Package.app/Contents Package.app/Contents/MacOS Package.app/Contents/MacOS/ZendStudio (the executable) Package.app/Contents/MacOS/ZendStudio.ini Package.app/Contents/Resources Package.app/Contents/Resources/Java Package.app/Contents/Resources/Java/artifacts.xml Package.app/Contents/Resources/Java/configuration Package.app/Contents/Resources/Java/features Package.app/Contents/Resources/Java/p2 Package.app/Contents/Resources/Java/plugins Product is installed by user by copying (dragging) from DMG archive to /Applications. User has full r+w rights on product directory, it's not shared install. Product is updated via P2 UI: Help -> Check for Updates. dropins IU: <unit id='toolingorg.eclipse.equinox.p2.reconciler.dropins' version='1.1.0.v20100525' singleton='false'> <hostRequirements size='2'> <required namespace='osgi.bundle' name='org.eclipse.equinox.p2.reconciler.dropins' range='1.1.0.v20100525'/> <required namespace='org.eclipse.equinox.p2.eclipse.type' name='bundle' range='[1.0.0,2.0.0)' greedy='false'/> </hostRequirements> <properties size='1'> <property name='org.eclipse.equinox.p2.type.fragment' value='true'/> </properties> <provides size='2'> <provided namespace='org.eclipse.equinox.p2.iu' name='toolingorg.eclipse.equinox.p2.reconciler.dropins' version='1.1.0.v20100525'/> <provided namespace='org.eclipse.equinox.p2.flavor' name='tooling' version='1.0.0'/> </provides> <requires size='2'> <required namespace='osgi.bundle' name='org.eclipse.equinox.p2.reconciler.dropins' range='1.1.0.v20100525'/> <required namespace='org.eclipse.equinox.p2.eclipse.type' name='bundle' range='[1.0.0,2.0.0)' greedy='false'/> </requires> <touchpoint id='null' version='0.0.0'/> <touchpointData size='1'> <instructions size='4'> <instruction key='install'> installBundle(bundle:${artifact}) </instruction> <instruction key='uninstall'> uninstallBundle(bundle:${artifact}) </instruction> <instruction key='unconfigure'> markStarted(started: false);rmdir(path:${installFolder}/dropins) </instruction> <instruction key='configure'> markStarted(started: true);mkdir(path:${installFolder}/dropins) </instruction> </instructions> </touchpointData> </unit>
Created attachment 180477 [details] profile.gz complete profile.gz file
ah and btw. when starting my product for first time, dropins folder is not created and there's no error in the log about any problems with creating it.
I also tested a zip with Windows build, generated straight by pdebuild, unpacked it to writeable directory (~\Desktop). There's no dropins folder, it's not created after start. But still, updates on Windows work fine.
The configure/unconfigure instructions are run when the bundle is installed/uninstalled (not when the bundle is started). So if you have a zipped product with the bundles already installed, the dropins folder should already be there.
oh so it's build-time issue, that pdebuild installs bundles but doesn't configure them. yes? Is there a way to control this?
btw. it's still strange that all works on other platforms but not on Mac
How do you repackage your product from the original form that PDE/Build outputs?
Dropins folders are already missing in pdebuild output. I'm using basebuilder R36_RC4 in the build, and eclipse 3.6.1 as a base dependency. Is there anything special I could look for in debug output from the build? my product build.properties: # Product file path product=/com.zend.php/ZendStudio.product runPackager=false skipFetch=true # P2 Metadata / Update Site Generation p2.gathering=true p2.compress=true p2.append=true p2.repo.dir=${resultDirectory}/repo p2.metadata.repo=file:${p2.repo.dir} p2.artifact.repo=file:${p2.repo.dir} p2.metadata.repo.name=Zend Studio Update Site p2.artifact.repo.name=Zend Studio Artifacts p2.publish.artifacts=true p2.flavor=tooling p2.director.profile=studioProfile #this property indicates whether you want the set of plug-ins and features to be considered during the build to be limited to the ones reachable from the features / plugins being built filteredDependencyCheck=false #this property indicates whether the resolution should be done in development mode (i.e. ignore multiple bundles with singletons) resolution.devMode=true # Specify the output format of the compiler log when eclipse jdt is used logExtension=.log zipargs= tarargs=
Andrew, does PDE/Build do a director install when building a product?
(In reply to comment #12) > Andrew, does PDE/Build do a director install when building a product? Yes PDE/Build is doing a director install when "p2.gathering=true" is used. However, I'm not seeing any special handling for dropins in the build, the old generate.p2.metadata might have done something though. I would check the product IU to see if it requires this 'toolingorg.eclipse.equinox.p2.reconciler.dropins' IU in comment #3. Looking at the product build for the eclipse SDK itself, the .product file specifies a start level for dropins (and all other plugins that need it), and the .product also provides a p2.inf with a configure "mkdir(path:${installFolder}/dropins);" instruction. This mkdir would be on the product and not on a dropins specific CU.
we have product p2.inf file and it works, altough does other things than mkdir(dropins), namely addRepository(). Our product is feature-based and depends on eclipse.platform feature and equinox.p2.user.ui feature. There's no any start-levels defined, but I'm not sure what's connection between setting plug-in start-level and invoking it's p2.inf during p2.director call during the build.
(In reply to comment #13) > Looking at the product build for the eclipse SDK itself, the .product file where's Eclipse SDK .product file? I can't find it.