What should be in the MetaData

[Nick Chalko <ni...@chalko.com>]

I'll start the discussion with what John Toohey said.

In both html and xml format

    * list of available versions,
    * their MD5's,
    * dependencies,
    * perhpas a code for licenses


-- 
Nick Chalko                                         Show me the code.
                          Centipede
  Ant + autodownloadable build plugins + needed jars autodownload.
              http://krysalis.org/centipede
---------------------------------------------------------------------

Re: What should be in the MetaData

[Nick Chalko <ni...@chalko.com>]

This seems like  a whole lot of HTML for what is implicit in the URI and 
the manifest.

Re: What should be in the MetaData

[Costin Manolache <co...@apache.org>]

On Thu, 6 Mar 2003, Andrew C. Oliver wrote:

> Nick Chalko wrote:
> 
> > This seems like  a whole lot of XML for what is implicit in the URI 
> > and the manifest.
> >
> >
> You mean the very specific to one server and one layout?  Your goals may 
> differ.  Thats fine.

I think the "repository" list was created to define the layout and 
metadata for the asf server. And by side effect - it may affect the
release process and naming in many apache projects.

IMHO a lot of XML and complexity is a bad idea for the repository.
But I agree that some complexity to support multiple repositories is
needed in a download tool. Different goals, you're right.

<rant>
I just heard "read fewer specifications" the other day. I think people 
should do the reverse - "write fewer specifications", and maybe read
the existing ones ( especially the ones that are actually relevant
and proved to be good enough and work ). A DTD is a specification.

For example: there are few widely used formats to describe version, 
dependencies, etc. Manifest is one, Apt is another. I know CPAN has 
a descriptor for mirrors ( supported by few tools ), and I'm sure
there are other ones. Maybe reading them and discussing with people
who might have used them would be more valuable than just inventing
another XML format.
</rant>

Costin

Re: What should be in the MetaData

["Andrew C. Oliver" <ac...@apache.org>]

Nick Chalko wrote:

> This seems like  a whole lot of XML for what is implicit in the URI 
> and the manifest.
>
>
You mean the very specific to one server and one layout?  Your goals may 
differ.  Thats fine.

-Andy

Re: What should be in the MetaData

[Nick Chalko <ni...@chalko.com>]

This seems like  a whole lot of XML for what is implicit in the URI and 
the manifest.

Re: What should be in the MetaData

[Costin Manolache <co...@apache.org>]

On Thu, 6 Mar 2003, Andrew C. Oliver wrote:

> I don't really intend to have an english discussion on this, I would 
> rather discuss in Java.  I'm approximately 3-5 days away from having 
> this done...

I have a feeling that if people would first discuss things in english 
we wouldn't have the current mess of XML vocabularies ( and not only )... 

So - we'll have yet another 4-5 "original" XML DTDs, with some code that 
support them. Like that's what we're missing. 

Sometimes it's good to first do and discuss later. But usually it's 
good to first think - and that may involve discussion with other people 
like those who may be affected - and do later.



Costin
 

Re: What should be in the MetaData

["Andrew C. Oliver" <ac...@apache.org>]

:-(  oh man... did ya have to?

I don't really intend to have an english discussion on this, I would 
rather discuss in Java.  I'm approximately 3-5 days away from having 
this done...

The code goes and grabs a version of a jar based on 4 XML descriptors 
(don't take these as gospel, they are changing as I go).

repository.xml - i.e. repository-name= "iBiblio Maven repository" -  
tells who the mirrors are, masters are and where directory.xml files can 
be found (iBiblio for instance might note the FTP and HTTP versions)
directory.xml -  Tells what packages are there (i.e. 
packagename="jakarta-poi") and where their packagedirectory xml file is.
packagedir.xml (i.e. jakarta-poi-dir.xml) = what versions are on this 
server and where the jar descriptor is
jardescriptor.xml = similar to module.xml + url to the actual jar.

Eventually I'll have an alternative to the jardescriptor.xml which just 
lets you put it in the jar.  I'll also allow you to have 
MYBigFatDistro.zip with the jardescriptor.xml inside it.

Installation will be handled via:
1. Copy the file and hand edit
2. Commandline tool
3. Wizard (if Nicola Ken is in the mood)

where is this?  I have code to parse repository.xml and get 
directory.xml.  I have code to parse directory.xml and get the 
packagedir.xml (jakarta-poi-dir) in this case. 

I'm working on code which will parse packagedir.xml and grab the actual 
jardescriptor.xml (which will actually be named jakarta-poi-1.6-dev.xml 
or something).

Once that's done I'll code the grab of the actual jar file.

Goals:

1. Directory structure independance
2. Hierachial authority (support mirrors and "official distribution" points)
3. ease of administration.  A admin should just type something like 
"installjar jarname.jar -repository path/to/repository.xml" in the case 
of a cooperative package..  Obviously for those who do not participate, 
they'll have to specify things like the version/etc.
4. Protocol independance
5. Ant/Maven/Centipede integration.  I don't really need cooperation 
from Ant to do this for ant.  I'll need cooperation from the other two 
projects to do it for them.  though they might inherit it from ant...  
(ant and command line will be my focus)
6. support for mutlipe versioning schemes.  I put explicit support for 
the X.x.y-zzz-n scheme and support others textually (though we won't 
support things like "grab latest minor version" or "grab latest release" 
if it isn't in this scheme)
7. depenency resolution.
8. Initial Simplicity

Examples of things I won't be resolving this week:

1. command line installation utilities (for respository administration)
2. local repository management / ant tasks / maven plugins
3. FTP/SSH/etc protocol handlers (http only for now)
4. DTD / namespaces (will be jardir: namespace probably next week or so)
5. Distribution / signed jar code.
6. bells and whistles (license policy / MD5 checks /etc)
7. mirror resolution /etc... 
8. non-linear dependency resolution (meaning Avalon -> Cocoon, etc)
9. descriptor versioning (want to get at least something functional 
before I version things off)
 In other words...this week is just for basics...

Its unlikely that I'll be the one doing #6.  Thats why there are other 
people in the world.

Method

Test-first.  (of course)

I'm not particularly open to english based feedback at this stage.  Once 
I get my initial code which goes and grabs the jar (at least) then 
maybe.  I'd prefer feedback in java/diff -u format. 

If repository@ or ruper or whomever is interested in this code or 
working with me...fine.  It will be most useful if widely adopted, but I 
guess what I'm trying to say is that I don't have time to fight or argue 
about it.

Now you know my secret project.

-Andy

Nick Chalko wrote:

> I'll start the discussion with what John Toohey said.
>
> In both html and xml format
>
>    * list of available versions,
>    * their MD5's,
>    * dependencies,
>    * perhpas a code for licenses
>
>