Res,
I believe this is a fairly classic dependency management question with
several decent answers. The 'master build script' approach you have
taken is somewhat similar to the approach some Maven projects take.
Personally, I'm not a big fan of the approach, but it certainly works
for a number of organizations.
Anthill does have a dependency support mechanism of its own. At a high
level what it does is allow you to specify groups of projects that have
dependency relationships. You would then build these groups of projects
together and Anthill would tell your build scripts where to find the
shared jars - and likewise where to deliver the jars. You would need to
tweak your build scripts, but probably wouldn't need to overhaul them.
If this sounds like a viable approach, let us know and we can talk about
that in more depth. As a side note, Anthill Pro does something similar
but uses a different model to manage the dependencies. If the Anthill OS
model doesn't work for you, it might be worth a look.
If you are really serious about dependencies and don't really want your
build system managing them, I would use Ivy. The tool has been out for
about a year and while young is really nice. Instead of copying jar
files around, you use ivy to 'publish' them to a repository. Each
project will also have a file where you list out the jars (and versions
of jars) it is dependent on. When you start a build, you run an Ant task
to retrieve the dependencies first thing. The repository is usually just
files copied to the file system, but I believe there are extensions
available to back it to Subversion.
The nice thing about Ivy is that dependencies are handled the same way
on the build server that they are handled on the developer machine. The
more we can make the build process on the developer's machine like the
build process on the build server, the better.
On the side note, I'm not sure why Anthill would care if your build
script is checking out code, and if you wanted we could look into that.
I think that you are recreating the built in dependency management though.
Kind Regards,
Eric
Res Pons wrote:
> Sorry to post across the userlists.
>
> I'm using Subversion, Ant, and Anthill OS to automate my projects. We
> release many products in different projects.
>
> Currently I have set up a property sheet in Anthill for each project's
> build.xml and everything works fine. However, many of the projects
> create a .jar file which is used or needed by other projects. I tell
> my build.xml file in each project where to get the compiled jar files.
>
> With so many jar files being copied all over and our projects growing
> larger and larger daily, I was asked to create my own top parallel
> project and call all the build files from my master proj and make this
> project the exchange folder for all the jar files or any other
> artifact. It's a cleaner way, of course and more contained but it
> entails more work on my part.
>
> I've got my master build file to work, running at the cmnd prompt,
> however, Anthill does not like it when you tell a build file to check
> out other top level project files from the repo. Should I create dummy
> project files in Anthill just to check out the other projects and then
> let my build file take control?
>
> Somebody please give me guidance on the big picture. Is this a good
> idea to have a master and separate build project aware of all the
> other projects and but the other projects not being aware of it? How
> do I bypass the Anthill's shortcoming? By switching to CruiseControl?
> Are there or do you have any examples I could see please?
>
> _________________________________________________________________
> FREE pop-up blocking with the new MSN Toolbar – get it now!
> http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
>
> _______________________________________________
> Anthill mailing list
> Anthill@lists.urbancode.com
> http://lists.urbancode.com/mailman/listinfo/anthill
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Mar 8 16:19:55 2006