Community
Participate
Working Groups
1. pde automatically creates configuration files of p2 under <$workspace>/.metadata/.plugins/org.eclipse.pde.core/p2 2. dev have to clean those files by hand
When are those files being created for you? What version of Eclipse are you using? AFAIK the files created in PDE core metadata are put into folders starting with '.' and are intended to be persisted longer than the your launch configurations. Any files created during a launch should be put under a configuration directory named the same as your launch config. Those files should be cleaned up when you delete the appropriate launch config.
Eclipse version is 3.5 GA, Build id: 20090619-0625 Yes, I know the configuration files of Eclipse Application would put a directory named the same as my launch configuration. It also provides a very useful option to clean workspace, including user data and osgi cache. My RCP is a installer application based on p2. So the persist files under <$workspace>/.metadata/.plugins/org.eclipse.pde.core/p2 probably are created by p2 API. PDE cleaning the p2 configuration files should benefit to p2 related development before launching the application.
I don't see why p2 code would be creating data in the pde metadata. We need to know what is creating the folder before I can say whether we can clear it. Also, as I mentioned before, launch data should be stored under the folder for the specific launch. If a launch config deleted data in the pde metadata folders, it could easily remove data required by other code. cc'ing Pascal on the off chance he knows of some p2 API that could be creating a p2 folder in the PDE metadata.
Could you please provide detailed steps that lead to the creation of the p2 folder?
My app is simple. It always tries to install my rcp into a empty folder. So I call IProfileRegistry.addProfile to create new profile firstly if it doesn't exist. The profile property 'PROP_INSTALL_FOLDER' always caches the installation location. Hence I want to clean the cached profile to installing my rcp in a clean environment. The default implementation of p2's profile registry would persist the profile in a directory. The default AgentLocation service is initialized by below code, which is relative to 'osgi.configuration.area'. URL defaultLocation = new URL(aContext.getProperty(PROP_CONFIG_DIR) + DEFAULT_AGENT_LOCATION + '/');
Pascal, is the default p2 data area 'p2' or '.p2'? I think there is a bug in PDE related to bug 272810. We are supposed to be moving the p2 data area under the metadata so it gets cleaned up, but it appears we only do that if the data area is explicitly set.
I think this bug will be fixed by the changes on bug 250126. If you can, try out the patch there. It should be put in for M3.
Should be fixed with the changes in bug 25126. Meng Xin Zhu, can you please see if your problem is fixed using M3?
I tried it on M3. I found the p2 configuration area has been moved into configuration for PDE launching. So the p2 configuration can be cleaned when checking the option 'clear the configuration area before launching'. Thanks for your work,:)
Thanks for getting back to us. Verified.
@Curtis, I have some new thoughts about this enhancement, so reopen it. The current fix is that putting the p2 data beneath the configuration when launching the RCP in PDE. The p2 data would be cleaned if checking the option to clean the configuration data when running/debugging the RCP. However, p2 data and OSGi configuration are totally different. You can see the official release of Eclipse also put them in different folders, configuration/, p2/. When I develop the our RCP, I want to clean the OSGi cache to let the changes of MANIFEST take effect, and keep the p2 data. The profile data is useful for our development, recovering it need cost some time to install some things. So it's necessary to distinguish the p2 data and OSGi configuration data while running RCP in PDE. The better solution is adding an option to indicate whether cleaning up the p2 data.
I will open a separate enhancement request so we can better track the changes. Returning to FIXED.
Returning to VERIFIED. The created bug will depend on this bug.
