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.
- 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:-
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?