ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <>
Subject RE: Store pom dependency Managment in extra data
Date Thu, 14 Feb 2008 09:49:51 GMT

> -----Original Message-----
> From: Xavier Hanin []
> Sent: jeudi 14 février 2008 9:44
> To: Ant Developers List
> Subject: Re: Store pom dependency Managment in extra data
> I think we need to distinguish two kind of extra metadata: those used to
> identify the module, and those which are pure information. IMO extra
> attributes on the info tag are good candidates for the first kind of extra
> meta information:
> - because it's how they work now
> - because the info tag attributes are mainly identifying the module.
> So I think it's better to distinguish the other kind of extra information,
> and you seem to agree, so this is fine :-)
> Now about how to define these extra information, how to name them, and how
> they can be used. IMO, if we introduce something in the core for maven 2
> compatibility, it's better to try to find a use case for users who use Ivy
> files only. So I think we need at least to find a syntax in Ivy files to
> support setting this additional extra information.

My idea was to use the attribute of the info tag as identifier, like it is now.  And put to
other values under the info
tag, like you have now the license, the repository and so on.

We could put all those info into an extraInfo.

> Now about calling them properties and making them available as properties in
> the Ivy file. What I like about that is that:
> - it uses an existing concept in Ivy, so we don't need to define a new one
> - it answers to a use case that at least I've had before (so I guess other
> users have too), where I need a property in an ivy file and don't want to
> define it outside my ivy file
> About the added complexity, I think we need to distinguish two kind of
> complexity: complexity in Ivy code, and complexity for users. IMO, it's
> something pretty easy to understand by users, because we reuse an existing
> and well known concept. In Ivy code, I don't think it make it really more
> complex, if we allow to use a property only after it is declared (so if the
> property definition comes after the info tag in the xsd, we won't be able to
> use locally defined properties in the info tag). We already do this kind of
> substitution for globally defined properties, and it can be easily factored
> at the beginning of the startElement method, so I don't see much added
> complexity here.
> So I'm still in favor of this properties support in Ivy files. Did I manage
> to change your mind ? :-)

Well, I'm now -0.1 for this.  I understand the use case, and I already faced it as well, but
I still found the concept
of properties already quiet loaded (ant properties, settings properties, each with potentially
different overwrite rules
and scoping).

Let see what the other things about it?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message