Re: [Anthill] I need help with project concept

[Eric Minick <et...@urbancode.com>]

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