[
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
