[jira] Commented: (MSITE-426) Site-structure and links messed up when using inheritance and sub-sub-modules

["Lukas Theussl (JIRA)" <ji...@codehaus.org>]

    [ http://jira.codehaus.org/browse/MSITE-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=251896#action_251896 ] 

Lukas Theussl commented on MSITE-426:
-------------------------------------

Which version of the site plugin are you using? Already with 2.2 I cannot reproduce some of the problems you mention. Please also try 2.3-SNAPSHOT and report back any specific issues.

> Site-structure and links messed up when using inheritance and sub-sub-modules
> -----------------------------------------------------------------------------
>
>                 Key: MSITE-426
>                 URL: http://jira.codehaus.org/browse/MSITE-426
>             Project: Maven 2.x and 3.x Site Plugin
>          Issue Type: Bug
>          Components: inheritance
>         Environment: WindowsXP, Solaris 2.8, SLES10, Maven 2.2.0, JDK 1.6
>            Reporter: Michael Wenig
>             Fix For: 2.3
>
>         Attachments: 1.zip, 2.zip, 3.zip, demo1.zip, demo2.zip, demo3.zip
>
>
> We have a structure like this:
> pom.xml (A) (inherits from a companies-pom and acts primary as a generated multi-module-pom which should not be in need to be changed by developers)
>  + ModuleContainer
>       + pom.xml (B)
>  + Module1 (which inherits from upper-pom)
>       + pom.xml (C)
>  + Module2 (which inherits from ProjectSuperPom)
>       + pom.xml (D)
>  + Module3
>       + pom.xml (E)
> pom A is intended to get generated and not changed by project team (includes the basic settings for issue management and so on). It is a multimodule and includes exactly one module (ModuleContainer)
> pom B is primarly intended to define the modules of the project and is intended to be changed by the project team. It could also act as a SuperPom of the project or delegate this to a separate module
> pom C, D, and E are 'normal' modules which use as parent the ModuleContainer-Pom, a separate SuperPom or the pom A
> I made several tests, changed the inheritance, module definitions but did never achieved a site which was working (after deploying the site!).
> I achieved that the sites are stored in a sensable structure but needed to add a distributionManagement to each pom which is error-prone.
> But I did not achieve that the links are ok - the are everytime extrapolated in some strange way. The should be read out of the pom 
> (or parent-pom and calculated the normal maven-way) of the module and perhaps extrapolated when there ist none (but then a configurable pattern
> would be better).
> I attached three samples together with the created sites (windows, JDK 1.6, Maven 2.2.0).
> demo1:
> The physical structure does not make sense in this case as the inheritance-parent-poms name AND the module artifact name is used as a suffix for the directory
> and has no benefit there
> demo2:
> I added a distributionManagement and url to all poms
> now the physical structure is ok
> The following problems:
> The rootPoms-site contains two links (which are syntactically correct and working):
>  - to modules (ok)
>  - to projectPom 
> I either expect only a link to modules (as this is the only direct module of rootPom) or a link
> to all modules including the submodules of rootPom. It seems that the module list is build up out of the modules and the direct inherited projects
> (as rootPom is the parent-pom of projectPom) - this makes IMHO no sense!
> Neither the site of the modules nor of projectPom contains any links to the other modules.
> I would expect a list of projectPom, module1, module2
> demo3:
> I removed the double-multimodule and included all modules in the RootPom but keeping the extra projectPom
> Problems:
> - Only The projectPom is linked from RootPom
> - the structure of the different sites is different:
> demo3\Module1\0.0.1-SNAPSHOT (ok)
> demo3\projectPom\0.0.1-SNAPSHOT (ok)
> demo3\RootPom\0.0.1-SNAPSHOT (ok)
> demo3\Module2\0.0.1-SNAPSHOT\Module2 (becaus of missing distributionManagement which makes no sense)
> The physical structure should be that of demo2 even if the distributionManagement is missing in the sub-poms (it is error-prone to have it in every one).
> There should be a configuration-switch to deactivate ANY magic in building the structure and use a pattern instead.
> e.G. in a companies-pom which is a superpom of all projects and modules (direct or indirect):
> 	<url>file:///tmp/mvn-sites/${groupId}/${artifactId}/${version}</url>
> 	<distributionManagement>
> 		<site>
> 			<id>mysites</id>
> 			<url>file:///tmp/mvn-sites/${groupId}/${artifactId}/${version}</url>
> 			<name>nada</name>
> 			<strict>true</strict> <!-- deactivates the auto-suffix and always use this one -->
> 			<hierarchically>true</hierarchically> <!-- leads to com/mycompany/demo instead of com.mycompany.demo -->
> 		</site>
> 	</distributionManagement>
> and no need for any distributionManagement or url in the other poms. Therefore the pom of the module has to be analyzed if there is a url coming out.
> If not the 'old way' could be used
> and for every link the RESULTING url of the destination should be used.

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