In parent site, automatically create link to modules sites and vice-versa

Added these requirements

had to stop the copying due to a bug

Patch reinstates modules support through use of reactor projects and the parsing of their distributionManagement site information.

My bad, missed bug for leaf nodes that resulted in empty modules menu. New patch has one line difference to previous patch, namely line 791 (in patched file) which changes from:-

if ( ( addModules && reactorProjects.size() > 1 )

to:-

if ( ( addModules && reactorProjects.size() > 1 && project.getModules().size() > 0 ) )

John, thanks a lot for your work!

Just one comment that I would want to clarify:
It appears that the last patch creates as well parent project links and module links.
But, the code uses project.getParent().getUrl() to find the path (if I don't miss something). So, we need to deploy on a web server all projects (before testing for instance).
IMHO, I think it could be best to copy all generated sites (I mean modules site) in the parent site. Thus, we could browse the site in off line mode.
WDYT?

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?

I am using this type of relative url link for all sub modules in staging, so it can work with parent site and it works

<url>../../<module-name>/target/site</url>

John, Thanks for all your work

John,

I liked your comments, and ideas, specially the "stage idea". Much appreciated.

To resolve the testing pb, I propose to define a new Mojo that will "simulate" a deployment.

SimulateDeployMojo should have a stagingDirectory as parameter.
SimulateDeployMojo could replace project.url by an hardcode url based on the stagingDirectory (I mean file schema)

Details :
Multiproject
distributionManagement.site.url=scp://myHost/www/myPath/multiproject/
stagingDirectory=C:\testingsite

Multiproject.framework1
distributionManagement.site.url=scp://myHost/www/myPath/framework1/

Multiproject.framework2
distributionManagement.site.url=scp://myOtherHost/www/myOtherPath/framework2/

If distributionManagement.site.url is never defined, try to use the project.url.

The Mojo will create the following structure and all links (parent project and modules) should be hardcode.
C:\testingsite

WDYT?

Hi Vincent,

Yeah i think this is a more approrpiate approach, especially as its only intended for testing.

So the key to the the simulate mode is that all projects referenced by the reactor env. will be expected to share a common URL root and this root will be set by a plugin config rather than try and use the main POM.

This would be great and would solve another problem i have with my CI based builds - In CI builds i still wnat to build the sites to allow project teams to access the latest SNAPSHOT javadocs, review code coverage etc without me having to deploy the site to the 'offical' location (a task I associate with a project deployment, not just CI builds)

I think we should also support the deployment of this 'simulated' site to a remote site which leads me to thinking that all this link URL business is pretty much dependent on where we're intending to deploy things to (staged or deployed/published location) so should we make the settings of these URLs something that the deploy operation does as a preparatory action?

site:site - generate site for deployment but create placeholders for links

site:stage - set parent and module links to file:// URLs based upon the project's distributionManagement.site details (i.e. exactly as you proposed) and then deploy the site to the location defined by the Mojo config (this supports us scp'ing the staged site to a remote host and implicitly supports the stagingDirectory you proposed)

site:deploy - set parent and module links to URLs defined the project's real URL details (i.e. as my patch currently assumes) and then deploy the sites as defined by their distributionManagement settings (which must be related to their project.URLs otherwise the POM writer has screwed up )

We're definately getting their :- WDYT ...

ps. in regards to naming, staging is a common term for review/testing of a web site. Do we want to just call this site:stage rather than simulate? I know to us its simulating the real site deployment but in terms of business process the user is staging it for testing or local review. Not gonna get religous over about it though

So, I created a SiteStageMojo (agree with the naming) with stagingDirectory and stagingSiteURL as parameters:

• stagingDirectory as discussed
• stagingSiteURL could be scp://www.mycompany.com/www/project/ (ie samething that the distributionManagement.site.url element)

I will put a new diff file with your proposal and a dummy project.

BTW, this issue could be related to MNG-983

diff file and dummy project

Vincent, the patch seems to be missing the new SiteStage mojo.

Repost with SiteStageMojo

Thanks Vincent, works a treat!

I'm using the staged site not only reviewing but also for internal pre-release publications (i.e. CI build generates an internally published site).

Applied. Thanks John!

Hi,

I've been trying to get the parent and child projects linked from the site.
Luckily you've already done all the work.
I did make a few small changes to default to the getModulesMenu() and getProjectParentMenu()
reporting output directory for if the parent\child urls are not set.
If you would like the changes I can upload a diff of the changes

Patrick

re the patch,

theres a bug in the SiteStageMojo::getStructure() method under windows.

Windows distribution paths can start with drive prefixes and thus we need to sanitize the ':' as its illegal in the newly generated compound path.

Dont have a patch as this is a patch on a patch with no revision to compare against but starting at line 157:-

Repository repository = new Repository( site.getId(), site.getUrl() );
if ( StringUtils.isEmpty( repository.getBasedir() ) )

// might need to sanitize a drive letter under windows (eg. D:)

String baseDir = repository.getBasedir();

if ( baseDir.charAt(1) == ':' )
{
StringBuffer buffer = new StringBuffer();
buffer.append( baseDir.charAt( 0 ) );

if ( baseDir.length() > 3 )

baseDir = buffer.toString() ;

System.out.println( "new baseDir = " + baseDir );
}

if ( baseDir.startsWith( "/" ) )

Additionall problem with new staging functionality and accessing uninterpolated parent project attributes.

project.getParent() returns a project that has not been 'cooked' and thus contains uninterpolated expressions (e.g. $

)

we need to use the reactor projects to find the parent as these have been properly processed.

John - please create a new issue for your staging site problems