Geir Magnusson Jr. wrote:
> 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.
>
But of course we are interested ;-)
(In the background... 'Let's get ready to RUMBLE!') ;-)
> 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...).
>
Correct. CJAN would eventually require serious heavy lifting. But that
is what baby steps are all about...
> 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
You do have to start somewhere, right? So you are starting at:
A JDK
An internet connection
Your tiny jar file
Not bas for a start. I just add Ant to that list.
>
> * small size : given the heart-rending stories of
> Craig and his analog modem travails...
Agreed. Heavy is not on the 'A' list.
>
> * 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.
Like the classloader idea, but then you get questions like 'where is
that class magically coming from?
>
> * ANT support : once the basic API is in place, Ant
> tasks are simply wrappers on top of the core
> functionality
But of course ;-)
>
> * 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
>
Are you saying that the local repository would contain both jars and
info (properties files)? So you would need to sync them, correct? Just
thinking off the top of my head, as I do not currently cache the repo
info on the client side, so the http request is inevitable every time.
> * 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.
>
Cool. I've showed you mine. Now lets see yours ;-)
> 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...)
Yes. Put 'er up somewhere, or just drop it into the sandbox.
>
> * 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
>
I started with Ant as that is the basis of my needs for CJAN, build time
jar support. So, XML is free if you depend on Ant for the basis of the
work (using an Ant task). But, as it grows, if you had some dynamic
pages on the server, you could serve anything, down to one-line text
files, if necessary.
> * 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 :)
More than I aspire to in the first cut. CJAN currently supports
multiple versions of multiple components, and allows alternate
protocols, such as FTP for the download of the jar itself. It does not
currently supoort the dependency notion, pointers, news or any other
fancy stuff. I am not going to add that until it is needed ;-)
The DTD is in CVS, and we can obviously build it up, but then the
repository also has to be maintained, so I think that there is a balance
to be struck here (too much info vs. too little).
>
> * 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.
>
Cool. Right now the commons-cjan.jar is a whopping 8KB. Ant hides a
lot of the fat, such as XML support ;-) Most java developers have
started to use Ant. It has become the defacto standard for a java build
tool. I want to leverage that. I see the other usecases coming a
little further down the line.
>
> 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.
My intention would be to point to anything, Jakarta or not. It would
just be a matter of which jars jakarta would host, as I assume everyone
else would host their own.
>
> 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.
>
Cool. Where? ;-)
> 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 would like to see it. I am sure others would like to as well.
> 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.
>
Let's see it and get the discussion going,
Scott Sanders
