Message-ID: <636503233.300152.1369033152254.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_300151_1614196312.1369033152254" ------=_Part_300151_1614196312.1369033152254 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Basically a TODO list
How do we deal with the separation of transient (developer) information = from project information in a single module (eg jakarta-commons-foo) scenar= io?
Perhaps in this case, there's no harm in including the development repor= ts for a released version in the site, or we use a profile to turn them off= when we deploy to the live site?
What about creating separate deployment locations for snapshot sites?
Could be done with a profile, but to align with <distributionManageme=
<snapshotRepository> maybe we should have <distributionManagement&= gt;
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 http://maven.apache.org/2.1-SNAPSHOT to see the site wit= h reports intact
and totally up to date, while maven.apache.org remains the last release
John Allen reports that this is currently what the site:stage goal is de= signed for and this should be reviewed before the 2.0 release. He also note= s 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 sit= e instead of stage/live is a good idea.
Is there a way to designate reports that are for users and part of the s=
list, scm, plugin reference) from development reports (junit,
cobertura, even javadoc)? Note that these have nothing to do with their rat= e of change. Mailing lists and SCMs should be part of the "current&quo= t; 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 documentat= ional, and are versioned, like Javadoc. Reports like junit are generally im= mediately published, but tied to a codebase rather than the site.