Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <dev@avalon.apache.org>
To: dev@avalon.apache.org
From: Leo Simons <leosimons@apache.org>
Subject: Re: Maven/Gump Question about special changes to build
Date: Tue, 17 Jun 2003 22:10:22 +0200
Lines: 50
Message-ID: <bcnsjd$n0j$1@main.gmane.org>
References: <3EEF21D2.2040602@apache.org> <3EEF36E1.1040007@apache.org>
 <bcnl4d$5i7$1@main.gmane.org> <3EEF69F4.7090201@apache.org>
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.1; en-US;
 rv:1.3) Gecko/20030312
In-Reply-To: <3EEF69F4.7090201@apache.org>
Sender: news <news@main.gmane.org>

Berin Loritsch wrote:
>> why do you need to copy source files? Do the tools/ need access to 
>> container/ sourcefiles at runtime?
> 
> Yes.  THe tools make use of the util/dag/** stuff as well as the
> util/Service class and the impl/roles/ServiceMetaManager for
> various aspects.

ok, I get the problem now. What we have, in fact, is a circular 
dependency between fortress-container and fortress-tools, because the 
tests for fortress-container utilise the metainfo task provided by 
fortress-tools, and fortress-tools utilizes classes from fortress-container.

---

Your solution to the problem is

1) duplicate the classes fortress-tools needs from fortress-container, 
ie, copying them, at buildtime, before compiling

A few more options:

2) don't use the metainfo task in the fortress-container tests, breaking 
the loop and removing the dependency on fortress-tools, generating a 
convenience 'fortress-tools-complete.jar' containing the required 
materials from fortress-container.jar (or maybe everything from 
fortress-container-complete, for convenience)

3) seperate out the code that the tools need into a new 
(mini-)subproject, fortress-util (and/or perhaps a fortress-meta)

4) make fortress-container generate a jar that contains sourcefiles, and 
  fetch and unpack that from fortress-tools

---

my preference is probably #2, because it seems the cleanest 
conceptually: unit tests should not depend on dependencies of what they 
are testing, and having a subproject for three classes is ugly.

Regardless of all that, I think for the gump build it is cleanest to not 
modify the ant buildfile but just have inherit="runtime" for 
dependencies on fortress-tools. This does not require buildfile 
customization and is consistent with how this works for other build 
projects (like ant).

cheers!

- LSD


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org