Adopt TypeTable #676
Adopt TypeTable #676
Conversation
|
Ok, next fun edge case discovered on a failing test here: meta annotations. ~/.rewrite/classpath/.tt/org/springframework/spring-context/6.+/org/springframework/stereotype$ javap Service.class
public interface org.springframework.stereotype.Service extends java.lang.annotation.Annotation {
public abstract java.lang.String value();
}This of course differs quite a bit from what we see in Spring: @Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Component
public @interface Service {
/**
* Alias for {@link Component#value}.
*/
@AliasFor(annotation = Component.class)
String value() default "";
}So the recipe here relies on the Service annotation itself being a component, as per the matchers here. rewrite-spring/src/main/java/org/openrewrite/java/spring/RenameBean.java Lines 252 to 256 in 7015375 Looks like we need to capture yet more about the Service.class in openrewrite/rewrite` before we can replace the .jars here.
|
|
Not seeing the same (or any) failure locally; Ci reports this: This is the decompiled class as extracted locally public class org.springframework.web.server.ResponseStatusException extends org.springframework.core.NestedRuntimeException {
public org.springframework.web.server.ResponseStatusException(org.springframework.http.HttpStatus);
public org.springframework.web.server.ResponseStatusException(org.springframework.http.HttpStatus, java.lang.String);
public org.springframework.web.server.ResponseStatusException(org.springframework.http.HttpStatus, java.lang.String, java.lang.Throwable);
public org.springframework.web.server.ResponseStatusException(int, java.lang.String, java.lang.Throwable);
public org.springframework.http.HttpStatus getStatus();
public int getRawStatusCode();
public java.util.Map<java.lang.String, java.lang.String> getHeaders();
public org.springframework.http.HttpHeaders getResponseHeaders();
public java.lang.String getReason();
public java.lang.String getMessage();
}Where I don't immediately see differences with the orignal at Also not spotting any obvious issues with the public abstract class org.springframework.core.NestedRuntimeException extends java.lang.RuntimeException {
public org.springframework.core.NestedRuntimeException(java.lang.String);
public org.springframework.core.NestedRuntimeException(java.lang.String, java.lang.Throwable);
public java.lang.String getMessage();
public java.lang.Throwable getRootCause();
public java.lang.Throwable getMostSpecificCause();
public boolean contains(java.lang.Class<?>);
static {};
} |
|
@sambsnyd Given the limitations seen here and the potentially continued use of (some) packaged resource jars, how would you feel about swapping the order of these two lines such that packaged jars take precedent? That would make it a lot easier to add a type table for all, while still keeping around the odd jar where needed. Now it's a bit awkward having to download recipe jars for a select few only by commenting out the rest, and then creating a type table with the inverse such to the jars are not ignored because of fault entries in type tables. |
|
Endless fun to be had! TypeTable uses getResourceAsStream, which is documented as unstable ordering when multiple such resources exist.
|
|
Next issue: we're storing in the |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
|
Perfect, just what I was hoping for: a quick apply the plugin, run the task, and off we go! |
This reverts commit d3c135d.
What's changed?
Needs a new
What's your motivation?
Packaged resource jars could trip up scanners, even if the jars are not the classpath.
Anything in particular you'd like reviewers to focus on?
Over time we have also added test resource jars; these are typically used only to compile the before-test-sources, and not needed on the runtime classpath, because there JavaTemplate only needs the after-jar-versions. I think I'd prefer to keep that this way, and not unnecessarily inflate the
.tsvfile further; especially seeing how we also have to deflate that on startup, which could cause a bit of an IO spike.Any additional context
TypeTableas a substitute for packing whole jars intoMETA-INF/rewrite/classpathrewrite#4932