On Thu, Feb 14, 2008 at 10:49 AM, Gilles Scokart <[EMAIL PROTECTED]> wrote:
> > > > -----Original Message----- > > From: Xavier Hanin [mailto:[EMAIL PROTECTED] > > 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. You can already put whatever you want in the description tag (which has xs:any children in the xsd). So the difference would only be that this information is parsed by Ivy, but how users could use them, if they aren't properties? Only when using Ivy API? > > > > > 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). Yes, but in this case it's actually just simpler: properties are defined in the same file as where they are used. I agree that we still have to deal with overwrite, but I don't think it's a major issue. Xavier, trying to get at least a 0.1++ :-) > > Let see what the other things about it? > > Gilles > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
