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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
