geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: Builds in limbo during voting cycle
Date Sat, 16 Dec 2006 21:02:38 GMT
No, I believe that there will always be a time when builds are in  
limbo due to reliance on our projects artifacts being deployed to a  
remote repository... when they have not made it there yet.

IMO, the only way to avoid this limbo is to always build components  
from source, removing the remote repository from the equation.

This is also the only way to ensure that when working with SNAPSHOT  
artifacts, that you always use a known set, and don't accidentally  
get a new artifact midway through your build.


On Dec 16, 2006, at 10:35 AM, Dain Sundstrom wrote:

> This is because we have not been diligent in releasing sub projects  
> like Genesis, Specs, JavaMail and Geronimo schema.  If we had, then  
> then nothing would be in limbo at all.  In the future, I think we  
> should have the rule be no SNAPSHOTS to subprojects we control and  
> the exception to be SNAPSHOTS.   Not like we currently have it were  
> everything under G has a SNAPSHOT dependency.
> Basically, this shouldn't happen again.
> -dain
> On Dec 15, 2006, at 5:11 PM, Jason Dillon wrote:
>> Why is it that when we go through a voting cycle that builds are  
>> left in limbo?
>> For example, to build server 1.2 at the moment, users need to also  
>> know that they must build genesis 1.1 from its tag, openejb from  
>> its tag, and then a handful of specs, from each of their  
>> respective tags.  I don't even know which tag is actually needed  
>> for each of the damn specs, so I have to go hunt down what version  
>> is actually being used, then check out each tag one by one...
>> or I have to hack the pom to add the "staged" repos, which is  
>> equally worse has to build as tag I have to change its source?!?!   
>> and IMO that is just unacceptable.
>> I would much rather check out everything that is needed from the  
>> tag and build... though that brings me right back to this mess  
>> with per-module versioned specs.  Its a nightmare to find the  
>> right tags, check them out and build them.  The entire process  
>> would be dramatically easier if there was on tag for the specs to  
>> be checked out and built... and that is for manual or automated.
>> IMO these projects, and their branches should always be buildable,  
>> at any time, with out making changes to sources... and we need to  
>> be able to setup an automation process to help ensure that they  
>> always remain buildable.  It should be possible to setup an  
>> automated build for release branches/tags during the voting phase,  
>> and even more so, it should be possible to setup the automated  
>> system to actually handle cutting that release.
>> BUT... to get to that point with the tools which we have decided  
>> to use, we need to adhere to a few restrictions which simplify the  
>> entire matter... which I don't think that many of you have even  
>> thought about.
>> maybe the community does not want stable builds?  maybe the  
>> community does not want to have durable builds?  maybe the  
>> community does not want to have an automated system to ensure  
>> build consistency?
>> maybe I am just wasting my time?
>> --jason

View raw message