[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ivy-user
Subject:    Re: Central version numbering.
From:       "John Gill" <llignhoj () gmail ! com>
Date:       2007-09-25 13:27:12
Message-ID: 49c77ae40709250627ma68b058s90e2e7919ca22de1 () mail ! gmail ! com
[Download RAW message or body]


I have created issue IVY-609 (https://issues.apache.org/jira/browse/IVY-609)

On 9/25/07, Xavier Hanin <xavier.hanin@gmail.com> wrote:
>
> Could you open a JIRA issue for that? For the name I like "now" too for
> the
> same reason.
>
> Xavier
>
> On 9/25/07, John Gill <llignhoj@gmail.com> wrote:
> >
> > OK forget the "shutdown" trigger. I don't mind what you call the
> > "on-startup" trigger. I like "now" as it is nice and short, but
> > "immediate"
> > or  "immediately" is probably more technically correct.
> >
> > On 9/24/07, Xavier Hanin <xavier.hanin@gmail.com> wrote:
> > >
> > > On 9/24/07, John Gill <llignhoj@gmail.com> wrote:
> > > >
> > > > I understand the issues with introducing filterchains into
> > ivysettings,
> > > > which is why I thought I'd better ask first.
> > > >
> > > > Yes, the trigger idea sounds like a much better idea.
> > > >
> > > > I am guessing I would have something like:
> > > >
> > > > <ivysettings>
> > > >
> > > >     <!-- call the trigger to read my depends.xml and auto.xml and
> make
> > a
> > > > ivy.properties file in the build directory -->
> > > >     <triggers>
> > > >         <ant-build antfile="${ivy.settings.dir}/build.xml"
> > > > target="make-ivy-properties"
> > > >                        event="on-startup"/>
> > > >     </triggers>
> > > >     <properties file="build/ivy.properties" override="true"/>
> > > > </ivysettings>
> > > >
> > > > I've made a guess at the name of the event as "on-startup" (and it
> > > should
> > > > call the target as soon as the trigger definition is detected).
> > > > In addition, it might pay to round out the functionality and add an
> > > > "on-shutdown" event as well (although I'm not sure what I would use
> > this
> > > > for
> > > > personally, but I'm sure someone will want it :-).
> > >
> > >
> > > on-startup is not too bad, but what do you think of "immediately" or
> > > "now"?
> > > For the on-shutdown, I'm not sure what we can call a shutdown in
> Ivy...
> > we
> > > are never sure there won't be any further call.
> > >
> > > Xavier
> > >
> > > On 9/24/07, Xavier Hanin <xavier.hanin@gmail.com> wrote:
> > > > >
> > > > > 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/
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > 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/
>



-- 
Regards,
John Gill


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic