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
Jason van Zyl wrote:
On Fri, 2003-11-07 at 15:38, Stephen McConnell wrote:
Jason van Zyl wrote:
On Fri, 2003-11-07 at 11:48, Stephen McConnell wrote:
Adam R. B. Jack wrote:
Three comments (probably all repetitions) :
1) Perl/Python have a package index/identification ap
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
On Fri, 2003-11-07 at 15:38, Stephen McConnell wrote:
> Jason van Zyl wrote:
>
> >On Fri, 2003-11-07 at 11:48, Stephen McConnell wrote:
> >
> >
> >>Adam R. B. Jack wrote:
> >>
> >>
> >>
> >>>Three comments (probably all repetitions) :
> >>>
> >>>1) Perl/Python have a package index/identifica
Jason van Zyl wrote:
On Fri, 2003-11-07 at 11:48, Stephen McConnell wrote:
Adam R. B. Jack wrote:
Three comments (probably all repetitions) :
1) Perl/Python have a package index/identification approaches. We might want
a similar concept, i.e. queriable metadata that associates keywords/con
Lets agree on some first steps to take
We need to
1. Agree on Repository goals
2. Agree on Repository requirements
3. Agree on URI syntax
4. Recommend best practices for
1. Client Tools
1. Management Tools
Then we can encourge / sponsor projects that write code.
This assum
On Fri, 2003-11-07 at 11:48, Stephen McConnell wrote:
> Adam R. B. Jack wrote:
>
> >Three comments (probably all repetitions) :
> >
> >1) Perl/Python have a package index/identification approaches. We might want
> >a similar concept, i.e. queriable metadata that associates keywords/concepts
> >wit
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
Adam R. B. Jack wrote:
Three comments (probably all repetitions) :
1) Perl/Python have a package index/identification approaches. We might want
a similar concept, i.e. queriable metadata that associates keywords/concepts
with packages/groups/artefacts. These concepts could be language sensitive
(s
Three comments (probably all repetitions) :
1) Perl/Python have a package index/identification approaches. We might want
a similar concept, i.e. queriable metadata that associates keywords/concepts
with packages/groups/artefacts. These concepts could be language sensitive
(so either different, or
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
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 same
thing, may be w
- repository and board are CCed -
- please reply to general@incubator.apache.org -
There is a discussion going on over at [EMAIL PROTECTED] about the
creation of an Apache jar and artifact repository. The discussion is
being constructive and is bringing in people from diverse efforts:
Maven, Rup
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
Joshua Slive wrote:
maven.repo.remote = [preferred]/avalon,http://www.ibiblio.org/maven
Sorry, I'm not on [EMAIL PROTECTED] (Do we have any mirror
maintainers on that list?) But I don't believe this is a particularly
smart thing to do.
hmm. Good point. I've disabled this feature for now. A sh
[EMAIL PROTECTED] wrote:
Nicola Ken Barozzi <[EMAIL PROTECTED]> wrote on 07/11/2003 12:34:54 AM:
Reading Dion's messages I gather that there is no particular will of
Maven to participate ATM to an independent "Repo" project with active
development as ATM Maven is satisfied of its current implemen
> I have been out of commission for the better part of this year but
> Plexus was slated to integrate Maven's repositories directly. Of late
> I've been discussing this with the Loom folk and ~10 people who have
> access to the Plexus-based version of Maven.
Yes, I remember checking out maven-new
Here is the currently listed goals
http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&id=ASFRepository
Goal:
A repository architecture/implmentation for software artifacts
(primarily JARs) for streamlining distribution. Corrolary Goal: Removing
JARs from CVS.
* Open (language independent,
here is the goals / requirements currently listed at the wiki.
Lets hash through them so we can move forward.
http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/Requirements
* ASF Repository shall
** only host artifacts approved by a PMC
** be accessible to the public via http
** be m
--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
On Thu, 2003-11-06 at 21:41, [EMAIL PROTECTED] wrote:
> Hi Jason,
>
> > Just a note to any Maven developers who are interested in discussing the
> > format of the future repository layout for Apache are welcome to join in
> > at [EMAIL PROTECTED] I think we have lots to offer in this area so
> > i
"Adam R. B. Jack" <[EMAIL PROTECTED]> wrote on 07/11/2003 01:13:16 AM:
> All,
>
> As I understand it we have enough apache committers interested in this
to
> make a viable project. We clearly have gobs of volunteer code, should
that
> need arise. We have everything but a vehicle for progress. W
On Thu, 2003-11-06 at 21:41, Brett Porter 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
>
> So I guess type != ext, which makes sense.
It doe
On Thu, 2003-11-06 at 22:14, [EMAIL PROTECTED] wrote:
> Nicola Ken Barozzi <[EMAIL PROTECTED]> wrote on 07/11/2003 05:36:40 AM:
>
> > I'm sorry you didn't know about it. Dion is on the list since it started
>
> > IIRC, I thought that he would have told Mavenites about it. Should have
> > checke
Nicola Ken Barozzi <[EMAIL PROTECTED]> wrote on 07/11/2003 12:34:54 AM:
> Reading Dion's messages I gather that there is no particular will of
> Maven to participate ATM to an independent "Repo" project with active
> development as ATM Maven is satisfied of its current implementation. In
Pleas
Niclas,
Very sound advice and keen observations ... you're right! Time will tell and
we need to start making some baby steps in the right direction for now. I
think involvement with the Maven people in defining what a repository is for
one single Apache repository is most important first.
>
> 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.
Nicola Ken Barozzi <[EMAIL PROTECTED]> wrote on 07/11/2003 05:36:40 AM:
> I'm sorry you didn't know about it. Dion is on the list since it started
> IIRC, I thought that he would have told Mavenites about it. Should have
> checked.
I figured if people were interested they were reading the list
> > > > > 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
Hi Jason,
> Just a note to any Maven developers who are interested in discussing the
> format of the future repository layout for Apache are welcome to join in
> at [EMAIL PROTECTED] I think we have lots to offer in this area so
> if you have some pop into the discussions.
Very cool you have good
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/mod_
> > > 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 imagined the
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
43 matches
Mail list logo
