[
https://issues.apache.org/jira/browse/BEAM-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16765157#comment-16765157
]
Scott Wegner commented on BEAM-4050:
------------------------------------
There's still a bunch of raw XML manipulation that is verbose and error-prone,
i.e. [everything within the pom.withXml
block|https://github.com/apache/beam/blob/7940259137e20d5eb35b4be142ff628e078fe6a1/buildSrc/src/main/groovy/org/apache/beam/gradle/BeamModulePlugin.groovy#L1031].
In addition, much of the pom generation logic [was
duplicated|https://github.com/apache/beam/blob/a5a139d5c7be01fbbd1f8b14df9ef5e05696af2c/buildSrc/src/main/groovy/org/apache/beam/gradle/VendorJavaPlugin.groovy#L221]
for the vendored artifacts.
That being said, this code doesn't change often and it hasn't bothered me since
doing the initial Maven -> Gradle migration. I still think it would be nice if
the logic was a bit cleaner, but it's not very high priority and if Gradle
doesn't natively support a better syntax I don't think we should invent one.
> Move pom generation metadata logic out of build_rules.gradle
> ------------------------------------------------------------
>
> Key: BEAM-4050
> URL: https://issues.apache.org/jira/browse/BEAM-4050
> Project: Beam
> Issue Type: Sub-task
> Components: build-system
> Reporter: Scott Wegner
> Priority: Minor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When preparing a release, we generate pom files for each artifact to be
> released. Most of the pom structure is filled in automatically, but there is
> a good deal of metadata that needs to be manually added. The [code for
> manipulating the XML
> structure|https://github.com/apache/beam/blob/c78b96a67c0313f44d78262ee46f86aa4866a3aa/build_rules.gradle#L605]
> is verbose and it would make more sense to actually express it as XML rather
> than groovy DOM manipulations.
> It would be nice to refactor this and clean up the build_rules.gradle file a
> bit. Some potential ideas for refactoring:
> # Check in a "base pom.xml" file pre-filled with metadata, and use this as
> the source for generated pom manipulations.
> # Check in and release a parent pom file which contains all required
> metadata. Other artifacts can reference it as a parent and then drop the
> duplicated metadata.
> # At the very least, refactor the pom manipulation logic out to a different
> method or different file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
