You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by "Buck, Robert" <rb...@verisign.com> on 2007/05/02 19:17:25 UTC
best repository layout? (opinions solicited)
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?
Thanks in advance,
Bob
Re: best repository layout? (opinions solicited)
Posted by Xavier Hanin <xa...@gmail.com>.
On 5/4/07, todd lee <To...@amis.com> wrote:
>
>
>
> Gilles Scokart wrote:
> >
> >
> > 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.
> >
> >
>
> Thanks for the input Gilles, so given that this is something that we're in
> the process of implementing right now, I wonder if someone would be willing
> to share the details of their experience with implementing this? If we can
> learn from someone's wins/losses we would certainly be grateful!
>
> Beyond the basics of setting up the hardcoded path segments for resolvers
> (all of our stuff is local/filesystem based) in the ivysettings file ie -
>
> <chain name="local-repository">
> <filesystem name="local-releases">
> <ivy
> pattern="${ivy.repo.dir}/release/[organization]/[module]/[revision]/ivy.xml"/>
> <artifact
> pattern="${ivy.repo.dir}/release/[organization]/[module]/[revision]/[artifact].[ext]"/>
> </filesystem>
> <filesystem name="local-integrations">
> <ivy
> pattern="${ivy.repo.dir}/integration/[organization]/[module]/[revision]/ivy.xml"/>
> <artifact
> pattern="${ivy.repo.dir}/integration/[organization]/[module]/[revision]/[artifact].[ext]"/>
> </filesystem>
> </chain>
>
> How are people specifying their resolve strategy to ensure that the right
> resolver/repository is used?
It depends on what you mean by the 'right' repository. Usually the
main special point is if you use a local repository, which must take
precedence over any other repository, to be sure what you publish here
will be picked up (useful when a developer is working on two modules
or more). This can easily be accomplished using a chain with
returnFirst="true". Then in regular sistuations if you ask a
latest.integration version both a release and an integration
repository are 'right', so a regular chain between the two is ok. If
you want some module to depend on the latest release, things get
slightly more complicated. You can use latest.release, this works
fine, expect that it needs to load your modules metadata to know if a
module is a release or not. In your case this shouldn't be an issue if
all your repositories are filesystem based (unless you use a slow
shared filesystem). If it is a problem you can also switch between
different settings (one with and one without your integration repo)
depending on your needs. But this applies to the whole dependency
resolution, and thus does not answer to finer grain needs (like
latest.release). A neat solution which require some work would be add
a filter to a dependency resolver, to use it only when latest.release
is asked, for instance. Not too difficult to implement, but require
some Java work (could be contribute back to the community if
implemented with some flexibility).
Xavier
> It may seem like a basic question, but it seems
> pretty critical to being able to properly setup and maintain a repository as
> Gilles described earlier. I'm assuming that the best way is to conditionally
> switch on ${ivy.status} and set ${ivy.resolver} accordingly. Is there
> anything 'under the hood' that we should be aware of that might help/hinder
> us??
>
> Thanks
> Todd
> --
> View this message in context: http://www.nabble.com/best-repository-layout--%28opinions-solicited%29-tf3682010.html#a10322325
> Sent from the ivy-user mailing list archive at Nabble.com.
>
>
--
Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/
RE: best repository layout? (opinions solicited)
Posted by todd lee <To...@amis.com>.
Gilles Scokart wrote:
>
>
> 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.
>
>
Thanks for the input Gilles, so given that this is something that we're in
the process of implementing right now, I wonder if someone would be willing
to share the details of their experience with implementing this? If we can
learn from someone's wins/losses we would certainly be grateful!
Beyond the basics of setting up the hardcoded path segments for resolvers
(all of our stuff is local/filesystem based) in the ivysettings file ie -
<chain name="local-repository">
<filesystem name="local-releases">
<ivy
pattern="${ivy.repo.dir}/release/[organization]/[module]/[revision]/ivy.xml"/>
<artifact
pattern="${ivy.repo.dir}/release/[organization]/[module]/[revision]/[artifact].[ext]"/>
</filesystem>
<filesystem name="local-integrations">
<ivy
pattern="${ivy.repo.dir}/integration/[organization]/[module]/[revision]/ivy.xml"/>
<artifact
pattern="${ivy.repo.dir}/integration/[organization]/[module]/[revision]/[artifact].[ext]"/>
</filesystem>
</chain>
How are people specifying their resolve strategy to ensure that the right
resolver/repository is used? It may seem like a basic question, but it seems
pretty critical to being able to properly setup and maintain a repository as
Gilles described earlier. I'm assuming that the best way is to conditionally
switch on ${ivy.status} and set ${ivy.resolver} accordingly. Is there
anything 'under the hood' that we should be aware of that might help/hinder
us??
Thanks
Todd
--
View this message in context: http://www.nabble.com/best-repository-layout--%28opinions-solicited%29-tf3682010.html#a10322325
Sent from the ivy-user mailing list archive at Nabble.com.
RE: best repository layout? (opinions solicited)
Posted by Gilles Scokart <gs...@gmail.com>.
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 <To...@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 <af...@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 <rb...@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/
Re: best repository layout? (opinions solicited)
Posted by Xavier Hanin <xa...@gmail.com>.
On 03-May-2007 12:27:52 EDT, Todd_Lee@amis.com <To...@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.xml"
> />
> <artifact
> pattern="${ivy.repo.dir}/[status]/[organization]/[module]/[revision]/[artifact].[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 <af...@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 <rb...@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/
Re: best repository layout? (opinions solicited)
Posted by To...@amis.com.
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.xml"
/>
<artifact
pattern="${ivy.repo.dir}/[status]/[organization]/[module]/[revision]/[artifact].[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)
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 <af...@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 <rb...@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.
Re: best repository layout? (opinions solicited)
Posted by Xavier Hanin <xa...@gmail.com>.
On 5/3/07, Bagwell, Allen F <af...@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 <rb...@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/
RE: best repository layout? (opinions solicited)
Posted by "Bagwell, Allen F" <af...@sandia.gov>.
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.
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 <rb...@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/
Re: best repository layout? (opinions solicited)
Posted by Xavier Hanin <xa...@gmail.com>.
On 5/2/07, Buck, Robert <rb...@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/
RE: best repository layout? (opinions solicited)
Posted by Gilles Scokart <gs...@gmail.com>.
I never did it personally, but you should maybe consider also the [branch].
Gilles
> -----Original Message-----
> From: Buck, Robert [mailto:rbuck@verisign.com]
> Sent: mercredi 2 mai 2007 19:17
> To: ivy-user@incubator.apache.org
> Subject: best repository layout? (opinions solicited)
>
> 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?
>
> Thanks in advance,
>
> Bob
>
>