Skip to content

bndrun: refresh model before Resolve to get changes of included .bndrun files #6550

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

chrisrueger
Copy link
Contributor

@chrisrueger chrisrueger commented Apr 5, 2025

this fixes the problem that the Resolve button did not "see" changes of included .bndrun files (e.g. -include: shared.bndrun). So when you changed something in an include and pressed the "Resolve" button , then the "Resolve" process would still see the old state when the BndEditor was initially opened and as if the change to -include: shared.bndrun would not have happened. Previous workaround was to close and open the BndEditor of the actual .bndrun file again

Steps to reproduce

(you can also use this workspace3.zip)

  1. Create a.bndrun

-include: shared.bndrun

  1. Create a shared.bndrun
-runrequires: \
	bnd.identity;id='bar.impl',\
	bnd.identity;id='bar.consumer',\
	bnd.identity;id='org.apache.felix.gogo.command',\
	bnd.identity;id='org.apache.felix.gogo.runtime',\
	bnd.identity;id='org.apache.felix.gogo.shell'

-runfw: org.apache.felix.framework

-runrepos: \
	Workspace,\
	OSGI R8 - Build,\
	OSGI R8 - Runtime Distro
  1. Now open a.bndrun and press Resolve and do not close the editor.

Resolve should Succeed.

  1. Now open shared.bndrun and remove e.g. two runrepos
    -OSGI R8 - Build,
    -OSGI R8 - Runtime Distro

  2. go back to the still opened a.bndrun editor and press Resolve again.

Actual Result: It still resolves sucessfully.
Expected Result: Resolve should fail, because we removed the runrepos

If you close and reopen a.bndrun and resolve again, then this will expectedly fail, because the model is reloaded and the change to 'shared.bndrun' is seen.

This PR basically does that automatically on each press to "Resolve", so that the workaround is no longer needed.

It drastically improves developer experience, because I often was misled by the previous behavior, because I made a change and was suprised that it was not used. I found out by accident that I had to reopen the editor.

this fixes the problem that the Resolve button did not "see" changes of included .bndrun files (e.g. -include: shared.bndrun). So when you changed something in an include and pressed the "Resolve" button , then the "Resolve" process would still see the old state when the BndEditor was initially opened and as if the change to -include: shared.bndrun would not have happened. Previous workaround was to close and open the BndEditor of the actual .bndrun file again

Signed-off-by: Christoph Rueger <chrisrueger@gmail.com>
@chrisrueger chrisrueger merged commit a83e688 into bndtools:master Apr 6, 2025
11 checks passed
@chrisrueger
Copy link
Contributor Author

@pkriens I merged and will test it in the wild. I will keep an eye on it and revert if things broke. But it will be very useful for my other PR for the Eclipse P2 repo stuff like #6535 and #6536 where I need to update .bndrun and included .bndrun files all the time.

chrisrueger added a commit to chrisrueger/bnd that referenced this pull request Apr 6, 2025
This fixes a double-resolve when having resolveMode=AUTO introduced by my laster PR bndtools#6550

I needed to make the reallySave() method public, so I can call it from the Resolve button action in the RunRequirements part

Signed-off-by: Christoph Rueger <chrisrueger@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant