1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
|
<document>
<head>
<name url="building.html">Building The Projects</name>
<doc-version>$Date: 2003/06/10 18:06:38 $</doc-version>
<author>Matt Albrecht</author>
</head>
<body>
<P>
The <a href="http://jakarta.apache.org/ant/index.html">Ant Project</a>
keeps the projects working smoothly together. The build process uses
the recommended-but-hated form of XML entities for including shared
Ant XML fragments in each project. Future versions of Ant may include
the <include> and <import> tags, which would simplify the current
system. However, the build process works just fine without it, for the moment.
</P>
<P>
You can download the source from the <a href="downloads.html">downloads</a>
page.
</P>
<P>
If you are interested in building the projects from scratch, here's the
recommended process:
<OL>
<LI>
Ensure you have JDK 1.2, JDK 1.3, and JDK 1.4 installed on your
system. The complete build process will require all of these to be
installed, but it is not needed for most circumstances. Also, to
completely test the projects you will need to be connected to the internet
while running the build, but again this is not needed for most
circumstances, but is required for actual releases.
</LI>
<LI>
Download the latest CVS tree (see the
<a href="https://sourceforge.net/cvs/?group_id=22594">Sourceforge project
CVS page</a> for details on how to do this).
The module to download is 'projects'. The CVS tree will contain
all the necessary non-JDK files needed for building.
</LI>
<LI>
Currently, only Windows, Unix-like variants, and
<a href="http://www.cygwin.org">Cygwin</a> are supported build platforms.
Windows users should use 'make.bat' from the base directory, while
Cygwin and Unix-like users should use 'make.sh'. The remainder of
this guide is oriented towards Bash shell users on Unix platforms,
but other platforms and shells should be very similar. Alternatively,
you can use the 'makeall.sh' script to build the entire project, which
does about the following:
</LI>
<LI>
<PRE>
$ cd <i>'projects' home</i>
$ export JAVA_HOME=<i>JDK 1.4 home</i>
$ ./make.sh clean
$ export JAVA_HOME=<i>JDK 1.2 home</i>
$ ./make.sh main
$ export JAVA_HOME=<i>JDK 1.3 home</i>
$ ./make.sh main
$ export JAVA_HOME=<i>JDK 1.4 home</i>
$ ./make.sh deploy
</PRE>
</LI>
<LI>
By this time, you have just spent about 30 minutes to 5 hours building and
testing all the sub-projects on all supported JDK versions. The final
deployment output is sitting in the '_projects' sub-project 'deploy'
directory. Each sub-project will have its individual deployment file set
in its own 'deploy' directory.
</LI>
</OL>
</P>
<section>Why Does CVS Contain Everything?</section>
<P>
I have put everything in CVS that the build depends upon, except for the OS
and JDKs. I, the build manager for GroboUtils had (and still has)
responsiblities involving both source control repository (SCR) maintenance and
build maintenance. If the developers have fewer dependencies that they have
to locally manage, then they have fewer risks to cause the build to fail
when everything works fine for them. Not only that, but by putting all
dependencies in the SCR, it reduces the problem of the build manager dealing
with "source rot" while trying to rediscover the exact library files that
the source works with.
</P>
<P>
I've known some people who <i>do</i> go so far as to
archive the OS and JDKs in the SCR, and rebuild from scratch the build machine
every time. Now it's true that this allows the project to be able to
completely restore a build based on just the SCR, and the build managers are
less dependent on the IT group to correctly rebuild the machine in the case
of critical failures, I feel that you still need
the hardware the build was compiled on. If you don't have an OS for your
hardware, then you're just as screwed as if you don't have the same hardware.
</P>
<P>
But this project, like most Java and open-source projects, are in a different
boat. We <i>want</i> to be compiled on lots of hardware, OSs, and JDKs.
</P>
<P>
So what is this rambling about? It means that the SCR respository has been
optimized to reduce third-party dependencies for the user, while opening the
platforms available for compatibility testing.
</P>
</body>
</document>
|
