On 14/04/2010, Phil Steitz <phil.ste...@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-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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
