Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@ant.apache.org
Received-SPF: pass (athena.apache.org: domain of mgitman@gmail.com designates
 209.85.216.200 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=N9V/Kwg6hanpuWMNrd6KBggc7nvhmedB6bclw5dqFKUPPN1vdoOnXR3ds3sK0Qvofl
         GprbyMuprs6iRdWXYOsHkrcVAHqjk0iJzX7wKlZjehqvkGVfr3YjLP2aRbogldQbVtpA
         7rsreJ4MzDnrkBCaBS1SO/sIOada37F9bdU1M=
MIME-Version: 1.0
In-Reply-To: <4B0D1081.6010007@sbdev.net>
References: <4B0C144A.7050902@sbdev.net>
	 <7916a6a60911240930j41cc07ffka6c260224a5580c9@mail.gmail.com>
	 <4B0D1081.6010007@sbdev.net>
Date: Wed, 25 Nov 2009 08:32:21 -0800
Message-ID: <7916a6a60911250832v2d17b1e9ia595a9c05ec9b5d8@mail.gmail.com>
Subject: Re: Using Ivy to automate build
From: Mitch Gitman <mgitman@gmail.com>
To: ivy-user@ant.apache.org
Content-Type: multipart/alternative; boundary=000e0cd1a3cc60a76f0479349a21

--000e0cd1a3cc60a76f0479349a21
Content-Type: text/plain; charset=UTF-8

Jonathan, I think buildlist as it exists will do what you're looking for. I
can attest that my team is able to do a multimodule build against a
completely empty Ivy repository. It's clear then that Ivy is determining the
build order strictly from the Ivy module descriptors of the checked-out
projects. As the multimodule build goes along, though, we do an ivy:publish
at the end of each individual project build so that each dependency shows up
where expected on-demand.

Suppose your application project--the one that depends on everything
else--depends on:
* a win32-deployer project in a win32 conf
* a macosx-deployer project in a macosx conf

Then suppose another project, a leaf project, depends on application and
asks for its macosx conf.

Then the build might go something like this:
1. macosx-deployer
2. application
3. leaf
4. win32-deployer

Or maybe like this:
1. win32-deployer
2. macosx-deployer
3. application
4. leaf

Since win32-deployer isn't depended upon in this configuration chain, its
place in the order doesn't matter.

To second what Alex Foreman wrote, just make sure to eliminate circular
dependencies.

Now, if you have certain unit tests or integration tests that behave
differently or succeed or fail depending on the project's current
configuration, then buildlist won't help you. But that's also a sign that
your project is using Ivy to do something it probably shouldn't.

Also, I would dispute one assumption you make in response to Alex: "however,
why should I have to worry about building MacOsX+Release when I just want to
test my Win32 build i.e. (Win32+Test)."

I would argue that you want a multimodule build to build every project, even
if you only want a particular path through the projects. This way you know
that your full system is published and ready to use regardless of the conf
desired. The only advantage to only building a slice of your projects is
saving time. But really, the last thing a multimodule build "from scratch"
should be about is saving time.

P.S. It sounds like a technique like the special buildlist Ivy conf I
describe is something you don't need. Reason: you're already able to
establish build order from the existing Ivy confs.

On Wed, Nov 25, 2009 at 3:09 AM, Jonathan Oulds <jonathan@sbdev.net> wrote:

> Thank you for your reply, let me explain the raison d'etre for my question
> inline
>
> many thanks
> Jonathan
>
>
> Mitch Gitman wrote:
>
>> Jonathan, there's one statement from you that doesn't make sense:
>> "...however in this particular case I need to build without access to the
>> artefact [sic] repository."
>>
>> Maybe I'm misunderstanding what you mean, but you can't really use Ivy to
>> build if you're not accessing an Ivy repository.
>>
>
> I admit this was a bit unclear, what I am attempting to do is build the
> entire project source from start to finish in one pass from a clean
> checkout.  I actually will have access to an artefact repository, however
> this repository will be empty, as such any attempt to resolve will fail,
> thus the only way to accomplish my task is to build the dependencies in the
> correct order, however the build order is dependant on configuration of the
> project.
>
> For example imagine the configuration was something like "Win32+Test", this
> would obviously give a different build order to "MacOsX+Release"
>
> Ideally I would like the ivy:buildlist to be able to determine the build
> order with respect to the required configuration, however this does not seem
> possible.
>
>
>
>
>> I can attest that my team has had success using *ivy:buildlist *to do
>> multimodule builds. Part of the deal, though, is that you still have to
>> tell
>> Ivy what it needs to know. Each module is responsible for doing an
>> *ivy:publish
>> *during its turn in the multimodule build--after doing whatever arbitrary
>> work it was asked to do in the first place.
>>
>> Also, there are times when the proper build order cannot be determined
>> simply by looking at the existing Ivy confs. For example, there may be a
>> project that does some deployment work. Other projects downstream don't
>> depend on its library being in the classpath (maybe it doesn't even
>> publish
>> a JAR), but they do depend on its having done its work by then. (In a
>> normal
>> situation, I would argue against having such relationships, but play with
>> me.) In this case, you may want to add a special Ivy conf--call it
>> "buildlist"--whose job is strictly to help establish build order. So you
>> get:
>> <dependency org="..." name="..." rev="..." conf="buildlist->..." />
>>
>
> Could you elaborate on this a little more, could I use such a technique to
> define different buildlists for say release, debug or testing builds?
>
>

--000e0cd1a3cc60a76f0479349a21--