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 <[email protected]> > 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 < > [email protected]> 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:[email protected]] > > Sent: Wednesday, March 03, 2010 4:15 PM > > To: [email protected] > > 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 [email protected] --------------------------------------------
