Skip to content
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

Missing version property in exported GEF packages #393

Open
ptziegler opened this issue Apr 2, 2024 · 4 comments
Open

Missing version property in exported GEF packages #393

ptziegler opened this issue Apr 2, 2024 · 4 comments

Comments

@ptziegler
Copy link
Contributor

Some weeks ago I ran into an issue where -after the 2024-03 release- some plugins were throwing a NoClassDefFoundError because GEF was not updated properly.
The problem: I use "Import-Packages" to declare the dependencies, which doesn't specify any version ranges. Because an older version was already installed, the Eclipse considered the version to be compatible and did not update it.

image

I don't think maintaining the versions manually is the solution here... And I'm open to suggestions on how this could be automated. My initial idea was to use the "Convert to Automatic Manifest Generation" and see how it goes, but perhaps there are other options?

@merks
Copy link
Contributor

merks commented Apr 2, 2024

Can you elaborate on “not updated properly”?

This sounds like a familiar problem but I want to be sure it’s the same problem I’m imagining.

@ptziegler
Copy link
Contributor Author

ptziegler commented Apr 2, 2024

Can you elaborate on “not updated properly”?

This sounds like a familiar problem but I want to be sure it’s the same problem I’m imagining.

It's this discussion here. The user updated to WindowBuilder 1.15 which depends on GEF 3.17 (or higher). But after the updated, GEF remained at the already existing 3.16.

@merks
Copy link
Contributor

merks commented Apr 3, 2024

So one (the?) significant problem to address is that the packages should be versioned? I use Oomph's versioning tool in a number of projects to automate such a thing. It's generally kind of complementary to the API tools helping to manage the micro version within the IDE, including quick fixes to fix all problems. E.g., if you change the version of a bundle, there will be errors that the exported package version doesn't match the bundle version and a quick fix to fix that. Maybe that's useful/interesting?

@ptziegler
Copy link
Contributor Author

So one (the?) significant problem to address is that the packages should be versioned?

That's correct. I would like to specify a version range with which WindowBuilder is compatible, similar to what is already possible with the Required-Bundle header.

if you change the version of a bundle, there will be errors that the exported package version doesn't match the bundle version and a quick fix to fix that. Maybe that's useful/interesting?

Having a quick-fix would help, but it's having yet another step which keeps me concerned. In my little dream world, the package versions are automatically updated with the bundle version where you would only have to do the initial configuration.

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

No branches or pull requests

2 participants