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

[target] Implicit Plugin Dependencies is broken #451

Open
laeubi opened this issue Jan 31, 2023 · 5 comments · May be fixed by #1475
Open

[target] Implicit Plugin Dependencies is broken #451

laeubi opened this issue Jan 31, 2023 · 5 comments · May be fixed by #1475

Comments

@laeubi
Copy link
Contributor

laeubi commented Jan 31, 2023

The target environment has a section called "Implicit Plugin Dependencies", where one can add a plugin, and then the target is marked as "dirty" but save has no effect.

grafik

As this could become a very handy feature to include e.g. testing or annotation libs, it would be good to re-enable the feature, and possible have a way to select if this is a regular or test dependency.

@laeubi
Copy link
Contributor Author

laeubi commented Feb 7, 2023

If we fix this feature, I think it would be good to have the opportunity to select if a dependency should be added for test or for regular classpath. This would help in setting up certain test-frameworks much easier.

@merks
Copy link
Contributor

merks commented Mar 14, 2023

This seems like a cool and good feature.

I can imagine though that many people use the running SDK (or even EPP package) as their target platform, because it works, they don't know any better, and the better/proper approach of defining a target platform requires quite a bit of knowledge and significant skills to set up. I guess those people would have to add the right things manually for it to work if things only worked because of those (action at a distance) implicit dependencies.

It would still seems nice if one could somehow declare the plug-ins needed at development-time, in the plug-in itself. Because without that people will continue to use hacks, i.e., optional package imports or build.properties properties because they just work. I also say this because Oomph's targlets looks at the plugins to figure out what they require to figure out what to put in the target platform, so having this information in the plug-ins would be beneficial.

Of course no one is obligated to implement such a nice feature...

@laeubi
Copy link
Contributor Author

laeubi commented Mar 14, 2023

I can imagine though that many people use the running SDK (or even EPP package) as their target platform, because it works, they don't know any better, and the better/proper approach of defining a target platform requires quite a bit of knowledge and significant skills to set up.

  1. Create a new target
  2. add a new location, choose "Installation"
  3. use the drop-down to choose ${eclipse_home}

You now have a target that is your eclipse installation but you can further customize that, so beside from people probably not know about that, it does not seem too hard.

It would still seems nice if one could somehow declare the plug-ins needed at development-time, in the plug-in itself

I once suggested such a feature but it was rejected as "not interesting for PDE", nerveless the main disadvantage is that one has to configure it for each and every project, what is a bit cumbersome if one has not a rather static setup.

@laeubi
Copy link
Contributor Author

laeubi commented Nov 11, 2024

One observation:

  1. add an implicit dependency
  2. then change e.g the OS
  3. switch to the Source tab
  4. Now they are "magically" there...

So it seems mostly some issues with that changes are not correctly reflected in the model under some cases.

laeubi added a commit to laeubi/eclipse.pde that referenced this issue Nov 13, 2024
Currently editing the Implicit Plugin-Dpendencies only seem to work
randomly (e.g. if one change some other property along with the change).

This now do not refresh the full target (what seem to reset the
underlying model and remove the dirty flag before changes are applied)
but only updates the UI so finally these thing appear in the target
file.

Fixes eclipse-pde#451
@laeubi laeubi linked a pull request Nov 13, 2024 that will close this issue
@laeubi
Copy link
Contributor Author

laeubi commented Nov 13, 2024

I have now added a fix here:

then one can finally edit this, but I mentioned that it is not syntax-highlighted and I suspect Tycho is currently not supporting this at all, but it is very similar to extraRequirements (but not that flexible) in the target platform configuration so one could probably just enhance this there.

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 a pull request may close this issue.

2 participants