Community
Participate
Working Groups
200211216 in a project, create a src folder and another src folder nested in it delete the outer one boom, both are gone need to see if it's us or jcore
IMO it is ok moving both. But we have to check what refactoring does to the build path.
I meant deleting both. After discussing with Adam and seeing it on the screen it might not be obvious for a user that this will delete both source folders since the aren't visually connected in the UI (no parent/child relationship).
IPackageFragmentRoot is not an ISourceManipulation so all these routines for reorg are now implemented in the ui land, which is suboptimal i think everytime something fundamental changes (like the fact that you can nest source folders now), we have to do work that is not really ui work Phillippe, can deeper reason why IPackageFragmentRoot is not an ISourceManipulation? Then, we could simply call 'delete/rename/copy/move' and jcore, which is in a much better position to do it, would do the right thing
Jdt/Core should honor this. Altering an enclosing source folder should not affect the nested one.
Adam, Dirk, Should the manipulations on an IPackageFragmentRoot update the classpath as well? If yes, what about jar files that are on several classpath? Won't users complain that their classpath is affected? An IWorkingSet used to be updated when a project was removed. It now remember the reference to the project. Not updating the classpath would be consistent with this behavior.
what we need is a way to control whether classpath is updated or not (a boolean flag for example) if the package fragment root is referenced by more than 1 project we could then open a warning dialog and ask the user if they want to update other classpaths as well
In this case, implementing ISourceManipulation wouldn't do it as it doesn't have a flag to control the updating of the classpath.
it will suffice if the required routines are declared on IPackageFragmentRoot
Adam, any objection if the copy, delete, move and rename APIs won't be allowed for external jars?
deleting of external jars should remove them from the classpath (that's the current behavior) how 'bbout we get a method removeFromClasspath on IPackageFRagmentRoot? then the ui could call this method if needed rename, copy and move are now not allowed on external jars so i guess it's fine if you do not support it. but delete we do need to keep current function. Dirk, any oppinions?
You don't seem to support renaming, moving, copying of internal jar package fragment root either. More generaly, what would be the meaning of copying and moving a library (jar or class folder) that is not in the project of the root?
Added the following API on IPackageFragmentRoot: /** * Deletes the resource of this package fragment root as specified by * <code>IResource.delete(int, IProgressMonitor)</code> but excluding nested * source folders. * <p> * If specified, update the raw classpaths of all Java projects referring to * this root's resource by removing the corresponding classpath entries on * the raw classpaths. * </p> * * @param updateFlags bit-wise or of update flag constants * (<code>FORCE</code> and <code>KEEP_HISTORY</code>) * @param updateClasspath whether the classpaths of the referring projects * should be updated * @param monitor a progress monitor * * @exception JavaModelException if this root could not be deleted. Reasons * include: * <ul> * <li> This root does not exist (ELEMENT_DOES_NOT_EXIST)</li> * <li> A <code>CoreException</code> occurred while deleting the resource * </li> * <li> This root is external (INVALID_RESOURCE_TYPE)</li> * </ul> * @see IResource#delete * @since 2.1 */ void delete(int updateFlags, boolean updateClasspath, IProgressMonitor monitor) throws JavaModelException; Moving back to JDT/UI to use this new API.
Adam, you are the man to fix this ;-).
there're some problems with the current implementation of the delete method a. it does not handle external jars so we, in the ui, have to handle that 1 case specially b. if the root is internal but not local to the project (e.g. a jar declared in project p and put on the classpath of project p2) the method deletes it from the disk - it should only remove it from the classpath of p2
a. Please open a separate bug b. I don't agree: if I select a jar and press delete, I expect it to be deleted from disk. If I want to remove it from the classpath, I would edit the classpath.
a. see bug 30506 b. deleting them would be scary - you select a jar in your project and it deletes it in some other project
I agree that this is scary. The situation is comparable with links on the file system.
The jar appears with its full path in the package explorer. So you see that it doesn't belong to the current project.
If I create a Test project and reference ant.jar from org.apache.ant I only see ant.jar. IMO deleting a reference should never delete the original element without presenting a warning to the user. If no warning is presented, deleting a reference should never delete the original. This is fail save. Why can't we add another flag to the updateFlag parameter to control this. Then the UI could present a dialog and depending on the users choice we would delete the jar or we would keep it.
Dirk, which build are you using? In I20030128, if I reference ant.jar from project Test, I see /org.apache.ant/ant.jar under Test. I agree that a warning should be presented to the user (in all cases actually). But isn't the current behavior to prompt for confirmation when the user presses delete?
If no delete behavior was to be performed, then the answer is simple: don't call delete on the root. If you want to modify the classpath, simply use setRawClasspath instead.
I am still using I20030122++ due to the launching problems in 28. IMO the warning should differ depending on if you delete a reference or if you delete a "original" element. For references I expect to see something like this: You are going to delete a Jar that is located in a different project. Do you want to delete the Jar. Doing so will affect the following projects: <a list of projects that reference the Jar as well> Since deleting a Jar can affect lots of projects in your workspace we should not assume that presenting the full path is enough information for the user.
Regarding Philippe's comment: That is what we do right now. The problem is that whenever something changes related classpathes the UI has to be adapted as well. That's why we prefer a solution that Core is doing it, because you know when something with the class path changes and you can adapt all code places.
The delete API is actually meant to perform some deletion (except for external JARs where we don't assume we own them). Maybe we could provide a flag to state whether it should delete the corresponding file ? delete(boolean shouldDelete) <g>
we are considering a different solution: - disabling the delete action on package fragment roots that are not residing in their parent projects - adding a 'remove from build path' (see bug 30592) action that would be enabled on all package fragment roots and would remove them from the classpath of their projects (works for both external and internal jars, and could work for source/class folders as well) opinions?
Sounds like a good compromise. So you really need a 'shouldDelete' flag (would be false if you just want to update the classpath). We're considering changing the APIs to take a bit-wise or of constants instead of the 'updateClasspath' boolean. How does it sound?
maybe add a method like 'removeFromClasspath(boolean allProjects)' that would remove the receiver from the class path of its declaring project or all projects that reference it
Maybe the API should be called: remove, then using flags you can clarify which behavior you want: - deleteResource - removeFromEnclosingProjectClasspath - removeFromAllProjectsClasspath we are thinking of moving away from boolean flags, but rather using an int (one bit per flag), so as to ease further adjustments.
sounds good
please bounce back when it's there for now, the 'remove from classpath' action (released today) uses our code to remove from classpath - will update to use jcore code when it's available
It should be released in HEAD.
fixed! thanks for all your help here
