feat(policy-condition): add ViolationType for expression conditions

[1azunna]

Problem

PolicyCondition has no violationType field, so expression conditions cannot be created through this client — DependencyTrack rejects them with HTTP 400.

PolicyConditionResource.maybeValidateExpression (DT 5.0.3):

private void maybeValidateExpression(final PolicyCondition policyCondition) {
    if (policyCondition.getSubject() != PolicyCondition.Subject.EXPRESSION) {
        return;
    }

    if (policyCondition.getViolationType() == null) {
        throw new BadRequestException(Response.status(Response.Status.BAD_REQUEST)
            .entity("Expression conditions must define a violation type").build());
    }
    ...
}

Every other subject supplies its own violation type from the Subject enum, but EXPRESSION is declared EXPRESSION(null) and depends entirely on the explicit field:

public PolicyViolation.Type getViolationType() {
    if (subject != null && subject.violationType != null) {
        return subject.violationType;
    }
    return violationType;
}

Change

• PolicyCondition.ViolationType, tagged json:"violationType,omitempty"
• PolicyConditionViolationType with LICENSE, SECURITY, OPERATIONAL — matching PolicyViolation.Type
• PolicyConditionSubjectExpression, which was also missing from the subject constants

Because of omitempty, conditions using any other subject serialise byte-identically to before, so this is purely additive.

Tests

policy_condition_test.go covers the serialisation contract. Written as unit tests so they run without a container, following util_test.go:

• violationType is emitted for an expression condition
• it is omitted when unset, so existing subjects are unaffected
• it round-trips on unmarshal

go build ./..., go vet ./... and go test -run TestPolicyCondition ./... all pass.

Context

Found while adding expression-condition support to SolarFactories/terraform-provider-dependencytrack, which vendors a fork of this client. I raised it here rather than on that fork because this is the canonical home for the change and the fork is currently identical to main.

[owasp-dt-bot]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[nscuro]

Thanks @1azunna! I am wondering whether we should bump the major version of this library before we start introducing v5-specific stuff. It'd be a pain to have the client work with v4 and v5 going forward.

Thinking to cut a v1 release (since we're currently at v0 still) of the current state, and then merging your PRs into what will then become v2. WDYT?

[1azunna]

Thanks @1azunna! I am wondering whether we should bump the major version of this library before we start introducing v5-specific stuff. It'd be a pain to have the client work with v4 and v5 going forward.

Thinking to cut a v1 release (since we're currently at v0 still) of the current state, and then merging your PRs into what will then become v2. WDYT?

I think v4 and v5 compatible features can go in the v1 release and the v2 release can be strictly v5 features.