version and ruper2

> Dion wrote: > > My question is do they fit our needs? Sadly, I've not had chance to locate/read the archives, but I'll try to answer the question of what they do. > > "Krysalis-Ruper2 is a resource updater, meaning it automatically keeps > > local resources up-to-date with versions of the r

Repository

I've read the archives (thanks infrastructure for that). If folks have the patience, I'd like to add a few more thoughts. I'll try to make this as brief as I can. I came to developing OSS because running a growing demo centre of lots of machines running on top of lots of Apache/OSS software I use

Re: Revival

From: <[EMAIL PROTECTED]> > So, a quick question. A 'repository effort' is not just about code, it's > mainly about keeping the repository up to date and accessible, and this > (from what I can tell) isn't covered by Ruper or Version, is it? Agreed, however with sufficient automation tools around

Repository

Hi, It seems to me that Dion put out a feeler with "Is anyone interested in reviving this project?" and a few of us (with unbounded passion) launched in w/ gobs of information/opinions. Maybe this was just a one time opening off flood gates, that was like drinking from a fire hose, but maybe it is

Re: Repository

Dion: <[EMAIL PROTECTED]> wrote: > > First, Dion, what would you like to see? What are your goals for this > > I was hoping to revive some discussion. Last time things jumped to code > and then stopped. I hear you, and I don't want to see that either. There are so many complex issues involved her

Re: URI Syntax was: Repository

Folks wrote: > > > > So here is a key focuossed issue. > > What should the URI look like > > > > The latest URI discussed was > > > > http:/artifact-[].ext > > > > For example > > * http://repo.apache.org/org-apache-ant/1.5.1/ant-1.5.1.jar Are we discussing URI or URL? If URI, ok good .. but

Re: URI Syntax was: Repository

> 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

Argrement #1? : Layout (aka URL)

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

metadata

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

Re: URL Syntax parts

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

Fw: ActivePython 2.3 and PyPPM

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

Repository Progress/Drive

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. We need goals/objectives/milestones, or maybe we just need drive. Maybe we need a pr

Re: Maven Repository @ Apache

> One exception could be if the automated process were to also grab the md5 > (or pgp, but that would be more complicated) from apache.org and verify > the file's integrity. I think this should be assumed as a minimum. Given this, would you be comfortable? [I see 'could be'.] regards Adam

Re: Proposals

> 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

Scope/Phasing (was Re: Proposals)

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

Re: Scope/Phasing

> It's really not that much more than that. > Sophisticated systems that are reliable are built upon simplicity not > complexity I agree. I'd like to think of what we are doing as laying out a simple file system, and later building services that index/query. Compare this to /cvsroot, cvs protocol

URI/URL Syntax -- little nits to be aware of

I know URI syntax is dragging on (and I don't know if we are coming to consensus or going round and round) but I hope folks are still open eared to this stuff, because IMHO the URI /URL syntax may be *the only critical thing* we need to determine/document for repository to be at a satisfactory phas

Re: URI/URL Syntax -- little nits to be aware of

> Why do you want to parse strings which describe versions? So one can look at a repository of artefacts and select the "best" for the user automatically. Each user has a different view of "best", some want latest (nightly/snapshot), some want latest "release" only. Having a repository with autom

Organization

I'm sorry, but I feel the significant traffic of this mailing list is overloading the value of the discussion. I feel we need to slow it down in order to get worthwhile progress. Many folk would've missed the weekend's flurry and have troubles catching up, and their lack of responses could be const

Repsitory Requirements ( was Re: Repo Goals )

This is on the Wiki here. http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository Please review it and help complete it. regards Adam - Original Message - From: "Nick Chalko" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, October 30, 2003 11:41 AM Subject: Repo Goals > Ok

Processing Versions

> Adam R. B. Jack wrote: > > >So one can look at a repository of artefacts and select the "best" for the > >user automatically. Each user has a different view of "best", some want > >latest (nightly/snapshot), some want latest "release" only

Manage discussions to a conclusion...

I am trying to move contentious topics to the Wiki so we can reference them individually, and (over time) come to an agreement. How does this layout work for folks? I have started with one discussion topic: http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/ToDo If we can agree upon some

Re: Processing Versions

> [...] and repository > possibly won't be limited to project hosted at ASF. This is why we need the Wiki, the e-mail archives are too hard to comsume. It was agreed a while ago that this is for Apache software, we aren't trying to solve this problem for everybody else. We need to stop going back

index.html (was Comments on URI Syntax

> http://repo.apache.org/apache/commons-logging/1.0.3/index.html > > Clearly, this is only useful to users browsing the repository, > and therefore makes no sense to include the version information. On index.html, wouldn't we discourage the use of this? Wouldn't we want the HTTP server to do a d

Disagreements/Agreements

> I am almost sure that with WIKI we will have much more chaos. > Wiki it's not a perfect techonology for maitaing disussions. > > -1 for using WIKI for dissusion I didn't mean solely, I think we need a mixture of both. I think e-mail threads are good (when tight) but a thread might end with the p

Re: Processing Versions

> So it will be our problem if we would like > to consider any constrains for version names (which IMHO are no realistic > in short term (if ever) even inside ASF) . > That's why I strongly believe that any discussion about artifact versioning > simply should not take place. You don't want to slo

Re: Where to put Version in the URISyntax

1) I'll cut-n-paste your pros/cons into the Wiki, thanks. I didn't want to presume to know your vote, so please put it there: http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/WhereIsVersionInURISytnax 2) I believe most folks want more conformity rather than less, so are more inclined to

