[
https://issues.apache.org/jira/browse/BEAM-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Wegner updated BEAM-4050:
-------------------------------
Description:
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.
was:
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.
> 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
> Assignee: Luke Cwik
> Priority: Minor
>
> 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)
