shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <>
Subject Re: Why generate a static maven site?
Date Wed, 26 May 2010 19:01:36 GMT
I would (hopefully) change it a bit the next time around.  Ant changed
his vote to +1, so we're still on for a release - I'd hate to have to
start over again if not absolutely mandatory.

As to the static site, I think generating it is still ok, but maybe we
just have symlinks to the reports that people care about.  We did this
on the old JSecurity website, and it worked really well.  That is:

/www/ (symlink) -->

Then our website navigation only points to the symlinks.  That way,
the static site never needs to be referenced anywhere - it is used
only as a report generation and hosting 'implementation detail'.

This does require the extra work of maintaining a download page like
we did previously (, but I think it
is well worth it - it is extremely easy for people to get the
information they care about, and the static site doesn't have to be
referenced again.

I just haven't set this up yet because we don't have an official
release yet.  Once that is (hopefully) approved, I wanted to add these



On Wed, May 26, 2010 at 11:42 AM, Kalle Korhonen
<> wrote:
> On Wed, May 26, 2010 at 11:08 AM, Alan D. Cabrera <> wrote:
>> Web site documentation evolves.  It should be decoupled, vote-wise, from our
>> release process of artifacts.
> Fundamentally, I don't care too much about it either way, but the
> point is that specifically the site artifacts (and it's less about
> documentation than the reports - dependencies, quality etc.) do not
> evolve since the reports are relevant for that specific revision of
> code only. Les asked me to configure the pom so that the the site can
> be archived so I did. The site can be seen as supporting documentation
> for the release and it may be easier to view the produced web pages
> rather than browse the raw pom file, especially for people not
> familiar with Maven. Since the site's not supposed to evolve and any
> desired change in the site would require changes in the pom and the
> tag, at least the given meta-data for that release should be correct
> and reviewed and thus subject to a vote, don't you think? Your
> statement that it should be decoupled contradicts with the process
> that Maven (the project) has put forth so I assume your statement is
> your opinion rather than Apache's official position on it. Is that
> correct? Finally, do you think we should vote on 1.0.0 again,
> excluding the site or just perhaps word the release vote email
> differently the next time around?
> Kalle
>> On May 26, 2010, at 11:05 AM, Kalle Korhonen wrote:
>>> On Wed, May 26, 2010 at 10:57 AM, Alan D. Cabrera <>
>>> wrote:
>>>> I think it was a mistake to generate it and include it in the release
>>>> vote.
>>>>  People will focus on this non-release artifact.
>>> Perhaps. But considering that the site will be versioned and archived,
>>> it's a secondary artifact of the release and deploying the site is
>>> according to the Apache/Maven release best practices. I don't mind if
>>> we need to make minor adjustments to the content to make everybody
>>> happy; I'd rather pay now than later. If nobody votes against, we can
>>> just gather the notes and fix the remaining issues in the next
>>> release.
>>> Kalle
>>>> On May 26, 2010, at 9:48 AM, Kalle Korhonen wrote:
>>>>> Additionally, the static sites will be versioned and archived unlike
>>>>> the wiki, where there's in principle just one version of it.
>>>>> Kalle
>>>>> On Wed, May 26, 2010 at 8:38 AM, Les Hazlewood <>
>>>>> wrote:
>>>>>> Yeah, its mainly just for the auto-generated reports - much easier
>>>>>> let Maven generate and upload the site automagically than us having
>>>>>> piecemeal it and do each one individually.
>>>>>> On Wed, May 26, 2010 at 7:46 AM, Kalle Korhonen
>>>>>> <> wrote:
>>>>>>> On Wed, May 26, 2010 at 7:06 AM, Alan D. Cabrera
>>>>>>> <>
>>>>>>> wrote:
>>>>>>>> Why do we generate a static maven site if we have a perfectly
>>>>>>>> one
>>>>>>>> driven by the wiki?
>>>>>>> For javadocs, info & quality reports and since it's simple.
>>>>>>> Kalle

View raw message