Sure man. Discuss all you like. Anyhow. I just finished the package
directory part. Now I'm working on the actual jar descriptor. That
will give me end-to-end grabbing of a jar. I'll then just have the
front end part to work on. I'll then do some doco and fill in some
places where the javadoc is rough and publish my first go at it.
Costin Manolache wrote:
On Sat, 8 Mar 2003, Andrew C. Oliver wrote:
The best way to go nowhere is to become mired in details. I'll get the
basic thing working and then we can discuss the details via patches.
I'm 70% through the packagedirectory part.
Andy - you seem to have a pretty strong opinion that writing code (and
patches ) is the ultimate goal and solution.
I'm not going to argue with you - anyone can believe whatever he wants -
but IMHO the benefit of Apache is that some of the people are pretty smart
and may have ideas or experience that could lead to better software.
Starting to write software without a good understanding of the domain
is one of the worse things that may happen. The purpose of mail
and discussion in english ( instead of patches ) is to learn -
which is sometimes better _before_ writing code.
I don't think this is a problem where code ( discussion via patches )
can work - we don't even know what we want the software to do.
So far all mails are on the same theme: "I have a hunch we should do this
and that" - or "I'm writing some code to do this and that". IMHO
what we need is:
- what do we want ( before knowing how to do it )
- what are other repositories doing and why we can't do the same
- if we decide to do things differently - what will we gain ?
We know how Maven organizes the code, we know APT/RPM repos,
CPAN, Apache's own distribution layout ( that lacks .jars ),
we know about sourceforge layout. We know what most projects
use, how Sun jars are named.
The goal of this list is not to create the software - but
to find a layout that would work for ASF projects to distribute
I'm really curious how the code you write will answer those questions
and resolve the real problem - which IMO is lack of information
and lack of agreement - both resolvable with communication, not
Again - sorry :-)
You're right - having some descriptors ( in some locations that can
be guessed somehow - follow some patterns, etc ) is absolutely needed.
And a download tool should deal with the various kinds of descriptors
used by different sites and repositories. ( for mirror lists, redirects,
dependencies, etc ).
But the point of the list is to figure out a consistent way to organize
our jars - we already have "every project follow his own layout".
It seems the mirroring proposal worked - and many projects were able to
follow that layout.
Right now I am thinking the best idea would be to just add a jars/ in
the current layout. Not sure who "owns" the mirroring document and
how open it is to changes.