[ http://jira.codehaus.org/browse/MNG-661?page=comments#action_51763 ]
John Allen commented on MNG-661: -------------------------------- Vincent, youre right regarding the limitations of using the projects 'published' URL location for building backward and fwd refs, namely that they only work until the site(s) are deployed but I felt constrained to comply by the maven project model for what defines a projects 'home' and how it relates to its partent, child modules and its distribution management details. My observations:- * A project can (and therefore someone will) define its project URL to something that is not necessarily derived from its parent. I.e the hierarchical model which we tend to assume is not the only mode of operation in regards to where a site will live in repsect to its parent and modules. This is a key observation. * A project's parent is not necessarily defined in the directory above it. A parent project can come from anywhere. Therefore one can not rely upon realtive backward and fwd refs: the relationship of a project to their parent and modules in regards to URLs is not necessarily hierarchical and we can not therefore just make the links relative, ie. parent is not just be ../index.html and its modules is not just be ./module_name/index.html. But the requirement you quite rightly identify is that we want to 'stage' the site somwhere so it can be tested and reviewed, before real publication but those project links just wont work unless the URLs properly resolves and those are defined for production deployment. So how do we handle the preparation of test deployment of a site? Dont know ... At first I thought we could perform some kind of 'okay so youre running in test deployment mode to i will re-write all URLS such that I expect a parents to be above me and a module to be beneath me and i know everything is going to be based of the same root URL (ie. a file store root) but not even that works becuase although I may be a project 4 deep in a module structure I can have a parent that is in some completely unrelated location. So if you want a staged site deployment we will need a new project attribute that lets us discover a project's location in the staged environment, which we would expect to hold a more hierarchical layout to enable deployment to a local filesystem or test HTTP server for easy testing. Note this is basically just saying have another project::URL attribute but that we expect the developer to set it to something more useful and relatively structured so that it can be employed in stage testing. Details (please excuse the structure of this!) directory: /dirA artifact: projectA, parent: null, url: http://foo, stageUrl: file:///stagingLoc/, site: scp://foo directory /dirA/dirB artifact: projectB, parent: projectA, url:http://foo/projectB, stageUrl: [inherited], site: [inherited] directory /dirA/dirC artifact: projectC, parent: projectA, url: http://bar/projectC, stageUrl: [inherited], site: scp://bar/projectC directory /dirA/dirD artifact: projectD, parent: projectE, url: http://bar/projectD, stageUrl: [inherited], site: scp://bar/projectD directory /dirE artifact: projectE, parent: null, url: http://foo/projectE, stageUrl: [file:///stagingLoc/, site: scp://foo/projectE gets site:deployed to host: foo, directory: / host: foo, directory: /projectB host: bar, directory: /projectC host: bar, directory: /projectD host: foo, directory: /projectE gets site:staged to:- stagingLoc/projectA stagingLoc/projectA/projectB stagingLoc/projectA/projectC stagingLoc/projectA/projectD stagingLoc/projectE The generation of parent and module links for the stage mode will just use the project::stageURL. the links for deployment mode will use the project::URL. And i guess the new site:stage Mojo will rewrite the links to be stageURL links and then invoke the stage wagon location - we'll need a new site wagon setting as the distributionManagement::site and the project::URL are bound together in their meaning so if we create a new stageURL we well require a new distributionManagement::stageSite setting (which would be set to file::/someLoc in most cases). Phew! What a lot of words for something so simple! WDYT? Do you see the problem we have? > In parent site, automatically create link to modules sites and vice-versa > ------------------------------------------------------------------------- > > Key: MNG-661 > URL: http://jira.codehaus.org/browse/MNG-661 > Project: Maven 2 > Type: Improvement > Components: maven-site-plugin > Versions: 2.0-alpha-3 > Reporter: Yann Le Du > Assignee: Vincent Siveton > Priority: Minor > Fix For: 2.0.1 > Attachments: SiteMojoPatch.txt, SiteMojoPatch.txt, SiteMojoPatch.txt > > > Say we have the following project structure : > A > +-- B > +-- C > +-- D > It would be nice to have the following links in the left menu of the > generated sites : > A : > Modules : B, D > B : > Parent : A > Modules : C > C : > Parent : B > D : > Parent : A -- 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
