Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Repository Tagging 2.0: Add new -phases instruction to control which repos used for -buildpath, -testpath and resolve

Aperta
  • Qualcosa non va?
#7,288 1 commento 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@peterkir ci sta già lavorando.

Dal 27/10/2026.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
java
Ambito
tooling

Direzione di ricerca

Start by reading the discussion in issue #7131 linked from this issue, then trace how repository tags and repository selection currently affect -buildpath, -testpath, and .bndrun resolution. The issue proposes a new -phases instruction but does not identify implementation files or tests; first establish the relevant entry points and existing test coverage. Done means phases can select repositories by tag for the stated contexts without breaking repositories that have no tags.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Problem

Based on https://github.com/bndtools/bnd/issues/7131#issuecomment-4053458824 we want to make Repository tags more flexible.

Main idea: a new life-cyclephase instruction -phases:

-phases: \ 
	id='build'; tags='compile_ecl_4.37'
	id='resolve'; tags='compile_ecl_4.38,evaluation,development'
	...

This defines 2 phases build (-buildpath) and resolve (.bndrun resolution) and the tags (on repos) which should be considered.

Example

in cnf/build.bnd:
# some repos
-plugin.eclipse-build: ... tags = "compile_ecl_4.37"
-plugin.eclipse-resolve: ... tags = "compile_ecl_4.38, evaluation"
-plugin.research: ... tags = "research"

Then in some-project/build.bnd or also cnf/build.bnd:

-phases: \
	id='build'; tags='compile_ecl_4.37'; \
	id='resolve'; tags='compile_ecl_4.38, evaluation'; \
	id='sources'; tags='compile_ecl_4.37, research'

Or in .bndrun files:

-phases: \
	id='resolve'; tags='compile_ecl_4.38, evaluation'; \
	id='runtime'; tags=''

Advantages:

  • ✅ Same repos, different meanings per context
  • ✅ Research repo can still be used for source lookup without blocking resolution
  • ✅ Non-invasive: just don't include the research tag in any phase where you don't want it used
  • ✅ IDE can visualize phases as a table: repos as rows, phases (build/resolve/runtime/sources) as columns with checkboxes

Original comment

> collection of my thoughts and our discussion in dev meeting
> 
> # Introduce tag capability for repositories
> 
> * purpose of tags is structuring repositories by semantic meaning
> * allow scoping of repository usage for specific purposes, e.g. project/bnd file, bndrun file, resolving, compilation.
> 
> ## tags `attribute` on repositories
> 
> one or multiple `tags` can be attached to repositories
> tags are strings, separated by comma
> 
> e.g. sample tag names
> 
> * `compile`
> * `compile_ecl_4.25`
> * `compile_ecl_4.38`
> * `build`
> * `test`
> * `source`
> * `baseline`
> * `research`
> * `development`
> * `evaluation`
> * `any string you like`
> 
> tags can be associated to this reserved (but extensible) phases
> 
> ## NEW instruction `lifecycle-phase`
> 
> introduce a new instruction `phases`
> this allows to assign the tags to a phases
> 
> There are already some `pre-defined` phases ( ? prefix with bnd: ) 
> 
> * `none`	  - used for repos without tags (backward compatibility)
> * `build`     - used for **compiler** classpath - only one bnd workspace configured via `cnf/build.bnd`
> * `bnd:build` - used for **compiler** classpath - only one bnd workspace configured via `cnf/build.bnd`
> * `resolve`   - used by **resolver** for cap/req resolving of bndrun files
> * `runtime`   - used from launcher to install bundles into runtime
> 
> * `sources` - used by IDE for lookup of source code files
> 
> Additional phases can be introduced and configured.
> Purpose of this is to create a scope used only inside project or a specific bnd run file.
> 
> ```*.-bnd/*.bndrun
> -phases: \ 
> 	id='build'; tags='compile_ecl_4.37'
> 	id='resolve'; tags='compile_ecl_4.38,evaluation,development'
> 	...
> ```
> 
> ## examples
> 
> ### 
> 
> | repo | name             			| tags         | phase
> | p2   | eclipse-platform-baseline  | ecl-baseline | compile, re
> | p2   | eclipse-platform-latest    |	
> 
> ## edge cases
> 
> * What about auto-included version specific default repo `/cnf/cache/7.3.0`
> 
> ## additional ToDo's, considerations
> 
> * bnd and run editors have to 
> 
> 	* allow addition/removal of tags to repositories
> 	* allow assigning of tags to phases
> 
> * `Repository View`
> 
> 	* allow sorting by labels
> 	* maybe table with phases as additional columns and checkboxes for inclusion of repo in phase
> 	
> ## Ideas
> 
> * allow color assignment for tags to be used on labels 

 _Originally posted by @peterkir in [#7131](https://github.com/bndtools/bnd/issues/7131#issuecomment-4053458824)_
Lingua principale
Java
Stelle
557
Fork
303
Merge medio
19h 1m
PR unite (30g)
39

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di bndtools/bnd

Tutte le issue di bndtools/bnd

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.