Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 50867 invoked from network); 23 Sep 2008 18:59:47 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 23 Sep 2008 18:59:47 -0000 Received: (qmail 3339 invoked by uid 500); 23 Sep 2008 18:59:44 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 3135 invoked by uid 500); 23 Sep 2008 18:59:44 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 3124 invoked by uid 99); 23 Sep 2008 18:59:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Sep 2008 11:59:44 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [62.179.121.48] (HELO viefep28-int.chello.at) (62.179.121.48) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Sep 2008 18:58:44 +0000 Received: from felixknecht.ch ([84.72.24.104]) by viefep28-int.chello.at (InterMail vM.7.08.02.02 201-2186-121-104-20070414) with ESMTP id <20080923185902.KKJJ23367.viefep28-int.chello.at@felixknecht.ch> for ; Tue, 23 Sep 2008 20:59:02 +0200 Received: (qmail 23343 invoked by uid 210); 23 Sep 2008 18:59:01 -0000 Received: from 192.168.1.97 by odin (envelope-from , uid 201) with qmail-scanner-2.02st (clamdscan: 0.93.3/8310. perlscan: 2.02st. Clear:RC:1(192.168.1.97):. Processed in 0.046174 secs); 23 Sep 2008 18:59:01 -0000 Received: from unknown (HELO ?192.168.1.97?) (192.168.1.97) by 192.168.1.11 with SMTP; 23 Sep 2008 18:59:01 -0000 Message-ID: <48D93C77.7020601@apache.org> Date: Tue, 23 Sep 2008 20:59:03 +0200 From: Felix Knecht Organization: apache.org User-Agent: Thunderbird 2.0.0.16 (X11/20080729) MIME-Version: 1.0 To: Apache Directory Developers List Subject: Re: [Studio] How to speed up build time? References: <98d8c0860809230747x72ef53bavb4a62f1f85daf273@mail.gmail.com> <48D925B4.5030405@apache.org> <98d8c0860809231040r75d2204fwc491417382c7efef@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org David Jencks schrieb: > > On Sep 23, 2008, at 10:40 AM, Pierre-Arnaud Marcelot wrote: > >> On Tue, Sep 23, 2008 at 7:21 PM, Felix Knecht > > wrote: >> >> Well, here's an idea let us see if we can adapt/configure it for >> our needs: >> >> Put the *help modules into a separate profile and have it >> activated by ? (see [1]). We just need to find an appropriate >> activator which fits our needs. We can have e.g. such a timestamp >> file (exist or not) to activate to 'help' profile. The >> question is just 'How to figure out if something has changed?". >> One possibility could be that we create such a file when doing a >> build and only delete it when running a new build >> including the 'clean' goal -> adapt the clean goal configuration >> in such a way that it deletes the timestamp file. >> The timestamp file needs to be added to svn:ignore and it's >> location can/should be in the *help modules root directory. >> >> As said, just an idea. Maybe there are better solutions. >> >> >> I must have catch the Maven way of thinking, because I was thinking >> about something pretty similar... Hehe. >> >> A special profile that gets triggered when we want, or based on a >> condition (a file existing [or not] somewhere). >> >> We'll see that after I'm done with the Manifests. ;) > > > In general the fact that a module hasn't changed doesn't mean it will > build: the stuff it depends on might have changed to break it. Thus I > think CI builds should be complete builds of everything. > > There's been activity recently in maven on enabling dependency based > partial builds. IIUC most of this will be in maven 2.1-M2 (it's > apparently in trunk) and there's a plugin for earlier mavens. I haven't > tried it personally yet.... the first experiment I made didn't work and > I didn't poke very hard to find out what was wrong. > > http://maven.apache.org/plugins/maven-reactor-plugin/ At first glance I don't see how the reactor plugin could help us. We have submodules which should be built only if there are any file changes in the specific submodule- Regards Felix