John Tolentino wrote:
[snip]
Right. I personally don't like raw maven output on such a page - the
docck report plugin
should just generate a normal report page, preferrably embed it in
this page.
I'll see what I can do on translating docck return values into a
suitable report.
Ok cool.
What's the 'download link' for? I can see how that's useful for
assembly releases,
like maven-2.0.x-bin.tar.gz, but for plugins/other loose artifacts,
would it point
to the jar in the repository? Is that useful?
When asking for a vote, we're expected to supply binaries of the
release candidate. This URL would point to that staging site.
Ah right. Should 'Download url' possibly be renamed to something like 'Release
site',
since it doesn't point to a binary or a page where you can ONLY download
the binary, but provides a complete mvn site?
[snip]
Another thought about the docck report: should we list that on the
page at all?
I think that, and the license header stuff are just plugins that fail
the build if
the project is not compliant. So we should assume that when those
plugins are enabled/used,
the project satisfies the requirements. A link to the project
(staging)site which already
contains all the reports should be enough, right?
We've created standards on documenting plugins. I think it would be
good for people to know that effort is being made to keep to those
standards. Would also make developers mindful that we should help on
the documentation of our work as well. Other than the plugins, it's
not required, but i know would really be appreciated by its users.
The parent pom for all plugins should include that report then. Isn't that
enough?
On the license, aren't this required by apache since October--or
earlier if my memory has failed me? Again, optional for other
projects.
Yup, true, but again, a plugin declaration in the root apache/maven pom
should take care of this.
Though I see what you're doing here - you prove compliance to all demands
set by apache for a binary release on one page. Perhaps a simple list
of demands with OK/FAIL behind them, where the elements in the list point
to the report itself, is sufficient?
for instance:
<ul>
<li><a href="docck-report.html">Documentation standards</a>: OK</li>
...
</ul>
We could make it an expandable section as well to keep things simple
and users interested in the detailed report could click on it for
viewing.
See above.
Also - when the release is made, will this page be available on the
project site somewhere?
So people can see the project history, examine changelogs, etc.
I think it would be handy for people to know what fixes/new features
are included. Can be added in the Project Reports section.
Cool.
versions on mvn sites still need some discussion; for instance a menu section
with 'previous versions', 'latest snapshot' etc. that point to complete sites
for other versions would be nice; all sites would have a version in their
directory too,
and a 'current' symlink or redirect page pointing to the latest non-snapshot
release.
But this should be discussed on a separate thread. (there was a thread about
this a
while back but nothing came out of it IIRC).
Thanks,
Kenney
-- Kenney
>
> Jason.
>
>> Thanks,
>> John
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
