[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   57m 32s ⏱️ - 1m 33s
  689 tests ±0    661 ✅  -  4  21 💤 ±0   4 ❌ +2  3 🔥 +2 
2 067 runs  ±0  1 991 ✅  - 10  63 💤 ±0  10 ❌ +8  3 🔥 +2 

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

Results for commit b10c80f. ± Comparison against base commit 0f862e5.

♻️ 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.