[Anthill-pro] AnthillPro 3

[Eric Minick]

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

Antoine Levy-Lambert wrote:

>Hello Eric,
>
>we are currently in the evaluation phase to choose our dependency/repository management tool.
>
>
>Does your codestation system store its files in the source repository of the project(s) being built or in the database of Anthill3 ? If it is in the database of Anthill3, it will not be practical for people working with multiple repository branches. Because they will have to maintain some metadata in Anthill3 and some in their source repository. And one likes to cut a new branch by initially copying the dev branch or the main branch or whatever. Software houses have established procedures to do this automatically.
>
>In the eventuality that we would choose ivy, it looks like we will have to manually recreate in Anthill3 the different projects that we want to build.
>
>Another question : does Anthill3 have APIs to "automate" Anthill3, that is to create automatically projects, builders, workflows, ... or to change them or to trigger builds ? We might create a lot of projects, and in the eventuality that we prefer Ivy or DPML or M2 over Codestation as a dependency/repository management tool, we might be interested in writing a tool which would scan our codebase for say ivy.xml files and generate corresponding projects in AnthillPro with the right dependencies.
>
>Regards,
>
>Antoine
>
>
>-------- Original-Nachricht --------
>Datum: Thu, 24 Aug 2006 13:35:30 -0600
>Von: Eric Minick <etm at urbancode.com>
>An: anthill-pro at lists.urbancode.com
>Betreff: Re: [Anthill-pro] AnthillPro 3
>
>  
>
>>Antoine,
>>
>>At this point, there is no plan for an automated migration feature. The 
>>concepts between the programs are different enough that any automated 
>>migration is likely to be poor. Due to the option of using XML project 
>>templates, importing projects into Anthill3 is easy. Unfortunately, 
>>exporting AnthillPro 2.x projects into that object model requires too 
>>many configuration gaps and dangerous amounts of guesswork.
>>
>>Repository management is important, and we agree that it should 
>>integrate with the build tool. We really wanted to provide a tight 
>>integration with Ivy, but it just wasn't feasible. Instead we expanded 
>>an internal tool, Codestation, to fill this role. Codestation should be 
>>available to Anthill3 users in the next month or two and is being used 
>>internally. Codestation removes the dependency configuration file 
>>(ivy.xml or the maven2 pom) from the project workspace and instead 
>>relies on dependencies configured in Anthill3. Ant tasks or a simple 
>>stand alone command line tool can fetch the appropriate artifacts from 
>>the Anthill3 artifact repository.
>>
>>Smartfrog does look like an interesting tool. I think Anthill3's 
>>deployment capabilities should cover most of what SmartFrog could do. If 
>>not, you could integrate it if it provides a decent command line or 
>>email driven interface. Sometime down the road, we'll flesh out a plugin 
>>infrastructure to cater to tighter integrations with testing, bug 
>>tracking, and deployment tools. That won't be available in the 3.0
>>release.
>>
>>Regards,
>>Eric
>>
>>    
>>
>_______________________________________________
>Anthill-pro mailing list
>Anthill-pro at lists.urbancode.com
>http://lists.urbancode.com/mailman/listinfo/anthill-pro
>  
>