You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2010/04/14 03:26:24 UTC
[DOC] Generating release notes from changes.xml
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.
Is that the best place for it?
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.
[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
Re: [DOC] Generating release notes from changes.xml
Posted by sebb <se...@gmail.com>.
On 14/04/2010, Dennis Lundberg <de...@apache.org> wrote:
> 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.
>
Thanks.
Is this the approach you took?
http://www.sonatype.com/people/2008/04/how-to-share-resources-across-projects-in-maven/
Or some other (perhaps simpler!) method?
> >
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DOC] Generating release notes from changes.xml
Posted by Dennis Lundberg <de...@apache.org>.
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
Re: [DOC] Generating release notes from changes.xml
Posted by sebb <se...@gmail.com>.
On 14/04/2010, Phil Steitz <ph...@gmail.com> 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.
Sorry, bad explanation on my part - the *compress pom* assumes it is
in src/changes, which it specifies using:
<templateDirectory>src/changes</templateDirectory>
>
> > 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.
The template currently supports limited formatting of the description
via multiple spaces.
But in the long term, hopefully the changes plugin will allow markup directly.
> On the release announcements, I will personally continue to
> hand-craft those; but have no objection to maintaining a boilerplate .
Just to be clear: I'm not proposing to change the generation of announcements.
Using a profile means that the default announcement template is unaffected.
> >
> > 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?
I don't think so - the properties are name and directory only.
> 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.
On the other hand if the template ever needs updating, it will be a
right pain if it is duplicated all over the place.
Besides, the release-notes can still be generated by hand; also it is
generally only the RM who will need to deal with it. The requirements
can be documented in the profile.
But maybe there is a better solution that addresses both our concerns.
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DOC] Generating release notes from changes.xml
Posted by Phil Steitz <ph...@gmail.com>.
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.
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