Skip to end of metadata
Go to start of metadata

JIRA reference


Additional Thoughts

Basically a TODO list

Transient and Project docs in a single module project

How do we deal with the separation of transient (developer) information from project information in a single module (eg jakarta-commons-foo) scenario?

Perhaps in this case, there's no harm in including the development reports for a released version in the site, or we use a profile to turn them off when we deploy to the live site?

Separate deployment of snapshots

What about creating separate deployment locations for snapshot sites?

Could be done with a profile, but to align with <distributionManagement>
<snapshotRepository> maybe we should have <distributionManagement>

This would allow us to just drop the reports straight into the site like
we do now without worrying about the layout issues, and turn it on or
off depending on the deployment target. The snapshot one would be
continuously spat out from CI, and users could go to to see the site with reports intact
and totally up to date, while remains the last release

John Allen reports that this is currently what the site:stage goal is designed for and this should be reviewed before the 2.0 release. He also notes it would be worth supporting the snapshot site directly in the POM. This was always intended as the functionality was present in m1, but hasn't been incorporated yet. Using the standard snapshot + release notation for a site instead of stage/live is a good idea.

Report categorisation

Is there a way to designate reports that are for users and part of the site (mailing
list, scm, plugin reference) from development reports (junit,
cobertura, even javadoc)? Note that these have nothing to do with their rate of change. Mailing lists and SCMs should be part of the "current" site as if they move, that details needs to change and is not tied to a release. However plugin references are release bound, but still documentational, and are versioned, like Javadoc. Reports like junit are generally immediately published, but tied to a codebase rather than the site.

  • No labels

1 Comment

  1. In regards to sites I just wanted to re-iterate my dev@ posting regarding the lack of proper URL to POM UID namespace management in the URL inheritence and extension schemes used in site generation. I may have a latest version of a project and this may have a nice site but i need to be able to continue to access, and critically link to (from other projects), older versions of the same project. The 'latest' version can always be made accessible via some nice URL mapping e.g. ==

    For me a site is simply another 'view' onto a project's products and in the same way one can access different versions of those products based on specify the version one can not access the various different sites. Note this can be done by manually specifying the project.url and for every project such that the URLS include the group, artefact and versionId information but this is error prone and nasty.

    In a nutshell, for me a project site's is just another project artefact and therefore its identity and namespace should be managed in the same robust way the the other project products are (jars, pom, src-jars etc), i.e. stored in a unique federated namespace. 

    See MNG-2679