jena-benchmarks: Drop older shaded Jena baselines; keep only latest Jena 5 baseline

[arne-bdt]

Change

Description
In jena-benchmarks we currently build and include multiple shaded Jena baseline artifacts:

• jena-benchmarks-shadedJena480
• jena-benchmarks-shadedJena510
• jena-benchmarks-shadedJena550

Keeping these baselines increases build time and maintenance overhead. I also suspect they are no longer particularly meaningful comparators for current performance tracking.

Proposal

• Remove the three older baseline artifacts listed above.
• Keep only the latest Jena 5 baseline (currently: jena-benchmarks-shadedJena560).

Rationale

• Faster builds and simpler maintenance.
• Baseline comparisons stay focused on current, relevant versions.

Question for maintainers/users
Is anyone still relying on 4.8.0, 5.1.0, or 5.5.0 as baselines for long-term regression comparisons? If there is a concrete use case, we could keep one additional historical baseline, but otherwise I recommend simplifying to just shadedJena560.

@Aklakan What do you think?

Are you interested in contributing a pull request for this task?

Yes

[afs]

jena-benchmarks-shadedJena560 does not exist (yet :-)).

Digression:

Maybe we should put the benchmarking in a separate repository (which may, or not may not, be formally released or not released)

Or have it in the same repo (source in the release) but not in the same POM - we can release the outcomes of multiple build-runs for binaries in a single release.

And not ship "bsbm-1m.nt.gz" (it's 50% of the size of source-release).

[arne-bdt]

On the dataset: bsbm-1m.nt.gz is not essential for this task from my perspective, and I’d be fine with removing it to keep the repo lean.

On the baseline artifacts: my assumption is that jena-benchmarks-shadedJena560 would be created as part of this task, while the older ones would be dropped.

I’m also open to the idea of not having jena-benchmarks built as part of the main reactor (same top-level POM), but I’m not fully sure what the preferred Jena approach would be.
But how exactly would that look like?

My perspective on keeping jena-benchmarks as an asset in the Jena repository:

• It took me quite a while to set up initially (I was new to shading and had limited JMH experience).
• It was crucial for enabling me to develop and validate GraphMem2*.
• I used it to develop the COALESCE performance fix and to measure and prove the performance gains.
• It helped @Aklakan improve the spatial query index.

Overall, I see jena-benchmarks as a “red carpet” for Jena developers: a practical place for benchmarks and performance regression checks, with lower setup friction for contributors.

[afs]

On the baseline artifacts: my assumption is that jena-benchmarks-shadedJena560 would be created as part of this task, while the older ones would be dropped.

Great.

I’m also open to the idea of not having jena-benchmarks built as part of the main reactor (same top-level POM), but I’m not fully sure what the preferred Jena approach would be. But how exactly would that look like?

A second POM would work.

But this part is a longer term item for us to think through.

My perspective on keeping jena-benchmarks as an asset in the Jena repository:

It certainly is an asset.

[Aklakan]

I essentially agree with what has been said already.
I'd also vote for keeping jena-benchmarks in the repo so that changes to the jena code base can be evaluated right away.

If really needed (it seems its not ;) ), the "bsbm-1m.nt.gz" file could also be generated on-demand by invoking its data generator - I created bsbm maven artifacts some time ago from my repo.

[arne-bdt]

I've restructured the POMs as shown in this commit. I don't have much experience with POM management, so I'd appreciate feedback on this approach:

Changes:

1. Created dependencies-pom.xml in the project root
2. Moved all properties and dependencyManagement from pom.xml to dependencies-pom.xml and set it as parent
3. Removed jena-benchmarks from the <modules> section in pom.xml
4. Modified jena-benchmarks/pom.xml to use dependencies-pom.xml as parent and reference necessary Jena modules

Is this the correct approach for isolating jena-benchmarks while maintaining dependency management? Any issues with this structure?