Hi
Ed,
Thanks
for the answer.
I
registered to cross-project a long time ago, I saw your mail
but I will re-read it carefully.
As
you stated in your solutions, there is a lot of persuasion
required ;)
That’s
why I sent this email to keep everyone informed.
I
will be happy to follow any kind of policy decided on
cross-project level for guava management.
(but
I didn’t saw any consensus on the subject. Maybe I missed
it?)
The
way I see it for
Papyrus context, we have 4 technical solutions:
-
Dropping
Guava
-
Removing
version (reuse Guava through a sub framework, like you do in
OCL)
-
Removing
the re-export (the problem will be handle by plugin
importing the Guavaized API)
-
Use
Import Package
The
fifth solution (outside Papyrus Team hand) would be to
convince EMF-Compare moving to Guava 21.
Obviously
there are pros and cons for each solution
J
We
need to agree on the solution with everyone (at least
EMF-Compare and Papyrus-RT Team)
Regards,
Benoît
Hi Benoit
You should be subscribed to cross-project-dev where I posted
the message below with Bugzilla references.
Bottom line: you have two choices.
a) Ideally you persuade all relevant Eclipse projects to
include accurate "uses" directives for Guava. Since there is
no tooling for this, it is really hard. I do not even know how
to do it for OCL.
b) You persuade all relevant Eclipse projects to include
Guava 21 within their dependency range so that in practice
Papyrus is single version.
OCL does not specify any Guava version bounds since it
re-uses Guava solely via Xtext to which the choice is
delegated. If you use Guava 21 you need the latest OCL N-build
to avoid use of a removed method.
NB. Particular challenges occur if Guava appears in APIs,
Therefore it is VERY important that e.g. Optional and MultiMap
are not used in interfaces.
Regards
Ed Willink