Community
Participate
Working Groups
I20050921 For split refactoring, temporary changing .class files is needed so that changes can be applied temporarily. Adding a working copy support on the attached source of a .class file would solve this problem.
To give some more context to this problem, I'll describe our scenarios in more detail: Scenario 1: Execute a series of refactorings during pre-catch-up hook of repository update operation - Refactoring information is stored per project in a separate refactoring history file - During catch-up, we would like to - Retrieve refactoring information from incoming resources - Execute all refactorings associated with the incoming resources - In order to produce no merge conflicts (the same refactoring has been executed both remotely and locally) we need to leave the set of files in the change set locally untouched during pre-catch-up hook - To achieve this, some kind of working copy mechanism is needed to operate on virtual source (structural information only), on virtual packages, and source folders Scenario 2: Execute a series of refactorings on a JAR file - We plan to annotate JARs with refactoring information - An import wizard takes the JAR and retrieves refactoring information - Before switching the old JAR to the new version - Execute all retrieved refactorings - Since refactorings must have a compilable workspace state at all times, the contents of the JAR file must be temporarily changeable. - After the execution of the refactorings, the temporary changes are discarded, and the JAR file is replaced with its new version. Based on these scenarios, we could imagine the following operations to be supported: - Create "working copy" of package fragments (both source and binary) - Hide package fragments (both source and binary) - Create compilation unit working copy in a package working copy - Create compilation unit working copy for binary type (class file or JAR entry) Note: We have to handle not only class files, but also entire JARs, with possibly no source attachment
Hey, you're asking too much :-) Let's focus on one problem at a time. I believe this bug is for your 4th requirement: "Create compilation unit working copy for binary type (class file or JAR entry)". However you said you want to handle class files with no source attachment. What would be the content of the working copy in this case ?
I was just outlining our story in order to give you more context to solve the problem ;-) Yes, the class file working copy covers the 4th requirement. I think we do not need to consider source attachments at all: Since class file working copies are never used to create or change a type's contents, but are of temporary nature only, refactorings only need a source file which is structurally equivalent to the binary type (a cu containing source similar as in the class file editor, if no source can be found). Of course, if there is a source attachment, we may also use the source instead of the structural equivalent.
In order to hide types, it might be a good idea to provide access to the buffer of the class file working copy (to make buffer empty).
I understand. Thanks for the context. You will have access to the IBuffer though IOpenable#getBuffer() (IOpenable is a supertype of ICompilationUnit).
Added API IClassFile#becomeWorkingCopy(IProblemRequestor, WorkingCopyOwner, IProgressMonitor) that returns an ICompilationUnit in working copy mode on the given class file. Added tests ClasFileTests#testWorkingCopy01() to testWorkingCopy10(). Note that due to bug 111420, class files with no source attached may not have a compilable working copy. Released in build > I20051004
Verified for 3.2 M3 using build I20051025-0800+JDT/Core v_618a
