Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[pull] main from openrewrite:main #38

Open
wants to merge 150 commits into
base: main
Choose a base branch
from
Open

Conversation

pull[bot]
Copy link

@pull pull bot commented Jan 16, 2025

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.1)

Can you help keep this open source service alive? 💖 Please sponsor : )

Summary by Sourcery

Tests:

  • Add a test to verify that system properties take precedence over project properties.

@pull pull bot added the ⤵️ pull label Jan 16, 2025
Copy link

sourcery-ai bot commented Jan 16, 2025

Reviewer's Guide by Sourcery

This pull request introduces a new test case to check whether system properties override project properties when resolving Maven dependencies. It also modifies the dependency resolution logic to prioritize system properties over project properties.

Sequence diagram for Maven property resolution with system property override

sequenceDiagram
    participant Client as Maven Client
    participant RP as ResolvedPom
    participant SP as System Properties
    participant PP as Project Properties

    Client->>RP: getProperty(key)
    alt System property exists
        RP->>SP: getProperty(key)
        SP-->>RP: return system property value
        RP-->>Client: return system property value
    else System property not found
        RP->>PP: get(key)
        PP-->>RP: return project property value
        RP-->>Client: return project property value
    end
Loading

Class diagram showing ResolvedPom property resolution changes

classDiagram
    class ResolvedPom {
        -Map~String, String~ properties
        +String getProperty(String property)
    }
    note for ResolvedPom "Modified to check System.getProperty() first"
Loading

File-Level Changes

Change Details Files
Added a test case to verify that system properties take precedence over project properties when resolving Maven dependencies.
  • Created a new test method systemPropertyTakesPrecedence to test the precedence of system properties over project properties in dependency resolution
rewrite-maven/src/test/java/org/openrewrite/maven/MavenParserTest.java
Modified the dependency resolution logic to prioritize system properties over project properties.
  • Updated the getValue method in ResolvedPom.java to first check for a system property with the given name before checking the project properties
rewrite-maven/src/main/java/org/openrewrite/maven/tree/ResolvedPom.java

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time. You can also use
    this command to specify where the summary should be inserted.

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

Copy link

coderabbitai bot commented Jan 16, 2025

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.


Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

greg-at-moderne and others added 26 commits January 16, 2025 06:14
* Correct TOML table parsing

Tables in TOML are not nested. I.e. the following should result in an AST with two top-level tables:

```toml
[table-1]
key1 = "some string"
key2 = 123

[table-2]
key1 = "another string"
key2 = 456
```

This has now been corrected in the parser.

* Adjust Gradle build script for ANTLR generation

