Community
Participate
Working Groups
I have Project A with a separate src and bin directory for the source and output folder and the entire contents in the output folder is marked as derived (as usual). However, if I import Project A into a fresh workspace, then the 'derived' state is not maintained. This is normally OK, except if you have a SCM like ClearCase which takes control of all files that are not marked as derived. When I try to build Project A in a new workspace which is controlled by ClearCase (note: I am disconnected from ClearCase), it will fail as the output folder cannot be scrubbed (if you are connected to ClearCase this is fine). All .class files are ignored by the ClearCase plug-in, so they do get deleted fine, however package directories are left behind. This results in the builder 'ignoring' the project and leaves project being left in an inconsistent state since it is not compiled properly. Note: Philippe Mulet [ 2:52:25 PM ] I suspect when flushing we could tag them as derived if not already so as to ensure clearcase can discard them properly
Since ClearCase seem to tolerate non-derived class files, we could only tag folders (and copied resources?). Wondering though if this is a default rule of ClearCase.
Since ClearCase has versioned directories, move/rename/deletes of files/folders requires a ClearCase-specific implementation. If the ClearCase plugin is the mode where the user does not allow communication with the ClearCase servers (i.e. "Disconnected" mode), the plugin will not normally allow move/rename/delete operations to occur. There are a few exceptions to that rule. The plugin will allow move/rename/deletes if any of the following are true: 1) the resource to be modified is marked isDerived() 2) the resource to be modified matches a pattern in "Preferences->Team- >Ignored Resources" 3) the resource to be modified was created by the current process (since the plugin is in "Disconnected" mode, the plugin can assume that the user didn't add the resource to source-control yet) Referring to Philippe's comment, if '*.class' is in the "Team->Ignored Resources" list, deletions of '.class' files are allowed.
So let's see if I understand this. 1. Copy the contents of a project from an existing workspace to a new workspace. How is this done? Did you export the project to a zip file? Or just copy the directory structure? 2. Then import it but never get to the point of releasing it. Correct? If so, why does Clearcase think it owns these files since they were never added? Can you delete them outside of Eclipse using another tool that is Clearcase aware? What happens if you do not copy the .class files when you copy project?
Not quite... You do not need to perform any copying. Just start-up a new workspace under the ClearCase snapshot directory, and Import a previously compiled project using the "Import an existing Project" feature. (this project must have it's src and bin directories separated) After performing the import, the files in the output folder are not marked as derived. If the ClearCase plug-in is not involved, then this is not a concern as the next build corrects that. However, if the ClearCase plug-in is involved and is disconnected, then it determines that it controls the workspace by finding a view.dat file which is created when you create a Clearcase snapshot view (I believe it's located in the root of the view directory). If the plug-in locates the view.dat file, then any move/delete/rename on a non-derived file will be caught by the plug-in and denied until you either connect to ClearCase, or mark the file as derived. You can go to the filesystem and delete the files without any problem. As Peter mentioned above, the .class files are excluded by default therefore they do get deleted properly. So in this particular situation, you will be left with many empty package directories left behind which cause the builder to not compile this project. If the output directory is empty when you import the existing project, there are no problems.
Sorry Troy, I don't follow. If I'm importing an existing project which was already built, then why weren't the package directories in the output folder still marked as derived? If they are marked as derived during a normal full build then when did they become non-derived?
I am assuming they are not marked as derived after the import because to the Eclipse importer, it's just another file (i.e. the metadata for each file in the old workspace is not preserved in the new workspace).
Ok that makes sense... one other question. If you turn auto-build off, can you delete the contents of the output folder from the Eclipse Navigator perspective and then launch a build?
Sorry I meant to say: If you turn auto-build off before performing the import, can you delete the contents of the output folder from the Eclipse Navigator perspective and then launch a build?
Whether auto-build is on or off does not seem to make a difference for being able to delete the contents of the output directory. The ClearCase plug-in still denies the contents from being deleted.
My apologies, I was wrong in the previous comment. If auto-build is on, the problem does not occur. It is only when auto-build is off that the problem can be reproduced.
The BatchImageBuilder will now recursively mark a folder & its contents as derived if its not... then delete it. Also backported to the 2.1.x stream.
RE: When does the project come under Repository control. CC adds a listener on post-auto-build events. This listener notices new projects and adds marks them as CC. Since this is a post-auto-build event, the builder will clean this up in auto-build mode. If auto-build is off, the builder will not have run. NOTE: CC provider should explore hooking a different event in 3.0 since autobuild events will occur at a different frequency.
With debugger, i imported a java project and output folder ressources are marked as derived when they were not. Verified for 3.0M6
Verified for 2.1.3 with build M200402251535.
This was backported to 2.1 stream.
Closing old bug that was fixed.
