Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 33 additions & 0 deletions .cursor/rules/git-town-stack.mdc
Original file line number Diff line number Diff line change
@@ -0,0 +1,33 @@
---
description: Git Town stacked PR workflow — use external git-town-stack for merges and tree ops
alwaysApply: true
---

# Git Town stack (mandatory)

This repo uses Git Town stacked PRs. Tool lives **outside** this repo (do not add scripts/docs here):

```bash
GTS="${GIT_TOWN_STACK:-${GIT_TOWN_STACK_HOME:-$HOME/projects/sergehuber/git-town-stack}/git-town-stack.sh}"
cd "$(git rev-parse --show-toplevel)"
bash "$GTS" doctor
bash "$GTS" status
```

**Doctor** also flags unfinished Git Town runstate, mid-rebase, unmerged index, index lock.

For merge, rebase, sync, branch delete, or PR base changes on stack branches: run **doctor** and **status** first.

**After each squash-merge on GitHub:** `bash "$GTS" after-merge <pr#> --dry-run` then `after-merge <pr#>`.

**Routine sync (parent not merged):** `bash "$GTS" sync-stack`

**Never:** delete a remote branch while a child PR uses it as base; blind `git town sync --stack` after parent squash-merge; commit `git-town-stack.sh` into Unomi PRs.

**Dirty tree:** `git stash push -u` before `git town continue` / sync.

**Stale Git Town runstate** (blocks switch/sync): `git town status reset` if stack already fixed; never `git town undo` after good force-push.

**Squash-merge conflicts:** `git rebase --onto master <merged-parent-tip> <child>` then `git push --force-with-lease`. Tool docs: `~/projects/sergehuber/git-town-stack/docs/KNOWN-ISSUES.md`

