Add an option to ignore references

[tivervac]

Note: there might be another way to do this, as I found a few half-wired up places. However, I couldn't find one while investigating my use case, so I added somewhat simple code that implements my use case.

I'm trying to proxy an entire target platform through an artifact repository, i.e., Nexus. As such, I've defined the software sites in my target platform to point to proxies of my own server. Sadly, it seems like p2 software sites are not necessarily self-contained. Namely, they can contain references to other repositories.

In our case, this causes us to load 122 external repos. Strikingly, most of these come from disabled references. As such I've added some code that would skip over these, let me know if that isn't allowed for some reason. Using only the enabled references, I still have 5 hits, much less, much faster, but not good enough. As such, I included a new backwards-compatible Software Site option that includes (or excludes) the traversal of references. In essence, this forces your software sites to be self-contained.

This ticket inspired another small ticket in p2.

[HannesWell]

Using only the enabled references, I still have 5 hits, much less, much faster, but not good enough.

That's a good catch. Disabled references should not be considered.

[tivervac]

@laeubi The build here seems to fail. Do you know what's going on? Also, what's the difference between continuous-integration/jenkins/pr-head and Jenkins?

[laeubi]

That looks strange an I have never seen this error before in PDE ... but the Github UI suggest that there are recent changes in the master branch, can you try to rebase your changes an current master if it solves the issue?

Beside that "continuous-integration/jenkins/pr-head" is the actual Jenkinsjob and "Jenkins " is the github action integration status check on Github level.

[HannesWell]

@laeubi The build here seems to fail. Do you know what's going on? Also, what's the difference between continuous-integration/jenkins/pr-head and Jenkins?

Looking at the failing tests it seems like new attribute somehow shows up in existing test-cases altough it should not be persisted if it's value is the default. I suggest you debug the failing cases in your IDE as JUnit Plug-in test and check what's going on.

[tivervac]

@laeubi The build here seems to fail. Do you know what's going on? Also, what's the difference between continuous-integration/jenkins/pr-head and Jenkins?

Looking at the failing tests it seems like new attribute somehow shows up in existing test-cases altough it should not be persisted if it's value is the default. I suggest you debug the failing cases in your IDE as JUnit Plug-in test and check what's going on.

Thanks, when I asked the question, the build was failing in a weird way. Now it's recognizable that these are test failures.

[laeubi]

@tivervac I think the tests needs adjustments now because they supply a new completion e.g. here:

There should not be any proposals at index 61. Following proposals found: [includeReferences]

So I think it fair enough to simply make the test assume that new attribute now (what ever it will be named).

[github-actions[bot]]

Test Results

   291 files  ±0     291 suites  ±0   56m 28s :stopwatch: - 5m 10s  3 526 tests ±0   3 468 :white_check_mark: ±0   58 :zzz: ±0  0 :x: ±0  10 875 runs  ±0  10 698 :white_check_mark: ±0  177 :zzz: ±0  0 :x: ±0 

Results for commit 05b656f7. ± Comparison against base commit 692af000.