ctubbsii commented on PR #304: URL: https://github.com/apache/fluo-uno/pull/304#issuecomment-2506717034
I don't have an issue with these changes, but wanted to add some extra info for context: > using a mvn plugin seems less prone to risk vs a piped grep & cut command The risks of errors are very minimal. All the commands used are standard with modern linux distros. The biggest risk is getting xmllint from libxml instead of libxml2. Both have the `--shell` option to do xpath expressions, but only libxml2 has the `--xpath` option which would have made the command much cleaner: ```bash xmllint pom.xml --xpath '/*[local-name()="project"]/*[local-name()="version"]/text()' ``` The xpath expression could be further simplified (in either `--shell` or `--xpath`) if the xml elements weren't in the default namespace. Unfortunately, if you define a default namespace, xpath has no way of identifying elements explicitly, so you have to use the `local-name()` matchers. But if you strip off the `xmlns=` that defines the default namespace for elements, either by removing it or giving it a temporary name, you can greatly simplify the xpath expression: ```bash xmllint --xpath '//project/version/text()' <(sed 's/xmlns=/xmlns:bak=/' pom.xml) ``` All of these options (including the original) are blazing fast, much faster than using Maven. The last one would be my preferred approach, since it's the simplest to maintain and is super fast. Unfortunately, some distros don't have libxml2 yet and are still using libxml, so xmllint is too old to have the `--xpath` option. The Maven approach is slow, but it's nice because it's really portable and easy to maintain. It can also evaluate Maven properties, rather than just parse the XML values. We don't need that here, but it's nice to have an example to follow if we need to do something like it in the future. It seems like this feature might have been added in Maven 3.1 (well, the forceStdout option, to make it useful, was added then, anyway). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
