Mailing-List: contact user-help@ant.apache.org; run by ezmlm
From: "W. Sean Hennessy" <shennessy@goldenhourdata.com>
To: "Ant Users List" <user@ant.apache.org>, <scottstirling@rcn.com>
Subject: RE: ClearCase UCM and Ant Best Practices
Date: Fri, 30 May 2003 09:51:49 -0700
Message-ID: <FCEPJMMNNIMNJCDGGLGCIEBKCCAA.shennessy@goldenhourdata.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <KIEHIBIOBAELJAHIPNHDAEEIDDAA.scottstirling@rcn.com>
Importance: Normal

Here is one view ( no pun on StarBase intended :)

Most UML tools provide some control mechanism to specify
the source folders so some tailoring should be possible.
Rational provides a mind numbing number of tailoring mechanisms and plug in
capability.
Highly recommend the Rational con$ulting $ervice$ to provide$ a$$i$tance
with mentoring your migration and automated build scripting.
Be explicit about your build environment requirements up front.

I. Rational
The UML Model (mdl) would live under a designated folder eg: ${doc.dir}.
The UML model generated source would target a source folder eg: ${src.dir}.
SCM Best practices recommend Naming conventions be established early on such
that package naming would facilitate the component project management.

A Component (CSCI) itself can be made up of other CSCI which
would drive a hierarchical Software Development Folder (SDF).
(numbered folder naming convention facilitates ordered directory display)

II. Ant
Ant build scripts could be setup to match the SDF directory layout below.
Proj-CSCIName/4.bin/build.xml
would have dependent targets which would call each sub component's
   ${Proj-CSCIName}/${3.1.SubComp-CSCIName-bin.dir}/build.xml
   ${Proj-CSCIName}/${3.2.SubComp-CSCIName-bin.dir}/build.xml
     would have dependent targets which would call
         ${3.1.SubComp-CSCIName-bin.dir}/build.xml
         ${3.2.SubComp-CSCIName-bin.dir}/build.xml

III. Corresponding Software Development Folder directory layout

/Proj-CSCIName
 +- 1.doc
 +- 2.java.src
 +- 3.1.SubComp-CSCIName
    +- 1.doc
    +- 2.java.src
       +- com
          +- cmpyname
             +- SubComp-CSCIPkgName
    +- 3.SubComp-CSCIName
    +- 4.bin
    +- 5.lib
    +- 6.test
       +- com
          +- cmpyname
             +- SubComp-CSCIPkgName
    +- 7.sql
    +- 8.web
 +- 3.2.SubComp-CSCIName
    +- 1.doc
    +- 2.cc.src
    +- 3.1.SubComp-CSCIName
    +- 3.2.SubComp-CSCIName
    +- 4.bin
    +- 5.lib
    +- 6.test
    +- 7.sql
    +- 8.web
 +- 4.bin
 +- 5.lib
 +- 6.test
 +- 7.sql
 +- 8.web

Good Luck.


-----Original Message-----
From: Scott Stirling [mailto:scottstirling@rcn.com]
Sent: Friday, May 30, 2003 5:40 AM
To: Ant Users List
Subject: ClearCase UCM and Ant Best Practices


Hi,

I'm working on a StarTeam to ClearCase UCM conversion.  It's very
interesting how UCM comes with certain restrictions that don't exist with
other SCM systems such as Perforce, CVS and StarTeam.  If you don't know,
ClearCase UCM (Unified Change Management) puts a layer of abstraction on top
of base ClearCase, such that the low level, day-to-day SCM interaction and
organization you are probably used to from other SCM systems (including base
ClearCase) is encapsulated/buried under Projects, Components, and
Activities.

A Project can be made of an arbitrary set of Components.  A Component is a
collection of files and folders that is self-contained within a top-level
directory, and is a versionable, buildable unit.  Components cannot be
nested and neither can projects.  Sharing files between Components can only
be done by putting the files in a Component -- there's no such thing as a
loose directory or a file that's not part of one Component or another in
ClearCase UCM.

The bottom line is that in UCM you must re-think your source control in
terms of Components (isolated top-level directories and their contents) and
their dependencies.  You aren't just dealing with a hierarchical file system
structure.  Why UCM, you ask?  Because management wants it for
accountability, reporting and project management (via ClearQuest, the
defect/change request tool), and QA wants it for ClearQuest (which
integrates beautifully (in theory) with UCM out of the box).

The product and management requirements are such that we have an enterprise
Java and Oracle product broken up into 4 or 5 different UCM projects, with
5-10 Components in each.  We're trying to support versioning and
upgradability at a pretty low level -- i.e., the level of subsets of Java
packages and various tid-bits inside a single war file.

Anyway, UCM, Ant and Java seem to be a rare combo in comparison to other
SCMs.  I'm looking for best practices for organizing a large Java project in
UCM and building its various Components and Projects with Ant.  I'd greatly
appreciate any pointers.  I've searched Google and the Rational Dev site
with scant results.

Regards,
Scott Stirling
Framingham, MA


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org