forked from fedora-java/howto
-
Notifications
You must be signed in to change notification settings - Fork 0
/
pom_macros.txt
194 lines (157 loc) · 6.93 KB
/
pom_macros.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
Sometimes Maven `pom.xml` files need to be patched before they are used
to build packages. One could use traditional patches to maintain
changes, but package maintainers should use `%pom_*` macros developed
specially to ease this task.
These macros are designed to be called from `%prep` section of spec
files. They are documented in `/usr/lib/rpm/macros.d/macros.fjava` configuration
file, which is also
link:https://github.com/fedora-java/javapackages/blob/master/macros.d/macros.fjava[available
online] and all the macros also have their own manual page. See the
manual pages for technical details how to use them.
.Handling XML namespaces
[NOTE]
=======
POM files use a specific namespace - http://maven.apache.org/POM/4.0.0.
The easiest way to respect this namespace in XPath expressions is
prefixing all node names with `pom:`. For example,
`pom:environment/pom:os` will work because it selects nodes from `pom`
namespace, but `environment/os` won't find anything because it looks for
nodes that don't belong to any XML namespace. It is needed even if the
original POM file didn't contain proper POM namespace, since it will be
added automatically.
=======
Using `%pom_*` macros not only increases readability of the spec file,
but also improves maintainability of the package as there are no patches
that would need to be rebased with each upstream release. Below are some
examples added for convenience.
[[pom_remove_dep]]
==== Adding/removing dependencies
Often dependencies specified in Maven `pom.xml` files need to be removed
because of different reasons. `%pom_remove_dep` macro can be used to
ease this task:
.Removing dependencies from pom.xml files
[source,spec]
--------
# Removes dependency on groupId:artifactId from ./pom.xml
%pom_remove_dep groupId:artifactId
# Removes dependency on groupId:artifactId from ./submodule/pom.xml
%pom_remove_dep groupId:artifactId submodule
# Removes dependency on groupId:artifactId from ./submodule1/pom.xml and
# ./submodule2/pom.xml
%pom_remove_dep groupId:artifactId submodule1 submodule2
# Removes dependency on groupId:artifactId from ./full/path/to/file.pom
%pom_remove_dep groupId:artifactId full/path/to/file.pom
# Removes dependency on all artifacts in group groupId from ./pom.xml
%pom_remove_dep groupId:
# Removes all dependencies from ./pom.xml
%pom_remove_dep :
--------
.Recursive mode
POM macros which remove elements can work in recursive mode, allowing
the maintainer to remove given dependency/plugin from all the poms
without the need to enumerate all POMs manually. It recursively
traverses all enabled submodules of given `pom.xml` by looking at
`<module>` nodes. It is activated by `-r` switch.
[source,spec]
-----
# Removes dependency on groupId:artifactId from pom.xml and all its
# submodules
%pom_remove_dep -r groupId:artifactId
-----
.Adding dependencies
Dependencies can also be added to `pom.xml` with `%pom_add_dep` macro.
Usage is very similar to `%pom_remove_dep`, see `"man pom_add_dep"` for
more information.
.Changing dependencies
Sometimes the artifact coordinates used in upstream `pom.xml` don't
correspond to ones used in Fedora and you need to modify them.
`%pom_change_dep` macro will modify all dependencies matching the first
argument to artifact coordinates specified by the second argument. Note
this macro also works in recursive mode.
[source,spec]
-----
# For all artifacts in pom.xml that have groupId 'example' change it to
# 'com.example' while leaving artifactId and other parts intact
%pom_change_dep example: com.example:
-----
[[pom_remove_plugin]]
==== Adding/removing plugins
`%pom_remove_plugin` macro works exactly as `%pom_remove_dep`, except it removes
Maven plugin invocations. Some examples:
.Removing Maven plugins from pom.xml files
[source,spec]
--------
# Disables maven-jar-plugin so that classpath isn't included in manifests
%pom_remove_plugin :maven-jar-plugin
# Disable a proprietary plugin that isn't packaged for Fedora
%pom_remove_plugin com.example.mammon:useless-proprietary-plugin submodule
--------
Like in previous case, there is also a macro for adding plugins to
`pom.xml`. See `"man pom_add_plugin"` for more information.
[[pom_disable_module]]
==== Disabling unneeded modules
Sometimes some submodules of upstream project cannot be built for
various reasons and there is a need to disable them. This can be
achieved by using `%pom_disable_module`, for example:
.Disabling specific project modules
[source,spec]
--------
# Disables child-module-1, a submodule of the main pom.xml file
%pom_disable_module child-module-1
# Disables grandchild-module, a submodule of child-module-2/pom.xml
%pom_disable_module grandchild-module child-module-2
--------
[[pom_remove_parent]]
==== Working with parent POM references
Macro `%pom_remove_parent` removes reference to a parent POM from Maven
POM files. This can be useful when parent POM is not yet packaged (e.g.
because of licensing issues) and at the same time it's not really needed
for building of the project. There are also macros for adding parent POM
reference (`%pom_add_parent`) and replacing existing reference with new
one (`%pom_set_parent`).
.Manipulating parent POM references
[source,spec]
--------
# Remove reference to a parent POM from ./pom.xml
%pom_remove_parent
# Remove reference to a parent POM from ./submodule/pom.xml
%pom_remove_parent submodule
# Add parent POM reference to ./pom.xml
%pom_add_parent groupId:artifactId
# Replace existing parent POM reference in ./pom.xml
%pom_set_parent groupId:artifactId:version
--------
[[pom_xpath_remove]]
==== Macros for performing generic modifications
The above macros cover the most common cases of modifying `pom.xml`
files, however if there is a need to apply some less-common patches
there are also three generic macros for modifying `pom.xml` files.
`%pom_xpath_remove` can be used to remove arbitrary XML nodes, described
by link:http://www.w3.org/TR/xpath/[XPath] 1.0 expressions.
`%pom_xpath_inject` macro is capable of injecting arbitrary
link:http://www.w3.org/TR/xml/[XML] code to any `pom.xml` file. And
finally, `%pom_xpath_set` replaces content of the arbitrary XML nodes
with specified value. Below you can find some examples for these
macros.
.Less common pom.xml modifications
[source,spec]
--------
# Removes extensions from the build
%pom_xpath_remove "pom:build/pom:extensions" module/pom.xml
# Adds new dependency
%pom_xpath_inject "pom:dependencies" "
<dependency>
<groupId>org.example.project</groupId>
<artifactId>awesomeproject</artifactId>
<version>1.0.0.GA</version>
</dependency>"
# Change groupId of a parent
%pom_xpath_set "pom:parent/pom:groupId" "org.apache"
# Use a bit more complex XPath to add additional exclusion into
# maven-wagon dependency
%pom_xpath_inject "pom:dependency[pom:artifactId[text()='maven-wagon']]/pom:exclusions" "
<exclusion>
<groupId>antlr</groupId>
<artifactId>antlr</artifactId>
</exclusion>"
--------