How WedaCon Simplifies IIQ Development with Maven

Managing identities, access, and workflows in a modern enterprise isn’t easy and neither is building the software that supports it. SailPoint IdentityIQ (IIQ) provides a powerful but complex framework for IAM. Its internal build processes rely on Apache Ant, a flexible yet manual system.

For growing teams or large deployments, this can mean repetitive tasks, scattered dependencies, and occasional surprises when deploying plugins or patches or adding/updating depedencies. Another build tool is Maven: a tool that promises automation, consistency, and easier dependency management. But Maven is not a silver bullet which comes without its own challenges, especially when applied to a proprietary system like IIQ.

In this post, we explore the journey from Ant to Maven in IIQ, discuss the advantages and pitfalls, and show how careful planning and expertise can unlock Maven’s potential for your IAM projects.

The Case

SailPoint IdentityIQ (IIQ) is a powerful IAM platform widely used for managing identities, workflows, and access governance. Internally, IIQ is built using Apache Ant, a flexible and procedural build system. For many developers, Ant works well but as projects grow, certain limitations start to appear.

Ant requires explicit instructions for everything: compiling source code, packaging JARs, copying files, and handling patches. Over time, this can lead to manual errors, inconsistent builds across environments, and difficulties managing dependencies or custom plugins.

The Goal

In modern software development, build automation and dependency management are key to ensuring reliability, consistency, and efficiency. Maven is a tool designed with these goals in mind. It brings built-in conventions, lifecycle automation, and centralized dependency management, which can be very useful for complex projects like IIQ. However, Maven is not a magic bullet. For teams without experience in its ecosystem, integrating Maven with IIQ can be tricky.

Challenges Using Maven Tools with IdentityIQ

• Legacy Ant Dependency: IdentityIQ’s default build system (Ant) lacks modern dependency management, forcing hybrid setups.
• Closed Ecosystem: Proprietary SailPoint JARs (e.g., sailpoint-tools.jar) aren’t in public Maven repos, requiring manual local installs.
• Classpath Conflicts: Maven’s transitive dependencies often clash with IIQ’s bundled libraries (e.g., log4j, spring-core).
• No Native POMs: Custom rules, connectors, or workflows lack standard pom.xml definitions, complicating dependency resolution.
• Deployment Friction: Maven-built artifacts must be manually copied to lib/custom/, disrupting CI/CD automation.
• Version Rigidity: Hardcoded library versions in IIQ’s Ant scripts complicate upgrades or security patching.

Result: Teams often face build inconsistencies, manual, error-prone processes, and maintenance overhead.

The Implementation

To tackle the challenges outlined, we designed a custom Maven-based workflow tailored for IdentityIQ. Instead of manually managing JAR files or copying libraries, our scripts automate the installation of all IIQ artifacts into a local or private Maven repository.

Key aspects of our implementation include:

• Automated dependency handling: All IIQ JARs, connectors, and helper libraries are installed automatically, ensuring consistent builds across all environments.
• Patch and eFix integration: Our scripts overlay patches and hotfixes in the correct order, creating versioned artifacts that can be reused safely.
• Repository-first approach: By leveraging a private Maven repository, teams can pull all required dependencies with a single comman. No more copying files or juggling classpaths.
• Repeatable builds: Developers can now run the same build process on any machine, guaranteeing the same artifact versions every time.

With this approach, the integration of Maven into IIQ becomes manageable, reliable, and repeatable.

A Simple Build Comparison: Ant vs Maven

Ant build.xml example:

<project name="my-project" default="dist" basedir=".">
    <property name="src" location="src/main/java/"/>
    <property name="build" location="target/classes"/>
    <property name="dist" location="target"/>

    <target name="compile">
        <mkdir dir="${build}"/>
        <javac srcdir="${src}" destdir="${build}"/>
    </target>

    <target name="dist" depends="compile">
        <mkdir dir="${dist}/lib"/>
        <jar jarfile="${dist}/lib/MyProject.jar" basedir="${build}"/>
    </target>
</project>

Here, every step like creating directories, compiling Java files, and packaging the JAR must be explicitly defined.

Maven pom.xml example

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.mycompany.exampleproject</groupId>
    <artifactId>my-project</artifactId>
    <version>1.0.0</version>

    <dependencies>
        <!-- Example dependency: Log4j -->
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core</artifactId>
            <version>2.20.0</version>
        </dependency>
    </dependencies>
</project>

To give a clearer picture, here’s a comparison highlighting the differences and potential benefits of Maven for IIQ projects:

At WedaCon Informationstechnologien GmbH, we specialize in end-to-end IAM and IIQ solutions. Our experience includes:

• Designing and implementing IIQ build pipelines.
• Developing custom scripts, plugins, and integrations for IIQ.
• Handling deployment, patching, and version management across environments.
• Helping clients unlock the potential of tools like Maven while mitigating the risks.

By combining IIQ expertise with modern build automation, we enable teams to develop and deploy custom, tailored IAM solutions. Reach out to us through one of our channels or take a look at our other solutions.