[ 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)