Explicit lucene version in org.eclipse.mylyn.tasks.index.core

[gnl42]

Not sure why doing a Clean Up on Tasks made this one pop up

org.eclipse.mylyn.tasks.index.core is asking for lucene 9.5.0 (don't know why). What we get from p2 is 9.9.1

[ruspl-afed]

asking for lucene 9.5.0 (don't know why)

it is asking for it to not get older versions from platform, that was a case some time ago. If you think this is an issue, feel free to create a PR

[gnl42]

Hmm, so when I Clean up Tasks I see this error in AbstractTaskListIndexTest:
The type org.apache.lucene.store.Directory cannot be resolved. It is indirectly referenced from required type org.eclipse.mylyn.internal.tasks.index.core.TaskListIndex

Changing the version in the manifest to 0.0.0 gets rid of the error.

Not sure how to proceed then

[ruspl-afed]

Interesting, perhaps there was a change of exported packages on lucene side or something similar.

Changing the version in the manifest to 0.0.0 gets rid of the error.

Could you please create a PR with this very change to let us see what pipeline tests think about it?

[merks]

The 9.5.0 is just a lower bound. I built new version of lucene in the nightly build yesterday:

I wonder which version is in your target platform?

It's strange that removing the bound would have any impact on the error. Does that change which version is show in the plug-in's dependencies?

[gnl42]

No, in either case its using 9.9.1

[ruspl-afed]

The 9.5.0 is just a lower bound.

Yes, true. It was an actual/ version of Apache Lucene when we (probably, I) did a reanimation procedures for Mylyn.

[merks]

Very strange. The problem you show is generally fixed by importing the package of the "indirectly required" class in the MANIFEST.MF...

[ruspl-afed]

May it be the consequence of clean-up, that cleared some declarations, then imports, and finally changed the resolution chain on IDE side?

[merks]

Maybe there is a split package involved because I see that org.apache.lucene.store is already imported. Let me look...

[merks]

This just makes no sense to me. If I pull the latest, should I be able to reproduce this?

[gnl42]

Clean up only affects the java classes. maven build has the same problem

[gnl42]

@merks Yes. Just select the Tasks node, right click, and select Cleanup

[merks]

I end up with a rather large set of errors:

This is generally how one fixes such a problem, i.e., import the package.

I really don't know how to make sense of all the errors and don't have significant time today to figure that out.

[gnl42]

That works for me as well. But then we have 9.9.1 in place and 9.5.0 in another.

[merks]

I only used that number because it's what PDE adds automatically. You can set it to 9.5.0 instead if you like. Also, given it's a test, it doesn't really matter to even set a constraint given that the constraint in the dependency will suffice.

[laeubi]

Well the problem is more this one if I understand the screenshot correct:

• StringConcatFactory can not be resolved eclipse-jdt/eclipse.jdt.core#1842

only possible fix for now is update the BREE of all bundle < 9 to something > 9 .... but this has nothing to do with imports (directly).

[gnl42]

Sorry, what is BREE?

I don't see anything in that ticket that relates to my problem

[merks]

Searching for this "BREE" header, I see some inconsistencies that could explain some of the errors:

[merks]

In my workspace I do see errors like this:

The project was not built since its build path is incomplete. Cannot find the class file for java.lang.invoke.StringConcatFactory. Fix the build path then try building this project

And I think that's what Christoph is alluding to...

You're likely to see this too if you update to the latest JDT...

[laeubi]

The ones with 1.8 are most likely causing issues, the ones with 11 are just bogus if you depend on latest platform that requires java 17 (so your bundle will never run/resolve < 17).