Scott Sanders wrote:
> Geir Magnusson Jr. wrote:
>
> > * 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.
The issue I have with ant, and I realize that this is orthogonal to the
wishes of the ant community, is that for whatever reason, the ant-ers
want ant to be an 'installed application', or so I'm told. That's fine
for a dedicated ant-using developer - it's a great app and I use it that
way - but that's inappropriate for something that should be able to be
used as an installer and build bootstrapper as well.
Coming from a non-Java background, one of the things that fills me with
rapturous joy about Java is the portable bytecode idea - it's so easy to
just use stuff... I love that... I don't want to *install* anything if
I don't have to, and expecially don't want to depend upon environment
variables if I don't have to. Yech.
> [SNIP]
> >
> > * 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?
I'm not sure about that, because if you are using this, and we make it
trustworthy, you know what's going to happen. I think the CLASSPATH
idea leads to more wonderment and mystery over where classes come from.
I avoid the environmental CLASSPATH at all costs if I can, and if not,
am very careful.
I am not sure if this will work out this way, but I think there is quite
a bit of potential for usefulness.
> [SNIP]
> >
> > * 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.
It's up to you. I didn't want to demand anything of the user. In the
current toy experiments, the 'local repository' is something informal -
the local directory if you are lazy, or a specific one if you want to
keep things neat [and I hope to make a no-write-to-disk option a
possiblity]- and is just the set of jars. The information about package
and version is kept in each jar, and the whole 'JJAR Dependency Info' is
kept on the server, so you need a http request to suck down the
repository info each time.
It would be good to be able cache the repository.index (the info) on the
client side, in the case where you are a developer and have a central
repository for your development - that way in the event of network
trouble of any sort, it could simply use the local cached copy.
>
> > * 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 ;-)
Like I said, I think it would be great if there is real interest in
going this way. I am not interested in a system that requires ant -
there should be first-rate ant support of course because its such a
great and popular tool around here - and still not sure about the XML
piece, although Peter has given me hope if there are <20K impl's out
there.
There is a little more refactoring I want to do first to help make the
core API clearer... but if there is hope, to the sandbox it will go.
> >
> > * 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 ;-)
Well, the point there is that I have a little program that can show
files, and the idea of a central place for files :)
The alternate protocol stuff is easy, as I am taking the cheap way out
and relying on URLConnection and it's decendants. However, I assume
right now that the repository server is accessable via http, and
therefore the jars are as well.
I see the need for ftp when there may be mirrors - and central services
can just redirect to a different URL. But ftp can be hard in the
corporate environment when IT believes they know better. They shut down
ftp and leave http wide open. It defies understanding :)
>
> 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).
You aren't required to read the news - just figure if you notice that
there is a new version of something, seeing release notes easily might
be convenient. Once of those things for which time will indicate a
need. It also ties in some of the ideas of the Catalog part of commons
- having a mecahnical lookup for catalog info would be kinda cool. (Not
just a web page...)
> >
> > * 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.
I think "most java devlopers have started to use ant" is a very long
stretch, IMHO. I have 4 regular consulting clients. *None* used ant
until I showed it to them, and not all do yet. And leveraging ant was
the easy part : once the core api was there, the ant task took about 45
minutes. Of course, it's a really dumb ant task, simply taking a
package name and version, and dropping result and dependencies into a
specified directory. It has the option to not get anything it already
sees, but that's the extent of it. (My next trick is to figure out how
to handle a nested <classpath> construct.)
> >
> > 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.
Yep.
> >
> > 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? ;-)
>
I'm not trying to be cagey here, just didn't feel like bombing sandbox
with something until it was clear this alternative philosophy is
welcome. I am deliberatly rejecting ant and xml as underpinnings for
this system (maybe reconsidering xml if it's small), and these are
popular here in Jakarta land.
> > 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
yep
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..."