**Current stack (verify with status):** master → UNOMI-880 (#763) → UNOMI-139 (#766). Merge top-down.
68 changes: 68 additions & 0 deletions .cursor/rules/jira-tickets.mdc
Original file line number Diff line number Diff line change
@@ -0,0 +1,68 @@
---
description: JIRA ticket style — problem-focused descriptions, plain-language summary, Confluence wiki markup
alwaysApply: true
---

# JIRA tickets (Apache Unomi / UNOMI-*)

When the user asks you to **draft, revise, or review a JIRA issue** (title, summary, description, acceptance criteria in JIRA), follow this style.

## Summary (plain language)

- One or two sentences a **non-technical reader** can understand (PM, release manager, new contributor).
- State the **user or team pain**, not the fix.
- Avoid file names, script names, class names, flags, and stack jargon unless the user explicitly wants a technical summary.

## Description (problem only)

- Describe **what is wrong today**, **who is affected**, and **why it matters**.
- Use a *What “good” would look like* section for **needs and outcomes** — still no implementation.
- Do **not** include in the main description: proposed scripts, architecture, file paths, CLI commands, code snippets, or step-by-step build instructions. Put those in a separate sub-task, PR, or “Technical notes” only if the user asks.

## Structure (Confluence wiki markup)

Write the description body in **JIRA / Confluence wiki markup** (not Markdown), so it can be pasted into JIRA’s wiki editor.

| Element | Markup |
|---------|--------|
| Heading 2 | `h2. Section title` |
| Heading 3 | `h3. Subsection` |
| Bold | `*text*` |
| Italic | `_text_` |
| Bullet list | `* item` (one `*` per line) |
| Numbered list | `# item` |
| Horizontal rule | `----` |
| Inline code | `{{monospace}}` |
| Code block | `{code}...{code}` |
| Info panel | `{panel:title=Note|borderStyle=solid}...{panel}` |
| Link | `[label|https://example.com]` |

## Template

```
h2. Summary

Plain-language summary here (1–2 sentences).

h2. What is going wrong today

* Bullet describing the current pain
* Another concrete symptom

h2. Impact

* Who suffers and how (developers, CI, releases, …)

h2. Who is affected

* Role or team

h2. What good would look like

* Observable outcome we need — *not* how to build it
```

## Title

- Short, problem-oriented (e.g. “Integration test runs lack clear memory and resource visibility”).
- Prefer “lack / hard to / cannot / unreliable” over solution verbs (“Add”, “Implement”, “Introduce”) unless the user wants a delivery-style title.
95 changes: 95 additions & 0 deletions .cursor/rules/pr-descriptions.mdc
Original file line number Diff line number Diff line change
@@ -0,0 +1,95 @@
---
description: GitHub PR descriptions — plain-language summary, self-contained context, concise structure
alwaysApply: true
---

# GitHub pull requests (Apache Unomi)

When the user asks you to **draft, revise, or create a PR description**, follow this style. Write for reviewers who may use **English as a second language** — see **Simple English** below.

## Simple English (required)

Apply to the **whole** description, not only the plain-language summary.

- Use **short sentences** (one idea each). Prefer **common words** over formal or idiomatic ones.
- Prefer: _fix_, _stop_, _allow_, _check_, _save_, _run_, _before_, _after_. Avoid: _leverage_, _remediate_, _no-op_, _land in that window_, _close those race windows_ (say _fix the race_ or _prevent the bug_ instead).
- Use **active voice**: “This PR adds a lock” not “A lock is introduced by this PR”.
- Avoid idioms, slang, and culture-specific phrases (_at the wrong moment_, _say the word_, _stand on its own_ → _can be read without other tickets_).
- Avoid double negatives and nested clauses. Split long sentences into two.
- Technical terms are fine when needed (scheduler, cache, lock), but explain the **effect** in plain words nearby.
- Bullets: start with a **verb**; keep each bullet to one or two short lines.

## Plain-language summary (required)

- Open with **2–3 sentences** a **non-technical reader** can understand (PM, release manager, new contributor).
- Explain **what Unomi feature or behavior** is affected in everyday terms (background jobs, rules/segments cache, REST API, etc.).
- State the **user or operator pain** (duplicate work, wrong data, failed shutdown, flaky CI) — not the fix.
- Avoid file names, class names, JIRA keys, and stack jargon in this section unless the user explicitly wants a technical opener.

## Self-contained (required)

- The description must **stand alone**: a reviewer who has not read linked tickets should understand **what changed and why**.
- Do **not** rely on “see UNOMI-xxx” or “as discussed in …” as the main explanation.
- JIRA keys and issue links belong in a **References** line at the bottom, not in the summary.

## Technical summary (required, concise)

- One short section with **3–5 bullets** on the actual fix — enough for a developer to orient without reading every commit.
- Name subsystems (scheduler, cache, REST) not individual methods unless a method name is the whole point.
- Skip commit hashes and per-commit review maps unless the PR is unusually large or the user asks for one.
- Keep the same **Simple English** rules: short lines, clear verbs, no idioms.

## Test plan (required)

- Checklist of what was run or what CI will run.
- Keep it factual; do not repeat the summary.

## Stacked PRs (when applicable)

This repo uses Git Town stacked PRs (see `.cursor/rules/git-town-stack.mdc`). When the PR is **not** based directly on `master`:

- Add a **Stack** section near the top (after the plain-language summary).
- Link the **parent PR** (the PR whose branch is the base branch) with title and number, e.g. `[UNOMI-880 (#763)](https://github.com/apache/unomi/pull/763)`.
- List any **known child PRs** at write time (same link format). If none exist yet, say so explicitly: _No child PRs yet._
- One sentence on **where this PR sits** in the merge order (e.g. “Merge after #763; #766 depends on this branch.”).
- The plain-language summary and **What changed** must still stand alone — stack links are navigation, not a substitute for explaining this PR’s scope.

Verify stack relationships with `bash "$GTS" status` before writing; do not guess parent/child numbers.

Skip the Stack section when the PR targets `master` directly and has no stack children.

## Structure (Markdown for GitHub)

```markdown
## Plain-language summary


## Stack

- **Parent:** [title (#nnn)](https://github.com/apache/unomi/pull/nnn) — merge this PR first
- **Children:** [title (#mmm)](https://github.com/apache/unomi/pull/mmm) — or _None yet_
- **Order:** …

## What changed

* …

## Test plan

- [ ] …

## References

UNOMI-xxx, UNOMI-yyy
```

## Title

- Short and outcome-oriented; JIRA keys in the title are fine when the repo convention uses them.
- Prefer describing the fix domain over internal ticket-only wording.

## Conciseness

- Target **~15–25 lines** total for typical bug-fix PRs (add ~3–5 lines when a Stack section is needed).
- Omit anti-patterns: duplicate bullets, “Review map” tables keyed only by ticket, empty boilerplate sections.
15 changes: 15 additions & 0 deletions extensions/router/router-service/pom.xml
Original file line number Diff line number Diff line change
Expand Up @@ -82,6 +82,21 @@
<artifactId>slf4j-api</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-junit-jupiter</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<scope>test</scope>
</dependency>
</dependencies>

<build>
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -59,6 +59,15 @@ public void setConfigSharingService(ConfigSharingService configSharingService) {
}

public String extractProfilesBySegment(ExportConfiguration exportConfiguration) {
Object segmentProperty = exportConfiguration.getProperty("segment");
if (segmentProperty == null || StringUtils.isBlank(segmentProperty.toString())) {
throw new IllegalArgumentException("Export segment is required");
}
Map<String, String> mapping = (Map<String, String>) exportConfiguration.getProperty("mapping");
if (mapping == null || mapping.isEmpty()) {
throw new IllegalArgumentException("Export mapping is required");
}

Collection<PropertyType> propertiesDef = persistenceService.query("target", "profiles", null, PropertyType.class);

Condition segmentCondition = new Condition();
Expand Down Expand Up @@ -97,6 +106,9 @@ public String convertProfileToCSVLine(Profile profile, ExportConfiguration expor

public String convertProfileToCSVLine(Profile profile, ExportConfiguration exportConfiguration, Collection<PropertyType> propertiesDef) {
Map<String, String> mapping = (Map<String, String>) exportConfiguration.getProperty("mapping");
if (mapping == null || mapping.isEmpty()) {
throw new IllegalArgumentException("Export mapping is required");
}
String lineToWrite = "";
for (int i = 0; i < mapping.size(); i++) {
String propertyName = mapping.get(String.valueOf(i));
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,105 @@
/*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
* The ASF licenses this file to You under the Apache License, Version 2.0
* (the "License"); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.unomi.router.services;

import org.apache.unomi.api.Metadata;
import org.apache.unomi.api.Profile;
import org.apache.unomi.api.PropertyType;
import org.apache.unomi.router.api.ExportConfiguration;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;

import java.util.Collections;
import java.util.HashMap;
import java.util.Map;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertThrows;
import static org.junit.jupiter.api.Assertions.assertTrue;

class ProfileExportServiceImplTest {

private ProfileExportServiceImpl profileExportService;

@BeforeEach
void setUp() {
profileExportService = new ProfileExportServiceImpl();
}

@Test
void extractProfilesBySegment_missingSegment_throwsIllegalArgumentException() {
ExportConfiguration configuration = new ExportConfiguration();
configuration.setProperty("mapping", Map.of("0", "firstName"));

IllegalArgumentException exception = assertThrows(IllegalArgumentException.class,
() -> profileExportService.extractProfilesBySegment(configuration));

assertEquals("Export segment is required", exception.getMessage());
}

@Test
void extractProfilesBySegment_blankSegment_throwsIllegalArgumentException() {
ExportConfiguration configuration = new ExportConfiguration();
configuration.setProperty("segment", " ");
configuration.setProperty("mapping", Map.of("0", "firstName"));

IllegalArgumentException exception = assertThrows(IllegalArgumentException.class,
() -> profileExportService.extractProfilesBySegment(configuration));

assertEquals("Export segment is required", exception.getMessage());
}

@Test
void extractProfilesBySegment_missingMapping_throwsIllegalArgumentException() {
ExportConfiguration configuration = new ExportConfiguration();
configuration.setProperty("segment", "frequent-buyers");

IllegalArgumentException exception = assertThrows(IllegalArgumentException.class,
() -> profileExportService.extractProfilesBySegment(configuration));

assertEquals("Export mapping is required", exception.getMessage());
}

@Test
void convertProfileToCSVLine_missingMapping_throwsIllegalArgumentException() {
ExportConfiguration configuration = new ExportConfiguration();
Profile profile = new Profile("profile-1");

IllegalArgumentException exception = assertThrows(IllegalArgumentException.class,
() -> profileExportService.convertProfileToCSVLine(profile, configuration, Collections.emptyList()));

assertEquals("Export mapping is required", exception.getMessage());
}

@Test
void convertProfileToCSVLine_nullPropertyValue_writesEmptyField() {
ExportConfiguration configuration = new ExportConfiguration();
configuration.setColumnSeparator(",");
Map<String, String> mapping = new HashMap<>();
mapping.put("0", "firstName");
configuration.setProperty("mapping", mapping);

Profile profile = new Profile("profile-1");
PropertyType propertyType = new PropertyType();
propertyType.setMetadata(new Metadata("firstName"));

String line = profileExportService.convertProfileToCSVLine(profile, configuration,
Collections.singletonList(propertyType));

assertTrue(line.isEmpty());
}
}
Original file line number Diff line number Diff line change
Expand Up @@ -293,9 +293,13 @@ private void testV2ModeBehavior() throws Exception {
try (CloseableHttpClient adminClient = HttpClients.custom()
.setDefaultCredentialsProvider(credsProvider)
.setDefaultRequestConfig(requestConfig)
.build();
CloseableHttpResponse jaasResponse = adminClient.execute(getRequest)) {
assertEquals("Private endpoint with JAAS auth should work in V2 compatibility mode", 200, jaasResponse.getStatusLine().getStatusCode());
.build()) {
try (CloseableHttpResponse jaasResponse = adminClient.execute(getRequest)) {
assertEquals("Private endpoint with JAAS auth should work in V2 compatibility mode", 200, jaasResponse.getStatusLine().getStatusCode());
}
try (CloseableHttpResponse privacyResponse = adminClient.execute(new HttpGet(getFullUrl("/cxs/privacy/info")))) {
assertEquals("GET /cxs/privacy/info with Karaf auth should work in V2 compatibility mode", 200, privacyResponse.getStatusLine().getStatusCode());
}
}
}

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -1754,7 +1754,7 @@ public void setPropertyMapping(final PropertyType property, final String itemTyp
Map<String, Object> subSubMappings = (Map<String, Object>) subMappings.computeIfAbsent("properties", k -> new HashMap<>());

if (subSubMappings.containsKey(property.getItemId())) {
LOGGER.warn("Mapping already exists for type {} and property {}", itemType, property.getItemId());
LOGGER.debug("Mapping already exists for type {} and property {}", itemType, property.getItemId());
return;
}

Expand Down
Loading
Loading