Add IRepository.contains(T) method

[HannesWell]

This methods provides a more convenient and in most cases faster way to test if a repository contains an element, compared to querying the repository for it.
IArtifactRepository already has a contains() method so this effectively only adds it for IMetadataRepository and generalizes it.

The implementation is based on the query() or everthing() implementation of the corresponding class, if possible.

The first of the two commits contains the clean-ups in the the IRepository and IArtifactRepository interfaces.

[github-actions]

Test Results

       9 files  ±0         9 suites  ±0   42m 48s ⏱️ + 3m 51s
2 175 tests ±0  2 171 ✔️ ±0    4 💤 ±0  0 ❌ ±0 
6 615 runs  ±0  6 604 ✔️ ±0  11 💤 ±0  0 ❌ ±0 

Results for commit 3436ab4. ± Comparison against base commit f891c9f.

♻️ This comment has been updated with latest results.

[merks]

Looks fine.

[laeubi]

could this be default implemented?

[merks]

An "everything" query can be like this

new ExpressionMatchQuery<>(IInstallableUnit.class, ExpressionUtil.TRUE_EXPRESSION)

so I think it would be tricky to create a correct query even for that case though I suppose with some instanceof tests one could do that...

[laeubi]

what about

query(QueryUtil.createMatchQuery(ExpressionUtil.TRUE_EXPRESSION)).toSet().contains(element)

[merks]

See org.eclipse.equinox.p2.query.QueryUtil.ALL_UNITS and note the type of that query:

IQuery<IInstallableUnit> ALL_UNITS = QueryUtil.createMatchQuery(ExpressionUtil.TRUE_EXPRESSION);

[HannesWell]

The problem is that here it is operated on the generic type T and not IInstallableUnit and I didn't found a way to create a query for any type (generic type probably won't work since that info is lost at runtime).

But it could be default implemented in the IMetadataRepository.

[HannesWell]

I also tought about moving contains() to queryable but discarded it due to the high implementation work.

But with a good default impl this would be much less work and it can be overriden where suitable.
I'll try it this evening.

[HannesWell]

Added it now and also provided more direct implementations in most complementing classes.

What do you think about keeping the contains(boolean) override in the IRepository in order to provide a bit better javadoc?
Unfortunately we cannot remove the contains method from the IArtifactRepository interface since this would be a binary incompatible change.

[laeubi]

Looks good to me if it helps to have better javadoc why not, but I think you need to default implement (and delegate to IQueryable impl) this as well as otherwhise you remove the default impl inherited from the parent otherwhise.

[merks]

It also should have an @Override if it's already declared in the base interface. And it would seem odd to add a method to API without an @since; I don't think I've ever seen an @since that includes a micro version. I mention this because of the other comment about there being no additional API; perhaps/probably a default method would additional API.

[HannesWell]

Looks good to me if it helps to have better javadoc why not, but I think you need to default implement (and delegate to IQueryable impl) this as well as otherwhise you remove the default impl inherited from the parent otherwhise.

Good point. Done that.

It also should have an @Override if it's already declared in the base interface.

Yes that, that's right as well. Done, too.

And it would seem odd to add a method to API without an @since; I don't think I've ever seen an @since that includes a micro version. I mention this because of the other comment about there being no additional API; perhaps/probably a default method would additional API.

Agree on that, lets see if the API tools are now fine with it.

[laeubi]

API tools now assumes no new API here so 2.7.200 seems sufficient.

[merks]

Maybe this assumption will change if/when a default method is implemented...

[HannesWell]

The build is now all-green.

For me this is ready.
@merks, @laeubi any final words?

[iloveeclipse]

See #320.