Scott Sanders wrote:
>
> geir:
>
> > scott:
> >> 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.
> >
>
> I don't understand about the env variables. I just installed Ant and
> then I type 'ant'. That's it. I didn't set anything else up. But I do
> see your point from the end-user (non-developer) perspective.
Really? I thought that would mean that it was added to the PATH, and
ANT_HOME was setup.
> [SNIP]
>
> >
> >> [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.
>
> But if you have network trouble, having the cached copy doesn't really
> help if you need to download a jar, I suppose ;-)
*If* you need to download a jar - I think that an important use-case is
the working developer, and having a local repository means that all jars
are available in a way that lets that developer use them in whatever way
they choose, w/o worrying about dorking with the classpath.
Sure - the conventional approach many people take is to put everything
under the sun (no pun intended) into the classpath, and run that way.
Kinda the 'Hail Mary' of late binding...
I don't like working this way - I prefer the determinism of specifically
specifying a particular package (and that means you can work with
different versions of things at the same time if you want...).
By adding the classloader functionality, or private classpath
functionality for a JVM instance, then each app/project is indep and
partitioned.
> >
> >
> >>> * 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.
> >
>
> That's fine. I started with Ant because that is the way I saw it
> working. I have no issues wrt making Ant just sit on top of an API.
I am not criticizing the support of Ant - I do think it's critical for
success- I just want to step back a little from it.
> > 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.
> >
> >
>
> Collaboration, man. Come on. Let's get it in and work together on this.
> I am not against any of the ideas that you have put forth, although I
> am pro-xml ;-) If I can't see what you've done, and I agree with what
> you are doing, I have two choices: 1) wait for you to show the code, and
> 2) write more of it myself. I hate duplication. Let's get the code
> together!
I am very pro XML myself. I think think that since the API takes care
of all details though, putting everything behind a Repository class, it
could be implemented via gerbils...
> [SNIP]
>
> > 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...)
> >
> >
>
> Agreed. Let time tell if these things are needed. My only concern was
> the maintenance of the index based upon the amount of information and
> the rate of change of that information. The repo index is the most
> crucial part of this, as it has to stay fresh to keep all of the users
> happy. If that index is large, the maintenance will go down ;-(
The master index can be kept in XML, and then transformed into a
properties when pushed onto the repository server for digestion by the
client API if we stay this way, and if we use jjar. You could even get
XSLT involved, to be even more buzzword compliant.
> [SNIP]
>
> >>> 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 alternative philosophy is certainly welcome. I will eventually try
> and convince to you go the xml way, and I don't see you rejecting Ant,
> merely putting it in its place, as a layer on top of the core API.
I am not worried about the XML, if it's small and we glop it into the
jjan.jar. I would prefer XML as long as it kept the memory and
performance footprint small. I don't know what small means, but I think
this has usage beyond jakarta developers with big memory quick-boxen.
Would be cool to boot an app via a wireless handheld..
> Again, I started with Ant to get the ball rolling. I see a need for a
> CJAN type system *now*, not next year, so I went with what I knew, Ant
> and XML.
My approach isn't a criticism. Just something different - I was
thinking about this subject for a while, before commons, and some of the
things we debated when starting commons fed it. I have no belief that
jjar is the final solution either, but I see in myself and my clients
lots of wasted time screwing with the classpath, downloading and
building jars, etc. My dream, described fuzzily, is a lightweight tool
that can do things like boostrap a project install, incorporate into a
developers build process to manage versioned packages and their
inclusion, a runtime classloader that also suppots the same thing, etc -
and a pile of trusted jars accessable to all as a resource... It's a
common dream I suppose.
> If the xml size is a concern, we could get you to write a JavaCC parser
> for a specific DTD, no? That parser would be very small ;-)
Actually, that's not a bad idea :) But I am fundamentally lazy, and if
the XML parser is small enought, problem solved...
I am going to do a few things more to it, and then I can drop it into
the sandbox so people can play with it. It's pretty ugly right now :)
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..."
