Get rid of Guava?

[LorenzoBettini]

Motivation

Do we really need Guava? With Java 8 we could do without.
While working on #135 I have already gotten rid of Guava Optional (in favor of Java 8 Optional, as reported by Sonar); similarly for Guava Object that can be replaced by Java Objects.

We could also do without Immutable Collections, couldn't we? Do we really need Immutable Collections properties?

My main concerns about our use of Guava is that in future versions of Eclipse a newer version of Guava might be present that is not more compatible with the one we use

[LorenzoBettini]

Of course we could keep Guava in tests if that's strictly necessary

[echebbi]

Guava is only there for legacy reasons. Now that Pitclipse relies on Java 8+ I see no obvious reason to keep the dependency to the library.

[LorenzoBettini]

NOTE: WorkspaceLevelClassFinder should use ProjectUtils, just like WorkspaceLevelProjectFinder does

[LorenzoBettini]

Maybe we can simply reorder the definition of enum values so that we don't need this guava Ordering?

    private enum StatusComparator implements Comparator<Status> {
        INSTANCE;

        private static final Ordering<DetectionStatus> STATUSES_IN_ORDER = Ordering.explicit(ImmutableList.of(SURVIVED,
                NOT_STARTED, STARTED, KILLED, TIMED_OUT, NON_VIABLE, MEMORY_ERROR, RUN_ERROR, NO_COVERAGE));

        @Override
        public int compare(Status lhs, Status rhs) {
            return STATUSES_IN_ORDER.compare(lhs.getDetectionStatus(), rhs.getDetectionStatus());
        }
    }

[LorenzoBettini]

    private List<String> splitBasedOnComma(String elements) {
        return Arrays.stream(elements.split(","))
                .map(String::trim)
                .filter(s -> !s.isEmpty())
                .collect(Collectors.toList());
    }

to an utils class

[LorenzoBettini]

For .runner project, MutationsModel remains

[LorenzoBettini]

todo org.pitest.pitclipse.ui

[LorenzoBettini]

REMOVED from bundles, now we can remove it from the classpath built when running PIT and from the dependencies of our features (probably also remove the repository reference?)

[Bananeweizen]

If I got it right, the 2.7.5 fixes the issue. It's meanwhile released, so you may want to upgrade again.

[LorenzoBettini]

@Bananeweizen I'm not sure I understand what you mean related to this very issue

[Bananeweizen]

Sorry for the confusion. The Tycho downgrade from 2.7.4 to 2.7.3 was attributed to this issue. Meanwhile 2.7.5 is released, and I had the understanding that the required/included behavior is as before, making the downgrade to 2.7.3 superfluous.

14b04b2

[LorenzoBettini]

Mh... the downgrade wasn't actually attributed to this issue. However, for sure now I can upgrade to Tycho 2.7.5 :)

[LorenzoBettini]

Oh, now I see that commit. It was part of the branch for this issue, but it's not related to that.