Woops - see small correction in line.

Stephen McConnell wrote:

Tim Anderson wrote:

By implication - the README is not an artifact but a feature of a version.
Is that a reasonable conclusion?

Why make the distinction? I view everything a project deploys as an
artifact. Some artifacts will only be useful to end users (e.g, README, LICENSE.txt etc), others will be useful to tools.

Because there is difference between aggregation of files of a partiular type as distinct from files that describe a particular typed file instance. I view the "artifact" as the principal file held in a directory qualifed by a type (e.g. the jar file in a jars directory), and that other resources such as READMEs, LICENSEs, MD5s, etc. are examples of data that describe features of specific things such as a group, version, artifact, etc.

Why make the distinction? When I look at the available artifacts in a /jars/ directory I will present these as an list of artifacts. A user may select to view the properties/features of one of these items. Using the name of an artifact - I can locate additional information about the artifact such as the MD5 signature, maybe the license or some dependency information - providing there is a convention that is predictable. I.e. I need a mechanism to locate information about a particular artifact - e.g.

I left out the all important principal artifact.

<artifact-path>.<type> <--------- the principal artifact (e.g. jars/fred.jar)
<artifact-path>.<something> <------ some metadata
<artifact-path>.<something-else> <-- more meta data
<artifact-path>.MD5 <--------------- artifact signature
<artifact-path>.README <------------ readme about the artifact

The important thing is the recognition of the difference between a file that *is* the artifact as distinct from a file that *describes* an artifact.






Stephen J. McConnell

Reply via email to