Community
Participate
Working Groups
AK (9/14/2001 1:52:11 PM) 1. create a cu and make it read-only (in the navigator) 2. create another package and copy the cu (from the packages view) 3. you get an error dialog. this is inconsistent with the navigator - shows no errors NOTES: AK (9/14/2001 1:53:48 PM) the navigator uses IResource::copy which does not report any errors. the packages view uses ISourceManipulation::copy (on CompilationUnit) which reports an error when setting the new contents of the file one solution would be to supress the read only error (by java model) in that case
moved to 'active'
i don't think ui should do something here i think it should be handled in CompilationUnit::copy suggest moving to jcore
agreed, moving to Java Core
same happens if you try renaming a package that has a read-only compilation unit - you get a JavaModelException
The JavaModel operation does copy the resource, and then tries to update its content (even if nothing actually needs to be changed). What behavior would you expect in case it did fail to update the source, and the source would need to be modified ? Silently fail, and no update did occur ? Thinking of a similar problem (Java model does not notify when failing to update the .classpath if read-only), I do not think that silently failing is an option. I did however fix the case where nothing needs to be updated, it will not even attempt to do so anymore.
As per discussion with DJ, we should not be editing the contents of read-only files ever (copy/move). Is it ok for you to not update their contents at all ? Package statements would be incorrect, but if the file is read-only anyway...
The conclusion makes sense to me. Adopting PR. Adam can we warn the user that the files are readonly and that the package declaration will not be updated?
I don't think copied compilation units should retain the read-only attribute. We are using a VCS where only locked files are writeable. I don't want to have to check out a file just to make a copy of it.
preserving the read-only attribute the common behaviour on most platforms and is also the behaviour I'd expect. I don't fully understand your use case. When you copy a read only file the copy isn't managed by the VCM yet so you can just go in and change its attribute to writeable and start editing.
What I want is the same functionality that Together provides. Copying a read-only java source file creates a new writeable class ready to compile with it's new class name. A typical example is creating a new JUnit test. I nearly always copy an existing one. It would be nice if the copy would change any internal references to it's own class to the new class. e.g. in the suite method of a JUnit test.
I agree with Neil. I don't really like to 'feature' of the new file copy maintaining the read-only attribute. I am often frustrated by coping a read- onle file opening it in an editor and being frustrated when trying to save the file because it is read only. We have a number of classes each representing a different message. When creating a new message, we often copy an existing class. If the existing class is readonly, we lose much of the benefit of the copy mechanism. In our case we usually copy the class into the same package. This creates an entirely new class with CopyOf prepended to the class name. However, none of the internal references are updated. If we subsequently check out the new class and rename it, we loose the automatic updating of the class name and constructors. If copy needs to change the file in order for it to remain consistent, it should remove the read-only attribute, at least for JDT compilation units.
This should be driven by UI. The JCore should only do the minimal (rsc copy), and JUI should jump in and offer to lose the read-only flag, so as to perform refactoring operations. Then maybe revert the flag back to read-only afterwards (likely not IMO). Olivier - please check our rsc copy behavior in presence of read-only files. Then this problem should move to JUI for further action.
The problem is that JCore is doing more than just copying the file. It tries to update the package declaration at the beginning of the file according to where the compilation unit has been copied. So for now the copy fails for a compilation unit because of this update. The copy is created with the read-only flag. This is consistent with the copy from the navigator.
I added an extra check on the compilation unit copy. If the destination is read-only, there is no more update of its contents. This means that if you copy a compilation unit A.java from package p1 to package p2 and A.java is read-only, you end up with A.java in p2, but its package declaration is still package p1;. This is consistent with the navigator copy for read-only files. Now if an extra update wants to be applied, the JUI should take care of it. Move to JUI.
Is making the behavior consistent between the navigator and the package view really the goal? The main reason for having separate copy behaviors was because the Java package view had knowledge of what is being copied and can insure consistency within the Java model. A Java copy inherently requires an update of the compilation unit if for no other reason than to update the package statement. The copy behavior is also not consistent between the two views if you make a copy of the file in the same directory. Select "A.java" and say copy. Select the same directory and select paste. The navigator will create a new file called "Copy of A.java". The package view will create a new file called "CopyOfA.java". If "A.java" is writable, the "CopyOfA.java" file will have the class name and all constructors updated with the correct name. It simply doesn't make sense to leave the new file in an inconsistent state when performing a copy from the Java package view.
*** Bug 8663 has been marked as a duplicate of this bug. ***
no action for 2.0
This is really annoying and we should find a solution for 2.1. I agree that copying a resource in a Java world should not honor the read-only flag. Or at least we should show a dialog upfront asking whether the user wants: - to keep the read-only flag with no content change - make the file writable and update the content And there should be a check box saying: always make file writeable on copy.
Chaning state from assigned later to resolved later. Assigned later got introduced by the last bug conversion and is not a supported Eclipse bug state.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
