Hi
The OOMPH integration is unlikely to help; it checks
installability.
With a conflicting singleton such as Guava
- the 'left-hand' subsystem successfully installs using version
X
- the 'right-hand' subsystem successfully installs using version
Y
At run-time, any class passed in the 'API' between left and
right subsystems gets a bad class version. This probably happens
as an integrating system's class loader must 'choose' whether it
uses 'left' or 'right' hand class versions.
If the 'API' is clean enough, e.g. no Optional, it can work.
Regards
Ed Willink
On 06/08/2019 07:43, Christian
Dietrich wrote:
@Michael do you mean this one (see screenshot)
Am 05.08.19 um 20:51 schrieb Michael Keppler:
Am 05.08.2019 um 17:43 schrieb Ed Willink:
But no. Sorry deep integrators must suffer.
Unfortunately there is no cross-project integration testing. But I
vaguely remember Eike or Ed has shown an Oomph setup called "egg-laying
wool-milk-pig" containing everything from a release train at one of the
early Oomph presentations. Maybe one could do at least some manual
integration testing using that Oomph setup? However, I don't find any
link to that anymore.
Ciao, Michael
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
