I have been thinking much about the whole build / jars checkin / 'CJAN'
/ newbie user / experienced developer issues for a little while now,
and have been doing some experimentation. I wanted to wait a bit longer
to polish it a bit, but as Scott's CJAN effort is supposedly ready for
testing, I figured we should take a look at two different approaches at
the same time, if we are interested in doing so.
I have a working example of something I call JJAR - 'Jakarta Java
Archive Repository' ('CJAN' as a name was taken a little while into my
journey... ;) and CJAN requires some heavy lifting to propertly emulate
CPAN...).
The fundamental idea is to have a central directory of information about
'packages' and a portable, lightweight API that can be used to access
and act on that information.
Some of the things I thought important are :
* minimal dependencies - shouldn't rely on any
other jars to get things because one of the
design goals is to be able to be used to help
new users get started, to help avoid much of
the easter-egg hunting for jars that we currently
require
* small size : given the heart-rending stories of
Craig and his analog modem travails...
* embeddable in applications : as just another API,
it allows a developer to embed the API in apps. For
example, one thing I want to do (not done yet )
is to provide a smart classloader that can
fetch what is needed, and therefore let a programmer
do things like specify dependencies in code, which
will be resolved at runtime, all in memory if you
wish.
* ANT support : once the basic API is in place, Ant
tasks are simply wrappers on top of the core
functionality
* command line tool : an important part, as this allows
a wide range of functionality to a large spectrum of
users. Examples :
- to allow a developer to maintain a local repository
and update painlessly from a command line.
- allow easy one-off 'go fetch' functionality to get a
specific package+version when needed for testing et al
- etc
* with a command line tool, can build 'boot' scripts for
projects that do the prefetch to get things started for
new user. No need to get and <ahem> install Ant just to
see what something is about. I love Ant, and encourage
anyone and everyone to use it, but it's not practical to
expect this of every non-Jakarta consumer, especially of
the smaller packages like those in commons.
So I have put together a basic version with a working system with API,
command line tool, Ant support and repository. It doesn't hope for the
power of a CJAN - the whole CPAN-ish upload server, mirror distribution
and multiplexed server stuff can come later if needed.
Keeping in mind that this is just barely working, probably full of
design warts, and screaming for a refactoring, here is what it can do
now :
* there exists a repository configuration and jar set that
is accessed remotely by the API. (will move to a public
machine tomorrow if anyone cares...)
* this repository index is a properties file - processing
this information can't require XML - one design goal is
no external dependencies, and XML support is a heavy one
* all repository info (index and jars) is served via http,
* this repository configuration can handle dependency trees of
varied complexity, multiple versions per package, and other
properties like pointers to CVS, homepages, etc I also
imagine that it could easily pump news out, so you can see
version release notes and such :)
* command line tool can list the repository for all items or
single packages, listing dependencies, etc
* command line tool can fetch packages by request, and supports
dependency trees,
fetching all dependencies connected to the requested package
* command line tool can verify package and version information
* ant task to do fetching, with dependency support
* the whole jar for jjan is 17K w/o debugging info. there ain't
much code needed to do this.
Versioning : Currently, the version scheme is this :
<major>.<minor>-<modifier>
ex
1.0
1.0-dev
3.2-rc3
yes, some people do things like 1.0.1 (er, Velocity... ) but screw em...
:) For the velocity jar, I just did 1.0-1 It really doesn't matter -
the note field in the repository index indicates it's 1.0.1
The version and package information is kept in the manifest, in what is
probably the wrong way :
Implementation-Title: <packagename>
Implementation-Version: <version>
in the main attributes. It's easy to change.
Dependencies : The dependencies are 'hardwired' into the repository
index information - we can easily generate this from information in the
jars themselves when added - I think it's important that we don't
have to haul the jar bits over the wire just to check dependencies -
just stick to the lightweight repository index and make sure it's
right. This way we also can have human control - I am including
non-Jakarta packages like JUnit and JDOM, and there is no reason to
expect that they would conform to either our versioning markings or
correct dependency listing.
Examples : I have two examples
The first is the [required] ant task test - it is able to go and get
from the repository a package and it's dependencies. There are lots of
things to work out there wrt ant, which I expect will come from use.
The second is a small shell script that uses the command line tool to
fetch ant and dependencies into a local repository, and uses it to start
the build script. The idea is that you can make a small installer to
get ant's jars, and then invoke ant to do something more complicated
like get things from CVS, compile, all the wonderful thing ant does...
Anyhow, it's late and I'm beat. If there is positive interest to see
this in detail, I can put it into sandbox, but would want to do a bit of
refactoring and cleanup...
I hope to do some real ant use-testing in a project jason is working on
- a riff on the Gump idea - I think it will be important to see what to
see what ant integration really requires, and garner some use-practice
with it.
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
"still climbing up to the shoulders..."
