On Nov 9, 2003, at 6:20 PM, Stephen McConnell wrote:
Take for example the following:
http://www.ibiblio.org/maven/ant/jars/ant-1.5.jar
http://www.ibiblio.org/maven/ant/jars/ant-1.5.jar.md5
You can express the above as:
//..
This implies that there is a notion of meta-data down at the base
level -
peter royal wrote:
On Nov 7, 2003, at 5:37 PM, Stephen McConnell wrote:
Searching is certainly on the my agenda. We need it for IDE related
development, repository management, and intelligent query based
artifact aquisition (and HTTP in this context is not an ideal solution).
But that's a laye
On Sun, 2003-11-09 at 11:48, Noel J. Bergman wrote:
> peter royal wrote:
> > On Nov 7, 2003, at 5:37 PM, Stephen McConnell wrote:
> > > Searching is certainly on the my agenda. We need it for IDE related
> > > development, repository management, and intelligent query based
> > > artifact aquisitio
peter royal wrote:
> On Nov 7, 2003, at 5:37 PM, Stephen McConnell wrote:
> > Searching is certainly on the my agenda. We need it for IDE related
> > development, repository management, and intelligent query based
> > artifact aquisition (and HTTP in this context is not an ideal
> > solution).
>
On Nov 7, 2003, at 5:37 PM, Stephen McConnell wrote:
Searching is certainly on the my agenda. We need it for IDE related
development, repository management, and intelligent query based
artifact aquisition (and HTTP in this context is not an ideal
solution).
But that's a layer that would sit on
"Anou Manavalan" <[EMAIL PROTECTED]> wrote on 08/11/2003 02:01:52 AM:
> I am not sure if my earlier mail made it to the list, I really want to
see a
> different view of the URI
> http:project//-[-][.ext]
>
> It seems like we are inclining towards the already existing "Maven" kind
of
> URI
Thank you somebody for seeing these needs as well. I would like
to second Nick's response yet again.
> -Original Message-
> From: Nick Chalko [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 07, 2003 5:18 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Proposals
>
> With repositories growing fast, it needs to be searched and there should
> be
> a keyword search that assists faster search ( speaking from the
> established
> UDDI Repository and Database point of view ).
Yes exactly. Coming from the directory side I see a massive synergy. By
enabling attribu
On Fri, 2003-11-07 at 18:28, Nick Chalko wrote:
> Stephen McConnell wrote:
>
> >
> > Sure - and I think HTTP protocol support is fundamental. With the
> > Avalon stuff we are using HTTP today but we making sure that the
> > repository SPI enables selection of alternative repository protocols
>
Stephen McConnell wrote:
Sure - and I think HTTP protocol support is fundamental. With the
Avalon stuff we are using HTTP today but we making sure that the
repository SPI enables selection of alternative repository protocols
so that we put a lot more intelligence into the backend/client
relati
Nick Chalko wrote:
Stephen McConnell wrote:
Anou Manavalan wrote:
With no responses supporting this idea, I guess I will put this idea
to rest in peace ;-)
Searching is certainly on the my agenda. We need it for IDE related
development, repository management, and intelligent query based
ar
Stephen McConnell wrote:
Anou Manavalan wrote:
With no responses supporting this idea, I guess I will put this idea
to rest in peace ;-)
Searching is certainly on the my agenda. We need it for IDE related
development, repository management, and intelligent query based
artifact aquisition (an
Anou Manavalan wrote:
With no responses supporting this idea, I guess I will put this idea
to rest in peace ;-)
Searching is certainly on the my agenda. We need it for IDE related
development, repository management, and intelligent query based artifact
aquisition (and HTTP in this context is
Anou Manavalan wrote:
With repositories growing fast, it needs to be searched and there
should be a keyword search that assists faster search ( speaking from
the established UDDI Repository and Database point of view ).
With no responses supporting this idea, I guess I will put this idea
to res
I concur, it is just shifting the the problem. Is xerces in XML or Web
Services or Text Processing or Library or Core or Utility or Base or
Transormation or .
:-) You ask me, then I would say XML-Parser. I unerstand it is hard to
group them into one, but every project focuses on one t
Nicola Ken Barozzi wrote:
Anou Manavalan wrote:
I am not sure if my earlier mail made it to the list, I really want
to see a different view of the URI
http:project//-[-][.ext]
It seems like we are inclining towards the already existing "Maven"
kind of URI. It has already proven its existence
eves and manage one on Apache hardware w/ partner mirrors. I think
prototyping and phasing are keys here.
regards,
Adam
- Original Message -
From: "Anou Manavalan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, November 07, 2003 8:01 AM
Subject: RE: Proposals
Anou Manavalan wrote:
I am not sure if my earlier mail made it to the list, I really want to
see a different view of the URI
http:project//-[-][.ext]
It seems like we are inclining towards the already existing "Maven" kind
of URI. It has already proven its existence, instead of repeating the
to know is what they want to solve.
regards,
-Anou
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: RE: Proposals
Date: Fri, 7 Nov 2003 12:43:17 +1100
No.
In Maven, it's the artifact type, e.g. jar(s), war(s) exe(s).
I thought we'd been over this on
On Fri, 7 Nov 2003 [EMAIL PROTECTED] wrote:
> not as much bandwidth...
So lets design this a bit better then = make sure that it allows for the
authoritative source to be on ASF[*] hardware (perhaps with an ASF signed
key, sha1 or md5) - but it can be mirrored out through ibiblio, my local
disk
--On Thursday, November 06, 2003 21:51:25 -0500 "Noel J. Bergman"
<[EMAIL PROTECTED]> wrote:
I imagine:
.../httpd/dists/httpd-2.0.45-src.zip
.../httpd/dists/httpd-2.0.45-src.tar.gz
.../httpd/dists/httpd-2.0.45-bin-solaris.tar.gz
.../httpd/dists/httpd-2.0.45-bin-linux.tar.gz
From a strict user-ce
On Thu, 2003-11-06 at 22:26, [EMAIL PROTECTED] wrote:
>
>
> >
> > Well, let's make sure that we get input from the httpd release folks before
> > we re-design the layout of the library. I just want to make sure that we
> > have a consensus across projects that everyone can live with, not just J
in-win32/etc)
> 3) artifact format (extension: tar.gz, tar.bz2 - only makes sense for
> some artifact types)
>
> Cheers,
> Brett
>
> > -Original Message-
> > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
> > Sent: Friday, 7 November 2003 1:32 PM
> >
>
> Well, let's make sure that we get input from the httpd release folks before
> we re-design the layout of the library. I just want to make sure that we
> have a consensus across projects that everyone can live with, not just Java
> projects, and which works for the full spectrum of projects.
> > > > > http:jars/[-][-].ext
> > > > Is jars/ to be / for the non-Java crowd?
> > > No. In Maven, it's the artifact type, e.g. jar(s), war(s) exe(s).
> > How do we address additional portable and native platforms,
> > e.g., http://www.apache.org/dist/httpd/binaries/? For that
> > matter, wh
> I thought we'd been over this one before.
We had, but until we finalize decisions in some documented form late comers
are going to keep rehashing them. How do we document decisions? Wiki? Web
Site? We are waiting on your lead, I believe -- or is that not what you
envisioned?
regards
Adam
Title: RE: Proposals
I imagine:
.../httpd/dists/httpd-2.0.45-src.zip
.../httpd/dists/httpd-2.0.45-src.tar.gz
.../httpd/dists/httpd-2.0.45-bin-solaris.tar.gz
.../httpd/dists/httpd-2.0.45-bin-linux.tar.gz
So I guess type != ext, which makes sense.
I would prefer, for example:
.../so
> > > http:jars/[-][-].ext
> > Is jars/ to be / for the non-Java crowd?
> No. In Maven, it's the artifact type, e.g. jar(s), war(s) exe(s).
How do we address additional portable and native platforms, e.g.,
http://www.apache.org/dist/httpd/binaries/? For that matter, what is the
mapping for h
No.
In Maven, it's the artifact type, e.g. jar(s), war(s) exe(s).
I thought we'd been over this one before.
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
"Noel J. Bergman" <[EMAIL PROTECTED]>
Brett Porter wrote:
Maven's is
http:s/[-][-].
This seems reasonable to me
We need to describe what a "group" is.
artifact_types
release types
and
version syntax. (perhaps)
smime.p7s
Description: S/MIME Cryptographic Signature
Title: RE: Proposals
Maven's is
http:s/[-][-].
Which should cover all platforms (as artifact_type can be dll, jar, maven-plugin, doc, etc).
This also means http://repo.apache.org/org.apache.xerces can be the single place to download Xerces in C++, Java, cobol, whatever.
I ima
Noel J. Bergman wrote:
http:jars/[-][-].ext
Is jars/ to be / for the non-Java crowd?
--- Noel
Sounds reasonable.
smime.p7s
Description: S/MIME Cryptographic Signature
> http:jars/[-][-].ext
Is jars/ to be / for the non-Java crowd?
--- Noel
Jason van Zyl wrote:
Howdy,
Just joining in now and was wondering where the existing proposals are
for perusing.
Ther is some wiki stuff at
http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository
But note the URI syntax listed there is likely to change.
the last almost consensus was closer t
34 matches
Mail list logo
