Tag Archives: Maven

Dependencies All the Way Down – Builds (2 of 4)

Posted on by
Reply
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.

http://www.cs.princeton.edu/courses/archive/spr01/cs217/slides/5.make.pdf

Understanding this graph is important for performing an incremental build. Continue reading →

AnthillPro is a Maven Repository!

Posted on by
Reply

and it’s freindly with the Maven repo you already have

AnthillPro’s integrated build artifact repository is one of our favorite things about the tool. After all, if you’re going to support moving a build through it’s lifecycle towards production with deployments and tests, it’s helpful to manage the files that are “the build”.The repository is also hugely helpful for managing build time dependencies between projects. However, teams using Maven don’t necessarily need a new repository and definitely don’t want a new way of specifying dependencies. Continue reading →

Maven’s Strengths and Weaknesses as a Dependency Management System

Posted on by
Reply

For many Java teams, switching to Maven will introduce them to formal dependency management. Maven actually does a pretty decent job and is a fantastic system out of the box for informal projects. However, for teams looking to implement rigorous component reuse policies, Maven falls short.

Last month, in our article Chaperoning Promiscuous Software Reuse, we reviewed four elements of a successful strategy for managing components. Briefly, these elements are:

  1. Testing and Validation of 3rd party components Only libraries approved for reuse should be used by developers. If developers want to use additional libraries, they can submit them for screening.
  2. A Definitive Software Library: A team should have an official storage place for reusable, versioned components (both internal and 3rd party).
  3. Using Protection: A team should have an “immune system” that rejects libraries other than those from the DSL.
  4. Rapid impact analysis audit When something goes wrong, it should be easy to determine what versions of which components were used by the project. Continue reading →