Very good question Lonut!

I think what you are asking for can only be done if you use some dynamic
properties/profiles or leverage the project version to generate a "this is a
branch" <project><url></...></....> (aka deployment path).

Sorry I'm about to go on an adhoc rant...

I know this is a rant, but here goes... It's important to note that a
<project>/release/version/branch has documentation (aka site). At some point
in time (install/release) the documentation (site) and the artifact abandon
each other. Why? To me this seems like a really really *strange* choice. A
much slimmer yet richer option would be to publish the site alongside the
artifact in the maven repository. This means the site-deploy config drops
back to the maven project/repository naming conventions (which might fix
your problem?). These naming conventions (paths) can be exploited to provide
html parent/modules/versions/dependency/plugins href's. It would also remove
the need for extra user configuration, because by default they have a local
repository to "host" this content (file://${user.home}/.m2/repository/) eta
eta eta. It would also mean that documentation is stored/cached locally, and
even better from an organizational level with archiva managing both doco and
artifacts. Note this means that providing archiva (or your local repo) has
the artifact in its repo, you can get a html href to all the dependency
documentation in your repository...

Other option is to build site war's, but that still seperates things and I
don't promote that idea too much.

Anyway I could go on, but I think this is a neat idea and probably
comparatively less work.



On Thu, Feb 14, 2008 at 11:21 PM, Ionut Scutaru <[EMAIL PROTECTED]>
wrote:

> Hi,
> Recently we needed to create a new branch for our code and we realized the
> documentation generated by maven with "mvn site:site" will drift apart in
> time. So we need to deploy both versions of the site (multiple versions
> for
> the future maybe ?)
>
> I was wondering if there are some best practices for this ..
>
> Thank you.
>

Reply via email to