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 32699 - Taglibed & ClearCase: tag handler packages are not added to source control
Summary: Taglibed & ClearCase: tag handler packages are not added to source control
Alias: None
Product: javaee
Classification: Unclassified
Component: Code (show other bugs)
Version: -S1S-
Hardware: All All
: P2 blocker (vote)
Assignee: sgleason
Keywords: RELNOTE
Depends on:
Reported: 2003-04-08 01:38 UTC by Mikhail Romanov
Modified: 2010-01-12 02:06 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Proposed patch that parallels WebContextObject's solution (12.39 KB, patch)
2003-04-13 21:03 UTC, sgleason
Details | Diff
New patch that addresses two problems from code review (17.95 KB, patch)
2003-04-15 01:42 UTC, sgleason
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mikhail Romanov 2003-04-08 01:38:54 UTC
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
Comment 1 sgleason 2003-04-11 19:49:16 UTC
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

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

  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

Comment 2 sgleason 2003-04-11 19:52:11 UTC
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.

Comment 3 sgleason 2003-04-13 21:03:33 UTC
Created attachment 9896 [details]
Proposed patch that parallels WebContextObject's solution
Comment 4 sgleason 2003-04-15 01:41:31 UTC
Code review on the patch:

> Date: Mon, 14 Apr 2003 19:54:46 +0200
> From: Petr Jiricka <>
> the code looks almost fine. A couple of clarifications and
> If I understand it correctly, the one thing that is different about
> dialog compared to the WebContext one is the message displayed to
> 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
> not under ClearCase ?
> Petr

Date: Mon, 14 Apr 2003 11:50:46 -0700 (PDT)
From: Simran Singh Gleason <>

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
   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
   method, and so that doesn't go through the netbeans filesystem at
   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
   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
   quite accurate, because it might be in a filesystem that should be
   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
   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
   or do you know of a better way to find out?
Comment 5 sgleason 2003-04-15 01:42:43 UTC
Created attachment 9939 [details]
New patch that addresses two problems from code review
Comment 6 sgleason 2003-04-18 03:38:31 UTC
Bug waiver request made April 16; 24 hours of non-disapproval was
achieved April 17; adding S1S5_WAV_APPROVED keyword. 
Comment 7 sgleason 2003-04-19 01:01:24 UTC
Integrated fix into trunk. 

Checking in src/org/netbeans/modules/web/taglibed/;
new revision: 1.10; previous revision: 1.9
Processing log script arguments...
More commits to come...
Checking in
new revision: 1.16; previous revision: 1.15
Checking in
new revision: 1.16; previous revision: 1.15
Comment 8 Martin Schovanek 2004-07-15 16:32:06 UTC