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: local policy)
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <dadb1ce57ad377b5c72fb9d1c1ae1b1c@yahoo.com>
References: <dadb1ce57ad377b5c72fb9d1c1ae1b1c@yahoo.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <e95a1d222b9da035454fdd20b542b771@gluecode.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <djencks@gluecode.com>
Subject: Re: nightly builds -- another perspective
Date: Mon, 25 Apr 2005 10:28:44 -0700
To: dev@geronimo.apache.org

I'd like to attempt to clarify one of my main points.

In my opinion we do not have an acceptable way to build geronimo, so we 
should not attempt to produce automated nightly builds.  Apparently 
there are various packaging steps that should be gone through after a 
successful build, but IMO we do not yet have a way to discover if 
geronimo builds.

I explain below why I think we do not have an acceptable build 
procedure.

The "new build system" I added is a partial fix: if all steps succeed 
it will have built geronimo + tranqls + openejb in an acceptable order, 
but it does not stop if a step fails.  I imagine someone who knows a 
little bit of shell could fix the script in 5 or 10 minutes.  Chatting 
with Brett revealed that maven 2 has a simple way of dealing with this 
entire problem directly in maven.

thanks
david jencks

On Apr 21, 2005, at 10:10 AM, David Jencks wrote:

> 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
>