Mailing-List: contact continuum-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: continuum-dev@maven.apache.org
Received-SPF: pass (athena.apache.org: domain of rahul.thakur.xdev2@gmail.com
 designates 209.85.146.177 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:from;
        b=RE6fNHEC7Ablko+cwkiOnGVjqTOBVRIMEYVrED/lpoU8IdC0P9WDbOaKYL0uErpg7E2bQomMhDvO9m7js/NQdujR/IGDz9yGo7rducvA7rfNWPWCTBEKSLcq8DD40vIddq3l7uID2mpgx12lfaH69GO59XcCAJqQKCvLpPz+8CQ=
Message-ID: <47025327.9020101@apache.org>
Date: Tue, 02 Oct 2007 19:48:15 +0530
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: continuum-dev@maven.apache.org
Subject: Re: CONTINUUM-310 - customizable email templates
References: <fc59deef0710010436p1e41dd97u1df37a538f8bb33@mail.gmail.com>
	 <4701A711.8050007@apache.org>
 <4701EEC1.3070401@venisse.net>	 <fc59deef0710020431h36911fbewcc7f1cc49c13469f@mail.gmail.com>
	 <47023338.2080008@venisse.net> <47024D10.8050002@apache.org>
 <a43524d00710020704j526b99d7vf60005ee644b8ec8@mail.gmail.com>
In-Reply-To: <a43524d00710020704j526b99d7vf60005ee644b8ec8@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: Rahul Thakur <rahul.thakur.xdev2@gmail.com>


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 <rahul.thakur.xdev2@gmail.com> 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
>>>
>>>
>>>       
>>     
>
>
>