When we look at software builds, we’re looking, for the most part, at dependency problems. Traditional build scripting tools like Make or Ant are dependency languages. In order to do thing A, do B and C first, etc, etc.
The example below, in order to build the very small program “unique” main.o and strset.o need to be built. Those in turn rely on the input files main.c, strset.h and strset.c.
Understanding this graph is important for performing an incremental build. Continue reading
Every developer has done it. We just needed a bit of XML parsing or a better utility for dealing with connections. So we downloaded a library, stuck it in our code base and used it. Minutes later we felt great as our software had new capabilities quickly. Weeks later when things started to break we wondered, “Did one of those libraries also have bugs and does our team even know all the libraries it has let into its code?”
Reuse of open source or commercial libraries can be great. It lets a team focus on delivering unique functionality to the business without rewriting that XML parsing utility. However, a mature software development organization needs to understand some of the risks of reuse and take steps to chaperon their code. Continue reading
Many software projects have dependencies at run time on other projects that are built and deployed by the software team. Some version of another application must be present in order to run properly.
We see this situation appearing most often with Web Services, J2EE environments where EJB clients and applications must match, and even in the roll-out of related database schemas.
The basic problem these scenarios face, is that deployments must be orchestrated so that any related projects move through the life-cycle at the same time. The strategies for addressing this in AnthillPro are pretty straight-forward.
First create a new AnthillPro project that uses dependency rules to represent the full set of components that get released together. A “Build” of this project is mostly responsible for assembling a set of components that will be deployed together. At this point there are two main paths to follow: Continue reading
Lets say that we have two projects, Project A and Project B, such that Project A depends on Project B. When doing a build of Project A, we need to make sure that B.jar is in the classpath. Very often, as developers, we’ll have both Project A and Project B open in our IDE. For this example, let’s say Eclipse. In that case, we will configure Eclipse to recognize this dependency between Project A and B. Having Eclipse recognize this dependency is very nice during development because any refactorings will be applied to both projects and we can navigate code between the two project seamlessly. But, having this project based dependency does at least seem to present a bit of a problem when using the CodeStation plugin. Lets take a look at how we can solve this problem. Continue reading