3.0.0-M3 Support for Apache Solr Removed

[ravig-kant]

No description provided.

[fabapp2]

Thanks for your PR @ravig-kant ! 🚀
I had one comment.

[fabapp2]

Thanks @ravig-kant 🚀

[ravig-kant]

Hi @fabapp2

Can you help me with the Test failure? I cannot find the correct API to get the super class in AST. OpenRewriteType.getExtends() does not return a value unless the superclass is in the same project.

[fabapp2]

Hi @ravig-kant

Sorry for my late reply, I am on parental leave.
You're correct. The API is not sufficient here. :/
In the past, there was an attempt to represent non-project sources with CompiledType but the getExtends() and getImplements() methods are not reflecting this (yet). It was more a spike than a completed feature.
Long story short, I can see two options (short-term):

1. Use plain OpenRewrite recipes (see: CrudRepositoryExtension which does something similar). This might be the "better" way as we want to contribute the modifying recipes to OpenRewrite too.
2. I (or you can if you like) provide a method isExtending(String fqName) in Type which we could use and encapsulate the logic there, probably using a custom OpenRewrite visitor as in 1. behind this method.
   This would free us from completing the API with CompiledType (or another approach) as a precondition for this PR.

Thoughts?

[ravig-kant]

Hi @fabapp2

I prefer option 2 as the new API can benefit other use cases. I can implement it but need around two weeks as I am travelling.

Thanks
Ravi

[fabapp2]

Hi @fabapp2

I prefer option 2 as the new API can benefit other use cases. I can implement it but need around two weeks as I am travelling.

Thanks Ravi

Great @ravig-kant !

Thanks for keeping up the great work and contributing to Spring Boot Migrator. 🚀
I think option 2 is a good choice for this problem as I need to think a bit about how to represent Java source files and compiled type information in the model. I am also on leave but will try my best to stay responsive.
Enjoy your travel Ravi

[ravig-kant]

Hi @fabapp2

I attempted to change the code as per approach 2. However, I couldn't find the required support in OpenRewrite to complete the implementation. ClassDeclration holds JavaType as JavaType.Unknown if the interface does not exist in the same project. The object graph I used to get the JavaType from ClassDeclaration is below.

classDeclaration.getImplements().stream().findFirst().get()).getClazz()

The object returned by the above expression is of type J.Identifier. J.Identifier has an instance variable called simpleName, which holds the correct value. I thought of combining it with the CompilationUnit.getImports(). I couldn't complete it this way because J.Identifier.simpleName is protected without any getters. So OpenRewrite needs to provide a getter for simpleName to complete this task.

[fabapp2]

Hi @ravig-kant

Thanks for looking into this again!

I'm guessing, but the reason for JavaType.Unknown could be missing type resolution in your test?
You can provide the required dependencies in TestProjectContext API like so:

  .withBuildFileHavingDependencies("groupId:artifactId:version")

Sandeep and Andrei had to solve something similar, here's what they did in CrudRepositoryExtension:

spring-boot-migrator/components/sbm-recipes-boot-upgrade/src/main/java/org/springframework/sbm/boot/upgrade_27_30/CrudRepositoryExtension.java

Lines 64 to 70 in b501d07

	private boolean doesItExtendPagingAndSorting(J.ClassDeclaration classDecl) {
	if (classDecl.getImplements() == null) {
	return false;
	}
	return classDecl.getType().getInterfaces().stream()
	.anyMatch(impl -> impl.getFullyQualifiedName().equals(pagingAndSortingRepository));
	}

Maybe something like could do the trick for us in OpenRewriteJavaSource:

public boolean isExtending(String fullyQualifiedName) {
    // and the if when anything in getClassDeclaration().getType().getInterfaces() might return null
    return getClassDeclaration().getType().getInterfaces().stream() 
             .anyMatch(impl -> impl.getFullyQualifiedName().equals(fullyQualifiedName));
}

Could try if this would solve our problem?

[ravig-kant]

Hi @fabapp2

Thanks for pointing out the correct API to build the TestProjectContext. I have updated the PR. The test is fixed. So it's ready to merge.

Thanks
Ravi

[fabapp2]

Thanks for your contribution @ravig-kant 🚀