parent filesystem site.xml is never be found

It's actually a fault with the way the path is built when trying to location a parent's site_en.xml or site.xml via the passed in basedir. I expect MSITE-81 fault is actually the fault described here.

John, do you think we could use the relativePath that you calculate at the top in conjunction with project.getBasedir() in cases where the given basedir points to the wrong location? This would effectively reorient that siteDirectory to the proper basedir with the proper relative path.

I only ask because it looks like you started down this road (in the patch), but then there's a comment about assuming a standard location...I'd like to take advantage of any lessons you learned when making this patch.

I'm not sure I exactly follow you John, I've had a look at the patch and the opening line in it is to remove the existing relativePath logic altogether:

-        String relativePath = getRelativePath( siteDirectory.getAbsolutePath(), basedir.getAbsolutePath() );

When i think about this method I see a very simple purpose, namely to try and find a site+locale+xml file for the passed in project, and if a locale specific one can not be found, to assume that a default site.xml will exist. Clients of the method obviously know that the returned File object may or may not exist so it's not necessary for this methods to check for that.

Ideally we would pass in the MavenProject object we're interrogating here rather than it's basedir as this would provide more opportunities in the future to try and find the real site directory for the operand project, however as that is not a model parameter and is instead a configuration parameter of the site plugin itself, we would need a way of looking at the configuration settings of the site plugin for the passed in project and I don't think we have a ppropriate way of doing this at the moment.

This method, as you know, is used for two things. One, to get this project's site.xml (prefering a locale based one) and secondly to try and find other project's site.xml files as the client code tries to peek up the project inheritance hierarchy. Neither of these uses cases seem to warrant a relative path approach, after all there is no need to use a relative path when we have explicit paths to work with and, once we find the file, (or not as the case maybe) we instantiate a File object from it, so we loose any interest in whether the File object's location (i.e. the site.xml filename and path) was found via a relative path approach or not.

The method does have one concession to supporting a site.xml file that is being stored in a 'non default' location but that only comes when looking for 'this' project's site.xml file as we have access to this project's site plugin configuration.

We could take a stance that when trying to find any project's site xml file we assume it will use the same site directory location that this project is using:

protected File getSiteDescriptorFile( File basedir, Locale locale )
 {
        String sitePath;

        if ( basedir.equals( project.getBasedir() ))
        {
            // it's this project's basedir so use our siteDirectory 
            
            sitePath = siteDirectory.getAbsolutePath();
        }
        else
        {
            // it's not this project's basedir so it must be one of our parent's
            // so lets assume they store their site.xml in the same location relative
            // to their basedir as we do

           String ourRelativeSiteDirectory = siteDirectory.getAbsolutePath().substring(
                        0, project.getBasedir().getAbsolutePath().length() );
                
           sitePath = basedir.getAbsolutePath() + "/" + ourRelativeSiteDirectory;
        }          
        
        File siteDescriptor = new File( sitePath, "site_" + locale.getLanguage() + ".xml" );

        if ( !siteDescriptor.exists() )
        {
            siteDescriptor = new File( sitePath, "site.xml" );
        }

        return siteDescriptor;

Thus if this project stores its site files in ${basedir}/src/foo then we will try and find all site.xml files in the directory src/foo. In fact we could go a step further and try that first and if we fail then fall back to trying the standard default location of src/site.

Don't know if I've helped here

ps. The code block above was written in JIRA and has not been tested, its just for illustration

I believe this has been fixed with MSHARED-18.