>> 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.
>
>> [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.
>
OK.
>
>> [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 ;-)
>
>
>>> * 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.
> 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!
>>>
>>> * 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.
>
Agreed, the alternate protocol stuff is easy, and I too am assuming http
for the repository index access.
> 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 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.)
>
>
Again. Everyone has their point of view. Command line is not a
problem, IMHO. I just saw Ant as an easy entry ;-)
>>> 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.
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.
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 ;-)
Scott
