Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Trivial Trivial
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      0

      Description

      • 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)

        Activity

        Hide
        Brett Porter added a comment -

        I think I've got this filed away somewhere in m1.

        Basically, the key should be to separate documentation from site - where documentation is versioned and distributed, and the site is not (the documentation is likely still rendered HTML, however).

        Either might also link to another version of the doco - to the extent of "this version" and "latest".

        Also, developer documentation should be segregated from user documentation. I believe this should be acheived by defining arbitrary categories for site content so that reports can also be filed under those categories (allowing design docs, javadoc and clover to go to the dev doco, but user guides, project info and faqs , etc to go to the user section).

        Show
        Brett Porter added a comment - I think I've got this filed away somewhere in m1. Basically, the key should be to separate documentation from site - where documentation is versioned and distributed, and the site is not (the documentation is likely still rendered HTML, however). Either might also link to another version of the doco - to the extent of "this version" and "latest". Also, developer documentation should be segregated from user documentation. I believe this should be acheived by defining arbitrary categories for site content so that reports can also be filed under those categories (allowing design docs, javadoc and clover to go to the dev doco, but user guides, project info and faqs , etc to go to the user section).
        Hide
        John Allen added a comment - - edited

        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:

        
        		<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>
        
        

        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.

        Show
        John Allen added a comment - - edited 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: <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> 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.
        Show
        Vincent Siveton added a comment - From dev@ http://www.nabble.com/Publishing-Plugin-Sites-(was:-Re:-Plugins-sandbox-site)-td13044546s177.html

          People

          • Assignee:
            Unassigned
            Reporter:
            Jason van Zyl
          • Votes:
            4 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated: