Below you can find some examples of how you will be able to use Jibe when implemented in your organization. These examples include the actual build files the developers will be seeing when using the system (the ones they can customize at predefined places to do additional tasks) and the administrative files, the buildmeister will use to keep the system running, provide the build with a so-called build-sequence, etc. All the examples are given to show the ease of use of Jibe.
Below you can find an example of a simple directory structure representing a codebase using Jibe. Besides the directories, some properties are given, which are usable in the Ant build files.
ROOT
build ${build}
lib ${general.lib} (general library repository)
ant --- (containing Ant distribution)
mod-helloworld ${basedir}
build.xml (the actual module build file)
src ${compile.source} (root of java source dir)
foobar
Clss.java (one of the source files)
test ${test.source} (root of java test source dir)
TestClss.java (JUnit testcase)
etc (Etc. directory for add. storage)
doc (Additional dir for documentation)
The module build file specifies what is build, what the title of the module will be, what dependencies the module will have and what additional things besides Java classes should be in the jarfile. The sequence is:
compile target, doing the compilation (not visible
for developer)copy-extra target (see example below), giving the
developer the opportunity to copy extra files (like configuration files
or DTDs)jar target, which jars the complete directory in which
the classes were compiledtest or distribute):
do-extra target, giving the developer the opportunity to do
extra copying or things a like, between the jar process and the automated
test processtest or distribute):
test target, doing the automated test, using all Java
files contained by the test directorytest or distribute):
distribute, which just copies the tested jar to the
general library directory
<project name="somemodule" default="jar" basedir=".">
<property name="mf.impl.title" value="SomeModule, the Implementation"/>
<property name="mf.spec.title" value="SomeModule"/>
<property name="mf.spec.version" value="1.0"/>
<property name="mf.sealed" value="false"/>
<property name="project.dependencies" value="log4j.jar"/>
<target name="copy-extra">
<copy todir="${compile.destination}"
file="${basedir}/etc/somemodule.dtd"/>
</target>
<target name="do-extra"/>
&include;
&module-include;
</project>
The component build file specified what components are included in the result of the build, what client classes should be generated and what additional jars must be located at the beans classpath. Server specific testing is completely transparent to the developer (although a default application server needs to be specified). The developer just writes his/her test code and in the automated build, the test are run, on all application servers.
<project name="samplecomponent" default="jar" basedir="."> <property name="mf.impl.title" value="SampleComponent"/> <property name="mf.spec.title" value="SampleComponent"/> <property name="mf.spec.version" value="1.4"/> <property name="mf.sealed" value="true"/> <!-- the compile dependencies --> <property name="project.dependencies" value="j2ee.jar;shdao.jar"/> <!-- the bean-classpath (usually everything excluding j2ee.jar --> <property name="project.bean-classpath" value="shdao.jar"/> <!-- Files not put into the client jar (e.g. bean classes) --> <patternset id="client-jar-filter"> <exclude name="**/*Bean.*"/> <exclude name="**/*PK.*"/> <exclude name="**/*Constants.*"/> </patternset> <!-- resembles the bean-classpath, but this time, an exclusion filter --> <patternset id="ear-dependency-filter"> <exclude name="j2ee.jar"/> </patternset> <!-- copy-extra target --> <target name="copy-extra"> </target> <!-- do-extra target --> <target name="do-extra"/> &include; &component-include; </project>
The buildmeister organizes the automated build procedure, keeps a close eye on what happens in the build procedure, checks dependencies and more. Using Jibe the buildmeister has a very easy task. Jibe takes away lots of his responsibilities. The overhead of building, testing and releasing your software becomes very minimal.
With CVS and Jibe in place, you can use so called label incrementers, to organize
your versioning. Not the versioning of your sources, the versioning of your binaries
and distributables. This is done using the manifest templates. If you have a look
at the developer examples you will see that some extra
meta information about a module may be specified by the developer. This
meta-information will be merged into the jar's manifest, together with some
general version information. At SmartHaven for instance, we generate the
following manifests in our jar files, in a completely automatic way, derived
from the labelincrementers. the MAIN-b376 is the version number of
our main codeline.
Manifest-Version: 1.0 Specification-Title: SmartHaven Conversion Application Specification-Vendor: SmartHaven B.V. Created-By: Jibe - 25 February 2002 10:51 AM Implementation-Vendor: SmartHaven B.V. Specification-Version: 1.1 Implementation-Version: MAIN-b376 - 25 February 2002 10:51 AM Implementation-Title: SmartHaven Conversion Application
With Jibe in place the creation of manifests for in your bean jar is a piece of cake. The following manifest was generated using Jibe. The Class-Path entry is used by application servers to figure out what classes this specific bean needs. This is extremely helful if you're assembling your collection of beans into an .ear file.
Manifest-Version: 1.0 Specification-Title: Language Identifier Specification-Vendor: SmartHaven B.V. Created-By: Ant Automated Build - 21 December 2001 05:31 PM Implementation-Vendor: SmartHaven B.V. Specification-Version: 1.5 Class-Path: ext/nlp.jar ext/shutil.jar Implementation-Version: MAIN-b103 - 21 December 2001 05:31 PM Implementation-Title: Language Identifier
In the codebase, there's one central module, called build
that contains the libraries and administrative files used by Jibe to (e.g.)
figure out what the build sequence will be for the new build. In the
etc directory for instance, there's a file called
module-list.txt that contains the following (in our case):
shdata shutil shui adminframe blobmanager concept classifierlogic shdao
This file specifies in what order to build the modules. This way you can manage the different dependencies. Files like this also exist for the component layer and the application layer.
Using a simple procedure of adding a module to the CVS, adding it to the administrative file(s) in the central build module, enables you to quickly add a module.