Skip to content

Conversation

@dweiss
Copy link
Contributor

@dweiss dweiss commented Sep 29, 2025

Fixes #15250, hopefully.

@dweiss dweiss added this to the 11.0.0 milestone Sep 29, 2025
@dweiss dweiss self-assigned this Sep 29, 2025
@github-actions
Copy link
Contributor

This PR does not have an entry in lucene/CHANGES.txt. Consider adding one. If the PR doesn't need a changelog entry, then add the skip-changelog label to it and you will stop receiving this reminder on future updates to the PR.

Comment on lines +171 to +173
// Collect dependencies from selected configurations
// and copy them over to a local configuration.
List<Dependency> subdependencies = new ArrayList<>();
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's 1:1 the same as before - dependency resolution can end up with different outputs... in theory at least. But it seems to work for me.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that was my question, too. You create a clone of the config, but how could they differ. I would say it would resolve the config separately (like a new project with all merged configs, correct?).

It may differ, I am opening the project with Groovy, works!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can theoretically imagine a situation with two configurations having a transitive dependency in different versions - then it would resolve this differently... I think. I wouldn't worry about it though, it's a hack already.

@uschindler
Copy link
Contributor

It looks like this works. It creates a new one-time configuration by copying all config entries into it. It's then its own config and can resolve it as wanted. Nice!

Now I see 2 new errors in Eclipse next to the heisenbug with LeafReaderContext:
image

@dweiss dweiss merged commit 2a68f37 into apache:main Sep 29, 2025
12 checks passed
@dweiss dweiss deleted the fix-eclipse-gradle-9.1 branch September 29, 2025 13:54
@uschindler
Copy link
Contributor

This is a bug in the ecj version that ships with my Eclipse release. The field is definitively initialized in the this() ctor called before. Maybe its another kind of Heisenbug!

@uschindler
Copy link
Contributor

There's already a bug open at ECJ and fixed already: eclipse-jdt/eclipse.jdt.core#4416

@uschindler
Copy link
Contributor

We don't see the bug in the Gradle build, because we have ECJ I20250926-1800, which has the fix already.


// Add gradle plugin portal to the source repository list and
// apply any ecj source repository hackery the same way as everywhere.
project.getRepositories().gradlePluginPortal();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we need this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are plugin dependencies (in the build-infra) that wouldn't be resolved from maven central alone and this configuration for Eclipse is set up in the root project (which only has mavenCentral as the source repository).

@uschindler
Copy link
Contributor

I found another bug with ECJ: eclipse-jdt/eclipse.jdt.core#4449

We can't trust Java 25 compilation with ECJ at the current stage. So all errors or non-errors should be carefully inspected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Eclipse configuration doesn't work

2 participants