ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From hyunsoo Lee <nezahr...@gmail.com>
Subject Re: Sharing Ivy settings file amongst developpers
Date Thu, 04 Mar 2010 04:32:21 GMT
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.clitheroe@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
--------------------------------------------

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