You can already declare new properties in your settings file. You can also define properties into your ant script and use them into the ivy files.
So, just put your <properties file="myVersionnumbers.properties" /> into your ant script would do it for the ivy.xml file of your source module. But I don't think you can declare new properties into the ivy file. It Means that you can probably not do it for published modules (but I don't think you should do it anyway). Gilles > -----Original Message----- > From: Maarten Coene [mailto:[EMAIL PROTECTED] > Sent: vendredi 21 septembre 2007 15:19 > To: ivy-user@incubator.apache.org > Subject: Re: Central version numbering. > > Isn't this already available with the current version of Ivy? > > -- > Maarten > > ----- Original Message ---- > From: "Foreman, Alex (IT)" <[EMAIL PROTECTED]> > To: ivy-user@incubator.apache.org > Sent: Friday, September 21, 2007 3:10:35 PM > Subject: RE: Central version numbering. > > Would is be possible to add a properties resolution to ivy files? > > Eg: > In myVersionNumbers.properties > common.xerces=2.8.0 > > <properties file="myVersionnumbers.properties" /> > <dependencies> > <dependency org="myOrg" name="myModule" rev="${common.xerces}" /> > > Can this be added for the next release? > > Many thanks, > Alex > > > -----Original Message----- > From: Foreman, Alex (IT) > Sent: 11 September 2007 14:48 > To: ivy-user@incubator.apache.org > Subject: RE: Central version numbering. > > Ok. We are going to have to do some fiddling :D > > Thanks for help > -----Original Message----- > From: Gilles Scokart [mailto:[EMAIL PROTECTED] > Sent: 11 September 2007 14:01 > To: ivy-user@incubator.apache.org > Subject: RE: Central version numbering. > > You can also say that you are using version range 1.2+ (I'm not 100% > sure about the syntax). In that case, when you release a new version of > C that must replace the previous one, you give a version number like > 1.2.2. If the new version must not replace the previous one, publish it > with 1.3.0 or 2.0.0. > > Now, if you want to take a different decision per module, then you will > always have to republish a new ivy.xml file for A and B when there is a > new version of C. > > Gilles > > > -----Original Message----- > > From: Foreman, Alex (IT) [mailto:[EMAIL PROTECTED] > > Sent: mardi 11 septembre 2007 14:33 > > To: ivy-user@incubator.apache.org > > Subject: RE: Central version numbering. > > > > I saw that but was a little unsure on how it worked. > > > > What if we released a new Version of C but we didn't want A or B to > > use it? > > > > Alex > > > > -----Original Message----- > > From: Gilles Scokart [mailto:[EMAIL PROTECTED] > > Sent: 11 September 2007 09:50 > > To: ivy-user@incubator.apache.org > > Subject: RE: Central version numbering. > > > > If you want that, you have to say that A and B are using the version > > "latest.integration" of C (or an other version pattern) inside the > > ivy.xml file of A and B. > > > > > > Gilles > > > > > -----Original Message----- > > > From: Foreman, Alex (IT) > > > [mailto:[EMAIL PROTECTED] > > > Sent: mardi 11 septembre 2007 10:43 > > > To: ivy-user@incubator.apache.org > > > Subject: Central version numbering. > > > > > > Consider this: > > > > > > > > > Artifact A relies on Artifact C, but does not expose it as a > > > transient > > > > > dependency. > > > > > > Artifact B relies on Artifact B and also Artifact C. > > > > > > Now we have a situation where A and B rely on a certain version of > > > Artifact C. > > > > > > If in the future there is a new version of Artifact C which we wish > > > to > > > > > use we have to change the version number in A and B. Is there a way > > > > that we can somehow have one change point so that the version number > > > > we wish to use is automatically picked up? > > > > > > The way we are considering atm is to have a separate ivy file with > > > Artifact C revision ="default" > > > > > > And the default value will have the specific revision as a > > > dependanciy > > > > > inside that. Or even a symlink to the correct ivy file. > > > > > > > > > Is there any better way to get this behaviour? > > > > > > Many thanks, > > > Alex > > > -------------------------------------------------------- > > > > > > NOTICE: If received in error, please destroy and notify sender. > > > Sender > > > > > does not intend to waive confidentiality or privilege. Use of this > > > email is prohibited when received in error. > > -------------------------------------------------------- > > > > NOTICE: If received in error, please destroy and notify sender. Sender > > > does not intend to waive confidentiality or privilege. Use of this > > email is prohibited when received in error. > -------------------------------------------------------- > > NOTICE: If received in error, please destroy and notify sender. Sender > does not intend to waive confidentiality or privilege. Use of this email > is prohibited when received in error. > -------------------------------------------------------- > > NOTICE: If received in error, please destroy and notify sender. Sender > does not intend to waive confidentiality or privilege. Use of this email > is prohibited when received in error. > > > > > > > __________________________________________________________________________ > __________ > Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, > news, photos & more. > http://mobile.yahoo.com/go?refer=1GNXIC
