ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johannes Stamminger <Johannes.Stammin...@astrium.eads.net>
Subject Re: Central version numbering.
Date Mon, 24 Sep 2007 08:02:44 GMT

Hi,

just my 2 cents on that topic: as we use IntelliJ and we did not find any 
suitable plugin to update the dependent libs of an IntelliJ module, we wrote 
a plugin ourself (fullfilling just our needs, not usable outside our specific 
environment!). And there we were faced with this problem, too, as our large 
set of projects' setups are within the ant build.xml. And we wanted to avoid 
duplication of configuration items.

We came around this by first calling an ant task (by way of ant API) being 
responsible for configuring the ivy. The we get the Ivy object from the ant 
instance and use this one for updateing the libs dependencies.

That way we keep the responebilities (ant for project setup, building, etc. 
and ivy for dependencies management) without the need of configuring both 
systems indepedently or by common properties file(s).

Regards,
Johannes

On Friday 21 September 2007, Xavier Hanin 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



-- 
!!! NEU/NEW !!!     vvvvvvv
Johannes.Stamminger@Astrium.EADS.net   [2FE783D0 http://wwwkeys.PGP.net]
------ ----<--{(@ ------------------                        EADS ASTRIUM
Koenigsberger Str. 17, 28857 Barrien           Ground System Eng. (TE55)
+49 4242 169582 (Tel + FAX)                 Airbus Allee 1, 28199 Bremen
+49 174 7731593 (Mobile)             +49 421 539 4152 (Tel) / 4378 (FAX)

This email (including any attachments) may contain confidential and/or privileged information
or information otherwise protected from disclosure. If you are not the intended recipient,
please notify the sender immediately, do not copy this message or any attachments and do not
use it for any purpose or disclose its content to any person, but delete this message and
any attachments from your system. Astrium disclaims any and all liability if this email transmission
was virus corrupted, altered or falsified.
---------------------------------------------------------
Astrium GmbH Vorsitzender des Aufsichtsrates: Thomas Mueller - Geschaeftsfuehrung: Evert Dudok
(Vorsitzender), Dr. Reinhold Lutz, Pablo Salame Fischer
Sitz der Gesellschaft: Muenchen - Registergericht: Amtsgericht Muenchen, HRB Nr. 107 647

Mime
View raw message