ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <gscok...@gmail.com>
Subject RE: best repository layout? (opinions solicited)
Date Fri, 04 May 2007 07:47:11 GMT
I would also advise to have different repositories for integration and
releases.  This is really two different things and they are plenty of
reasons to separate them:
 - You can have different backup policies
 - You can have different security access
 - You can have different approach to clean it
 - You can have different performance expectations
 - You can have different storage size requirements
 ...

When you start your repository this is probably not important.  But after
some time, you will maybe have to differentiate more the two repository.

So I think the 2 repository with chained resolver is the right approach to
take, because it will allow you to more easily evolve, and more easily
migrate one or the other repository without having to change his layout.

Gilles


> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: jeudi 3 mai 2007 18:37
> To: ivy-user@incubator.apache.org
> Subject: Re: best repository layout? (opinions solicited)
> 
> On 03-May-2007 12:27:52 EDT, Todd_Lee@amis.com <Todd_Lee@amis.com> wrote:
> > I know it doesn't seem to be supported right now, but our org was
> thinking
> > it would be nice to be able to build a repository using a structure
> like:
> >
> >     <ivy
> >
> pattern="${ivy.repo.dir}/[status]/[organization]/[module]/[revision]/ivy.x
> ml"
> >  />
> >     <artifact
> >
> pattern="${ivy.repo.dir}/[status]/[organization]/[module]/[revision]/[arti
> fact].[type]"
> >  />
> >
> > Note the addition of the [status] token. The rationale being that it
> would
> > help you separate 'release' and 'integration' builds. (We have a goal of
> > being able to support promotion of an integration to a release and the
> > clean distinction would be helpful for starters)
> Usually I recommend this form of separation in an hard coded way as
> you suggest below. The problem to have it as a token is that Ivy can't
> guess the status value from your dependencies definition... unless
> maybe if you use it as an extra attribute (never tried before, but it
> may work):
> <dependency org="..." name="..." status="milestone"
> rev="latest.integration" />
> In this case the pattern you suggest may work (but you need to specify
> the status everytime, and Ivy won't look into the release if a
> milestone is not available (which is what Ivy does with
> latest.milestone, but this requires module descriptors parsing, which
> has performance issues, especially with slow repository.
> 
> Xavier
> 
> > I guess given the lack of support for the status token in resolver
> patterns
> > a workaround might be to have chained resolvers that use hardcoded base
> > paths ie-
> >
> >
> > pattern="${ivy.repo.dir}/release/[organization]/[module]/[revision]...
> >
> >
> pattern="${ivy.repo.dir}/integration/[organization]/[module]/[revision]...
> >
> > And try to filter publish/resolves accordingly...
> >
> > Has anyone else played around with this type of concept? Anyone have
> other
> > novel ways of dealing with releases/integrations specifically?
> >
> > Todd
> >
> >
> >
> >
> >              "Xavier Hanin"
> >              <xavier.hanin@gma
> >              il.com>
> To
> >                                        ivy-user@incubator.apache.org
> >              05/03/2007 12:15
> cc
> >              PM
> >
> Subject
> >                                        Re: best repository layout?
> >              Please respond to         (opinions solicited)
> >              ivy-user@incubato
> >                r.apache.org
> >
> >
> >
> >
> >
> >
> >
> >
> > On 5/3/07, Bagwell, Allen F <afbagwe@sandia.gov> wrote:
> > >
> > > I've been faced with a similar choice.  For testing purposes (ivy is
> > > experimental at this stage in our build process) I'm using:
> > >
> > > organisation/module/revision/type/artifact.ext +
> > > organisation/module/ivys/ivy-revision.ext
> > >
> > > This works well at the moment because all of our modules that are
> > > publishing right now are in-house developed C++ static libraries and
> > > their header files.  With traditional names like libFoo.a, the
> revision
> > > number isn't a part of the library name versus a typical .jar file.
> > Notice that the name in the repo and the name once retrieved is not
> > necessarily related, so you can have the revision in the name in the
> > repo and remove it when you retrieve your dependencies. Since you can
> > filter on retrieve, you can retrieve with one pattern your header
> > files and with another one your jar files.
> >
> > This is just an idea, there's nothing wrong with avoiding the revision
> > in your artifact names.
> >
> > Xavier
> > >
> > > However, we will soon be adding Java to our project -- using both
> > > publicly available jars with revision # in the file name as well as
> our
> > > own -- so I will likely have to re-think this. I know with .so files
> > > there is a tradition of naming them 'libFoo.so.[revision]' and have a
> > > symlink of 'libFoo.so' point to the latest.  Maybe we should adopt a
> > > similar convention with our .a files and something like
> > > 'headers-libFoo-[revision].zip' for the other stuff.
> > >
> > > If anyone has a suggestion, I'm all eyes and ears. :)
> > >
> > > Allen
> > >
> > >
> > > -----Original Message-----
> > > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> > > Sent: Thursday, May 03, 2007 4:43 AM
> > > To: ivy-user@incubator.apache.org
> > > Subject: Re: best repository layout? (opinions solicited)
> > >
> > > On 5/2/07, Buck, Robert <rbuck@verisign.com> wrote:
> > > > Hi,
> > > >
> > > > Not being an advanced user of IVY, I wanted to pass this question by
> > > > the user community. I wanted to nail down my repository layout ASAP.
> > > >
> > > > In your experience, which repository layout works best?
> > > >
> > > > Here are a couple options:
> > > >
> > > > 1. organisation/product/version-num/jars-here  +
> > > > organisation/product/ivy-product-version.xml
> > > >
> > > > 2. organisation/product/version-num/jars/jars-here   +
> > > > organisation/product/version-num/ivys/ivys-here
> > > >
> > > > 3. other?
> > > >
> > > > There may be considerations that I have not considered, but what I
> > > > presently have (and can change with ease) is option # 1.
> > > >
> > > > Thoughts or debate anyone?
> > > It really depends on your needs and requirements, but here are some
> > > general feedback:
> > > * group data by version, it makes it easier to manage your repository
> > > (so option #2 seems better here).
> > > * depending on your needs, try to keep things as simple as possible.
> > > If you can distinguish your artifacts without the type and if you do
> not
> > > have too much artifacts per module, avoid the [type] directory (but if
> > > you want to store sources and javadocs artifacts, they are usually
> > > distinguished only by type)
> > > * use the branch token if you plan to use branches some time.
> > > * keep the revision in the file name if the repository can be accessed
> > > directly (on a web server for instance) to make it obvious what the
> > > revision of the artifact is once downloaded
> > >
> > > HTH,
> > >
> > > Xavier
> > > >
> > > > Thanks in advance,
> > > >
> > > > Bob
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Learn Ivy at ApacheCon: http://www.eu.apachecon.com/ Manage your
> > > dependencies with Ivy!
> > > http://incubator.apache.org/ivy/
> > >
> > >
> > >
> >
> >
> > --
> > Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
> > Manage your dependencies with Ivy!
> > http://incubator.apache.org/ivy/
> >
> >
> > AMI Semiconductor - "Silicon Solutions for the Real World"
> > NOTICE:
> > This electronic message contains information that may be confidential or
> privileged. The information is intended for the use of the individual or
> entity named above. If you are not the intended recipient, please be aware
> that any disclosure, copying, distribution or use of the contents of this
> information is prohibited. If you received this electronic message in
> error, please notify the sender and delete the copy you received.
> >
> >
> 
> 
> --
> Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
> Manage your dependencies with Ivy!
> http://incubator.apache.org/ivy/


Mime
View raw message