forked from fedora-java/howto
-
Notifications
You must be signed in to change notification settings - Fork 0
/
mvn_macros.txt
197 lines (167 loc) · 6.77 KB
/
mvn_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
195
196
197
[[mvn_macros]]
=== Macros for Maven build configuration
Maven builds can be configured to produce alternative layout, include additional
aliases in package metadata or create separate subpackages for certain
artifacts.
[[mvn_artifact]]
==== Installing additional artifacts
It is possible to explicitly request an installation of any Maven artifact
(JAR/POM file). Macro `%mvn_install` only knows about Maven artifacts that were
created during execution of `%mvn_build`. Normally, any other artifacts which
were built by some other method would need to be installed manually.
`%mvn_build` macro doesn't even need to be used at all. Luckily, all artifacts
created outside of `%mvn_build` can be marked for installation with
`%mvn_artifact` macro. This macro creates configuration for `%mvn_install`.
.Requesting installation of Maven artifact
[source,spec]
-------
%prep
...
# Request installation of POM and JAR file
%mvn_artifact subpackage/pom.xml target/artifact.jar
# Request installation of POM artifact (no JAR file)
%mvn_artifact pom.xml
# Request installation for JAR file specified by artifact coordinates
%mvn_artifact webapp:webapp:war:3.1 webapp.war
-------
[[mvn_alias]]
==== Additional Mappings
The macro `%mvn_alias` can be used to add additional mappings for given POM/JAR
file. For example, if the POM file indicates that it contains groupId
commons-lang, artifactId commons-lang, this macro ensures that we also add a
mapping between groupId org.apache.commons and the installed JAR/POM files. This
is necessary in cases where the groupId or artifactId may have changed, and
other packages might require different IDs than those reflected in the installed
POM.
.Adding more mappings for JAR/POM files example
[source,spec]
-------
%prep
...
%mvn_alias "commons-lang:commons-lang" "org.apache.commons:commons-lang"
-------
[[mvn_file]]
==== Alternative JAR File Names
In some cases, it may be important to be able to provide symbolic links to actual JAR
files. This can be achieved with `%mvn_file` macro. This macro allows packager
to specify names of the JAR files, their location in `%{_javadir}` directory and
also can create symbolic links to the JAR files. These links can be possibly
located outside of the `%{_javadir}` directory.
.Adding file symlinks to compatibility
[source,spec]
-------
%prep
...
%mvn_file :guice google/guice guice
-------
This means that JAR file for artifact with ID "guice" (and any groupId) will be
installed in `%{_javadir}/google/guice.jar` and there also will be a symbolic links to
this JAR file located in `%{_javadir}/guice.jar`. Note the macro will add ".jar"
extensions automatically.
[[mvn_singleton]]
==== Single Artifact Per Package
If the project consists of multiple artifacts, it is recommended to install each
artifact to the separate subpackage. The macro `%mvn_build -s` will generate
separate `.mfiles` file for every artifact in the project. This file contains
list of files related to specific artifact (typically JAR file, POM file and
metadata). It can be later used in `%files` section of the spec file.
.Creating one subpackage for each generated artifact
[source,spec]
-------
...
%description
The Maven Plugin Tools contains...
%package -n maven-plugin-annotations
Summary: Maven Plugin Java 5 Annotations
%description -n maven-plugin-annotations
This package contains Java 5 annotations to use in Mojos.
%package -n maven-plugin-plugin
Summary: Maven Plugin Plugin
%description -n maven-plugin-plugin
The Plugin Plugin is used to...
...
%build
%mvn_build -s
%install
%mvn_install
%files -f .mfiles-maven-plugin-tools
%doc LICENSE NOTICE
%files -n maven-plugin-annotations -f .mfiles-maven-plugin-annotations
%files -n maven-plugin-plugin -f .mfiles-maven-plugin-plugin
%files -f .mfiles-javadoc
...
-------
[[mvn_package]]
==== Assignment of the Maven Artifacts to the Subpackages
The macro `%mvn_package` allows maintainer to specify in which exact package the
selected artifact will end up. It is something between singleton packaging, when
each artifact has its own subpackage and default packaging, when all artifacts
end up in the same package.
.Assigning multiple artifacts to single subpackage
[source,spec]
-------
...
%prep
%mvn_package ":plexus-compiler-jikes" plexus-compiler-extras
%mvn_package ":plexus-compiler-eclipse" plexus-compiler-extras
%mvn_package ":plexus-compiler-csharp" plexus-compiler-extras
%build
%mvn_build
%install
%mvn_install
%files -f .mfiles
%files -f .mfiles-plexus-compiler-extras
%files -f .mfiles-javadoc
-------
In above example, the artifacts `plexus-compiler-jikes`,
`plexus-compiler-eclipse`, `plexus-compiler-csharp` will end up in package named
`plexus-compiler-extras`. If there are some other artifacts beside these three
mentioned (e.g. some parent POMs), then these will all end up in package named
`%{name}`.
[TIP]
======
`%mvn_package` macro supports wildcards and brace expansions, so whole `%prep` section from previous example can be replaced with single line:
`%mvn_package ":plexus-compiler-{jikes,eclipse,csharp}" plexus-compiler-extras`
======
It is possible to assign artifacts into a package called `__noinstall`. This package
name has a special meaning. And as you can guess, artifacts assigned into this
package won't be installed anywhere and the package itself won't be created.
.Skipping installation of an artifact
[source,spec]
-------
%prep
...
%mvn_package groupId:artifactId __noinstall
-------
[[mvn_config]]
==== Modifying XMvn configuration from within spec file
Some packages might need to modify XMvn's configuration in order to build
successfully or from other reasons. This can be achieved with `mvn_config`
macro. For example, some old package can use `enum` as an identifier, but it is
also keyword since Java 1.5. Such package will probably fail to build on current
systems. This problem can be easily solved by passing `-source 1.4` to the
compiler, so one could add following line to the spec file:
.Overriding default XMvn configuration
[source,spec]
-------
%prep
...
%mvn_config buildSettings/compilerSource 1.4
-------
XMvn's configuration is quite complex, but well documented at project's
http://mizdebsk.fedorapeople.org/xmvn/site/[official website]. The website
should always be used as a primary source of information about XMvn
configuration.
[TIP]
======
Read about XMvn's configuration
http://mizdebsk.fedorapeople.org/xmvn/site/configuration.html[basics] and see
full http://mizdebsk.fedorapeople.org/xmvn/site/config.html[configuration reference].
======
[TIP]
======
All `%mvn_` macros have their own manual page which contains details on how to
use them. All possible options should be documented there. These manual pages
should be considered most up to date documentation right after source code. Try
for example `man mvn_file`. These pages are also included in the <<manpages, Appendix>>.
======