Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 89827 invoked from network); 7 Oct 2004 15:57:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 7 Oct 2004 15:57:19 -0000 Received: (qmail 39114 invoked by uid 500); 7 Oct 2004 15:56:40 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 38987 invoked by uid 500); 7 Oct 2004 15:56:38 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@geronimo.apache.org Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 38880 invoked by uid 99); 7 Oct 2004 15:56:37 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from [64.14.202.141] (HELO mgd.gluecode.com) (64.14.202.141) by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 07 Oct 2004 08:56:35 -0700 Received: from [192.168.17.103] ([192.168.17.103]) (authenticated bits=0) by mgd.gluecode.com (8.12.10/8.12.10) with ESMTP id i97G5l1q021098 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 7 Oct 2004 09:05:48 -0700 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <735EDED8-1879-11D9-B927-000D93C5B79C@gluecode.com> Content-Transfer-Encoding: 7bit From: Dain Sundstrom Subject: Re: Proposed new multiproject build Date: Thu, 7 Oct 2004 08:56:28 -0700 To: dev@geronimo.apache.org X-Mailer: Apple Mail (2.619) X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N After some thinking, I don't think this can be done directly with maven... let me explain. I thought we could simple do a standard reactor build (the thing that executes maven for each sub-module) with a do nothing target such as build:start. This would cause maven to download the dependencies or each module but would not execute anything. The problem is maven would attempt to download all intermodule dependencies (i.e., all geronimo, openejb, tranql, activmq and howl jars). I think the best approach would be to transform our version-info.ent file into a project.xml file that only had the external dependencies. Then we would just execute it with maven and viola all the dependencies would download. Anyway, it is a bunch of work, so I won't be able to get to it for a while. -dain On Oct 7, 2004, at 7:21 AM, Aaron Mulder wrote: > Yuo might be interested in GERONIMO-364 in JIRA -- which is to > provide a build target to do all the downloads in one shot so the rest > of > the build can be run quickly in offline mode. Dain was going to look > into > it in his copious free time... :) > > Aaron > > On Fri, 8 Oct 2004 sissonj@insession.com wrote: >> It worked for me... but.. >> >> A bit off topic, as my problems don't have anything to do with Dain's >> changes, but I have some questions on the build processing. >> >> I tried the following (without cleaning my repository but with an >> empty >> geronimo directory): >> >> maven m:co >> maven m:build >> >> I then got impatient because it was attempting to download artifacts >> from >> ibiblio over and over and also started running tests, so I cancelled >> the >> build and tried: >> >> maven m:build -o >> >> This then failed because I didn't have the correct version of the >> jetty >> jar in my repository. >> >> So I then tried >> >> maven m:build -Dmaven.test.skip=true -Dmaven.itest.skip=true >> >> and the build was getting plenty of timeout or connection reset errors >> (something between ibiblio and myself having problems, as the ibiblio >> website was timing out often also): >> >> Attempting to download openejb-core-2.0-SNAPSHOT.jar. >> Error retrieving artifact from [ >> http://www.ibiblio.org/maven/openejb/jars/openejb-core-2.0- >> SNAPSHOT.jar]: >> java.net.ConnectException: Connection timed out: connect >> >> and the build finally completed in the lightening fast time of: >> >> BUILD SUCCESSFUL >> Total time: 54 minutes 35 seconds >> Finished at: Thu Oct 07 22:02:19 EST 2004 >> >> A few questions... >> >> If I want to do a build of Geronimo and related projects (ActiveMQ, >> OpenEJB, TranQL) the first two steps sound right to me: >> maven m:co >> maven m:build >> >> But when I build Geronimo (using maven m:build) I think I only want >> it to >> attempt to download dependencies (e.g. jetty, tomcat, xerces) from the >> maven central repository (ibiblio) and not keep attempting to >> download JAR >> files for geronimo (the code I am building) such as >> geronimo-system-1.0-SNAPSHOT.jar. >> >> Is there some chicken and egg situation as to why the code needs to >> download the geronimo SNAPSHOT jars when building geronimo? If not, >> is >> there a way we can prevent the build from downloading the geronimo >> SNAPSHOT jars, but download the other dependencies such as jetty? >> >> If we have a situation where the build is broken, is there an easy >> way to >> build Geronimo using all the versions of the files (svn and CVS) of >> the >> last successful nightly build? Am I dreaming :-) ? >> >> Thanks, >> >> John >> >> Dain Sundstrom wrote on 10/06/2004 12:53:43 >> PM: >> >>> I have rewritten our multiproject build to add support for windows. >>> The new goals all start with m: so as to not disrupt our current >>> stuff. >>> Assuming everyone is happy, I would like to remove the current >>> multiproject and reactor goals (and drop the m: prefix). This is >>> only >>> a proposal, so if people don't like it I can just delete or refactor >>> the goals. >>> >>> Before I get to the new goals, there are a few weirdism. I disabled >>> the activemq tests as they take for ever (like 30 minutes) and >>> eventually fail. This is a hard coded disable, as maven 1 would not >>> let me do it in a more elegant way. I also disabled the openejb >>> itests >>> as they fail every time. This failure is due to something outside of >>> the multiproject build (i.e. it happens in standalone openejb). I >>> also >>> had to disable the geronimo itests as they use some artifacts from >>> the >>> openejb itests. Hopefully these problems can be worked out and all >>> of >>> the test reenabled. I have verified that the current goals work on >>> Mac >>> OS X and Windows. Anyway, on the the new goals.... >>> >>> >>> The main goals for the new multiproject build are: >>> >>> m:default or m:build >>> Executes default build for all available project modules >>> >>> m:clean >>> Deletes the 'target' directory in all available project modules >>> >>> m:clean-repo >>> Deletes the local repository artifacts of ActiveMQ, Geronimo, >>> HOWL, >> >>> OpenEJB, and TranQL. NOTE: This may cause problem is you do not have >>> the source for the all of the other projects available. >>> >>> m:rebuild >>> Same as m:clean m:default >>> >>> m:rebuild-all >>> Same as m:clean m:clean-repo m:default and it includes >>> geronimo-spec modules >>> >>> m:checkout or m:co >>> Checks out ActiveMQ, HOWL, OpenEJB, and TranQL >>> >>> m:update >>> Updates ActiveMQ, Geronimo, HOWL, OpenEJB, and TranQL from >>> cvs/svn >>> HEAD >>> >>> m:fresh-checkout >>> BE CAREFUL: Deletes checkout of ActiveMQ, HOWL, OpenEJB, and >>> TranQL >> >>> and checks them out again >>> >>> >>> In addition to the above we support a -Dmodules command line option >>> which is a comma separated list of module names (ie. common, core, >>> ...) >>> >>> -dain >>> >>> -- >>> Dain Sundstrom >>> Chief Architect >>> Gluecode Software >>> 310.536.8355, ext. 26 >>> >> >>