(Sorry if this results in a re-send, dodgy connection) I have contributed to a number of threads in the past regarding the fact that maven site's are just another set of meta-data or, if you will, a view upon an artifact and therefore the site for a specific version of an artifact must remain valid for as long as that artifact is in existence (i.e. forever for published artifacts) and must therefore co-exist with it's 'version' peers. Put another way, If i want the javadoc for some version of some artifact, i want THAT version of the javadoc, not the latest one. @dev tend tos see 'Maven site' as a way of producing your main web site, this is not what most organisations or useful repositories should do, instead you need to let users access the 'historical' site for the version of the artifact that they're interested in.
An artificat has many versions yet only has one site - which is plainly wrong. This is manifest in many areas of maven, especially evident in the default mechanisms employed for generating artifact site URLs (which are simply based upon the artifacts folder name/artifact id (cant remember which)). To work around this limiting assumption we have to specify in every POM the following: project.url=http://artifacts.example.com/{project.groupId}/{project.artifactId}/${versionId} and distributionManagement.site.url=webdav:http://artifacts.example.com/upload/{project.groupId}/{project.artifactId}/${versionId} Note this must be specified in EVERY pom, and not just a base pom, to prevent the base pom's ${properties} being used instead of the child (leaf) pom's values. Bottom line - Maven should honour an artifact's unique identity in all its guises, including its site content. i.e. the site URL address space should be handled in the same robust way that the repository artifact address space is managed. In terms of finding the 'latest' version of an artifact via the web we provide two techniques: Apache redirects (currently via a explicit redirect rule in httpd.conf land but could easily be made more intelligent and automatic) http://artifacts.example.com/{project.groupId}/{project.artifactId}/LATEST to the artifact's latest site and http://artifacts.example.com/{project.groupId}/{project.artifactId}/SNAPSHOT to the artifacts SNAPSHOT site (we don't support more than one SNAPSHOT version, we presume serial version progression). We also provide a link on every artifact's site, in the right hand side links area, to the latest version of that artifact (via the Apache technique described above). We also provide, via a custom report mojo, an external report called ancestry, that, in its current guise, uses a simple bit of PHP that does a live list of versions available. This obviously could be improved but you get the idea. So here's another appeal from me, please consider an artifact's site part of its state and thus unique in terms of group, artifact and version by default and no longer assume that an artifact, possessing of many versions, only has one site. it doesn't, it has one site per version. -John Wendy Smoak-3 wrote: > > On 4/21/07, Brett Porter <[EMAIL PROTECTED]> wrote: > >> Now that, theoretically, the plugins are all documented up to their >> current release and improvements in docs can wait until the next >> release, this sounds fine to me. > > -- > Wendy > > -- View this message in context: http://www.nabble.com/Publishing-plugin-docs-tf3621488s177.html#a10356515 Sent from the Maven Developers mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
