Pointing the Ivy dependency at your locally built module isn't the way to solve this. Instead when you build module B publish it to your local Ivy repository. When you resolve your dependencies for module A it will pull down module B from your local repository.
From the Ivy docs on the local repository:
The local repository is particularly
useful when you want to do something
without being disturbed by anything
else happening in the environment.
This means that whenever ivy is able
to locate a module in this repository
it will be used, no matter of what is
available in others.
For instance, if you have a module
declaring a dependency on the module
foo in revision latest.integration,
then if a revision of foo is found in
the local repository, it will be used,
even if a more recent revision is
available in other repositories.
This may be disturbing for some of
you, but imagine you have to implement
a new feature on a project, and in
order to achieve that you need to
modify two modules: you add a new
method in module foo and exploit this
new method in module bar. Then if you
publish the module foo to your local
repository, you will be sure to get it
in your bar module, even if someone
else publish a new revision of foo in
the shared repository (this revision
not having the new method you are
currently adding).
But be careful, when you have finished
your development and publish it on the
shared you will have to clean your
local repository to benefit from new
versions published in the shared
repository.
Note also that modules found in the
local repository must be complete,
i.e. they must provide both a module
descriptor and the published
artifacts.
The Using Ivy in multiple projects environment documentation has an example publish-local
Ant task that you might find useful.