Just to make my intentions clear, I am not trying to in any way dictate
or limit what developers do. The purpose here is to try and make our
Commons 'deliverables' as well-packaged and simple to get, build and
play with as possible.
I think your average corporate IT developer just trying to get a job
done is happiest when things are easy to build, install and use. I know
I am when I just want to use something.
More inline...
"Craig R. McClanahan" wrote:
>
> As I warned Geir I would :-),
Ever the gentleman... ( Of course, I recieved it after I sent my
proposal off :)
> I've got a different set of preferences for
> build procedures to suggest. Anyone who has followed along on TOMCAT-DEV
> and GENERAL knows that I'm not a fan of checking JAR files in to the
> repositories. Having a common build/lib directory, as Geir suggests
> below, is better than having ant.jar checked into every single Commons
> package, but IMHO it will lead to conflicts over versions of the shared
> JARs (I need Ant 1.3, someone else needs Ant 1.2, and so on).
I understand what you are saying, but how does making the user go
'fetch' solve anything if that user wants to build two components of the
Commons package, and they require different versions of Ant? Should we
ask the user to go download and install *two* different versions of
Ant? And then force them to diddle with their classpath for each
component build step?
To solve that version issue, why not just add the version to the jar
name and include them in the top-level lib? Then you can simply include
in your Ant build script the jar that you want into the classpath
definition. There is nothing that says that you can't have both
ant-1.2.jar and ant-1.3.jar - in fact, this makes it much clearer. So I
don't see how that would be a problem, unless we are lazy or sloppy.
> In addition, what would we do about dependencies between Commons packages
> themselves? After all, reuse is the whole idea? If Rodney's DBCP is
> accepted, that means we need copies of the other three Commons packages he
> depends on (JOCL, Pool, Collections). OK, that means that when I build
> Pool there's a common of commons-pool.jar in my compile classpath unless I
> go to interesting lengths to explicitly exclude it ...
This is a good thing to talk about. I believe that if you are depending
upon a specific released version of a jar, I think you should include
that, not depend on the CVS du jour, or whatever happens to be lying
around in the users classpath. That sounds like misery. Also, Gump
takes care of the possible-future-maybe problem detection very well.
Of course, we can clearly state the requirements in the documentation,
but still. Craig, you write gorgeous documentation, but I would bet it
still goes unread at first...
But it would be nice, assuming we can avoid circular dependencies, to
put into a build system a 'Gump-like' cross build so you could just use
the jar produced by an earlier build step in the global build, or have a
component build step invoke the build of something its dependant upon,
although I can easily imagine what a tortuous mess this could become.
So, what solution other than jars of specific versions if you depend on
them?
> Instead, an approach to build scripts that I'm currently using in Struts
> (and plan to suggest for Tomcat) makes a single assumption about what
> software the developer has installed on their machine -- you must have
> your favorite version of "$ANT_HOME/bin" on your PATH so that the
> "ant" command found there can be executed. Now, you don't need build.bat
> or build.sh scripts, or all the ugly environment variables that go with
> them -- all you do is say things like:
>
> ant clean
Well, that's the problem I am trying to avoid - making assumptions, or
making a user go hunting, or making a user go hunting for multiple
versions of a given utility/tool.
And those build scripts are pretty straightforward and really don't
require environment variables - specify the known, desired ant-x.y.jar
right in the java invocation of Ant with the buildfile.
I realized how beautiful the world can be when I first played with the
Turbine TDK. If I recall, download the tgz, unpack, type 'build.sh' or
'build.bat', then type 'startup.sh/bat', and aim your browser at
localhost to find that the TDK installed and started a running version
of tomcat with a Turbine application. The only requirement was a J2SE
JDK.
Cool huh?
We make Velocity the same - unpack, cd build and then build.sh with
optional target name. Nothing else is required. Granted, Velocity is a
small tool, but so are these components.
Not the thing the average participating developer will do, but it makes
it so simple for 'consumers'.
There a reason why the software installer business (InstallShield, Wise)
are so big in the windows world, and I have believe that the whole
'configure - make - make install' pattern should be recognized for it's
contribution to the spread of open source software - it's easy. My Aunt
Matilda can build and install a Linux kernel...
And that is something that is part of what Commons addresses...
usability and packaging.
>
> To deal with external dependencies, the current build script for Struts
> (and the one I checked in for the beanutils package) uses the ability of
> recent Ants to load configuration properties from properties files
> (and was inspired by the fact that the Ant build.xml itself uses this
> approach), while silently ignoring any such files that don't exist. In
> the case of beanutils, you will see the following at the top of the
> build.xml file:
>
> <property file="build.properties"/>
> <property file="../build.properties"/>
> <property file="${user.home}/.build.properties"/>
>
> which lets the user define a convenient hierarchical set of places to look
> for customizations. Setting things like xerces.home in your user home
> directory lets you share this declaration across all projects, while
> overriding it with a local file
Yes this is cool. That's fine - I am not suggesting that how a
component wishes to work should be dictated here - just that including
the important 'default bits' to get things build is a good idea...
And this is great for a developer to customize (as you talk about
below). But the default build.properties could reference the global
jars needed to just get the thing built.
> The developer's copy of "build.properties" is *not* checked in to CVS,
> because it is specific to a particular user's environment. However, a
> "build.properties.sample" is checked in to document the configurable
> propeties that this particular package depends on (for beanutils, the
> external dependency is on where you've installed JUnit).
>
> I'm a believer that developers want control over which versions of which
> JAR files they use when building things. Build scripts based on checked
> in JAR files will either disallow us that control, or they will have to
> support the same level of complexity for external dependencies already
> identified. For me, I don't see the value add of having the JAR files
> there.
but that's easy for them to control. Just replace the jar, or replace
the info in the build.properties. This doesn't *mandate* how and what
developers do, but rather makes it easy for the casual user (or not so
casual user) to download, build and take a look at what we are offering.
> I'm also aware that lots of projects do in fact check in JARs (how many
> copies of Ant do you have installed on *your* disk? :-). But I would
> prefer that we don't do that.
I have a few jars, I think, of Ant. (can't have too much Ant :) But I
don't care much - they make the projects they come in trivial to build,
w/o any worries of 'ant 1.2 or ant 1.3?', so I know I can download a
snapshot at any time, anywhere, and just build it.
geir
>
> Craig
>
> On Sat, 31 Mar 2001, Geir Magnusson Jr. wrote:
>
> >
> > I think it would be nice if for the jakarta-commons tree, there is a
> > build.sh/build.bat that will invoke the build of every component, and
> > further, that the jakarta-commons tree include all the necessary jars to
> > build all components completely, except the JDK.
> >
> > This way, our nightly snapshot is self contained - very convenient for
> > first time users as well as those instances where you are on a strange
> > machine and need to quickly download and build (which happens to me
> > often as a consultant...)
> >
> > I know we only have one component in the main CVS, but it might be good
> > to get this started early .
> >
> > So what I want to do is make the following
> >
> > 1) jakarta-commons/build
> >
> > containing a build.sh/bat/xml set that has a default target that builds
> > all the components in one shot. Each component is responsible for
> > wiring their build in there. I am hoping all use ant to build, so it
> > will be darn easy. (I forget if we 'require' that...) We can make it
> > generate a complete javadoc for all the components, a common jar of all
> > the components, etc.
> >
> > 2) jakarta-commons/build/lib
> >
> > contains common jars used for building. For example, I would start with
> > ant.jar, ant-optional.jar, xerces.jar, junit.jar and velocity.jar (for
> > using Anakia for documentation generation.) That way each project
> > doesn't have to include these, and users don't have to go on an
> > easter-egg hunt to find all the parts needed to build.
> >
> > For those wary of centralized control, the following is not the
> > proposition of a requirement :) -> Then each component can have their
> > own build/lib with jars that they need. If commonality can be found,
> > then we can move them to the top-level build/lib. If a component needs
> > a version different than that it the top level, then they can keep their
> > own copy w/in their component.
> >
> > I know there are strong feelings about putting binaries in CVS, but I
> > think this would be a good thing. We do this in Velocity, and I think
> > it works out.
> >
> >
> > I am happy to do the work. I am looking for alternative suggestions or
> > votes of support.
> >
> > geir
> >
> >
> > <aside>
> > I want to note that I think having each component under the same CVS
> > tree will be ungainly as we acquire more components. It will be
> > important to be able to download individual nightly builds of each
> > component, as well as the whole thing...
> > </aside>
> >
> > --
> > Geir Magnusson Jr. [EMAIL PROTECTED]
> > Developing for the web? See http://jakarta.apache.org/velocity/
> >
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
