Message-ID: <1084041633.779810.1386343759900.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_779809_375334296.1386343759899" ------=_Part_779809_375334296.1386343759899 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Currently we have a number of small metadata files:=20
RELEASE.version.txt(detemines the latest release of the a= rtifact)
SNAPSHOT.version.txt(determines the timestamp/build# of t= he latest build of the artifact)
LATEST.version.txt(determines the latest build of the art= ifact, whether it be a timestamp or a release)
plugins.xml(maps plugin prefixes to artifact Id within th= e group)
With the advent of version ranges, this will require use to get a list o= f versions for an artifact also. This has gotten to "critical mass&quo= t; of metadata that we should move to handling general directory metadata.<= /p>=20
We can safely remove reading of plugins.xml now since there hasn't been = a release cut that uses it, and there are not significant amounts to conver= t in the repo. We should continue to read the others, but deprecate it. The= y only need to be looked for if the repository metadata file is missing.=20
Metadata will be stored at the directory level, allowing different metad=
ata for each granularity. The file will be called
/code>. Note that the format is the same for each directory, though it is e=
xpected that only a subset will be used for each. This is in preference to =
having 3 different metadata formats.
As changes made locally may need to be merged with the remote version, t=
hey will be stored in
maven-metadata-local.xml alongside the o=
ther file which is downloaded from the remote repository (when newer).
maven-metadata-local.xml will be merged with
tadata.xml with the local changes being considered newer regardless =
of time. If this later becomes an issue we can timestamp each entry.
This means that multiple local changes can be made, but when it comes to= deploy one, all that is needed is:=20
maven-metadata.xmlis up to date
For removals, they should be removed from
maven-metadata.xml directly in the local repository. This will not be overwritten until the =
remote file changes so is persistent long enough and avoids having to have =
"deleted" semantics in
Due to the fact that each remote repository will have a subset of the da=
ta, when the metadata is stored locally, the filename will include the =
repository key. Currently, the
id used to access the repo=
sitory will serve as the repository key, but in the future a repository wil=
l be created by an admin program and metadata stored at its root which give=
s it a repository key, canonical URL and other such metadata.
For example, a directory in the local repository may look like:
id will be that of the source repository, so is not cha=
nged for mirrors (as mirrors are considered to be identical). This does mea=
n that files may be doubled up if your download id and upload id differ (a =
problem that will also be resolved by keys). This is not harmful.
When looking for metadata from a given repository, only the file for tha= t repository (plugin -local merged in) will be consulted.=20
We will need to get a process running over the repository that monitors = its health. We should be able to reuse repoclean in an "m2 reporting m= ode" to do this. It can check for md5s, sha1s and create and/or warn i= f they are missing, check if the metadata matches the directory, and so on.==20
This will be a later feature to add. It could be part of the repo manage= ment application so that errors can be shown and rectified via the web inte= rface.