Support Workspace resolution of artifacts

[laeubi]

Currently an artifact has to be a remote (or local installed) artifact. It should be possible to reference a maven project as well.

[laeubi]

FYI @mickaelistria @HannesWell

I got this working in a little POC at least the case for a pom+its dependencies works quite well. For other project types it depends a bit on the type of project as it requires that the meta-info is available and I haven't checked yet how good PDE handles the case of changing meta-data.

Anyway I think we can add simple support first and enhance this in different areas (might include to have better m2e support for felix-bundle / bnd-maven plugin and changes in PDE).

Beside that I will postpone this until

• Create a feature out of a maven-target location #280 #376

is done to not get too much merge conflicts, but I'm confident we can get this in for 2022-03 release then.

[HannesWell]

For clarification, I assume you mean the resolution of Maven-Projects included into the Target-Platform via a Maven-Target?

I think that's a very handy feature which would simplify the workflow significantly if one has a Maven project, that is intended to be included in the TP, in the workspace because it should be modified (IIRC we already talked about this in a PR, didn't we?) and it would also help for the workspace case of Mickael's use-case in #418 (I followed that discussion in m2e a bit but didn't had the time to join in and just read through the PDE bug)?

Do you think we should enable this feature by default (as long as the project is open) or only on demand? Since it is an advanced feature that requires deeper understanding of Eclipse-PDE and Maven, I wonder if it would be good if the user has to opt-in in some way to use it, to not modify the TP unintentionally (as it was some of the main concerns in PDE Bug 577605?
AFAIK until now the TP is not influenced by projects from the workspace, so this would be a whole new workflow/concept (which isn't bad IMHO, but I think users should be aware of it).

Another question is how do we deal with changes?
If the dependencies of the workspace-resolved project the TP has to be (partially) reloaded. Other changes, for example in the Code should not require a TP-Reload because they are likely 'automatically' reflected into the workspace because the bundle is a directory and JDT hopefully recognises resource changes right automatically?

[laeubi]

I think this is just not that complicated as one might assumes.

Actually there are (right now) only the following cases:

1. a dependency is a pom-dependecy
2. a dependency is a bundle
3. a dependency is a plain jar

The first case is quite easy as we have nothing PDE has to actually understand and I would just resolve this at the time the target is opened and set, any changes in the pom afterwards won't make it to the target state until reloaded/set again. That is consistent with regular target handling as of today.

The second case is even simpler as all we need to do is nothing here, as PDE always gives precedence of works-pace projects over target supplied ones. All that needs to be done here is not give an error and maybe show a nice icon to the user that indicates that this maps to a workspace project (like done in the Project-Maven-Dependecies), we might even add that edit/double-click jumps to the project but that's al syntactic sugar I think.

The last case is a bit odd I think as it depends on whether automatic wrapping is enabled or not, if not, we could simply error, if wrapping is enabled I would for simplicity choose to wrap the content that is available at the time the target is set (similar to case 1). If one likes to have more dynamic support, one could simply use BND/Felix maven plugin to add OSGi meta-data at the first place.

[HannesWell]

I think this is just not that complicated as one might assumes.

Actually there are (right now) only the following cases:

1. a dependency is a pom-dependecy

2. a dependency is a bundle

3. a dependency is a plain jar

The first case is quite easy as we have nothing PDE has to actually understand and I would just resolve this at the time the target is opened and set, any changes in the pom afterwards won't make it to the target state until reloaded/set again. That is consistent with regular target handling as of today.

That's reasonable and consistent. But as outlined in the mentioned PDE bug it would be very handy if this would be reloaded automatically.

The second case is even simpler as all we need to do is nothing here, as PDE always gives precedence of works-pace projects over target supplied ones. All that needs to be done here is not give an error and maybe show a nice icon to the user that indicates that this maps to a workspace project (like done in the Project-Maven-Dependecies), we might even add that edit/double-click jumps to the project but that's al syntactic sugar I think.

Sounds good to. With bundles you mean Maven-Projects that either have a dedicate MANIFEST.MF or generate one using plug-ins like the Maven-Bundle-Plugin?
In this case the Maven update-mechanism likely has to be adjusted to add the PDE buildCommand to the .project file too.
Furthermore while I reworked M2E's Maven-runtime bundle that the M2E's classpath container did not work well in combination with PDE's requiredPlugins container. But I didn't investigate this in more detail yet.
But in the first place there is actually the question which container should be added to the .classpath? Only the M2E Maven-Dependencies container or the PDE's requiredPlugins container too? My first intuition is to only add the M2E container since a Maven Project should not have to relay on bundle dependencies respectively only on other Maven-Projects (they might be bundles too).

The last case is a bit odd I think as it depends on whether automatic wrapping is enabled or not, if not, we could simply error, if wrapping is enabled I would for simplicity choose to wrap the content that is available at the time the target is set (similar to case 1). If one likes to have more dynamic support, one could simply use BND/Felix maven plugin to add OSGi meta-data at the first place.

Sounds reasonable 👍🏽 But if 'dynamic' self updating locations are possible this could also be dynamic.

[laeubi]

But as outlined in the mentioned PDE bug it would be very handy if this would be reloaded automatically.

Maybe yes, but that's really not a priority for me. Targets don't reload themself (e.g. on folder change for directory locations, or if there are newer version for an update-site) and I think this is better handled on an upper level, my idea here is that a target location could be adapted to some kind of "Update-Checker" so in regular interval such a checker could be queried for updates and the the user could be asked to apply them (or choose to automatically apply them) like the "Search for Updates" Feature inside eclipse itself.

With bundles you mean Maven-Projects that either have a dedicate MANIFEST.MF or generate one using plug-ins like the Maven-Bundle-Plugin?

right, something that if build by maven in the end could be deployed inside an OSGi framework.

In this case the Maven update-mechanism likely has to be adjusted to add the PDE buildCommand to the .project file too.

As far as I can see m2e adds the pde-nature to the project what seems enough for the project to be recognized as a PDE Plugin.

the question which container should be added to the .classpath? Only the M2E Maven-Dependencies container or the PDE's requiredPlugins container too?

Only M2E Maven-Dependencies container would be necessary. There is nothing PDE has to resolve here.

But if 'dynamic' self updating locations are possible this could also be dynamic.

Especially for "wrapped" items the goal should always be to add first-class-metadata to the project/artifact itself. SO I don't want to support people to much to be lazy if they could archive more feature-rich metadata with simply adding felix/bnd maven plugin to their maven project.

[laeubi]

I'll mar this as fixed, we could open specific issues if there are any more things to do.