Community
Participate
Working Groups
Currently, PDE create some new "runtime-EclipseApplication" as siblings of the launching application, so that if Eclipse is installed in your $HOME, you get some runtime-* folders created in your $HOME (which is usually a folder you like to keep control on). Starting a test Eclipse instance is tightly coupled with the project you are testing, and this project is inside the workspace. So wouldn't it make sense, by default, to create the runtime instance somewhere under the workspace? We could think of using $WORKSPACE/.metadata/pde-runtimes/runtime-*" for example.
The main concern is that PDE can already end up with a bloated metadata folder and this would make that issue worse. There is no clean-up of workspace folders when you delete the launch configurations. That being said, it is irritating to have a folder filling up with workspaces, one for every junit class I run. I think there would definitely be benefits for JUnit Plug-in Launches.
(In reply to Curtis Windatt from comment #1) > The main concern is that PDE can already end up with a bloated metadata > folder and this would make that issue worse. I don't understand what you're meaning there. Can you please detail? I prefer a bloated metadata folder than a bloated $HOME folder. > There is no clean-up of > workspace folders when you delete the launch configurations. That's fixable. Should I open a dedicated issue for that? > That being said, it is irritating to have a folder filling up with > workspaces, one for every junit class I run. I think there would definitely > be benefits for JUnit Plug-in Launches. Yes, that would already be a good improvement.
(In reply to Mickael Istria from comment #2) > I don't understand what you're meaning there. Can you please detail? > I prefer a bloated metadata folder than a bloated $HOME folder. Not everyone uses their $HOME folder for their workspace (including myself). PDE already stores downloaded p2 target content, cached model information and more in the PDE .metadata folder. Storing workspaces in their will increase the folder size. Users may notice how large their workspace folder is getting. It can be a hassle to drill down into the folders to determine where the most space is wasted. Also, users are hesitant to delete information from .metadata as they perceive it to be important, whereas runtime-* folders outside of the workspace are most clear on their purpose. > > > There is no clean-up of > > workspace folders when you delete the launch configurations. > > That's fixable. Should I open a dedicated issue for that? Deleting user data is risky. We don't want to (can't?) offer a confirmation dialog whenever you delete a PDE launch config. We could have a preference (off by default) to clean the folder on delete, but I personally would never use it. There is an open request to allow users to run garbage collection on the p2 metadata we store. While it would be for advanced users only, we could offer an action on the preference page to clean up the metadata directory. Either delete all contents of the folder, or any that don't match up with an existing launch configuration. Have a similar option for the p2 target data (run GC or delete it all). So yes, this is worth having a separate issue open to discuss. > > > That being said, it is irritating to have a folder filling up with > > workspaces, one for every junit class I run. I think there would definitely > > be benefits for JUnit Plug-in Launches. > > Yes, that would already be a good improvement.
Pushed a Gerrit review for this trivial change: https://git.eclipse.org/r/28989
(In reply to Curtis Windatt from comment #3) > PDE already stores downloaded p2 target content, cached model information > and more in the PDE .metadata folder. Storing workspaces in their will > increase the folder size. I see that as an argument in favor of putting runtime WS in .metadata for consistency sake. > Users may notice how large their workspace folder is getting. It can be a > hassle to drill down into the folders to determine where the most space is > wasted. Also, users are hesitant to delete information from .metadata as > they perceive it to be important, whereas runtime-* folders outside of the > workspace are most clear on their purpose. > > > > > > There is no clean-up of > > > workspace folders when you delete the launch configurations. > > > > That's fixable. Should I open a dedicated issue for that? > > Deleting user data is risky. We don't want to (can't?) offer a confirmation > dialog whenever you delete a PDE launch config. We could have a preference > (off by default) to clean the folder on delete, but I personally would never > use it. Me neither. > There is an open request to allow users to run garbage collection on the p2 > metadata we store. While it would be for advanced users only, we could > offer an action on the preference page to clean up the metadata directory. > Either delete all contents of the folder, or any that don't match up with an > existing launch configuration. Have a similar option for the p2 target data > (run GC or delete it all). So yes, this is worth having a separate issue > open to discuss. That seems like a good solution. But anyway, I never heard someone complaining about a folder taking too much disk space for years ;) Disks are so big people never delete anything (except to cleanup stuff).
Vikas, please give this at try when you have time. We needto ensure it works for Eclipse launches, OSGi launches, JUnit Plug-in launches and that it doesn't affect existing launch configs.
It works OK for couple of scenarios I tested. According to me, the runtime things should go in workspace location folder and not in the parent of workspace location. However I have some questions/suggestions 1) Should we create a folder in .metadata folder or create a separate folder parallel to the workspace location - for example say "runtime". Which one is better? 2) The name should not be pde-runtime but just runtime. 3) Should we have different folders for debug, release, debug junit, run junit and all the possible combination of runtimes so that it is easily identifiable. Once we finalize on these issues, I can do the full test of this patch or the updated patch. What are your views?
(In reply to Vikas Chandra from comment #7) > 1) Should we create a folder in .metadata folder or create a separate folder > parallel to the workspace location - for example say "runtime". Which one is > better? I don't know what's best. Both are ok IMO. I'd avoid calling a folder "runtime" just under workspace as runtime is a name that will most likely be used by some user creating new projects. We could call it .runtime or something like LauncherRuntimes, which has less risk of being used by developers. > 2) The name should not be pde-runtime but just runtime. Ok. > 3) Should we have different folders for debug, release, debug junit, run > junit and all the possible combination of runtimes so that it is easily > identifiable. Currently, there is only a single folder (workspace parent) containing all kinds of runtimes and no-one seems to have complained so far. So I don't think it's necessary to have different folders.
(In reply to Vikas Chandra from comment #7) > 1) Should we create a folder in .metadata folder or create a separate folder > parallel to the workspace location - for example say "runtime". Which one is > better? It should be in the pde metadata folder. > > 2) The name should not be pde-runtime but just runtime. Yes > > 3) Should we have different folders for debug, release, debug junit, run > junit and all the possible combination of runtimes so that it is easily > identifiable. No, a single folder. Mickael, are you planning to update for these minor changes?
(In reply to Curtis Windatt from comment #9) > Mickael, are you planning to update for these minor changes? Yes, I think I'll be able to update the Gerrit patch according to this feedback. It seems like there is only 1 thing to change compared to the current patch. > It should be in the pde metadata folder. How can I programatically know the PDE metadata folder? Do you have a util method or some constants to get that?
(In reply to Mickael Istria from comment #10) > How can I programatically know the PDE metadata folder? Do you have a util > method or some constants to get that? PDECore.getDefault().getStateLocation() Then just append the folder name (i.e. .append(".p2"))
(In reply to Curtis Windatt from comment #11) > (In reply to Mickael Istria from comment #10) > > How can I programatically know the PDE metadata folder? Do you have a util > > method or some constants to get that? > > PDECore.getDefault().getStateLocation() > > Then just append the folder name (i.e. .append(".p2")) Thanks. And would such a method contain the ${workspace_loc} property? I guess that's something we'd like to keep, don't we?
(In reply to Mickael Istria from comment #12) > (In reply to Curtis Windatt from comment #11) > > (In reply to Mickael Istria from comment #10) > > > How can I programatically know the PDE metadata folder? Do you have a util > > > method or some constants to get that? > > > > PDECore.getDefault().getStateLocation() > > > > Then just append the folder name (i.e. .append(".p2")) > > Thanks. > And would such a method contain the ${workspace_loc} property? I guess > that's something we'd like to keep, don't we? Good point. Taking the state location from the plug-in would give you a full path. It would be better to use ${workspace_loc} with a hard coded path to the PDE .metadata folder.
Mickael, If we want to put the patch in 4.5M1, we should have it up for review.
(In reply to Vikas Chandra from comment #14) > Mickael, If we want to put the patch in 4.5M1, we should have it up for > review. Gerrit changeset: https://git.eclipse.org/r/28989 Patch-set one has the incorrect path. It should be: workspace_loc/.metadata/org.eclipse.pde.core/<folder name> My suggestion for <folder name> would be "runtime_workspaces". Since we are changing the workspace location, it would be great if new configurations also put their configuration directory inside of a named folder so they don't pollute the metadata folder as much. i.e. move them from workspace_loc/.metadata/org.eclipse.pde.core/ to workspace_loc/.metadata/org.eclipse.pde.core/runtime_configurations Reminder Vikas when testing to ensure that this does not break existing launches.
I just updated the patchset.
(In reply to Mickael Istria from comment #16) > I just updated the patchset. Patchset looks good. Vikas please test with new launch config and existing launch config as well as run the test suite. I cloned this bug to track changing the configuration folder location. Bug 440905
The feature works as explained. OSGI and junit launches works ok though path of junit folder is still ${workspace_loc}/.metadata/.plugins/org.eclipse.pde.core/pde-junit ( I think it would be tackled by cloned bug with config changes metadata moved to the new place)> However, I have minor doubt about the location of runtime - whether parallel folder to .metadata folder would have better or inside .metadata.
(In reply to Vikas Chandra from comment #18) > However, I have minor doubt about the location of runtime - whether parallel > folder to .metadata folder would have better or inside .metadata. I personally put them all parallel to the .metadata folder. So it would be ${workspace_loc}/junit-workspace I think that under .metadata should never require user interaction because it's hidden. But the runtime workspaces, often I go look at the files to see what's going on (investigation of test failure) and sometimes I clean them. I think putting them under ${workspace_loc}/runtime_configurations would be ideal because it would not be as hidden and they would all be grouped together.
${workspace_loc}/runtime_configurations ( or ${workspace_loc}/runtime-New_configuration to be consistent) would be my preferred choice for the same reasons mentioned in comment 19.
Or better still ${workspace_loc}/runtime_configurations/runtime-New_configuration so that the folder parallel to current workspace location doesn't get cluttered.
(In reply to Vikas Chandra from comment #21) > Or better still > ${workspace_loc}/runtime_configurations/runtime-New_configuration > so that the folder parallel to current workspace location doesn't get > cluttered. That's what I meant, sorry it wasn't clear. +1
Dani, can we get your opinion on this. I am agreeable to having a folder inside the workspace folder, but I thought only the .metadata folder as well as projects were stored there (plug-ins were expected to use the .metadata folder). If we do use the workspace root, I have two recommendations a) Start the folder name with a . to distinguish it from project names. b) Use "pde-runtimes" or another name specific to PDE so the user might guess who is creating them. To recap for Dani: Currently we put them as siblings to the workspace ${workspace_loc}/../runtime-* We could put them in the .metadata: ${workspace_loc}/.metadata/org.eclipse.pde.core/runtime-workspaces/runtime-* Or put them in the root of the workspace ${workspace_loc}/runtime_configurations/runtime-* or ${workspace_loc}/.pde-runtimes/runtime-*
Eclipse test/target workspaces and JUnit Plug-in Test workspaces are usually considered temporary data. Putting them into the workspace is a bad idea. For those users who disagree there's a preference where they can override this behavior. This is a WONTFIX for me.
Maybe there should be a "temporary" directory in an Eclipse workspace for such use-cases.
(In reply to Mickael Istria from comment #25) > Maybe there should be a "temporary" directory in an Eclipse workspace for > such use-cases. Why should that be inside the workspace? Temporary == I don't care.
Moving out of 4.5M2 since we are still debating on this.
(In reply to Dani Megert from comment #26) > Why should that be inside the workspace? Temporary == I don't care. Because the runtime application is contextual to the set of projects I'm working on, which are in the workspace; not in user home.
(In reply to Mickael Istria from comment #28) > (In reply to Dani Megert from comment #26) > > Why should that be inside the workspace? Temporary == I don't care. > > Because the runtime application is contextual to the set of projects I'm > working on, which are in the workspace; not in user home. I'm not arguing whether in user home or not. I just don't want it inside my workspace location. I have tons of target and test workspaces and I don't want to back up or copy them along with my workspaces.
(In reply to Dani Megert from comment #29) > I'm not arguing whether in user home or not. I just don't want it inside my > workspace location. I have tons of target and test workspaces and I don't > want to back up or copy them along with my workspaces. So what's the solution here? We list possible locations with pros and cons and we create a poll ?
(In reply to Mickael Istria from comment #30) > (In reply to Dani Megert from comment #29) > > I'm not arguing whether in user home or not. I just don't want it inside my > > workspace location. I have tons of target and test workspaces and I don't > > want to back up or copy them along with my workspaces. > > So what's the solution here? Sorry for the late response. Pretty busy times. I see two possible solutions: - The first time a Runtime workspace is created, we ask the user (unless he already changed the preference). - Since this bug report was triggered by the pollution of home/user directory, we could set the default based on whether the dev workspace itself is in home/user. I'd be in favor of the second approach.
(In reply to Dani Megert from comment #31) > - Since this bug report was triggered by the pollution of home/user > directory, > we could set the default based on whether the dev workspace itself is in > home/user. That would work for me. And in case the dev workspace is in $HOME, what would be a good location for the runtime workspaces in your opinion?
