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: local policy)
Date: Mon, 24 Aug 2009 17:45:28 +0200
From: Niklas Matthies <ml_ivy-user@nmhq.net>
To: ivy-user@ant.apache.org
Subject: Re: Provided conf
Message-ID: <20090824154528.GB89898@nmhq.net>
Mail-Followup-To: ivy-user@ant.apache.org
References: <0BDC5E8B8C50C7459F4428B214F6105E313CA7@mail.hq.rjlg.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0BDC5E8B8C50C7459F4428B214F6105E313CA7@mail.hq.rjlg.com>
User-Agent: Mutt/1.4.2.3i

On Mon 2009-08-24 at 11:16h, Jonathan Roberts wrote on ivy-user:
:
> I just don't really get how this is done in a nice way.  Is there a
> way to say get me all the "compile" dependencies, except the ones
> are that are in the "provided" conf?  

At my place we normally use the following basic configurations:

    common  (private)
    api     (public)  extends common
    runtime (public)  extends common
    compile (private) extends api, runtime

"Api" are the API dependencies of the module, i.e. what client modules
need to compile against the module.

"Runtime" dependencies are what the implementation of the module needs
at runtime.

"Common" is for convenience when declaring artifacts that belong both
to api and runtime (which is the common case).

"Compile" is what is needed to compile the module itself.

Dependencies that are provided by the runtime environment are either
placed into the "api" or into the "compile" configuration, depending
on whether the module's API or just its implementation depends on
them.

Packaging uses the "runtime" configuration, hence it doesn't include
such "provided" dependencies. There is no explicit "provided" conf,
because there is no need for it. (And in our case there would need to
be two different "provided" to make the distinction between API vs.
implementation dependencies).

-- Niklas Matthies