This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Bug is similar to one with creating new web module (see #31663 and dependent bugs). As ClearCase doesn't support adding of existing directories to souce control, then taglib editor must properly handle this situation and add tag handler packages to source control. Otherwise user needs to re-create all package tree by hand. How to reproduce: 1. Mount web module stored under ClearCase source control system 2. Create taglib in this web module and add some tags to it 3. Generate tag handler classes and notice that they are created as local directories and there is no convenient way to add them to ClearCase source control
This one will need to have an analogous solutionl to bugtraq # 4830260, which is dependent on 31663. In the solution to that one, the web module detected when a directory creation happened in in a clearcase web module, and used clear case directory creation commands, after asking the user whether that was desired. In the tag library case, directories are created in two ways: 1. when the tag handler generation root specifies a directory that does not exist, then it is created, and then mounted. This directory does not need to be in the same filesystem that the tld file is in. We can check the filesystem that we will be creating the directory in for clearcase, A problem with this is that the user can specify a directory that is not mounted as a file system. In this case we use File.mkdirs() on the absolute path, and then try to mount it. It's possible that this directory is controlled by clearcase (or something above it is). I'm not sure how we'd recognize that case. 2. when a tag handler class is generated, we create a folder for the package that the class will be generated into. In both 1 & 2, when we create a folder in an existing filesystem, we use FileObject.createFolder(). We can replace this with the same createFolderClearCaseHack() used in the WebContextObject patch.
The question remains as to whether this is a showstopper for nevada. The workaround for this bug is for the user to first make sure that the tag handler generation root is versioned properly. (In the usual case, the thgr will be WEB-INF/classes, and so will be OK), and then to make sure that the package directory for the tag handler classes is also fully versioned. In the usual case, this will be a new directory for the first tag generated for the tag library.
Created attachment 9896 [details] Proposed patch that parallels WebContextObject's solution
Code review on the patch: > Date: Mon, 14 Apr 2003 19:54:46 +0200 > From: Petr Jiricka <petr.jiricka@sun.com> > > the code looks almost fine. A couple of clarifications and questions: > > If I understand it correctly, the one thing that is different about the > dialog compared to the WebContext one is the message displayed to the > user, right ? Other than that they are the same. > > Secondly, when you call the mkdirs() method in IDEHelper, is it > guaranteed that this file is not mounted ? How do you make sure it is > not under ClearCase ? > > Petr > Date: Mon, 14 Apr 2003 11:50:46 -0700 (PDT) From: Simran Singh Gleason <Simran.Gleason@sun.com> At the moment, I see two problems with my solution. 1. there are two places where the dialog can come up, if the tag handler generatio nroot needs to be created, and when a new package is created. I haven't coordinated those two dialogs; they're called from different places, and I would need to put a static flag in IDEHelper, and be careful about resetting it (or something). 2. I'm worried about the part where I do mkdirs(). I use the java.io.File method, and so that doesn't go through the netbeans filesystem at all. Also, I don't really know whether the directory is being created or not. Perhaps I need something where I try to find a netbeans filesystem that is an ancestor of the path, and then do something relative from there, and if I cannot find anything like that, decide that it isn't under clear case after all, so File.mkdirs() is OK. But that still isn't quite accurate, because it might be in a filesystem that should be mounted as a clear case filesystem. On the other hand, this is probably a rarer occasion (when the user deliberately specifies a tag handler generation root that is in a directory that is not mounted anywhere else in the IDE, and should be under clear case. To find a mounted ancestor, will I have to poll the Repository filesystems, or do you know of a better way to find out?
Created attachment 9939 [details] New patch that addresses two problems from code review
Bug waiver request made April 16; 24 hours of non-disapproval was achieved April 17; adding S1S5_WAV_APPROVED keyword.
Integrated fix into trunk. Checking in src/org/netbeans/modules/web/taglibed/Bundle.properties; /cvs/web/taglibed/src/org/netbeans/modules/web/taglibed/Bundle.properties,v <-- Bundle.properties new revision: 1.10; previous revision: 1.9 done Processing log script arguments... More commits to come... Checking in src/org/netbeans/modules/web/taglibed/control/GenerateCodeAction.java; /cvs/web/taglibed/src/org/netbeans/modules/web/taglibed/control/GenerateCodeAction.java,v <-- GenerateCodeAction.java new revision: 1.16; previous revision: 1.15 done Checking in src/org/netbeans/modules/web/taglibed/control/IDEHelper.java; /cvs/web/taglibed/src/org/netbeans/modules/web/taglibed/control/IDEHelper.java,v <-- IDEHelper.java new revision: 1.16; previous revision: 1.15 done
Verified