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 normand gagnon <le...@gmail.com> on 2010/03/03 23:15:15 UTC
Sharing Ivy settings file amongst developpers
Hi,
I'm looking for a way to manage ivy settings file. My two main goals are
"build reproducibility" and provide a standard way within the enterprise to
resolve dependencies. I want to have your thoughts on this, do you use a
single ivy settings file for all your enterprise modules? Or are every
projects having their own ivy settings? Ar you committing settings file in a
SCM (and therefore, when building past versions of a given project, you are
using the ivy setting file that was in use at that time)?
Or maybe, you are giving a "template" of an ivy settings file to each
developer and you let them manage it as they want in their IDE, but when it
is time to publish a new module, they are forced to use a central build
system (or publishing is in fact managed by a continuous integration server
like Hudson)?
My idea is to let developer manages their own ivysettings file, which could
include another "enterprise-scope" ivysettings file, for the whole
development process. To publish new "public" release, then I would use a
central build system which would use an "official" ivysettings file that
would be used for all modules under the same branch. This to insure that
the dependencies are always resolved the same way when released publicly, so
you won't find in the public repository modules that were published
differently by different developers who were using different ivysettings
file.
Normand
RE: Sharing Ivy settings file amongst developpers
Posted by Shawn Castrianni <Sh...@halliburton.com>.
I chose checking the ivysettings files into an SCM repo "buildtools" so that I could recreate a past build if ever needed. If you don't version them, you don't know what state they were in at the time a build took place. We can store the subversion repo number of our ivysettings repo "buildtools" along with our module builds to have complete traceability back to source code.
Also, our main bat/sh scripts, that kick off the build that are also contained within the "buildtools" repo, check if the user's "buildtools" sandbox is uptodate and will update for them. This way, my users always have the latest version of the ivysettings files without having to put them on a website.
---
Shawn Castrianni
-----Original Message-----
From: Steele, Richard [mailto:rich@steelezone.net]
Sent: Thursday, March 04, 2010 8:57 AM
To: ivy-user@ant.apache.org
Subject: Re: Sharing Ivy settings file amongst developpers
Same here. We rejected putting in the SCM repo because we want our settings
shared across all projects, and at this company each project is in its own
repo.
We also have a shared (common) set of configurations that projects can
include, as well as the ivy.jar file on the same server.
You should consider whether you want to version the settings file or not.
There are tradeoffs here; version it and every project eventually needs to
make changes to ensure they're using the latest, don't version it and
possibly break builds at unexpected moments (if, for example, the repo names
in the settings file change).
Rich
2010/3/3 hyunsoo Lee <ne...@gmail.com>
> we are use ivysetting file on web server
> and use it by
>
> <ivy:settings id="ivy.artifact.settings" url="http://host.url
> /ivysettings.xml"
> />
>
>
> 2010/3/4 Geoff Clitheroe <g....@gmail.com>
>
> > We do something very similar except the settings and an ant build-base
> file
> > are located on a web server.
> >
> > Which ever way you go for hosting the files just think about what is
> > essentially your public api first - ie the filename, the access
> mechanism,
> > and how variables are named so that you can change under the hood without
> > breaking all your builds.
> >
> > If you want to look at ours as a starting point I'm happy to share. I
> > think
> > I have this done this before if you search the mailing lists you may find
> > enough.
> >
> > This is a common question - it would be ideal to make a jetty based
> project
> > that provides this functionality for the community.
> >
> > Cheers,
> > Geoff
> >
> >
> > On Thu, Mar 4, 2010 at 11:25 AM, Shawn Castrianni <
> > Shawn.Castrianni@halliburton.com> wrote:
> >
> > > I have all the ivy settings files (I use one per product release)
> checked
> > > into a SCM repo. This repo contains ant along with my master ant build
> > file
> > > in which all others import, ivy along with all the ivy settings files,
> > and
> > > any other build related tools a developer would use to build his code.
> A
> > > developer just checks out this buildtools sandbox and his module's
> > sandbox
> > > and he is ready to go. I have my master.xml build file coded to prompt
> > the
> > > user for what ivy settings file he wants to use by giving him a list of
> > > choices by product release name. He responds, and then my master.xml
> > loads
> > > in that ivysettings file and the build starts. The list of choices of
> > ivy
> > > settings files is constrained to only those that list the module to be
> > built
> > > in the modules section AND to only those that match the branch listed
> in
> > the
> > > modules section with the branch the sandbox was checked out from. In
> > other
> > > words, if the developer checked out a sandbox for module_A from
> branch_A,
> > > then only the ivysettings files that contain module_A with branch_A
> > > specified will show up in the list. If they hardcode an ivysettings
> file
> > > (possible by setting a RELEASE_NAME env variable in which my master.xml
> > > looks for) and that ivysettings file doesn't list that module OR
> > specifies a
> > > branch for that module that doesn't match the sandbox, then the
> developer
> > > gets a warning. This usually means the developer checked out the wrong
> > > branch sandbox to be used for the release he specified in which case he
> > > should get a warning because he is making a mistake.
> > >
> > > I have about 200 hundred developers across a large enterprise and this
> > > works beautifully.
> > >
> > > ---
> > > Shawn Castrianni
> > >
> > > -----Original Message-----
> > > From: normand gagnon [mailto:letrait@gmail.com]
> > > Sent: Wednesday, March 03, 2010 4:15 PM
> > > To: ivy-user@ant.apache.org
> > > Subject: Sharing Ivy settings file amongst developpers
> > >
> > > Hi,
> > >
> > > I'm looking for a way to manage ivy settings file. My two main goals
> are
> > > "build reproducibility" and provide a standard way within the
> enterprise
> > to
> > > resolve dependencies. I want to have your thoughts on this, do you
> use
> > a
> > > single ivy settings file for all your enterprise modules? Or are every
> > > projects having their own ivy settings? Ar you committing settings file
> > in
> > > a
> > > SCM (and therefore, when building past versions of a given project, you
> > are
> > > using the ivy setting file that was in use at that time)?
> > >
> > > Or maybe, you are giving a "template" of an ivy settings file to each
> > > developer and you let them manage it as they want in their IDE, but
> when
> > it
> > > is time to publish a new module, they are forced to use a central build
> > > system (or publishing is in fact managed by a continuous integration
> > server
> > > like Hudson)?
> > >
> > > My idea is to let developer manages their own ivysettings file, which
> > could
> > > include another "enterprise-scope" ivysettings file, for the whole
> > > development process. To publish new "public" release, then I would use
> a
> > > central build system which would use an "official" ivysettings file
> that
> > > would be used for all modules under the same branch. This to insure
> that
> > > the dependencies are always resolved the same way when released
> publicly,
> > > so
> > > you won't find in the public repository modules that were published
> > > differently by different developers who were using different
> ivysettings
> > > file.
> > >
> > > Normand
> > >
> > > ----------------------------------------------------------------------
> > > This e-mail, including any attached files, may contain confidential and
> > > privileged information for the sole use of the intended recipient. Any
> > > review, use, distribution, or disclosure by others is strictly
> > prohibited.
> > > If you are not the intended recipient (or authorized to receive
> > information
> > > for the intended recipient), please contact the sender by reply e-mail
> > and
> > > delete all copies of this message.
> > >
> >
>
>
>
> --
> --------------------------------------------
> 이현수
>
> 010-9920-1681
> nezahrish@gmail.com
> --------------------------------------------
>
Re: Sharing Ivy settings file amongst developpers
Posted by "Steele, Richard" <ri...@steelezone.net>.
Same here. We rejected putting in the SCM repo because we want our settings
shared across all projects, and at this company each project is in its own
repo.
We also have a shared (common) set of configurations that projects can
include, as well as the ivy.jar file on the same server.
You should consider whether you want to version the settings file or not.
There are tradeoffs here; version it and every project eventually needs to
make changes to ensure they're using the latest, don't version it and
possibly break builds at unexpected moments (if, for example, the repo names
in the settings file change).
Rich
2010/3/3 hyunsoo Lee <ne...@gmail.com>
> we are use ivysetting file on web server
> and use it by
>
> <ivy:settings id="ivy.artifact.settings" url="http://host.url
> /ivysettings.xml"
> />
>
>
> 2010/3/4 Geoff Clitheroe <g....@gmail.com>
>
> > We do something very similar except the settings and an ant build-base
> file
> > are located on a web server.
> >
> > Which ever way you go for hosting the files just think about what is
> > essentially your public api first - ie the filename, the access
> mechanism,
> > and how variables are named so that you can change under the hood without
> > breaking all your builds.
> >
> > If you want to look at ours as a starting point I'm happy to share. I
> > think
> > I have this done this before if you search the mailing lists you may find
> > enough.
> >
> > This is a common question - it would be ideal to make a jetty based
> project
> > that provides this functionality for the community.
> >
> > Cheers,
> > Geoff
> >
> >
> > On Thu, Mar 4, 2010 at 11:25 AM, Shawn Castrianni <
> > Shawn.Castrianni@halliburton.com> wrote:
> >
> > > I have all the ivy settings files (I use one per product release)
> checked
> > > into a SCM repo. This repo contains ant along with my master ant build
> > file
> > > in which all others import, ivy along with all the ivy settings files,
> > and
> > > any other build related tools a developer would use to build his code.
> A
> > > developer just checks out this buildtools sandbox and his module's
> > sandbox
> > > and he is ready to go. I have my master.xml build file coded to prompt
> > the
> > > user for what ivy settings file he wants to use by giving him a list of
> > > choices by product release name. He responds, and then my master.xml
> > loads
> > > in that ivysettings file and the build starts. The list of choices of
> > ivy
> > > settings files is constrained to only those that list the module to be
> > built
> > > in the modules section AND to only those that match the branch listed
> in
> > the
> > > modules section with the branch the sandbox was checked out from. In
> > other
> > > words, if the developer checked out a sandbox for module_A from
> branch_A,
> > > then only the ivysettings files that contain module_A with branch_A
> > > specified will show up in the list. If they hardcode an ivysettings
> file
> > > (possible by setting a RELEASE_NAME env variable in which my master.xml
> > > looks for) and that ivysettings file doesn't list that module OR
> > specifies a
> > > branch for that module that doesn't match the sandbox, then the
> developer
> > > gets a warning. This usually means the developer checked out the wrong
> > > branch sandbox to be used for the release he specified in which case he
> > > should get a warning because he is making a mistake.
> > >
> > > I have about 200 hundred developers across a large enterprise and this
> > > works beautifully.
> > >
> > > ---
> > > Shawn Castrianni
> > >
> > > -----Original Message-----
> > > From: normand gagnon [mailto:letrait@gmail.com]
> > > Sent: Wednesday, March 03, 2010 4:15 PM
> > > To: ivy-user@ant.apache.org
> > > Subject: Sharing Ivy settings file amongst developpers
> > >
> > > Hi,
> > >
> > > I'm looking for a way to manage ivy settings file. My two main goals
> are
> > > "build reproducibility" and provide a standard way within the
> enterprise
> > to
> > > resolve dependencies. I want to have your thoughts on this, do you
> use
> > a
> > > single ivy settings file for all your enterprise modules? Or are every
> > > projects having their own ivy settings? Ar you committing settings file
> > in
> > > a
> > > SCM (and therefore, when building past versions of a given project, you
> > are
> > > using the ivy setting file that was in use at that time)?
> > >
> > > Or maybe, you are giving a "template" of an ivy settings file to each
> > > developer and you let them manage it as they want in their IDE, but
> when
> > it
> > > is time to publish a new module, they are forced to use a central build
> > > system (or publishing is in fact managed by a continuous integration
> > server
> > > like Hudson)?
> > >
> > > My idea is to let developer manages their own ivysettings file, which
> > could
> > > include another "enterprise-scope" ivysettings file, for the whole
> > > development process. To publish new "public" release, then I would use
> a
> > > central build system which would use an "official" ivysettings file
> that
> > > would be used for all modules under the same branch. This to insure
> that
> > > the dependencies are always resolved the same way when released
> publicly,
> > > so
> > > you won't find in the public repository modules that were published
> > > differently by different developers who were using different
> ivysettings
> > > file.
> > >
> > > Normand
> > >
> > > ----------------------------------------------------------------------
> > > This e-mail, including any attached files, may contain confidential and
> > > privileged information for the sole use of the intended recipient. Any
> > > review, use, distribution, or disclosure by others is strictly
> > prohibited.
> > > If you are not the intended recipient (or authorized to receive
> > information
> > > for the intended recipient), please contact the sender by reply e-mail
> > and
> > > delete all copies of this message.
> > >
> >
>
>
>
> --
> --------------------------------------------
> 이현수
>
> 010-9920-1681
> nezahrish@gmail.com
> --------------------------------------------
>
Re: Sharing Ivy settings file amongst developpers
Posted by hyunsoo Lee <ne...@gmail.com>.
we are use ivysetting file on web server
and use it by
<ivy:settings id="ivy.artifact.settings" url="http://host.url/ivysettings.xml"
/>
2010/3/4 Geoff Clitheroe <g....@gmail.com>
> We do something very similar except the settings and an ant build-base file
> are located on a web server.
>
> Which ever way you go for hosting the files just think about what is
> essentially your public api first - ie the filename, the access mechanism,
> and how variables are named so that you can change under the hood without
> breaking all your builds.
>
> If you want to look at ours as a starting point I'm happy to share. I
> think
> I have this done this before if you search the mailing lists you may find
> enough.
>
> This is a common question - it would be ideal to make a jetty based project
> that provides this functionality for the community.
>
> Cheers,
> Geoff
>
>
> On Thu, Mar 4, 2010 at 11:25 AM, Shawn Castrianni <
> Shawn.Castrianni@halliburton.com> wrote:
>
> > I have all the ivy settings files (I use one per product release) checked
> > into a SCM repo. This repo contains ant along with my master ant build
> file
> > in which all others import, ivy along with all the ivy settings files,
> and
> > any other build related tools a developer would use to build his code. A
> > developer just checks out this buildtools sandbox and his module's
> sandbox
> > and he is ready to go. I have my master.xml build file coded to prompt
> the
> > user for what ivy settings file he wants to use by giving him a list of
> > choices by product release name. He responds, and then my master.xml
> loads
> > in that ivysettings file and the build starts. The list of choices of
> ivy
> > settings files is constrained to only those that list the module to be
> built
> > in the modules section AND to only those that match the branch listed in
> the
> > modules section with the branch the sandbox was checked out from. In
> other
> > words, if the developer checked out a sandbox for module_A from branch_A,
> > then only the ivysettings files that contain module_A with branch_A
> > specified will show up in the list. If they hardcode an ivysettings file
> > (possible by setting a RELEASE_NAME env variable in which my master.xml
> > looks for) and that ivysettings file doesn't list that module OR
> specifies a
> > branch for that module that doesn't match the sandbox, then the developer
> > gets a warning. This usually means the developer checked out the wrong
> > branch sandbox to be used for the release he specified in which case he
> > should get a warning because he is making a mistake.
> >
> > I have about 200 hundred developers across a large enterprise and this
> > works beautifully.
> >
> > ---
> > Shawn Castrianni
> >
> > -----Original Message-----
> > From: normand gagnon [mailto:letrait@gmail.com]
> > Sent: Wednesday, March 03, 2010 4:15 PM
> > To: ivy-user@ant.apache.org
> > Subject: Sharing Ivy settings file amongst developpers
> >
> > Hi,
> >
> > I'm looking for a way to manage ivy settings file. My two main goals are
> > "build reproducibility" and provide a standard way within the enterprise
> to
> > resolve dependencies. I want to have your thoughts on this, do you use
> a
> > single ivy settings file for all your enterprise modules? Or are every
> > projects having their own ivy settings? Ar you committing settings file
> in
> > a
> > SCM (and therefore, when building past versions of a given project, you
> are
> > using the ivy setting file that was in use at that time)?
> >
> > Or maybe, you are giving a "template" of an ivy settings file to each
> > developer and you let them manage it as they want in their IDE, but when
> it
> > is time to publish a new module, they are forced to use a central build
> > system (or publishing is in fact managed by a continuous integration
> server
> > like Hudson)?
> >
> > My idea is to let developer manages their own ivysettings file, which
> could
> > include another "enterprise-scope" ivysettings file, for the whole
> > development process. To publish new "public" release, then I would use a
> > central build system which would use an "official" ivysettings file that
> > would be used for all modules under the same branch. This to insure that
> > the dependencies are always resolved the same way when released publicly,
> > so
> > you won't find in the public repository modules that were published
> > differently by different developers who were using different ivysettings
> > file.
> >
> > Normand
> >
> > ----------------------------------------------------------------------
> > This e-mail, including any attached files, may contain confidential and
> > privileged information for the sole use of the intended recipient. Any
> > review, use, distribution, or disclosure by others is strictly
> prohibited.
> > If you are not the intended recipient (or authorized to receive
> information
> > for the intended recipient), please contact the sender by reply e-mail
> and
> > delete all copies of this message.
> >
>
--
--------------------------------------------
이현수
010-9920-1681
nezahrish@gmail.com
--------------------------------------------
Re: Sharing Ivy settings file amongst developpers
Posted by Geoff Clitheroe <g....@gmail.com>.
We do something very similar except the settings and an ant build-base file
are located on a web server.
Which ever way you go for hosting the files just think about what is
essentially your public api first - ie the filename, the access mechanism,
and how variables are named so that you can change under the hood without
breaking all your builds.
If you want to look at ours as a starting point I'm happy to share. I think
I have this done this before if you search the mailing lists you may find
enough.
This is a common question - it would be ideal to make a jetty based project
that provides this functionality for the community.
Cheers,
Geoff
On Thu, Mar 4, 2010 at 11:25 AM, Shawn Castrianni <
Shawn.Castrianni@halliburton.com> wrote:
> I have all the ivy settings files (I use one per product release) checked
> into a SCM repo. This repo contains ant along with my master ant build file
> in which all others import, ivy along with all the ivy settings files, and
> any other build related tools a developer would use to build his code. A
> developer just checks out this buildtools sandbox and his module's sandbox
> and he is ready to go. I have my master.xml build file coded to prompt the
> user for what ivy settings file he wants to use by giving him a list of
> choices by product release name. He responds, and then my master.xml loads
> in that ivysettings file and the build starts. The list of choices of ivy
> settings files is constrained to only those that list the module to be built
> in the modules section AND to only those that match the branch listed in the
> modules section with the branch the sandbox was checked out from. In other
> words, if the developer checked out a sandbox for module_A from branch_A,
> then only the ivysettings files that contain module_A with branch_A
> specified will show up in the list. If they hardcode an ivysettings file
> (possible by setting a RELEASE_NAME env variable in which my master.xml
> looks for) and that ivysettings file doesn't list that module OR specifies a
> branch for that module that doesn't match the sandbox, then the developer
> gets a warning. This usually means the developer checked out the wrong
> branch sandbox to be used for the release he specified in which case he
> should get a warning because he is making a mistake.
>
> I have about 200 hundred developers across a large enterprise and this
> works beautifully.
>
> ---
> Shawn Castrianni
>
> -----Original Message-----
> From: normand gagnon [mailto:letrait@gmail.com]
> Sent: Wednesday, March 03, 2010 4:15 PM
> To: ivy-user@ant.apache.org
> Subject: Sharing Ivy settings file amongst developpers
>
> Hi,
>
> I'm looking for a way to manage ivy settings file. My two main goals are
> "build reproducibility" and provide a standard way within the enterprise to
> resolve dependencies. I want to have your thoughts on this, do you use a
> single ivy settings file for all your enterprise modules? Or are every
> projects having their own ivy settings? Ar you committing settings file in
> a
> SCM (and therefore, when building past versions of a given project, you are
> using the ivy setting file that was in use at that time)?
>
> Or maybe, you are giving a "template" of an ivy settings file to each
> developer and you let them manage it as they want in their IDE, but when it
> is time to publish a new module, they are forced to use a central build
> system (or publishing is in fact managed by a continuous integration server
> like Hudson)?
>
> My idea is to let developer manages their own ivysettings file, which could
> include another "enterprise-scope" ivysettings file, for the whole
> development process. To publish new "public" release, then I would use a
> central build system which would use an "official" ivysettings file that
> would be used for all modules under the same branch. This to insure that
> the dependencies are always resolved the same way when released publicly,
> so
> you won't find in the public repository modules that were published
> differently by different developers who were using different ivysettings
> file.
>
> Normand
>
> ----------------------------------------------------------------------
> This e-mail, including any attached files, may contain confidential and
> privileged information for the sole use of the intended recipient. Any
> review, use, distribution, or disclosure by others is strictly prohibited.
> If you are not the intended recipient (or authorized to receive information
> for the intended recipient), please contact the sender by reply e-mail and
> delete all copies of this message.
>
Re: Sharing Ivy settings file amongst developpers
Posted by Kirby Files <Ki...@masergy.com>.
Shawn Castrianni wrote on 03/03/2010 05:25 PM:
> I have all the ivy settings files (I use one per product release)
> checked into a SCM repo. This repo contains ant along with my
> master ant build file in which all others import, ivy along with
> all the ivy settings files, and any other build related tools a
> developer would use to build his code. A developer just checks out
> this buildtools sandbox and his module's sandbox and he is ready to
> go.
[...]
> In other words, if the developer checked out a sandbox for module_A
> from branch_A, then only the ivysettings files that contain
> module_A with branch_A specified will show up in the list.
As always, Shawn, I am in awe of your descriptions of your dev/build
environment. You clearly get a lot more out of ant/ivy than most.
---
Kirby Files
Software Architect
Masergy Communications
kfiles@masergy.com
RE: Sharing Ivy settings file amongst developpers
Posted by Shawn Castrianni <Sh...@halliburton.com>.
I have all the ivy settings files (I use one per product release) checked into a SCM repo. This repo contains ant along with my master ant build file in which all others import, ivy along with all the ivy settings files, and any other build related tools a developer would use to build his code. A developer just checks out this buildtools sandbox and his module's sandbox and he is ready to go. I have my master.xml build file coded to prompt the user for what ivy settings file he wants to use by giving him a list of choices by product release name. He responds, and then my master.xml loads in that ivysettings file and the build starts. The list of choices of ivy settings files is constrained to only those that list the module to be built in the modules section AND to only those that match the branch listed in the modules section with the branch the sandbox was checked out from. In other words, if the developer checked out a sandbox for module_A from branch_A, then only the ivysettings files that contain module_A with branch_A specified will show up in the list. If they hardcode an ivysettings file (possible by setting a RELEASE_NAME env variable in which my master.xml looks for) and that ivysettings file doesn't list that module OR specifies a branch for that module that doesn't match the sandbox, then the developer gets a warning. This usually means the developer checked out the wrong branch sandbox to be used for the release he specified in which case he should get a warning because he is making a mistake.
I have about 200 hundred developers across a large enterprise and this works beautifully.
---
Shawn Castrianni
-----Original Message-----
From: normand gagnon [mailto:letrait@gmail.com]
Sent: Wednesday, March 03, 2010 4:15 PM
To: ivy-user@ant.apache.org
Subject: Sharing Ivy settings file amongst developpers
Hi,
I'm looking for a way to manage ivy settings file. My two main goals are
"build reproducibility" and provide a standard way within the enterprise to
resolve dependencies. I want to have your thoughts on this, do you use a
single ivy settings file for all your enterprise modules? Or are every
projects having their own ivy settings? Ar you committing settings file in a
SCM (and therefore, when building past versions of a given project, you are
using the ivy setting file that was in use at that time)?
Or maybe, you are giving a "template" of an ivy settings file to each
developer and you let them manage it as they want in their IDE, but when it
is time to publish a new module, they are forced to use a central build
system (or publishing is in fact managed by a continuous integration server
like Hudson)?
My idea is to let developer manages their own ivysettings file, which could
include another "enterprise-scope" ivysettings file, for the whole
development process. To publish new "public" release, then I would use a
central build system which would use an "official" ivysettings file that
would be used for all modules under the same branch. This to insure that
the dependencies are always resolved the same way when released publicly, so
you won't find in the public repository modules that were published
differently by different developers who were using different ivysettings
file.
Normand
----------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.