[gatein-dev] Build Failure !!!

[Julien Viet]

also it would be cool to be able to detect conflicting dependencies.

On Oct 9, 2009, at 7:35 AM, Julien Viet wrote:

>
> On Oct 9, 2009, at 2:32 AM, Dimitri BAELI wrote:
>
>> Hello,
>>
>>    Last commit broke the build. And will probably block the night  
>> team in VN :-)
>>
>> http://builder.exoplatform.org/hudson/view/All/job/gatein-portal-trunk/97/console
>
> it is a snapshot issue. Chris has taken the initiative to do a minor  
> refactor of the portlet container (moving the  
> LOCAL_PORTLET_INVOKER_ID constant from one class to another) that is  
> not yet visible to the world depending on it.
>
> I see two issues here:
>
> 1/ modifying an API used by a consumer (outlined by  
> org.gatein.pc.api package name)
>
> 2/ the usual issue of using snapshots with a random life cycle  
> driven by trunk development
>> /home/hudson/hudson/jobs/gatein-portal-trunk/workspace/gatein/ 
>> portal/trunk/component/pc/src/main/java/org/exoplatform/portal/pc/ 
>> ExoKernelIntegration.java:[133,61] cannot find symbol
>> symbol  : variable LOCAL_PORTLET_INVOKER_ID
>>
>>
>> location: interface org.gatein.pc.api.PortletInvoker
>>
>> Questions:
>>    How should we behave in such case ?
>>    Can we rollback the commit if the responsible is not present for  
>> few hours ? Or let it be and update to the last known stable state.
>
> we do not have a general policy for that.
>
> but in this case it is related to the policy I want to put in place  
> for using branches along with snapshots.
>
>>
>> Experimentation:
>>    I'll send the build notifications (only failures and back to  
>> normal state) to the gatein-dev list. Tell me if that's not  
>> acceptable also.
>>    Is there another target ML for that ?
>>
>
> sounds acceptable given the policy.
>
> I would add also that using a snapshot in the dependencies of a  
> project should also send some kind of warn.
>
>> The notification rules:
>> Every failed build triggers a new e-mail.
>> A successful build after a failed (or unstable) build triggers a  
>> new e-mail, indicating that a crisis is over.
>> An unstable build after a successful build triggers a new e-mail,  
>> indicating that there's a regression.
>> Unless configured, every unstable build triggers a new e-mail,  
>> indicating that regression is still there.
>>
>>
>> Dimitri BAELI - eXo Platform SAS
>> _______________________________________________
>> gatein-dev mailing list
>> gatein-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/gatein-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/gatein-dev/attachments/20091009/f7a8979c/attachment-0001.html