[Anthill-pro] AnthillPro 3

[Antoine Levy-Lambert]

Thanks Eric,

Regards,

Antoine
-------- Original-Nachricht --------
Datum: Thu, 24 Aug 2006 17:08:02 -0600
Von: Eric Minick <etm at urbancode.com>
An: anthill-pro at lists.urbancode.com
Betreff: Re: [Anthill-pro] AnthillPro 3

> Antoine,
> 
> If you use a dependency system outside of Anthill3 and Codestation, it 
> will work the same way it does for developers and fetch all the 
> artifacts just fine. What you will need to do is establish those 
> relationships again in Anthill3. That's a bit of rework, but still 
> feasible. Anthill3 also offers a bit more flexibility on how and when to 
> build dependencies, so you would probably want to do that anyway. If 
> project A depends on B, should I always build B before A, or should I 
> just let A use the latest artifacts from B? Of course, it's more 
> complicated than that, but the point is that a simple dependency graph 
> doesn't always imply build rules directly.
> 
> The artifact storage will be maintained by Anthill3 not in source 
> control. Branching is also nicely handled. A dependency relationship in 
> Anthill3 requires that you specify the project, the artifact names, and 
> a workflow. A workflow is tied to source configuration that will contain 
> the branch information. The effect is that when you specify a 
> dependency, you specify which branch the dependency is from. So if you 
> create a maintaince branch of Project B and want Project A to stop using 
> the latest and greatest, but instead work off the maintainance branch, 
> you would create a new source configuration in Project B that works off 
> of the Branch, copy the existing build workflow, change the source 
> configuration in the copy to maintainance and change the dependency 
> configuration in Project A to use the new workflow. If you followed 
> that, give yourself a pat on the back.
> 
> As an alternative to branching the dependent project, you may just 
> specify that some specific build version should always be used. Or, the 
> latest artifact from a build life to have attained some status (perhaps 
> we only want to use shared libraries that have been tested).
> 
> As for automating the configuration, there are a couple of options.
> 
> There is an existing interface to import and export projects and 
> dependencies. That requires using the web interface (Administration -> 
> Import/Export) to enter the xml definition of a project and afterwards 
> enter a dependency graph. For entering a handful of new projects at a 
> time, this may be the way to go. You could export a project configured 
> through the Web UI, as a template and have a small program make 
> adjustments to those templates based on your criteria. Then you could 
> load those new projects and dependencies back in. Not entirely 
> automated, but faster and less error prone than configuring by hand over 
> and over again.
> 
> The fancier approach would be to use the Anthill3 Client API which is in 
> Java. This would give you access to most of the internals of the 
> application from a remote application. When we get a chance to write a 
> command line interface for Anthill3, it will be around this API. In all 
> likelyhood, you would write either a small Java application to do this 
> work or use a Java based scripting language like Beanshell, Groovy or 
> Jython.
> 
> While the Client API might be appropriate for build triggers, an 
> alternative would be to use the 'Repository Triggers'. Those triggers 
> provide a url that can be used to start a build for that project.  The 
> intent is that repository 'hook' scripts would hit that URL to 
> communicate that files had been committed and a build should happen. But 
> anything could hit those urls and achieve the same thing.
> 
> Regards,
> Eric
>