Here is a fresh stab at what we are talking about.
I see the URL sytax having these parts
Sample
http://repo.apache.org/jakarta/commons-beanutils/jars/commons-beantutils-1.4.jar
* root
o http://repo.apache.org/jakarta
* Distribution Unit Name
o commons-beanutils
* Type
> Some artifacts don't like having the full version number.
> dll for example. I think the DLL name needs to be stable and thus
> would not have the full version info.
> For the dll example we can mandate that it has to be put in a versioned
> zip/tar.gzip
If we continue to think 100% genericall
Adam R. B. Jack wrote:
I feel we could/should unashamedly complete our thoughts on Java, then go
and recruit some per-language specialists to chime in on their flavour.
Maybe we'll have one repository 'class' with per language sub-classes. Let's
mature what we can agree upon before we specialize &
I would prefer to NOT have the TLP represented in the URI if possible.
Projects can be promoted. The package name for James was always
org.apache.james, and so did not change when the project was promoted.
Point being that I'm not sure if the URI should reflect the ASF
organization. A project na
Let's try to work this one through to completion:
http:/[-].ext
I think this is close to what some (most?) here are accustomed to, and are
comfortable with.
We need to enumerate [in 'English', I have to assume,
jar/src/etc...], and later agree on and , but I believe this is
a fair stake i
Adam R. B. Jack wrote:
Let's try to work this one through to completion:
http:/[-].ext
Should be
http:/-.ext
Version must be somewere in the path.
smime.p7s
Description: S/MIME Cryptographic Signature
Adam R. B. Jack wrote:
Let's try to work this one through to completion:
http:/[-].ext
So what should group be
Given Noel's concern about Top Level Project and projects moving. I
think that leaves us with the java package name. Allowing non java
groups to use
org.apache.tlp and then whatev
Metadata:
Since we need/want programmable I doubt we'll get disagreement on XML.
Static or dynamic is more interesting.
Questions:
1) Do we need server side metadata?
I suspect yes, for referencing the 'version' of the repository spec being
followed, if nothing else. That said, I could imaging
> http:/-.ext
> Version must be somewere in the path.
Why?
I think Adam has a pretty good starting point. And although a .ext is going
to be common, we should drop it as a requirement:
http:/[-][<.ext>]
--- Noel
Noel J. Bergman wrote:
http:/-.ext
Version must be somewere in the path.
Why?
I think Adam has a pretty good starting point. And although a .ext is going
to be common, we should drop it as a requirement:
http:/[-][<.ext>]
--- Noel
I guess unversioned as an implicit LATEST or Ukn
Adam R. B. Jack wrote:
Metadata:
Since we need/want programmable I doubt we'll get disagreement on XML.
Static or dynamic is more interesting.
I think we should have meta data, but I would like a repo to still be
usable at some level with out any. Just drop files in a dir on a
webserver and
> >Let's try to work this one through to completion:
> > http:/[-].ext
> So what should group be
> Given Noel's concern about Top Level Project and projects moving.
> I think that leaves us with the java package name.
Why?
> Also to keep the listing smaller can group be something like
> /a
Adam R. B. Jack wrote:
Metadata:
3) Do we need per version metadata? Hmmm... :(
I guess it's doable, tools could easily provide. The per *.md5 or *.asc
are such metadata.
I think per version metadata can be just another TYPE of artifact
stored in the repo
/commons-beanutils/meta/depend.xml
Things change, that is a fact that I'm just not sure we can generically
pre-empt, nor try.
Interestingly, Gump deals with a lot of the issues we are discussing here.
The main difference is that Gump purely metadata based, and lives only in
the 'now'. For changes it support aliasing.
http://gump.c
Noel J. Bergman wrote:
Given Noel's concern about Top Level Project and projects moving.
I think that leaves us with the java package name.
Why?
So lets go back to the start.
What sould the "group" part be. The java pakcage name works for me.
Also to keep the listing smaller can group
> >Let's try to work this one through to completion:
> > http:/[-].ext
> So what should group be
> Given Noel's concern about Top Level Project and projects moving.
> I think that leaves us with the java package name.
Why?
> Also to keep the listing smaller can group be something like
> /apac
Hi All,
I am trying to follow the emails to find out the requirements and the goals.
Since it is a revival, I am assuming it is discussed earlier ?
Things change with time, so it will be good to start from the requirements
and the goal and then try to solve each requirement in specific. It would
Nick Chalko <[EMAIL PROTECTED]> wrote on 31/10/2003 10:32:28 AM:
> [EMAIL PROTECTED] wrote:
>
> >Nick Chalko <[EMAIL PROTECTED]> wrote on 31/10/2003 09:05:06 AM:
> >>Must every artivact have the version in the file name?
> >>
> >Definitely.
>
> Some artifacts don't like having the full version n
[EMAIL PROTECTED] wrote:
I prefer to have version in the filename. but do we want to FORCE that
on projects prublishing to our repository.
Yes.
Ok I think we can concur. and add this to the requirement/ Goals doc
All artifacts in the repository WILL include the version in t
I think it is key we separate repository from "package indexing" (what is
'registered' on a machine) and "installation". I think these are awesome
goals, but weighty distractions we can't step up to. We'd need greater
community involvement than 'repository' ought have scope for. I'd like to
see the
20 matches
Mail list logo