* Add missing line terminators
…cipe execution (#4879)

* Add a test validation that execution context is not mutated during the recipe run.

* Allow messages from MavenExecutionContextView
…actId (#4905)

* Remove deprecated newArtifact Option

* Add newVersion Option to ChangePluginGroupIdAndArtifactId

* Apply formatter

---------

Co-authored-by: jestum_uhg <[email protected]>
Co-authored-by: Tim te Beek <[email protected]>
* Fix AddOrUpdateAnnotationAttribute unable to handle FieldAccess

(cherry picked from commit 7d7451a)

* Fix AddOrUpdateAnnotationAttribute unable to handle FieldAccess

(cherry picked from commit 7d7451a)

* Fix omitting addOnly and code style

* Use getCursor() for JavaTemplate

---------

Co-authored-by: Merlin Bögershausen <[email protected]>
#4888)

* Fixed missing version on multiple dependency management sections in multi-module projects and fixed ignored classifiers when choosing snapshot timestamp

* Formatted code, add unit test

* Added issue annotation to test

* Formatted

* Minor polish

* Further polish

* Generalize comment on continue

* Test for snapshot downloading issue

* Minor polish

---------

Co-authored-by: Tobias Hübner <[email protected]>
Co-authored-by: Tim te Beek <[email protected]>
* Fix parser

* restore build files

* Restore build file

* Put arguments on new line for readability

* Add test case (even though not reproducible)

---------

Co-authored-by: Tim te Beek <[email protected]>
Co-authored-by: Knut Wannheden <[email protected]>
* Groovy parser fail with Jenkinsfile and single line comment

* Minimize example

* Update rewrite-groovy/src/test/java/org/openrewrite/groovy/JenkinsFileTest.java

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

* Fix `StringUtils#indexOfNextNonWhitespace()`

A `//` sequence inside a multi-line comment caused trouble.

---------

Co-authored-by: Tim te Beek <[email protected]>
Co-authored-by: Tim te Beek <[email protected]>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Knut Wannheden <[email protected]>
* Add full blown support for Switch pattern matching
* Add print idempotency for Record pattern matching

---------

Co-authored-by: Laurens Westerlaken <[email protected]>
Co-authored-by: Tim te Beek <[email protected]>
* Pull up recipes from rewrite-migrate-java

* Also pull up `UpdateMavenProjectPropertyJavaVersion`

* Apply formatter
* feat: recipe for adding a key value pair to a json

* Slight polish

* Slight polish

* Strive for better formatting after insertion

* Improve some existing cases already

* Update test as suggested

* Refactoring, extract normalizeNewLines()

* Autoformat visitor for JSON

* Removing @NotNull annotations

* Basic tests for Autodetect

* Basic tests for NormalizeLineBreaksVisitor

* No public classifier

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

* Copy&paste typo

Co-authored-by: Knut Wannheden <[email protected]>

* Copy&paste typo

Co-authored-by: Knut Wannheden <[email protected]>

* Rename FindLineFormatJsonVisitor

* Adding package-info.java files

* Parsing the value parameter to JSON

* Fixed description

* Removing unneeded unQuote method

---------

Co-authored-by: dpozinen <[email protected]>
Co-authored-by: Tim te Beek <[email protected]>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Knut Wannheden <[email protected]>
* Support Groovy methods declaring generic type parameters

* Enable some working tests

Using `@ExpectedToFail` I found a bunch of tests which appear to have been fixed. I enabled those and replaced `@Disabled` with `@ExpectedToFail` on others.
While a class extending `groovy.lang.Script` typically represents the synthetic class representing the Groovy script as a whole, this is not necessarily the reason.

Additionally, also fix parsing of classes extending `Object` as well as correct type attribution for parsed classes with a super class (the `JavType.Class` should not declare any inherited methods).
* Map the type information provided by the compiler instead of trying to determine the type
In case a method's return type and method name contain the type and name of the method's first parameter (as in `public String foobar(String foo, String bar)`), the parameter alignment formatting could go wrong.
* Add backwards compatibility constructors

For the two recent changes to `J.Case` and `J.SwitchExpression` which both added new fields, the constructor changed and no constructor was added for API backwards compatibility.

This commit adds the corresponding constructors and annotates them both as `@Deprecated` and as `@ScheduledForRemoval` (from the JetBrains annotations). For the latter we provide a date value for the `inVersion` attribute as in `@ScheduledForRemoval(inVersion = "2025-05-01")`. This will allow us to implement some simple tooling to weed these constructors out again, without this chore getting forgotten.

* Polish
knutwannheden and others added 30 commits February 13, 2025 11:55
This could potentially correspond to some Java compiler internal object which we don't know what it is.
There was no path covering array type literals and as a fallback the method returned the input value itself. Both of these cases are now corrected so that annotation element values like `int[].class` are now correctly mapped.
This is required to allow the Java parser instance to be reused.
* Read all TypeTable `classpath.tsv.zip` files

* Look for jars first, to allow gradual adoption & improvements
* Support modifiers for Groovy method declaration parameters

* Merge visitModifiers and getModifiers

* Merge visitModifiers and getModifiers

* Improvement
…ts (#5041)

* Fixing line numbers for static star imports

* Fixing example of unit test not to have invalid import

* Revert to original duplicateImportsAndComments

* getStaticStarImports() to handle import statements spreading over several lines

* Refactoring, using StringUtils.countOccurrences
* fix: handle comment at the end of a method declaration

Multi line comment is allowed at almost any part of the Java source code
where whitespace is allowed. The reloadable Java parser visitor however
swallows multi line comment at the end of a method declaration, which
happens to be a common pattern in GWT in order to embed JavaScript in a
Java class.

Note that this effectively is a partial revert of #4412
(commit ac32851).

* Verify handling of one compilation issue per test case

---------

Co-authored-by: Tim te Beek <[email protected]>
* Improve Groovy parser modifier code

* Improve Groovy parser modifier code

* improvement

* improvement
* Groovy: Support property expression in annotation values

Support annotations like `@Foo(value = Test.CONST)` by using a custom `ResolveVisitor` which doesn't modify the AST by inlining the referenced constants in annotation attribute values.

* Polish

* Also support statically imported constants

* Polish

* Update rewrite-groovy/src/main/java/org/openrewrite/groovy/CustomResolveVisitor.java

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

* Replace CustomResolveVisitor by NoInlineAnnotationTransformationResolveVisitor

* improvement

* improvement

---------

Co-authored-by: Tim te Beek <[email protected]>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Jacob van Lingen <[email protected]>
* Upgrading ANTLR to 4.13.2

* Upgrading ANTLR to 4.13.2

* Regenerate ANTLR sources using ANTLR 4.13.2

* licenseFormat

---------

Co-authored-by: Tim te Beek <[email protected]>
* add test to reproduce behavior of adding a dependency inside a nested block

* simplify tests

* add test to reproduce behavior of adding a dependency inside a nested block

* simplify tests

* add `org.junit.vintage:junit-vintage-engine` to rewrite-test to fix IntelliJ test execution

* rename test to addToJVMTestSuite

* fix tests to fail and revert movement

* First version adding dependencies

* add support for suites without dependencies

* Apply typo fixes from review

Co-authored-by: Shannon Pamperl <[email protected]>

* Update rewrite-gradle/src/main/java/org/openrewrite/gradle/AddDependency.java

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

* align tests with review comments

* add disables tests to document open issues with the `AddDependency` recipe

* update tests to meet recipe configuration expectations

* move JVM plugin configuration resolution to search recipe

* Use `FindJMVTestSuites` in `AddDependency` and handle adding of dependencies with different configurations in JVMTestSuites

* add missing license information

* Apply code suggestions

* Light polish on FindJMVTestSuites

* Light polish on AddDependency

* Fix typo in recipe name

* Fix data table row insertion issue

* use `StringUtils#isBlank`

---------

Co-authored-by: Tim te Beek <[email protected]>
Co-authored-by: Shannon Pamperl <[email protected]>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* Fix: MergeYaml does not support insert-before options with comments

* Fix: MergeYaml does not support insert-before options with comments

* Improvement

* Add support for `After` insertMode

* Harder tests

* Improvements

* Improvement

* Improvement

* Add old constructor back

* Add old constructor back

* improvement
When a property in fact can assume a `null` value, the property's type must be annotated as `@Nullable`.
* Regenerate code using ANTLR 4.13.2

* Code suggestions

* Code suggestions

* Code suggestions

* Code suggestions
* Annotate `Hcl.Literal#value` as `@Nullable`

This also required annotating `Hcl.VariableExpression#name` as `@Nullable`, as currently the parser has a bug and parses a `null` literal as a `Hc.VariableExpression` with a `Hcl.Identifier` for the `name` property which represents the `null` value.

Additionally, there was a similar bug in the `JsonPath` grammar which had to be fixed.

* Fix copyright headers

* Apply best practices

---------

Co-authored-by: Tim te Beek <[email protected]>
Declare the root project's name. That's an [official Gradle recommendation]:

>Define the root project name in the settings file: The rootProject.name effectively assigns a name to the build, used in reports like Build Scans. If the root project name is not set, the name will be the container directory name, which can be unstable (i.e., you can check out your project in any directory). The name will be generated randomly if the root project name is not set and checked out to a file system’s root (e.g., / or C:\).

[1]: https://docs.gradle.org/current/userguide/multi_project_builds.html#sec:naming_recommendations
* Remove obsolete find-local-taint-flow-tests

* Remove obsolete dataflow-functional-tests
)

* JavaTemplate don't use type params on matching method invocations

* matchMethodWithGenericTypeWithConcreteType test case

* Fixing indents

* Adding EXACT_MATCH_EXPLICIT test case
Co-authored-by: lingenj <[email protected]>
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.