[jira] Issue Comment Edited: (MNG-41) best practices: site management

["John Allen (JIRA)" <ji...@codehaus.org>]

    [ http://jira.codehaus.org/browse/MNG-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103358 ] 

John Allen edited comment on MNG-41 at 7/26/07 6:54 AM:
--------------------------------------------------------

I know I've been banging this drum from day one so I'm obviously off 'Maven message' in this regard but as far as i can see a maven site is just another type of artifact generated by a project. It has all the same aspects, couplings et al as the other products of a project and should not be seen as a convenient way to knock up your OSS web pages. 

Corporate use of a maven project site is to render the human readable view on the project's constructs (UML models, javadoc, analysis reports, and yes even user guides) and is thus directly coupled to the version that generated it. This then leads to POMs with project.urls and distro.site.urls like this:

{code}

		<site>
			<id>projects.examples.site.deployment</id>
			<name>Examples: Site Deployment</name>
			<url>
				dav:https://maven.example.com/maven/site/${scm.repositoryName}/${project.groupId}/${project.artifactId}/${project.version}
			</url>
		</site>
		<downloadUrl>${project.url}</downloadUrl>
	</distributionManagement>

	<url>
		http://projects.examples.com/${scm.repositoryName}/${project.groupId}/${project.artifactId}/${project.version}
	</url>

{code}

Thus all our deployed sites attempt to maintain the rigour of a true version controlled namespace. 

How we then map to the 'latest' of these is another point, and again, one I have written about before; currently we do this, in the absence of real repository, with server side scripting (aka PHP hack) as there is no real 'release' semantic and we can't really afford to go creating one at the moment.

Hope I'm not missing the point and slipping into rant mode (I'm in bed with flu!)

Re the staging - we don't currently do that in the same public way you have to. At the moment we simply 'export' the SNAPSHOTs and get internal peer review from those (version info is not lost on ours) and if we had to do release:prepare then i would have the distro locations to point to a real sandbox staging environment and get QA acceptance there before performing a real release. 


 was:
I know I've been banging this drum from day one so I'm obviously off 'Maven message' in this regard but as far as i can see a maven site is just another type of artifact generated by a project. It has all the same aspects, couplings et al as the other products of a project and should not be seen as a convenient way to knock up your OSS web pages. 

Corporate use of a maven project site is to render the human readable view on the project's constructs (UML models, javadoc, analysis reports, and yes even user guides) and is thus directly coupled to the version that generated it. This then leads to POMs with project.urls and distro.site.urls like this:

{code}

		<site>
			<id>projects.examples.site.deployment</id>
			<name>Examples: Site Deployment</name>
			<url>
				dav:https://maven.example.com/maven/site/${scm.repositoryName}/${project.groupId}/${project.artifactId}/${project.version}
			</url>
		</site>
		<downloadUrl>${project.url}</downloadUrl>
	</distributionManagement>

	<url>
		http://projects.examples.com/${scm.repositoryName}/${project.groupId}/${project.artifactId}/${project.version}
	</url>

{code}

Thus all our deployed sites attempt to maintain the rigour of a true version controlled namespace. 

How we then map to the 'latest' of these is another point, and again, one I have written about before; currently we do this, in the absence of real repository, with server side scripting (aka PHP hack) as there is no real 'release' semantic and we can't really afford to go creating one at the moment.

Hope I've not missing the point.

Re the staging - we don't currently do that in the same public way you have to. At the moment we simply 'export' the SNAPSHOTs and get internal peer review from those (version info is not lost on ours) and if we had to do release:prepare then i would have the distro locations to point to a real sandbox staging environment and get QA acceptance there before performing a real release. 

> best practices: site management
> -------------------------------
>
>                 Key: MNG-41
>                 URL: http://jira.codehaus.org/browse/MNG-41
>             Project: Maven 2
>          Issue Type: Task
>          Components: Design, Patterns & Best Practices
>            Reporter: Jason van Zyl
>            Priority: Trivial
>             Fix For: 2.1.x
>
>
> * How to deal with multiple versions of the site
> * How to deal with staging directories for the site (will require a change to the POM)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira