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: Wed, 27 Feb 2008 16:42:50 +0100
From: Niklas Matthies <ml_ivy-user@nmhq.net>
To: ivy-user@ant.apache.org
Subject: Re: specify versions separate from dependencies
Message-ID: <20080227154250.GC12907@nmhq.net>
Mail-Followup-To: ivy-user@ant.apache.org
References: <20080226184625.7decc0cd@sbs173>
 <635a05060802270127u45d34548kb398ec4c259dc136@mail.gmail.com>
 <20080227115305.1a40c042@sbs173>
 <635a05060802270523i1512e901xc866a238388be697@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <635a05060802270523i1512e901xc866a238388be697@mail.gmail.com>
User-Agent: Mutt/1.4.2.3i

As for how to implement this in Ivy, how about:

- Provide an inclusion facility for ivy files to semantically
  include/merge the contents of some other ivy file, similar as
  "include" for the settings files. Possibly add an attribute to
  choose what to do in case of conflicting/non-mergeable specs.
  
  IMO *any* configuration/specification file format ought to have such
  a mechanism.

- Add the possibility to specify any kind of ivy file tags under the
  "module" tag of a settings file, to be semantically injected into
  the ivy files of all matched modules. Basically a "reverse-include".

  As above, possibly add an attribute to choose what to do in case of
  conflicting/non-mergeable specs.

Something along these lines would be more generic/orthogonal/flexible
than adding a dedicated construct for the specific use case here.

-- Niklas Matthies