Re: Where to put Version in the URISyntax

> I think we've the core of such an agreement, although we also need to invite > the current mirroring folks from infrastructure to review it once we at > least agree. I think we pretty much started with the core of an agreement, we've refined it somewhat, and we've been dancing around and around

Tooling (was Version Specifier in Re: [proposal] URI Syntax - v0.2)

> Its great idea to make Artifact Specifier to be opaque to give way to > different languages, but I am not sure about the Version Specifier. Version > Specifier can be considered as language independent and allowing different > best practices in there would make the repository unordered and could

Re: [proposal] URI Syntax - v0.2

> > >However, I don't think this is unreasonable. There is no requirement > > >that tools be able to parse URIs to extract meta-data. Say who? There is a requirement that repositories "work" (at some minimum level) without metadata, especially since we aren't specifying metadata. Without a parsab

Re: [proposal] URI Syntax - v0.2

Noel wrote: > Adam, and how is said tool going to start in the first place? Without > meta-data, there is a limit to what the tool can do. Basically, it would > have to operate relative to the URL provided to it. My input here is primarily based on writting Ruper (http://www.krysalis.org/ruper)

Re: [proposal] common build version specifier - v0.1

Tim, I *love* your specifications, I really appreciate the clear/concise/explicit nature of them. I only wish you'd use Wiki not EyeBrowse as your persistent documentation tool. Wiki has versioning (so we can see older copies should we need to refer back) and such, and allows other to make (respec

Parsable URI (Re: [proposal] URI Syntax - v0.2)

Noel wrote: > > You don't have to like the tool, I'm not trying to push the implementation > > I've never even seen the thing, and you are a priori assuming that I don't > like it? No Neol, I'm not that emoition, I meant it dispassionately and without inference, maybe it just read differently. Th

Re: Use of '/' in ???-specifier's

> Tim Anderson wrote: > > >For advocates of URI parsing, what problems are you trying > >to solve? This is a simple matter of practicality. We've agreed to delay metadata so we can get a nice/simple repository structure w/o all the differences of opinion that metadata might introduce. We basicall

Test/Prototypical Repository

All, As a way to force me to review the specification and attempt to implement I've started a knock up repository at: http://www.apache.org/~ajack/testrepo [If we think this is a good idea we can ask infrastructure@ for a location we can all write to.] Can folks tell me if this repository f

Re: Use of '/' in ???-specifier's

> Not a criticism, but I'd prefer to know the requirements, > before writing the tools. I know, I've been a huge advocate of that, but I'm starting to worry we are in analysis paralysis. Logical URIs are so virtual it is easy to miss practical implications. As such, I'd like to test the theory a

Re: Anywhere near concensus?

> Is there any consensus out there that the > repository URI proposals are the right/wrong way to go? I have to believe it is close. I think folks need to add any issues they have here to TODOs http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/ToDo If we can't agree on some we need to

Re: Anywhere near concensus?

> The third form leads to a flat repository structure, similar to > that in use by maven (http://www.ibiblio.org/maven) > >From a browsing perspective, this doesn't scale to large numbers > of groups (aka products). That could be said about anything, at any level. Luckily Apache (this repository)

Re: Anywhere near concensus?

> If someone with a public webspace can extract them both (Adam?), > that would be great. Done:http://cvs.apache.org/~ajack/repository/proposals/ regards Adam

Re: Anywhere near concensus?

> IIRC, the repository structure used by Maven (http://www.ibiblio.org/maven/) > has generated much discussion in the past, with the > general concensus being that the flat structure: > . didn't help artifact categorisation > . made it difficult to navigate and locate artifacts Folk have resolved

Re: Anywhere near concensus?

> > Done:http://cvs.apache.org/~ajack/repository/proposals/ > > I think of the group, I like repositoryFQDN/ best. For me, it is between that and group (oh yeah, I asked for that one. ;-) 'cos they are both of deterministic directory depth/layout. [BTW: If things get 'overloaded' we can do

Re: URI syntax

"Michael Davey" <[EMAIL PROTECTED]> wrote: > I'd like to suggest some changes to the URI Syntax document: > Do your changes need to be mandated, or could they be recommendations? If the former, what problem are you trying to s

Re: URI classification by subject

> How will the repository deal with things like organization name and > product name changing after some products have been added to the > repository? First off, I think we need to solve this for Apache first, and not worry too much about other organizations. Second, change happens. Sure, it is s

Re: ASF Repository, closer.cgi and Depot

- Original Message - From: "Mark R. Diggory" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; Sent: Wednesday, July 14, 2004 8:48 AM Subject: ASF Repository, closer.cgi and Depot > Sorry for the cross post but this seems relevant to both these groups. > > I was thinking about the subject o

Re: Rsync Emails

On Tue, 3 Aug 2004, Mark R. Diggory wrote: I'm curious, would others be interested in seeing the rsync emails from ibiblio for the rsync that runs every 4 hours on the login.ibibilio.org server? I could direct them to this list or possibly the maven devel list if its more appropriate. Are they v

Re: Rsync Emails

I could possibly tweek it to not send an email if there are no new files being moved. Please do. regards Adam