You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Grouper currently has no facility to manage third party library dependencies. Various JARs exist in the codebase itself that are pulled together via build scripts to execute compilation, packaging and deployment tasks. This approach has a number of drawbacks:

  • Difficult to upgrade a JAR, should a new version be required
  • Difficult to add new capabilities to Grouper which may depend on new JARs
  • Grouper codebase size is dramatically increased

We would want to devise a strategy by which such third party libraries can be pulled from public artifact repositories and integrated with the build. The following dependency management solutions may be considered.

Apache Ivy

The Grouper's build is managed via Apache Ant. Apache Ivy simply adds dependency management to Ant without replacing the existing build. Dependencies can be pulled from public repositories, conflicts managed and profiles created, etc. The advantage of using this option would be strong and tight integration with existing Ant scripts with relatively minimal effort. 

Apache Maven

Apache Maven is a build AND dependency management tool. While Ant is a bit more task-based and can provide script-like tasks and targets to execute builds without requiring any particular project structure or layout, Maven introduces a new standard layout for projects' resources and additionally allows support for managing and pulling in dependencies. Maven is also, unlike Ant, lifecycle based and so various phases in the overall build cycle are introduced by default that take care of compilation, packaging and deployment of artifacts without requiring much custom work. 

Notes to consider, if Maven is chosen:

  1. Existing ant build scripts need to be rewritten for Maven. Both are XML, but the syntax and format is totally different and it's not possible to use Maven's dependency management features without using its build features.
  2. Of course, it's all going to be XML. Configuration of builds, dependencies, profiles, plugins and such can be very verbose.
  3. Maven is not particularly good at running custom build scripts. All tasks need to fit into its own phases and the lifecycle cannot easily be intercepted or modified without writing maven plugins.
  4. Plenty of plugins exist for Maven that provide integration with all sorts of systems and capabilities.
  5. Grouper can take advantage of Maven's release plugin, by publishing artifacts to Maven central, etc when needed.
  6. JARs that are not found in any public repositories can be added to a maven build. While Maven has a concept of System dependencies, it would however be best if such JARs are put into a repository that is perhaps owned by Internet2. 
  7. Maven has a concept for Profiles, which allow specific settings to be activated per environment (dev, QA, etc)

 

Gradle/Grape

aaa

 

  • No labels