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

Partial support for parsing XML namespaces #3925

Merged
merged 32 commits into from
Jun 20, 2024

Conversation

ammachado
Copy link
Contributor

@ammachado ammachado commented Jan 16, 2024

What's changed?

Partial support for #3919, including namespace parsing and resolution

What's your motivation?

Anything in particular you'd like reviewers to focus on?

No

Anyone you would like to review specifically?

No

Have you considered any alternatives or workarounds?

No

Any additional context

No

Checklist

  • I've added unit tests to cover both positive and negative cases
  • I've read and applied the recipe conventions and best practices
  • I've used the IntelliJ IDEA auto-formatter on affected files

@ammachado ammachado marked this pull request as ready for review January 16, 2024 17:26
@timtebeek timtebeek added the enhancement New feature or request label Jan 16, 2024
@timtebeek
Copy link
Contributor

Thanks for getting this started @ammachado ! I've also tagged @knutwannheden for review since we're adding methods in the xml/tree package which require some additional scrutiny just to be safe.

@timtebeek
Copy link
Contributor

Once merged we can revisit these recipes in rewrite-migrate-java:
openrewrite/rewrite-migrate-java@9181655

timtebeek and others added 3 commits January 18, 2024 00:14
if (this.root == root) {
return this;
}
Map<String, String> namespaces = XmlNamespaceUtils.extractNamespaces(root.getAttributes());
Copy link
Contributor

Choose a reason for hiding this comment

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

What is the purpose of extracting the namespaces here?

Copy link
Contributor

Choose a reason for hiding this comment

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

Would we need this back in to later support namespace lookup for particular elements?

For example, using the test file, and wanting to look for the XPath /client/conduitSelector with the http://cxf.apache.org/jaxws namespace:

<jaxws:client name="{http://cxf.apache.org/hello_world_soap_http}SoapPort" createdFromAPI="true" xmlns:jaxws="http://cxf.apache.org/jaxws">
              <jaxws:conduitSelector>
                  <bean class="org.apache.cxf.endpoint.DeferredConduitSelector"/>
              </jaxws:conduitSelector>
          </jaxws:client>

@timtebeek timtebeek requested review from timtebeek and sambsnyd June 7, 2024 20:18
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.openrewrite.xml.internal;
Copy link
Contributor

Choose a reason for hiding this comment

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

Since this is returned from tree.Xml perhaps we should not have this class in an internal package?

import java.util.Collection;
import java.util.Map;

public class XmlNamespaceUtils {
Copy link
Contributor

Choose a reason for hiding this comment

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

Instead of a separate utils class, could this be methods on Namespaces instead you think?

@Value
public class Namespaces {

Map<String, String> namespaces = new HashMap<>();
Copy link
Contributor

Choose a reason for hiding this comment

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

A mutable map here might lead to problems with our immutability convention and detecting changes.

import java.util.Collection;
import java.util.Map;

public class XmlNamespaceUtils {
Copy link
Member

Choose a reason for hiding this comment

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

These could be methods on the Namespaces class for easier discoverability.

Comment on lines 36 to 39
public Namespaces add(String prefix, String uri) {
namespaces.put(prefix, uri);
return this;
}
Copy link
Member

Choose a reason for hiding this comment

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

Namespaces should be immutable like other parts of the LST

@sambsnyd
Copy link
Member

sambsnyd commented Jun 13, 2024

It seems like the recipes included in this PR are possible already without introducing new public API surface area in the form of this Namespaces concept. If this PR were just the recipes without the API changes it would be easier to accept.

github-actions[bot]

This comment was marked as outdated.

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

This comment was marked as outdated.

github-actions[bot]

This comment was marked as outdated.

timtebeek and others added 5 commits June 14, 2024 23:48
Got rid of Namespaces class as it is mostly a thin wrapper around Map
Merge XmlNamespaceUtils into Xml
When you control the definition of the type creating a "utils" class for it makes those methods harder for users to discover than if they were defined on the class itself
Moved unit test to use AssertJ assertions to be consistent with our other tests
Removed Namespaces field from XPathMatcher because it was unused
Sentence-cased recipe metadata
@sambsnyd sambsnyd merged commit 7a1b9c6 into openrewrite:main Jun 20, 2024
2 checks passed
crankydillo pushed a commit to crankydillo/rewrite that referenced this pull request Jul 11, 2024
* Partial support for parsing XML namespaces

* Adding namespace resolution

* Missing license header

* Adding recipes to search namespace URIs/prefixes

* Namespace shortcut methods on \'Xml.Document\'

* Change implementation to rely only on attributes

* Javadocs and cleanup

* Rename XmlNamespaceUtils & minor polish

Remove duplicate NonNull; see package-info.java
Validate argument not literal
Apply formatter

* Fix namespace search on XML hierarchy

* `ChangeNamespaceValue` now updates the `schemaLocation` attribute

* Consider namespaces on `SemanticallyEqual`.

* Suggestions from code review.

* Update rewrite-xml/src/main/java/org/openrewrite/xml/ChangeNamespaceValue.java

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

* Revert namespace comparison changes in `SemanticallyEqual`.

* Adding a Namespaces abstraction

* Add support for wildcard and local-name()

* Apply suggestions from code review

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

* Fix `Namespaces` mutability

* Adding an iterator implementation for `Namespaces`

* Replace `NotNull` with OpenRewrite's `NonNull`

* Polish.
Got rid of Namespaces class as it is mostly a thin wrapper around Map
Merge XmlNamespaceUtils into Xml
When you control the definition of the type creating a "utils" class for it makes those methods harder for users to discover than if they were defined on the class itself
Moved unit test to use AssertJ assertions to be consistent with our other tests
Removed Namespaces field from XPathMatcher because it was unused
Sentence-cased recipe metadata

---------

Co-authored-by: Knut Wannheden <[email protected]>
Co-authored-by: Knut Wannheden <[email protected]>
Co-authored-by: Evie Lau <[email protected]>
Co-authored-by: Evie Lau <[email protected]>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Sam Snyder <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

5 participants