As an aside, one of the issues we had when coming up with Maven's repository format, is that often artifacts (jars, wars, ears etc), will
get left on the filesystem outside of a repository.
Think rpms for example.
Having a file encode <project>-<artifact>-<version>.type has been very useful for us.
Yes, it's often different from what the project creates and distributes, but I (and others) have been bitten by
commons-logging.jar, struts.jar, junit.jar so many times, that seeing log4j-1.2.5.jar is a godsend.
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
-----Nick Chalko <[EMAIL PROTECTED]> wrote: -----
To: [email protected]
From: Nick Chalko <[EMAIL PROTECTED]>
Date: 03/01/2003 06:54AM
Subject: Re: [proposal] daedalus jar repository
Noel J. Bergman wrote:
>Nick,
>
>As long as you want to start with first principles ...
>
>
>
>>project/[subproject]/version/(jar|zip|gz|docs|liscenses)
>>is very good.
>>
>>
>
>How much should be encoded in a URI, and how much in data associated with
>the URI? You seem to be trying to encode all of the data into the URI
>naming space. Why not have a single URI for the target, and then trigger
>behavior based upon the content? That would seem more extensible and less
>fragile.
>
>
>This would also unify with Costin's thoughts regarding tool-neutral
>standards for the repository and project descriptors. The URI tells the
>repository what you want, and it responds with the information known about
>it, such as the locations of its parts, dependency information, build
>instructions, etc. The URI could encode optional filter information about
>what we want in the response. Depending upon whether the resource were
>dynamic or static, the filter might or might not be honored.
>
>Seems to me that some of the prior art associated with JNLP should be
>brought into the picture, as well as everything that Maven has learned about
>repositories. And REST in terms of the web interaction.
>
>
>Also, shouldn't URIs also support movement of the resource, e.g., when a
>sub-project moves from underneath a project? For that matter, is the
>project hierarchy really useful in the URI, or just a unique name?
>
>
>Thoughts?
>
>
Your approach seems very powerfull, I like it.
I was trying for a "Valid" repositry being just a filesystem. I think
we can add the rest later as optionl support elements.
A filesystem only approach lets other people build "compatible"
repositories without tools or keeping a catalog.xml or whatever uptodate.
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Nick Chalko Show me the code.
Centipede
Ant + autodownloadable build plugins + needed jars autodownload.
http://krysalis.org/centipede
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
To: [email protected]
From: Nick Chalko <[EMAIL PROTECTED]>
Date: 03/01/2003 06:54AM
Subject: Re: [proposal] daedalus jar repository
Noel J. Bergman wrote:
>Nick,
>
>As long as you want to start with first principles ...
>
>
>
>>project/[subproject]/version/(jar|zip|gz|docs|liscenses)
>>is very good.
>>
>>
>
>How much should be encoded in a URI, and how much in data associated with
>the URI? You seem to be trying to encode all of the data into the URI
>naming space. Why not have a single URI for the target, and then trigger
>behavior based upon the content? That would seem more extensible and less
>fragile.
>
>
>This would also unify with Costin's thoughts regarding tool-neutral
>standards for the repository and project descriptors. The URI tells the
>repository what you want, and it responds with the information known about
>it, such as the locations of its parts, dependency information, build
>instructions, etc. The URI could encode optional filter information about
>what we want in the response. Depending upon whether the resource were
>dynamic or static, the filter might or might not be honored.
>
>Seems to me that some of the prior art associated with JNLP should be
>brought into the picture, as well as everything that Maven has learned about
>repositories. And REST in terms of the web interaction.
>
>
>Also, shouldn't URIs also support movement of the resource, e.g., when a
>sub-project moves from underneath a project? For that matter, is the
>project hierarchy really useful in the URI, or just a unique name?
>
>
>Thoughts?
>
>
Your approach seems very powerfull, I like it.
I was trying for a "Valid" repositry being just a filesystem. I think
we can add the rest later as optionl support elements.
A filesystem only approach lets other people build "compatible"
repositories without tools or keeping a catalog.xml or whatever uptodate.
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Nick Chalko Show me the code.
Centipede
Ant + autodownloadable build plugins + needed jars autodownload.
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
