Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4BC60036.20202@apache.org>
Date: Wed, 14 Apr 2010 19:49:42 +0200
From: Dennis Lundberg <dennisl@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [DOC] Generating release notes from changes.xml
References: <n2g25aac9fc1004131826pf9938903z7b6f3b8d3564c3dd@mail.gmail.com>
 <4BC5229B.9060206@gmail.com>
In-Reply-To: <4BC5229B.9060206@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 2010-04-14 04:04, Phil Steitz wrote:
> sebb wrote:
>> It is useful to be able to generate both the announce message and
>> release notes from changes.xml.
>>
>> One way to do this is as currently implemented in Compress: add a
>> profile "relnotes" which overrides the changes template with the
>> release-notes.vm template.
>>
>> One can then do:
>>
>> mvn changes:announcement-generate  # => announcement.vm
>> mvn changes:announcement-generate  -Prelnotes # => release-notes.vm
>>
>> The template is assumed to be in src/changes, but it would be better
>> if a shared template could be used, for example in commons-site.
>>
> Have you tested moving it around? IIRC, I tried to move it but the
> plugin seemed to be hardcoded to start its path in
> src/site/resources.  Could be I missed something or this has been
> fixed since I last tried.
> 
>> Is that the best place for it?
> 
> I guess the release notes could - almost - be generically generated
> this way.  I always end up post-editing, but other than formatting,
> I guess it can all be standardized.
> 
> On the release announcements, I will personally continue to
> hand-craft those; but have no objection to maintaining a boilerplate .
>>
>> BTW, in order to allow for different workspace layouts, the template
>> directory should be expressed as a property, which users can override
>> in their settings.xml if they need to.
> 
> 
>>
>> To minimise the need for overrides, the default value for this
>> property should reflect a popular workspace layout. In my case
>> commons-compress and commons-parent etc are all at the same level, but
>> perhaps it is more usual to use some other layout.
>>
> This seems ugly. I guess there is no way to specify the file using a
> URL?  Back in the m1 days, we used to all have to have commons-build
> checked out in the right location for site builds to work and that
> was a PITA.  If the choice is between fiddling with settings.xml
> and/or other local workspace requirements and just duplicating the
> velocity templates, I would opt to duplicate the templates for those
> who wish to use them.  The less mysterious,
> not-in-the-component-checkout stuff we have to deal with, the better.

It is possible to have one or more templates in a separate
resources-module with its own release cycle. Any component that wishes
to use the template can add a dependency on the resources-module and
thereby get access to the templates in it. We have this set up at my day
job. Let me know if you want me to set it up for Commons.

> 
> Phil
> 
> 
>> [The idea would be to add the profile to the next release of commons-parent]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 


-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org