Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (hermes.apache.org: domain of
 gcjgd-geronimo-dev2@m.gmane.org designates 80.91.229.2 as permitted sender)
To: dev@geronimo.apache.org
From: Peter Nabbefeld <Peter.Nabbefeld@gmx.de>
Subject: Re: nightly builds -- another perspective
Date: Sat, 23 Apr 2005 09:49:56 +0200
Lines: 90
Message-ID: <d4ctua$8ja$1@sea.gmane.org>
References: <dadb1ce57ad377b5c72fb9d1c1ae1b1c@yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT;
 rv:1.7.3) Gecko/20040910
In-Reply-To: <dadb1ce57ad377b5c72fb9d1c1ae1b1c@yahoo.com>
Sender: news <news@sea.gmane.org>


If there are no "stable" or up-to-date "milestone" builds, nightly 
builds are just more convinient than building everything oneself:

- No further mail traffic is needed, if not every dependency is 
correctly fullfilled, so developers can better focus on hacking;

- Developers can see, if the current source is compilable or broken by a 
commit;

- Users are able to give feedback at an earlier time, so bugs and 
additional requirements will be easier to implement.

Kind regards

Peter Nabbefeld


David Jencks schrieb:
> I apologize for not contributing to this discussion earlier.
> 
> I don't have a clear idea of the goals of a nightly build:
> 
>  From the users perspective,
> To be able to run geronimo, all you need is the assembly jar.
> 
> To be able to build geronimo by itself, you need there to be up to date 
> tranql and openejb jars in a remote repository.
> 
>  From this point of view, running maven multiproject:deploy in several 
> places is sufficient.
> 
> If people want some other artifact as a result of a nightly build, I 
> would like to know what it is and what use it provides.
> 
> 
>  From the developers perspective, I believe one goal is to verify that 
> the "entire project" builds "cleanly" with "no inappropriate dependencies"
> 
> entire project == geronimo, tranql, tranql-connector, openejb
> 
> cleanly == offline, with no artifacts that will be built in the local 
> repository, and attempts to build each module/project only once.
> 
> no inappropriate dependencies == modules/(maven) projects can be built 
> in groups from the same project, in order.
> 
> Let me expand on that.   Currently the only way to build everything once 
> is to use maven m:rebuild.  This takes geronimo, tranql, 
> tranql-connector, and openejb, puts all the subprojects in a pile, and 
> lets maven figure out an order to build them in.  As we have discovered, 
> this lets people do things like make a geronimo module depend on an 
> openejb module.  Since openejb depends on geronimo, this is an 
> unacceptable circular dependency.  To avoid this kind of circular 
> dependency, there needs to be a division of each project into sets of 
> modules, where these modules can be cleanly built in order.  Here is an 
> example of such sets:
> 
> geronimo-specs
> tranql
> tranql-connector
> maven xmlbeans plugin
> geronimo-modules without assembly
> geronimo plugins except xmlbeans
> openejb core and builder
> geronimo applications
> geronimo assembly
> openejb assembly
> openejb itests
> 
> It is extremely important to make sure a build in this order can proceed 
> offline with a maven repo that contains no artifacts generated by the 
> build.  Otherwise it is all to easy to introduce dependencies on 
> artifacts that are no longer being generated.
> 
> Since I've been whining about these requirements for several months and 
> no one else has done anything about them I added a simple way to build 
> in this fashion on systems with bash.  After checking out the additional 
> projects in the locations expected by the m: build (tranql/tranql, 
> tranql/connector, and openejb), run ./buildall.sh
> 
> So far I've checked that the build does work.  Now that I've checked it 
> in I will see if the deploy step works, on a system without my local 
> modifications.
> 
> Many thanks,
> david jencks
> 
>