RE: repo security
One thing I'd like to see is *every* JAR signed w/ certs under a single CA, say the Maven one. Well, we have an ASF CA, which I would trust. Talk with Ben Laurie about it. --- Noel
RE: Maven and repository@apache.org
IMO we should [make] the Maven artifact handling better and used by all Apache and non-Apache projects. Is Maven willing to provide suitable support for Ant to use it? I just want to make sure that this is not the Maven repository, but is THE repository. Tool-agnostic. --- Noel
RE: Cron mdiggory@tribal /export/sunsite/users/mdiggory/bin/sync-apache
The only issue I can see is that the From address is [EMAIL PROTECTED] I will leave it to you to figure out. When you've done, please let me know. Right now I have to moderate these through. I'll add it to allow list after you're done fixing the address, although it it ends up being yours, I won't have to worry about it. --- Noel
RE: Cron mdiggory@tribal /export/sunsite/users/mdiggory/bin/sync-apache
Just doublechecking, did everyone on the repository list recieve this? Yes. Was this by accident, or something you wanted coming to the list now? --- Noel
RE: adding jaxme jars
jaxme would have been out of incubation by now but there are some major hassles with procedure. No, there was a vote taken. It was then redone a day later in a public forum. Hardly a major hassle, nor a significant delay. --- Noel
RE: [maven] developer repository?
Matthew, re: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] he.orgmsgNo=40252 See [EMAIL PROTECTED] There are already a group trying to do this work. Tim Anderson, for one, has done a superb job, as have others. If you can help herd the various projects that would be good. --- Noel
RE: licensing issues for virtual artifacts (was RE: click through license support?)
Nicola Ken Barozzi wrote [EMAIL PROTECTED] wrote: I'm failing to see the requirement for us to do [virtual artifacts] *now*. Because Apache projects using the repository would need also non-asf jars that we don't want to distribute - virtual artifacts. I still maintain that non-ASF jars are specified in meta-data made available to client tools, and thus virtual artifacts are unnecessary. The meta-data files will need to be present repository in order for the tools to work. --- Noel
RE: licensing issues for virtual artifacts (was RE: click through license support?)
Suppose ASF has the following link in the repository: http://repo.apache.org/sun/jndi/1.2.1/jars/jndi-1.2.1.jar This is a virtual artifact, not hosted at ASF. I do not like the idea of virtual artifacts. I think that the meta-data for any component that needs a foreign artifact should contain the information needed by some tool. I don't think that we want to include foreign components in the ASF namespace. In fact, there is a situation right now where someone else has done that to the ASF, and we're not happy about it. --- Noel
RE: click through license support?
I'm taking about downloading the whole thing from the sun site as users manually do. So there is effectively no distribuition difference. You would have to pass through the license request to the user. It would be a bad idea for the tool to pose as a user without requiring user approval of the actual license. Not sure if you've already said that; just making sure that it gets noted. Nick has a point that this is more of a tools discussion. Any reference to a click-through license would come from meta-data describing the location of a dependency. --- Noel
RE: Use of '/' in ???-specifier's
maybe the [organization]/[product] notion is artificial. What [organization]/[product] and [organization]/[product]/[version] do is to establish a path to an logical artifact. At any of it does is establish a path to a logical artifact. Seems to me that there is limited utility to being able to parse the URI, and that the real key is having meta-data with which to assemble it. But others don't seem to agree with that view. They want to parse semantic information from the URI. we should not be focussing on the url as a spec - but instead we should be focussing on the url as a [artifact-identifier] and from that point on we should be using metadata to provide us with the information about organization, product name, available versions, etc. So your feeling is that once you have a URI for the root component for a tool, you want meta-data suitable for your tool to indicate the location(s) of other content, such as license, dependents, etc. Those location(s) can be specified either by a full URI, or after all of Tim's good work, by URI parts, which the specification tells us how to assemble. The latter is how I have been viewing things so far. The meta-data could be in the form of a POM, a JNLP file, or some other format, and the tool would indicate what it is looking for as previously discussed. I think that's where you're going, right? I'm not keen on being the odd-guy out I don't think that you are. There may be some undocumented assumptions going on, and this helps to clarify them. For example, the above may help explain to Adam why I have been unconcerned about the ability to unambiguously parse a URL, whereas I do care about being able to assemble one. --- Noel
meta-data formats
Stephen, The meta-data could be in the form of a POM, a JNLP file, or some other format, and the tool would indicate what it is looking for as previously discussed. I think that's where you're going, right? In principal ... yes. But I am making an assumption that a very simple named value pair metadata syntax could be assumed along with a meta mime type. References in that structure could be absolute or relative to the location of the metadata file. That would be a possible meta-data format, but there are already others, such as Maven's POM or Sun's JNLP. The goal, IMO, would be to provide suitable content appropriate to the requesting client. I think we need to facilitate the mechanism, not dictate the possible meta-data formats. --- Noel
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. There is a requirement that repositories work (at some minimum level) without metadata, especially since we aren't specifying metadata. Without a parsable URI (or parsable URL) how do tools read a repository to do things like clean oldest nightly/snapshot, but leave all releases, download latest release or even the basics determine/display contents, show basic contents (irrespective of version/type). 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. As for the particular examples you gave, those carry semantic meaning that would require more specification that is contained in the URI syntax. Although those would be desirable, I don't know that we want to including that kind of semantic specification in the URI. If we are proposing a standard, there has to be a valid purpose for it -- and having a standard that isn't structured for computer processing seems setting the bar pointlessly low. Tim's URI schema supports your operations when combined with with a semantic layer, which can be implied or meta-data based. For me, the strongest argument for tooling (other purely than saving admins effort) is download + verify (MD5/whatever). That does not require the kind of semantic your earlier operations require. The verification content can be relative to the URI provided to the tool. --- Noel
RE: [proposal] URI Syntax - v0.2
My input here is primarily based on writting Ruper 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? It allows you to query what is there, query and capture oldest resources [and do a delete/clean], and download newest, etc. How does it know what OLDEST means? I see that Tim is trying to add some more structure, so maybe he's thinking that we can restrict the URI space so that a restricted notion of version assures an automatable concept of succession. Some find such a tool useful, I'd like to believe that apache users (admins and external users) would find it useful. I don't disagree. I simply said that if you view the repository solution as a layer of specifications, the lowest layer can be a syntax that does not require semantics such as an automatable concept of succession. If we need that, we can add it either by a convention within the URI space, or by other means. [I sometimes feel the acadaemics of the URI Scheme Specifiecation are outweighing the practicalities of an implementation. I beleive in writting a specification first, but specifications get revised based upon real world experience. Tools are that experience.] I'd like to say go get me xerces from any repository it is in, but get me the latest, but I only want release not nightly/snapshot That to me, is useful. Absolutely. But that may require something more than the URI schema. :-) I feel we have the potential to win big, and I'd like the ASF Repository to be a step forward towards these goals, not a step backward. I agree. But one layer at a time. :-) --- Noel
RE: repository@ awareness?
You're saying that those interested in enabling a repo with metadata and searches based on this metadata could wrap the repository with a servlet. Could? Yes. But that is just one way of many. I maintain that httpd could serve the content of most repositories, meta-data and all, without dynamic content generation. The URI could be used by the servlet to give a different view of the repository based on [criteria embedded in the request] IMO, the request should to encode the complete request. There should not be any other implied context. the servlet manages the interaction behind the scenes with some sort of metadata database to conduct the query and return the results as if they were regular files on the server's repo file system. It depends upon the repository implementation. It could work as you describe, or there could just be pre-built metadata stored in files. Consider that eventually web sites will likely use Subversion with WebDAV as their authoring mechanism. Authorized people will post directly to a Subversion repository. Although httpd can load directly from Subversion, that will not be as efficient as serving directly from the file system. The reason for that is that sendfile() does not work directly out of a BDB database (as far as I know). Therefore, when a file is posted to Subversion, it could be mirrored by a hook to a directory representing the current content, which is what would then be served by httpd. We used a similar technique at GEIS years ago with SourceSafe, so that when a checking occurred, a copy went into a shadow directory, and a build test was initiated. Likewise, a tool could be invoke to build meta-data, and store it in the file system. So there are ways and ways and more ways. The goal is the same, as should be the externally viewable behavior. --- Noel
RE: repository@ awareness?
Justin, Is anyone on infrastructure@ aware of what's going on in [EMAIL PROTECTED] Not from what I see on the subscriber list, which is why I have suggested on more than one occassion that such participation is important. Apparently, AFAICT, that list is supposed to allow for Java-based distribution of software. Other than that, I'm completely lost as to what that list is for. Eventually, it would be desirable to have a user-friendly tool that is capable of picking up, for example, httpd source, tomcat, and other parts, and doing a platform-specific install. But the tool is someone else's problem. The only thing that the repository needs to do is provide a non-fragile URI space for artifacts, of which files and, eventually, metadata are both examples. Do any 'core' infrastructure people need to get involved to help guide with what's practical or not? Yes. With a quick perusal of [EMAIL PROTECTED], I got the sense that they might be out in la-la land Agreed. The discussion on [EMAIL PROTECTED] was getting into tool areas that should be relatively orthogonal to the repository. There are three areas: - URI space - metadata - tools The first is the main issue that the repository needs to address. The second is an area where after we have decided upon the URI space, the tool groups could use the repository list as a gathering place to seek common ground. And then there are tools, which belong elsewhere, but use the repository. Some people are jumping ahead to tools before the URI space is resolved. The people advocating a file layout *only* get my uninformed +1.) I think that most people recognize that the file layout only approach to the URI space is necessary. meta-data is present in the URI space, and can be implemented with a static file. Even if we want to key off the user-agent for meta-data, that can still be served with static content in the file space. --- Noel
RE: repository@ awareness?
Stephen McConnell asked: File system - a convenient and simple solution - but should a file system driven approach be the basis for the next generation? The basis is a URI space. Whether a URI is efficiently served by a static file, or by some servlet, CGI or Grandma Moses typing very VERY fast really should not be visible to the user-agent. A solution must be implementation independent See: http://www.w3.org/Provider/Style/URI.html The URI is a request for content. It should not change, regardless of the means by which the content is generated. So why a preoccupation with meta-less file system structures as opposed to a preoccupation with an extensible repository protocol? The extensible repository protocol is HTTP. Nothing else needs to be visible. The only thing that the infrastructure team needs to deal with is the implementation of the URI space (allowing that the content addressed by a URI can vary based upon the user-agent). --- Noel
RE: [Possible Incubation] Apache Repo
Neither you or I are any great shining examples of an ideal collaborator. You'll have to bear with me while I try to make ammends. I will try to bear with you. Let take this at face value: someone admitting to faults, pledging to improve, asking for allowances while making even more mistakes in the interim, and offering the same in return. Few people cannot stand to improve their inter-personal communication. --- Noel
RE: Proposals
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 layer that would sit on top of the repository, right? That is my thought as well. First we need a layout, of which I like Tim's the best so far. On top of that we can add meta-data, and then tools that use the meta-data. For dumb servers, we can have tools that create static meta-data, which would also be more efficient. Smart servers might support dynamically creating, or simply reformatting, meta-data for different clients, e.g., Maven, Avalon or JNLP, from a single source, but otherwise we just store meta-data statically. The real smarts would be on the client side, where the metadata would be most often used. But since the meta-data would be present at a URL within the layout, I don't think that we need to deal with it right now. Just the layout, itself, which can be presented to infrastructure and the projects. Once we've a layout, existing tools can make use of it, and people can start discussing the next layer, which would be meta-data. At least that's my view. :-) --- Noel
RE: URL Syntax parts
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 name ought to be unique across the ASF. --- Noel
RE: New lists in eyebrowse
Brian Behlendorf wrote: On Sun, 10 Aug 2003, Noel J. Bergman wrote: The requested list [EMAIL PROTECTED] has not been added because there is no directory for it under daedalus:/www/www.apache.org/mail/. What's this list about? I see you listed as a moderator, is it intended to be a public list? Although it has been idle, that list is regarding an Apache repository, suitable for Maven and other tools, and not language specific. As I recall, there was some decent stuff on there before it went quiet. I don't know of any reason for it to not be public, but I'm cc'ing the list. --- Noel
