The only problem I have had with that idea, is if your properties are
different for each build, then you need lots of different ivy setting files
just for ivyDE (or am I missing something).
On 9/21/07, Xavier Hanin <[EMAIL PROTECTED]> wrote:
>
> On 9/21/07, Foreman, Alex (IT) <[EMAIL PROTECTED]>
> wrote:
> >
> > Hi,
> > Thanks for the response.
> >
> > Sorry Its last Friday and my brain wasn't working perfectly.
> >
> > I am able to do this from the command line fine.
> >
> > When I add it to the eclipseIDE when It resolves the file It doesn't add
> > the properties in. They are both pointing to the same ivysettings.xml
> > so they both have the properties loaded. However when you resolve in
> > eclipse not via ANT it doesn't do this subsitution so it cannot find the
> > version:(
> >
> > Eg cannot find [mylib | module | ${common.version}] <-- not replaced in
> > eclipse but works in ant :(
>
>
> It's usually because you define properties in Ant and not in Ivy settings.
> Are you sure the properties file is loaded in your ivy settings? If you
> prefer to load them in Ant for your Ant build, then you can use a settings
> file only for IvyDE which just import your main settings (those you use in
> Ant) and load the properties file you want.
>
> HTH,
>
> Xavier
>
> -----Original Message-----
> > From: Gilles Scokart [mailto:[EMAIL PROTECTED]
> > Sent: 21 September 2007 14:28
> > To: ivy-user@incubator.apache.org
> > Subject: RE: Central version numbering.
> >
> > 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
> > --------------------------------------------------------
> >
> > 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.
> >
>
>
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://incubator.apache.org/ivy/
> http://www.xoocode.org/
>
--
Regards,
John Gill
