We can't move all in the db because schema updates can be a pain.
In 1.2 all the conf, actually written in application.xml, will be move to an external file. This file will can be stored in ${user.home} so each installs will can use it like it is done in
archiva-configuration.
Emmanuel
Rahul Thakur a écrit :
I haven't seen pebble config...
I was thinking what if you move database between Continuum installs?
Since your template resides outside the db, it won't be portable.
Jesse McConnell wrote:
I rather like the configuration of pebble where some of the
configuration is
just putting in classnames and the same could easily be done with the vm
template resource location, source from some configuration and then if
resource isn't found just use the default like emm was saying...
jesse
On 10/2/07, Rahul Thakur <[EMAIL PROTECTED]> wrote:
I agree with Emmanuel; extracting templates from core jar is not a
solution.
So far from this thread it seems there are quite a few things we could
do for the email template customization feature. IMO, We need to
brainstorm what might make best sense.
Do we allow custom email templates for:
1) each Build Definition?
2) each mail notifier defined?
3) each Project/Project Group?
and,
4) What is the order of precedence if there were custom templates
defined at different levels?
IMO, I think we should persist the notifiers in the database itself in a
separate field.
WDYT?
Rahul
Emmanuel Venisse wrote:
Tomislav Stojcevich a écrit :
I think it should be re-opened since there still is no way to
completely customize the template itself other than turning on and off
the output and summary. In my case the turning on the summary wiith
the build output turned off will give me what I want but it is still
too much. I'd like to be able to customize further, there are only a
couple of things from the summary that I want to see. We could
continue to add flags to the xml file and if checks within the
template but where does it stop?
And what about internationalization? that would have to be a separate
issue but allowing access to be able to modify the templates directly
would at least let those users that really need to change the language
of the text that is hardcoded in the template to be able to do it
should they need to.
So how about my idea about extracting the templates from the core jar
into the webapp during the webapp build, that way they can be directly
modified? This at least allows the default templates to be
customizable easily.
I don't think it's the best solution. IMO, it would be better to allow
the user to choose the template he want to use if he don't want the
default.
Another issue should be opened to provide the functionality that Rahul
is suggesting about allowing different templates per group or project.
That would involve more changes. There would have to be a place in
the database to store template location per project or group or
possibly store the template itself and provide a template edit screen.
If we allow to have a template per group or project, in fact per mail
notifier, it's easy to add this feature if the one above is
implemented. We can store it in the mail notifier configuration field
so we don't need to change the db schema for it.
Emmanuel
