[TP] Update to Archetype 3.3.1 and unify archetypes OSGi metadata

[HannesWell]

• Adapt to API changes in archetype-common
• Updating to Archetype 3.3. allows to remove the 'maven-artifact-transfer' dependency.

[github-actions]

Test Results

  324 files  ±0    324 suites  ±0   1h 5m 43s ⏱️ + 5m 46s
  690 tests ±0    664 ✅  -  4  21 💤 ±0  3 ❌ +3  2 🔥 +1 
2 070 runs  ±0  1 996 ✅  - 10  63 💤 ±0  9 ❌ +9  2 🔥 +1 

For more details on these failures and errors, see this check.

Results for commit 37124de. ± Comparison against base commit e11227a.

♻️ This comment has been updated with latest results.

[laeubi]

@HannesWell I have checked this now and the problem ist that with the move to sisu now all components are tried to be looked up, and we have removed some dependencies intentionally. I'll check if we can use some bnd magic or if I can somehow intercept the loading of unwanted parts.

[laeubi]

Another issue seem that at least locally I can't see that the fragment approach works her all archetype artifacts are now plain bundles.

[laeubi]

With the proposed changes it works for me using plexus here. the main problem was that the fragments where not generated due to missing ${...} in if clause, so it used the literal what always evaluated to "true"

[laeubi]

By the way we probably should contribute to the archetype-plugin and ask if they can use constructor injection instead of field injection, then we can avoid the whole DI container thing and just create a default instance what should be enough for our case.

[HannesWell]

With the proposed changes it works for me using plexus here. the main problem was that the fragments where not generated due to missing ${...} in if clause, so it used the literal what always evaluated to "true"

Yes, then the implementation of the interface is found, however unfortunately the fields are still not injected. I have no clue why :/

By the way we probably should contribute to the archetype-plugin and ask if they can use constructor injection instead of field injection, then we can avoid the whole DI container thing and just create a default instance what should be enough for our case.

Yes that would be great.

[laeubi]

With the proposed changes I finally was able to use the injector instead of plexus and getting a proper injected instance.

Main problems here:

• javax.inject was not imported and so guice was not finding injectable fields / constructors
• We need a module that supplies the RepositorySystem required by the downloader

[laeubi]

@HannesWell I have pushed my current state and it looks like everything is injected correctly here:

• Use Sisu/Guice instead of plexus container for component lookup #1951

[HannesWell]

Main problems here:

* `javax.inject` was not imported and so guice was not finding injectable fields / constructors

* We need a module that supplies the `RepositorySystem` required by the downloader

Yes, thanks for finding them. Since explicitly listing the required imports seems to be very error-prone I not went with the opposite approach and excluded everything that we want to strip of. In the future we can simply inspect the generated Manifest and see what doesn't resolve and can then decide if we want to add it or exclude it.

I have also continued based on your changes and combined the two modules supplied by us and also found a way with that we can continue to use the archetypeDataSourceMap.

[HannesWell]

All tests except those for Windows succeed now but since I'm not sure if this a flaw in the test or an actual problem I'm postponing this to the next release cycle as I have to create the release for the 2025-03 now and have no more time to investigate this now.

[akurtakov]

@HannesWell Do you plan to revise this one? It would be nice to not have to extract dependency updates as done in #2019 .

[HannesWell]

I'll try to find the reasons for the failing tests and to compete this soon.

[eclipse-m2e-bot]

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

org.eclipse.m2e.core.ui/META-INF/MANIFEST.MF

An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch.

Git patch

From b9b29fb5ca0a4917d65ff797960abb60d52396e1 Mon Sep 17 00:00:00 2001
From: Eclipse M2E Bot <[email protected]>
Date: Sat, 18 Oct 2025 08:45:28 +0000
Subject: [PATCH] Version bump(s) for null object or invalid expression stream


diff --git a/org.eclipse.m2e.core.ui/META-INF/MANIFEST.MF b/org.eclipse.m2e.core.ui/META-INF/MANIFEST.MF
index 5acce318..3590bbc3 100644
--- a/org.eclipse.m2e.core.ui/META-INF/MANIFEST.MF
+++ b/org.eclipse.m2e.core.ui/META-INF/MANIFEST.MF
@@ -1,7 +1,7 @@
 Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-SymbolicName: org.eclipse.m2e.core.ui;singleton:=true
-Bundle-Version: 2.4.1.qualifier
+Bundle-Version: 2.4.2.qualifier
 Bundle-RequiredExecutionEnvironment: JavaSE-21
 Bundle-Name: %Bundle-Name
 Bundle-Vendor: %Bundle-Vendor
-- 
2.51.0

Further information are available in Common Build Issues - Missing version increments.