forked from pop4959/LWCX
-
Notifications
You must be signed in to change notification settings - Fork 0
/
pom.xml
445 lines (391 loc) · 27.9 KB
/
pom.xml
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
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.griefcraft.lwc</groupId>
<artifactId>LWCX</artifactId>
<name>LWCX</name>
<version>2.2.5</version>
<description>LWC Extended - An updated version of the LWC block protection plugin</description>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<repositories>
<repository>
<id>spigot-repo</id>
<url>https://hub.spigotmc.org/nexus/content/repositories/snapshots/</url>
</repository>
<repository>
<id>sk89q-repo</id>
<url>http://maven.sk89q.com/repo/</url>
</repository>
<repository>
<id>factions-repo</id>
<url>http://ci.ender.zone/plugin/repository/everything/</url>
</repository>
<repository>
<id>glaremasters-repo</id>
<url>https://repo.glaremasters.me/repository/public/</url>
</repository>
</repositories>
<dependencies>
<dependency>
<groupId>org.spigotmc</groupId>
<artifactId>spigot-api</artifactId>
<version>1.15-R0.1-SNAPSHOT</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.sk89q.worldedit</groupId>
<artifactId>worldedit-core</artifactId>
<version>7.0.0-SNAPSHOT</version>
<scope>provided</scope>
<type>jar</type>
</dependency>
<dependency>
<groupId>com.sk89q.worldguard</groupId>
<artifactId>worldguard-legacy</artifactId>
<version>7.0.0-SNAPSHOT</version>
<scope>provided</scope>
<type>jar</type>
</dependency>
<dependency>
<groupId>com.palmergames.bukkit.towny</groupId>
<artifactId>Towny</artifactId>
<version>0.95.1.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.massivecraft</groupId>
<artifactId>Factions</artifactId>
<version>1.6.9.5-U0.4.9</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>net.milkbowl.vault</groupId>
<artifactId>VaultAPI</artifactId>
<version>1.5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.bstats</groupId>
<artifactId>bstats-bukkit</artifactId>
<version>1.4</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>23.0</version>
</dependency>
</dependencies>
<build>
<finalName>${project.artifactId}-${project.version}</finalName>
<!-- <pluginManagement> -->
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.3</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
<plugin>
<groupId>pl.project13.maven</groupId>
<artifactId>git-commit-id-plugin</artifactId>
<version>2.2.4</version>
<executions>
<execution>
<id>get-the-git-infos</id>
<goals>
<goal>revision</goal>
</goals>
</execution>
<execution>
<id>validate-the-git-infos</id>
<goals>
<goal>validateRevision</goal>
</goals>
<!-- *NOTE*: The default phase of validateRevision is verify, but in case you want to change it, you can do so by adding the phase here -->
<phase>package</phase>
</execution>
</executions>
<configuration>
<!--
If you'd like to tell the plugin where your .git directory is,
use this setting, otherwise we'll perform a search trying to
figure out the right directory. It's better to add it explicitly IMHO.
-->
<dotGitDirectory>${project.basedir}/.git</dotGitDirectory>
<!-- that's the default value, you don't have to set it -->
<prefix>git</prefix>
<!-- @since 2.2.0 -->
<!--
The current dateFormat is set to match maven's default ``yyyy-MM-dd'T'HH:mm:ssZ``
Please note that in previous versions (2.2.0 - 2.2.2) the default dateFormat was set to: ``dd.MM.yyyy '@' HH:mm:ss z``. However the `RFC 822 time zone` seems to give a more reliable option in parsing the date and it's being used in maven as default.
-->
<dateFormat>yyyy-MM-dd'T'HH:mm:ssZ</dateFormat>
<!-- @since 2.2.0 -->
<!--
If you want to set the timezone of the dateformat to anything in particular you can do this by using this option.
As a general warning try to avoid three-letter time zone IDs because the same abbreviation are often used for multiple time zones.
The default value we'll use the timezone use the timezone that's shipped with java (java.util.TimeZone.getDefault().getID()).
*Note*: If you plan to set the java's timezone by using `MAVEN_OPTS=-Duser.timezone=UTC mvn clean package`, `mvn clean package -Duser.timezone=UTC` or any other configuration keep in mind that this option will override those settings and will not take other configurations into account!
-->
<dateFormatTimeZone>${user.timezone}</dateFormatTimeZone>
<!-- false is default here, it prints some more information during the build -->
<verbose>false</verbose>
<!-- ALTERNATE SETUP - GENERATE FILE -->
<!--
If you want to keep git information, even in your WAR file etc,
use this mode, which will generate a properties file (with filled out values)
which you can then normally read using new Properties().load(/**/)
-->
<!--
This is false by default, forces the plugin to generate the git.properties file.
Note that the functional meaning of git.build.time becomes different in a very subtle way (see later in this README)
-->
<generateGitPropertiesFile>false</generateGitPropertiesFile>
<!--
The path for the to be generated properties file, it's relative to ${project.basedir}
The default value is ${project.build.outputDirectory}/git.properties
*Note*: If you plan to set the generateGitPropertiesFilename-Path to a location where usually the source-files
comes from (e.g. src/main/resources) and experience that your IDE (e.g. eclipse)
invokes "Maven Project Builder" once every second, the chances that you are using
an IDE where the src-folder is a watched folder for files that are *only* edited by humans is pretty high.
For further information refer to the manual for your specific IDE and check the workflow of "incremental project builders".
In order to fix this problem we recommend to set the generateGitPropertiesFilename-Path
to a target folder (e.g. ${project.build.outputDirectory}) since this is
the place where all derived/generated resources should go.
-->
<generateGitPropertiesFilename>${project.build.outputDirectory}/git.properties
</generateGitPropertiesFilename>
<!-- Denotes the format to save properties in. Valid options are "properties" (default) and "json". Properties will be saved to the generateGitPropertiesFilename if generateGitPropertiesFile is set to `true`. -->
<format>properties</format>
<!--
this is true by default; You may want to set this to false, if the plugin should run inside a
<packaging>pom</packaging> project. Most projects won't need to override this property.
For an use-case for this kind of behaviour see: https://github.com/ktoso/maven-git-commit-id-plugin/issues/21
-->
<skipPoms>true</skipPoms>
<!-- @since 2.1.4 -->
<!--
Tell maven-git-commit-id to inject the git properties into all reactor projects not just the current one.
For details about why you might want to skip this, read this issue: https://github.com/ktoso/maven-git-commit-id-plugin/pull/65
The property is set to ``false`` by default to prevent the overriding of properties that may be unrelated to the project.
-->
<injectAllReactorProjects>false</injectAllReactorProjects>
<!-- @since 2.0.4 -->
<!-- true by default, controls whether the plugin will fail when no .git directory is found, when set to false the plugin will just skip execution -->
<failOnNoGitDirectory>true</failOnNoGitDirectory>
<!-- @since 2.1.5 -->
<!-- true by default, controls whether the plugin will fail if it was unable to obtain enough data for a complete run, if you don't care about this, you may want to set this value to false. -->
<failOnUnableToExtractRepoInfo>true</failOnUnableToExtractRepoInfo>
<!-- @since 2.1.8 -->
<!--
skip the plugin execution completely. This is useful for e.g. profile activated plugin invocations or
to use properties to enable / disable pom features. Default value is 'false'.
With version 2.2.3 you can also skip the plugin by using the commandline option -Dmaven.gitcommitid.skip=true
-->
<skip>false</skip>
<!-- @since 2.1.12 -->
<!--
Use with caution!
In a multi-module build, only run once. This means that the plugins effects will only execute once, for the parent project.
This probably won't "do the right thing" if your project has more than one git repository.
Important: If you're using `generateGitPropertiesFile`, setting `runOnlyOnce` will make the plugin
only generate the file in the directory where you started your build (!).
Important: Please note that the git-commit-id-plugin also has an option to skip pom project (`<packaging>pom</packaging>`).
If you plan to use the `runOnlyOnce` option alongside with an aggregator pom you may want to set `<skipPoms>false</skipPoms>`.
The `git.*` maven properties are available in all modules.
Default value is `false`.
-->
<runOnlyOnce>false</runOnlyOnce>
<!-- @since 2.1.9 -->
<!--
Can be used to exclude certain properties from being emitted into the resulting file.
May be useful when you want to hide {@code git.remote.origin.url} (maybe because it contains your repo password?),
or the email of the committer etc.
Each value may be globbing, that is, you can write {@code git.commit.user.*} to exclude both, the {@code name},
as well as {@code email} properties from being emitted into the resulting files.
Please note that the strings here are Java regexes ({@code .*} is globbing, not plain {@code *}).
-->
<excludeProperties>
<!-- <excludeProperty>git.user.*</excludeProperty> -->
</excludeProperties>
<!-- @since 2.1.14 -->
<!--
Can be used to include only certain properties into the resulting file.
Will be overruled by the exclude properties.
Each value may be globbing, that is, you can write {@code git.commit.user.*} to include both, the {@code name},
as well as {@code email} properties into the resulting files.
Please note that the strings here are Java regexes ({@code .*} is globbing, not plain {@code *}).
-->
<includeOnlyProperties>
<!-- <includeOnlyProperty>^git.commit.id.full$</includeOnlyProperty> -->
</includeOnlyProperties>
<!-- @since 2.2.3 -->
<!--
Can be used to replace certain characters or strings using regular expressions within the generated git properties.
Sample usecase (see below): replace the '/' with '-' in the branch name when using branches like 'feature/feature_name'
Replacements can be configured with a replacementProperty. A replacementProperty can have a `property` and a `regex`-Tag.
If the replacementProperty configuration has a `property`-tag the replacement will only be performed on that specific property (e.g. `<property>git.branch</property>` will only be performed on `git.branch`).
In case this specific element is not defined or left empty the replacement will be performed *on all generated properties*.
The optional `regex`-Tag can either be true to perform a replacement with regular expressions or false to perform a replacement with java's string.replace-function. by default the replacement will be performed with regular expressions.
Furthermore each replacementProperty need to be configured with a token and a value.
The token can be seen as the needle and the value as the text to be written over any found tokens. If using regular expressions the value can reference grouped regex matches by using $1, $2, etc.
Since 2.2.4 the plugin allows to define a even more sophisticated ruleset and allows to set an `propertyOutputSuffix` within each replacement property. If this option is empty the original property will be overwritten (default behaviour in 2.2.3). however when this configuration is set to `something` and a user wants to modify the `git.branch` property the plugin will keep `git.branch` as the original one (w/o modifications) but also will be creating a new `git.branch.something` property with the requested replacement.
Furthermore with 2.2.4 the plugin allows to perform certain types of string manipulation either before or after the evaluation of the replacement. With this feature a user can currently easily manipulate the case (e.g. lower case VS upper case) of the input/output property. This behaviour can be achieved by defining a list of `transformationRules` for the property where those rules should take effect. Each `transformationRule` consist of two required fields `apply` and `action`. The `apply`-tag controls when the rule should be applied and can be set to `BEFORE` to have the rule being applied before or it can be set to `AFTER` to have the rule being applied after the replacement. The `action`-tag determines the string conversion rule that should be applied. Currently supported is `LOWER_CASE` and `UPPER_CASE`. Potential candidates in the feature are `CAPITALIZATION` and `INVERT_CASE``(open a ticket if you need them...).
Please note that the replacement will *only be applied to properties that are being generated by the plugin*.
If you want to replace properties that are being generated by other plugins you may want to use the maven-replacer-plugin or any other alternative.
-->
<replacementProperties>
<!-- example: apply replacement only to the specific property git.branch and replace '/' with '-'
<replacementProperty>
<property>git.branch</property>
<propertyOutputSuffix>something</propertyOutputSuffix>
<token>^([^\/]*)\/([^\/]*)$</token>
<value>$1-$2</value>
<regex>true</regex>
<transformationRules>
<transformationRule>
<apply>BEFORE</apply>
<action>UPPER_CASE</action>
</transformationRule>
<transformationRule>
<apply>AFTER</apply>
<action>LOWER_CASE</action>
</transformationRule>
</transformationRules>
</replacementProperty>
-->
</replacementProperties>
<!-- @since 2.1.10 -->
<!--
false is default here, if set to true it uses native `git` executable for extracting all data.
This usually has better performance than the default (jgit) implementation, but requires you to
have git available as executable for the build as well as *might break unexpectedly* when you
upgrade your system-wide git installation.
As rule of thumb - stay on `jgit` (keep this `false`) until you notice performance problems.
-->
<useNativeGit>false</useNativeGit>
<!-- @since v2.0.4 -->
<!--
Controls the length of the abbreviated git commit it (git.commit.id.abbrev)
Defaults to `7`.
`0` carries the special meaning.
Maximum value is `40`, because of max SHA-1 length.
-->
<abbrevLength>7</abbrevLength>
<!-- @since v2.2.0 -->
<!--
The option can be used to tell the plugin how it should generate the 'git.commit.id' property. Due to some naming issues when exporting the properties as an json-object (https://github.com/ktoso/maven-git-commit-id-plugin/issues/122) we needed to make it possible to export all properties as a valid json-object.
Due to the fact that this is one of the major properties the plugin is exporting we just don't want to change the exporting mechanism and somehow throw the backwards compatibility away.
We rather provide a convenient switch where you can choose if you would like the properties as they always had been, or if you rather need to support full json-object compatibility.
In the case you need to fully support json-object we unfortunately need to change the 'git.commit.id' property from 'git.commit.id' to 'git.commit.id.full' in the exporting mechanism to allow the generation of a fully valid json object.
Currently the switch allows two different options:
1. By default this property is set to 'flat' and will generate the formerly known property 'git.commit.id' as it was in the previous versions of the plugin. Keeping it to 'flat' by default preserve backwards compatibility and does not require further adjustments by the end user.
2. If you set this switch to 'full' the plugin will export the formerly known property 'git.commit.id' as 'git.commit.id.full' and therefore will generate a fully valid json object in the exporting mechanism.
*Note*: Depending on your plugin configuration you obviously can choose the 'prefix' of your properties by setting it accordingly in the plugin's configuration. As a result this is therefore only an illustration what the switch means when the 'prefix' is set to it's default value.
*Note*: If you set the value to something that's not equal to 'flat' or 'full' (ignoring the case) the plugin will output a warning and will fallback to the default 'flat' mode.
-->
<commitIdGenerationMode>flat</commitIdGenerationMode>
<!-- @since 2.1.0 -->
<!--
read up about git-describe on the in man, or it's homepage - it's a really powerful versioning helper
and the recommended way to use git-commit-id-plugin. The configuration bellow is optional,
by default describe will run "just like git-describe on the command line", even though it's a JGit reimplementation.
-->
<gitDescribe>
<!-- don't generate the describe property -->
<skip>false</skip>
<!--
if no tag was found "near" this commit, just print the commit's id instead,
helpful when you always expect this field to be not-empty
-->
<always>false</always>
<!--
how many chars should be displayed as the commit object id?
7 is git's default,
0 has a special meaning (see end of this README.md),
and 40 is the maximum value here
-->
<abbrev>7</abbrev>
<!-- when the build is triggered while the repo is in "dirty state", append this suffix -->
<dirty>-dirty</dirty>
<!-- Only consider tags matching the given pattern. This can be used to avoid leaking private tags from the repository. -->
<match>*</match>
<!--
when you run git-describe it only looks only for *annotated tags* by default
if you wish to consider *lightweight tags* in your describe as well you would need to switch this to *true*
The difference between *annotated tags* and *lightweight tags* is outlined in more depth here:
https://github.com/ktoso/maven-git-commit-id-plugin/#git-describe-and-a-small-gotcha-with-tags
-->
<tags>false</tags>
<!--
always print using the "tag-commits_from_tag-g_commit_id-maybe_dirty" format, even if "on" a tag.
The distance will always be 0 if you're "on" the tag.
-->
<forceLongFormat>false</forceLongFormat>
</gitDescribe>
<!-- @since 2.2.2 -->
<!--
Since version **2.2.2** the maven-git-commit-id-plugin comes equipped with an additional validation utility which can be used to verify if your project properties are set as you would like to have them set.
*Note*: This configuration will only be taken into account when the additional goal `validateRevision` is configured inside an execution.
-->
<validationProperties>
<validationProperty>
<!--
A descriptive name that will be used to be able to identify the validation that does not match up (will be displayed in the error message).
-->
<name>validating project version</name>
<!--
the value that needs the validation
*Note* : In order to be able to validate the generated git-properties inside the pom itself you may need to set the configuration `<injectAllReactorProjects>true</injectAllReactorProjects>`.
-->
<value>${project.version}</value>
<!--
the expected value
-->
<shouldMatchTo><![CDATA[^.*(?<!-SNAPSHOT)$]]></shouldMatchTo>
</validationProperty>
<!-- the next validationProperty you would like to validate -->
</validationProperties>
<!-- @since 2.2.2 -->
<!--
true by default, controls whether the validation will fail if *at least one* of the validationProperties does not match with it's expected values.
If you don't care about this, you may want to set this value to false (this makes the configuration of validationProperties useless).
*Note*: This configuration will only be taken into account when the additional goal `validateRevision` is configured inside an execution and at least one validationProperty is defined.
-->
<validationShouldFailIfNoMatch>true</validationShouldFailIfNoMatch>
<!-- @since 2.2.4 -->
<!--
Allow to tell the plugin what commit should be used as reference to generate the properties from.
By default this property is simply set to `HEAD` which should reference to the latest commit in your repository.
In general this property can be set to something generic like `HEAD^1` or point to a branch or tag-name.
To support any kind or use-case this configuration can also be set to an entire commit-hash or it's abbreviated version.
A use-case for this feature can be found in https://github.com/ktoso/maven-git-commit-id-plugin/issues/338.
Please note that for security purposes not all references might be allowed as configuration.
If you have a specific use-case that is currently not white listed feel free to file an issue.
-->
<evaluateOnCommit>HEAD</evaluateOnCommit>
</configuration>
</plugin>
<!-- END OF GIT COMMIT ID PLUGIN CONFIGURATION -->
</plugins>
<!-- </pluginManagement> -->
<resources>
<resource>
<filtering>true</filtering>
<targetPath>.</targetPath>
<directory>${basedir}/src/</directory>
<includes>
<include>**/*.yml</include>
<include>lang/</include>
</includes>
</resource>
</resources>
</build>
</project>