This version replaces v1.0: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&ms gNo=308
Overview ======== The key aims of this proposal are: . language and artifact neutrality. It should be possible to support multiple languages and their artifacts, not just java. . it should be possible for users to easily navigate the repository and locate artifacts, including jars and release distributions. Compare this with the existing approach of separating release distributions (http://www.apache.org/dist/) and jars (http://www.ibiblio.org/maven). . it should be possible for tools to construct a URI to locate an artifact using a set of known criteria Artifacts --------- All files in the repository are artifacts. There is no distinction between artifacts and meta-data. Any relationships between artifacts is determined by supporting tools. Repository URI Components ========================= An absolute repository URI is written as follows: repository-uri = access-specifier "/" product-specifier "/" version-specifier "/" artifact-specifier Access specifier ---------------- The access specifier determines the scheme, authority, and optional repository directory prefix. There is currently no requirement for ftp, scp or file based access - only http is supported: access-specifier = http-access-specifier http-access-specifier = "http://"; authority "/" [directory "/"] directory = path_segments (authority and path_segments are per http://www.ietf.org/rfc/rfc2396.txt) <directory> is used when the repository cannot be located at the root of an absolute URI. URI examples: http://repo.apache.org/ http://repo.apache.org/pub/repository Product specifier ----------------- The product specifier specifies the organisation and project: product-specifier = organisation "/" project organisation = name-segments project = name-segment name-segments = name-segment *( "/" name_segment) name-segment = nchar+ nchar = alphanum | escaped | "_" | "-" | "!" | "~" | "@" | "&" (alphanum and escaped are per http://www.ietf.org/rfc/rfc2396.txt) <organisation> is the organisation name. It is arbitrary, but should be globally unique. It could be the domain name, or reverse domain name, with "." replaced by "/", e.g: "sun/com", "org/apache" or simply the name of the organisation, e.g "oracle". <project> is the project name. It is unique within an organisation. E.g, "ldap", "jndi", "maven", "commons-logging". URI examples: http://repo.apache.org/org/apache/commons-logging http://repo.apache.org/sun/jndi Version specifier ----------------- The version specifier specifies the version of the project: version-specifier = name-segments For the purposes of this proposal, version-specifier is opaque - its format is determined by language and deployment best practices. Some possible examples include: "1.0", "v0.9-beta", "nightly/20031113", "latest", "release/1.5.4" URI examples: http://repo.apache.org/apache/commons-logging/1.0 http://repo.apache.org/apache/commons-logging/1.1 http://repo.apache.org/apache/commons-logging/latest http://repo.apache.org/apache/ant/release/1.5.4 http://repo.apache.org/apache/ant/nightly/20031113 http://repo.apache.org/apache/commons-cli/nightly/1.0/20031113 http://repo.apache.org/apache/commons-cli/nightly/2.0/20031113 Artifact specifier ------------------ The artifact specifier uniquely identifies an artifact within a project version: artifact-specifier = name-segments For the purposes of this proposal, artifact-specifier is opaque - its format is determined by language and deployment best practices. Some possible examples include: jars/commons-logging-1.1.jar binaries/linux/httpd-2.0.40-i686-pc-linux-gnu-rh73.tar.gz URI examples: http://repo.apache.org/apache/common-logging/1.1/jars/commons-logging-1.1.ja r http://repo.apache.org/apache/httpd/2.0.48/docs/httpd-docs-2.0.48.en.zip http://repo.apache.org/apache/ant/1.5.4/KEYS Rationale ========= Of the URI components: . <access-specifier> and <product-specifier> are common accross all languages and deployments. . <version-specifier> is subject to language or deployment best practices . <artifact-specifier> is subject to language, deployment, artifact, or project best practices It is envisioned that there will be different repository deployment and query tools developed for each language. A generic tool cannot be written without providing supporting meta-data, which is outside the scope of this proposal. Projects should be able to deploy arbitrary artifacts to the repository, whether they be for end-users, or meta-data (e.g, maven's project.xml). Tools should ignore any artifact they don't understand. To ensure interoperability between language-based tools, best-practice guidelines need to be drawn up for each supported language and deployment scenario. Appendix ======== Changes from v0.1 ----------------- . repository-uri changed from: access-specifier "/" product-specifier "/" artifact-specifier to: access-specifier "/" product-specifier "/" version-specifier "/" artifact-specifier . product-specifier changed from: organisation "/" project "/" version to: organisation "/" project . organisation changed from: *pchar to: name_segments . project changed from: *pchar to: name_segment . version renamed to version-specifier, and is now opaque . artifact-specifier is now opaque
