ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: Central version numbering.
Date Mon, 24 Sep 2007 07:06:23 GMT
On 9/23/07, John Gill <llignhoj@gmail.com> wrote:
>
> Actually, I've just had an idea!
>
> If the ivy properties tag (
>
> http://incubator.apache.org/ivy/history/trunk/configuration/properties.html
> )
> supported filterchains that ant has, then I could load my depends.xmlwhich
> is in the form
> <project>
>     <property name="a" value="1.2.3"/>
>     <property name="b" value="4.5.6"/>
> </project>
>
> And then in my filterchain, run a series of regex filters on the file to
> turn it into a property file.
>
> So I would have something like (not sure the regex is exactly correct)
>
> <ivysettings>
>     <properties file="depends.xml" override="true">
>         <filterchain>
>             <replaceregex pattern="&lt;project&gt;" replace=""
> flags="gi"/>
>             <replaceregex pattern='&ltproperty="(.*) value="(.*)"'
> replace="\1=\2" flags="gi"/>
>             <replaceregex pattern="&lt;/project&gt;" replace=""
> flags="gi"/>
>         </filterchain>
>     </properties>
> </ivysettings>
>
> Obviously, it would be nice if it supported the full set of filterchains
> that ANT uses, and I guess ivy could probably just use the ant classes to
> do
> all the work.
>
> How viable do you think such an enhancement would be Xavier? If you
> support
> the idea, I'll try to implement it and submit a patch. Is there any reason
> why ivy can't be dependent on ant filterchain classes?


Ivy tries to depend on as few dependencies as possible. And I'm not sure if
adding filterchains is really something that belongs to the scope of Ivy.
That being said, I understand your need. Maybe we could find another way to
address it. An idea from the top of my head: why not add a way to call a
trigger from an ivysettings file? Then you could call an an target before
loading the properties file. Since we already support triggers, this should
be easy to do and can solve a lot of problems when using Ivy outside Ant.
What do you think ?

Also, can I load two properties files, because I would like something like
> this:
> <ivysettings>
>     <properties file="auto.xml" override="true">
>         <filterchain>
>            ...
>         </filterchain>
>     </properties>
>     <properties file="depends.xml" override="false">
>         <filterchain>
>             ...
>         </filterchain>
>     </properties>
> </ivysettings>


Yes, you can load multitple properties files, no problem.

Xavier

On 9/21/07, Xavier Hanin <xavier.hanin@gmail.com> wrote:
> >
> > You're right, you need one settings file for each Project. But those
> > settings files are very simple and do not require any maintenance: they
> > only
> > import one property file and one settings file. Using ant substitution
> as
> > you do is fine, but the developer has to remember to run the ant
> > substitution tasks each time they change a property or the ivy file...
> and
> > developers are lazy :-)
> >
> > Xavier
> >
> > On 9/21/07, John Gill <llignhoj@gmail.com> wrote:
> > >
> > > 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 <xavier.hanin@gmail.com> wrote:
> > > >
> > > > On 9/21/07, Foreman, Alex (IT) <Alexander.Foreman@morganstanley.com>
> > > > 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:gscokart@gmail.com]
> > > > > 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:maarten_coene@yahoo.com]
> > > > > > 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)" <Alexander.Foreman@morganstanley.com>
> > > > > > 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:gscokart@gmail.com]
> > > > > > 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:Alexander.Foreman@morganstanley.com]
> > > > > > > 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:gscokart@gmail.com]
> > > > > > > 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:Alexander.Foreman@morganstanley.com]
> > > > > > > > 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
> > >
> >
> >
> >
> > --
> > Xavier Hanin - Independent Java Consultant
> > http://xhab.blogspot.com/
> > http://incubator.apache.org/ivy/
> > http://www.xoocode.org/
> >
>
>
>
> --
> Regards,
> John Gill
>



-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://incubator.apache.org/ivy/
http://www.xoocode.org/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message