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: Relationship between branches, revisions; integration, and release.
Date Fri, 08 Jun 2007 10:48:28 GMT
On 6/8/07, Buck, Robert <rbuck@verisign.com> wrote:
>
> Hi Xavier,
>
> Sorry to belabor the points, but...
>
>   [branch][revision]
>
> Unless a company releases multiple versions from a single branch, these
> are redundant and may be reduced to one term, not two. Right?


It depends on your versioning policy. In your case I understand the two are
redundant, that's why I proposed other solutions if having the two
directories is not affordable. This solution is the simplest, that's why I
suggested it.

Regarding:
>
> > OK, I better get your situation now. One thing to know about
> > the latest.integration version constraint is that it matches
> > everything, including milestone and release. Why that?
> > Because if getting a simple integration version, a milestone
> > or release (which are usually better tested
> > :)) is even better. If you want a version constraint matching
> > only versions in integration status, you will need to provide
> > your own (which is very easy). But the problem of relying on
> > the status is that the status of a module can only be known
> > by parsing the module descriptor (the ivy file).
> > Thus using status dependent version constraints does not
> > perform very well and is not recommended.
>
> Oh, so what you are saying is that with using a pattern that is not
> bound to a directory name, IVY must always introspect the IVY files
> instead of doing a simple and efficient directory existence check. I
> think I see what you are saying now. Yes, parsing is a lot slower than a
> File.exists call.


Exactly.

Does IVY support a [status] pattern? It looks like it does not.


No, the tokens supported in the pattern corresponds to the attributes given
on the dependency element in your ivy files. So you can use a status token
if you add a status attribute when declaring your dependency, otherwise it's
not possible. And note that in this case Ivy will only do exact match, and
not consider a milestone as a better integration.

Regarding:
>
> > So the answer to your question is that it won't work like
> > that. Indeed when you ask for latest.integration version of
> > the branch BILINGSERVER-ACME, Ivy will check the release and
> > integration repository (according to your settings). In the
> > integration repo, only module on the branch will be found.
> > Fine. On the release repo, since you have no branch in the
> > pattern, Ivy will find your module too. If the release module
> > is younger than the integration one, it will take it.
>
> What if I had two different resolvers, for two different public
> repositories (integration and release), and use 'returnFirst'? The
> release repository is used for all released artifacts, and has highest
> priority, and we fallback to the integration repository if the former
> fails to find the artifact.
>
> Would this work?


It depends. It will work only if the release repo don't find the module, and
if you have no branch token in your release repo, Ivy will 'think' that all
your release modules are on any branch. So this works only if you have a
branch token in your release repo, or use another solution to make sure a
release do not match a branched dependency.

Xavier

Thank you,
>
> Bob
>
>
> > -----Original Message-----
> > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> > Sent: Thursday, June 07, 2007 9:11 AM
> > To: ivy-user@incubator.apache.org
> > Subject: Re: Relationship between branches, revisions;
> > integration, and release.
> >
> > On 6/7/07, Buck, Robert <rbuck@verisign.com> wrote:
> > >
> > > I'd appreciate an explanation of this one statement. A similar
> > > statement was made in an archived thread. I thought it
> > referred to 'release'
> > > versus 'integration' directories. But apparently not, based
> > upon the
> > > context of your statement.
> > >
> > > So, "what directory"? Can you provide an example of the layout?
> >
> >
> > I'm talking about adding a branch directory in the release repo:
> > <url name="public-resolver">
> >      <ivy
> > pattern="
> > http://localhost:20080/ivyrep/release/[organisation]/[module]/
> > [branch]/[revision]/ivys/ivy-[revision].xml
> > "/>
> >      <artifact
> > pattern="
> > http://localhost:20080/ivyrep/release/[organisation]/[module]/
> > [branch]/[revision]/[type]s/[artifact].[ext]
> > "/>
> >      <artifact
> > pattern="
> > http://localhost:20080/ivyrep/release/[organisation]/[module]/
> > [branch]/[revision]/[type]s/[artifact]-[revision].[ext]
> > "/>
> >      <artifact
> > pattern="
> > http://localhost:20080/ivyrep/integration/[organisation]/[modu
> > le]/[branch]/[type]s/[artifact].[ext]
> > "/>
> >      <artifact
> > pattern="
> > http://localhost:20080/ivyrep/integration/[organisation]/[modu
> > le]/[branch]/[type]s/[artifact]-[revision].[ext]
> > "/>
> >  </url>
> >
> > If you don't care about having such a directory (which will
> > end up being named 'main' or 'HEAD' according to your default
> > branch name setting), this is the easiest solution for Ivy to
> > know that your release modules are on the 'main' branch (and
> > thus not on any other branch, which is the reason behind that).
> >
> > HTH,
> >
> > Xavier
> >
> > > I do not want to misunderstand you.
> > >
> > > Bob
> > >
> > > > -----Original Message-----
> > > > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> > > > Sent: Thursday, June 07, 2007 8:19 AM
> > > > To: ivy-user@incubator.apache.org
> > > > Subject: Re: Relationship between branches, revisions;
> > integration,
> > > > and release.
> > > >
> > > > If you don't like having this additional directory in your layout
> > >
> >
> >
> >
> > --
> > Xavier Hanin - Independent Java Consultant Manage your
> > dependencies with Ivy!
> > http://incubator.apache.org/ivy/
> >
>



-- 
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/

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