failsafe uses surefire, which sucks. It also mean integ tests act alien right now.
I would rather have the consistency, e.g. things formatted the same way, running integ tests under security manager, etc.
1. tests don't have a bogus test dependency on zips anymore,
instead we handle this in pre-integration-test. This reduces
lots of confusion for e.g. mvn clean test.
2. refactor integ logic so that core/ and plugin/ share it.
previously they were duplicates but the above change simplifies life.
it also makes it easier for doing more interesting stuff
The previous strategy (target/xxx + .m2/repository) is obviously broken for multi-module
builds.
Includes hack for crazy jython, which "finds its own jar" then looks for a Lib/ beside it
This commit adds a release profile that runs additional checks like:
* check for `norelease` in the source
* check for `AwaitsFix` annotations
* deploys only if all reactor builds where successful
* signs all artifacts with the GPG key provided (required for release)
* builds the RPM together with the zip, tar.gz and .deb during package phase
Note this is WIP of replacing major functionality of the release pythong script but
won't work by itself.
The older runner (junit 4.0?) hides exceptions in static initialization
(and runs the tests anyways!). With this change, the actual cause
of the recent windows integ test failures with security manager
are shown.
Today everything is tight to having the next version as the latest.
In order to work towards 2.0.0.beta1 we need to fix all the usage of
2.0.0-SNAPSHOT to reflect the version we will release soon.
Usually we do this on the release branch but to simplify things I wanna
keep this on master for now and move to 2.1.0-SNAPSHOT on master once
we created a 2.0 branch.
Closes#12148
We also run our license checker in `mvn verify`, but there
are problems with checksum calculation on windows there, so I've
disabled the license checker on windows to prevent those false fails.
previously this was done wrong, junit4 ant tasks were brought into
the test classpath. This created jar hell for tests, and also encouraged
people to use _internal_ stuff like its bundled guava in tests.
also the task was set to be lenient and ignore errors. And we were
passing in a messload of unnecessary classpaths to run this. It
only needs the module classpath: the explicit ant dependencies we declare.
http://maven.apache.org/plugins/maven-pmd-plugin/
You should specify the version in your project's plugin configuration:
```xml
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<version>3.5</version>
</plugin>
```
Release Notes - Apache Maven PMD Plugin - Version 3.5
---------------
Bug
* [MPMD-208] Warning about deprecated Rule name when using rulesets/maven.xml
* [MPMD-205] Javascript violations won't fail the build
Improvement
* [MPMD-211] Upgrade plexus-resources from 1.0-alpha-7 to 1.1
* [MPMD-209] Upgrade to PMD 5.3.2
* [MPMD-206] Make the sourceDirectories configurable
New Feature
* [MPMD-207] Support Javascript and JSP for CPD
Release Notes - Apache Maven Invoker Plugin - Version 2.0.0
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317525&version=12332831
Important Note:
This Release is intended for the bug fix MINVOKER-187 and in this relationship
is was necessary to upgrade the JDK minimum to JDK 1.6. This was the reason for
the version upgrade to 2.0.0.
Bug:
* [MINVOKER-187] - Cloned IT project must be writable
Improvement:
* [MINVOKER-192] - Using fluido skin
The change makes rest-spec-api a project in the same way as we build dev-tools. it packages the tests and api in a bundle using the maven-remote-resources-plugin and uses the same plugin in the plugins and core pom to unpack the rest-api-spec into the target directory and references the rest tests there in the test resources.
The main stimulus for this change is that for those using Eclipse the current build does not work. After running `mvn eclipse:eclipse` the Eclipse IDE errors because the rest-api-spec is outside of the project scope, meaning that every time the command is run (required whenever any dependencies change), the class path of all the projects has to be manually fixed.
this is really just a workaround for plugins to run their own
REST tests instead of the core ones. It opts out of the rest test
loading from the core jar file and tries to load from the classpath instead.
Eventually we need to fix this infrastrucutre to move away from parameterized
tests such that subclasses can override behavior.
Closes#11721
Added a licenses/ directory to core which contains a sha1 file for each JAR
dependency, and one or more LICENSE files and one NOTICE file for each
project.
Also adds dev-tools/src/main/resources/license-check/check_license_and_sha.pl
which checks that the licenses/ dir is up to date during a mvn verify,
and which can be used to update the sha1 files when upgrading dependencies.
Closes#2794Closes#10684Closes#11705
In Maven parent project, in dependency management, we should only declare which versions of 3rd party jars we want to use but not force any scope.
It makes then more obvious in modules what is exactly the scope of any dependency.
For example, one could imagine importing `jimfs` as a `compile` dependency in another module/plugin with:
```xml
<dependency>
<groupId>com.google.jimfs</groupId>
<artifactId>jimfs</artifactId>
</dependency>
```
But it won't work as expected as the default maven `scope` should be `compile` but here it's `test` as defined in the parent project.
So, if you want to use this lib for tests, you should simply define:
```xml
<dependency>
<groupId>com.google.jimfs</groupId>
<artifactId>jimfs</artifactId>
<scope>test</scope>
</dependency>
```
We also remove `maven-s3-wagon` from gce plugin as it's not used.
This commit adds an additioal jar that is shaded and keeps all the
artifacts that are used by default on the server-side unshaded. Users
that need a shaded jar can now use the `shaded` classifyer to pull
the shaded minimized jar in instead. Including the shaded jar in a
downstream project looks like this:
```XML
<dependency>
<groupId>org.elasticsearch</groupId>
<artifactId>elasticsearch</artifactId>
<classifier>shaded</classifier>
</dependency>
```
```xml
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.5.5</version>
</plugin>
```
## Release Notes - Maven Assembly Plugin - Version 2.5.5
* Bug
- [MASSEMBLY-767] - Schema missing from the web site
- [MASSEMBLY-768] - JarInputStream unable to find manifest
created by version 2.5.4
- [MASSEMBLY-769] - ZIP fileMode permissions not properly set with
dependencySet and unpackOptions
Closes#11192 which I accidentally already closed.
Squashed commit of the following:
commit f23faccddc2a77a880841da4c89c494edaa2aa46
Author: Robert Muir <rmuir@apache.org>
Date: Fri May 15 16:04:55 2015 -0400
Simplify this FileUtils even more: its either from the filesystem, or the classpath,
not both. Its already trying 4 different combinations of crazy paths for either of these anyway.
commit c7016c8a2b5a6043e2ded4b48b160821ba196974
Author: Robert Muir <rmuir@apache.org>
Date: Fri May 15 14:21:37 2015 -0400
include rest tests in test-framework jar
The esoteric classifier contains in particular maps that take bytes or doubles
as keys. In the byte case, we can just use integer, and in the double case we
can use their long bits instead.
Codehaus announced they are shutting down their services: https://www.codehaus.org/
We should remove their repository from our pom as it could cause some errors an useless HTTP calls.
Related to #10939
This plugin should be ignored as it will make the internal eclipse build fail when there are NOCOMMIT comments in files, which are expected during feature development. This change only affects eclipse users and only when they are using the m2e eclipse integration
In order to automatically sign and and upload our debian and RPM
packages, this commit incorporates signing into the build process
and adds the necessary steps to the release process. In order to do this
the pom.xml has been adapted and the RPM and jdeb maven plugins have been
updated, so the packages are signed on build. However the repositories
need to signed as well.
Syncing the repos requires downloading the current repo, adding
the new packages and syncing it back.
The following environment variables are now required as part of the build
* GPG_KEY_ID - the key ID of the key used for signing
* GPG_PASSPHRASE - your GPG passphrase
* S3_BUCKET_SYNC_TO: S3 bucket to sync new repo into
The following environment variables are optional
* S3_BUCKET_SYNC_FROM: S3 bucket to get existing packages from
* GPG_KEYRING - home of gnupg, defaults to ~/.gnupg
The following command line tools are needed
* createrepo (creates RPM repositories)
* expect (used by the maven rpm plugin)
* apt-ftparchive (creates DEB repositories)
* gpg (signs packages and repo files)
* s3cmd (syncing between the different S3 buckets)
The current approach would also work for users who want to run their
own repositories, all they need to change are a couple of environment
variables.
Minor implementation detail: Right now the branch name is used as version
for the repositories (like 1.4/1.5/1.6) - if we ever change our branch naming
scheme, the script needs to be fixed.
Robert Muir
jaymode
Martijn van Groningen
Simon Willnauer
Robert Muir
Simon Willnauer
Ryan Ernst
uboness
David Pilato
Tanguy Leroux
Colin Goodheart-Smithe
Clinton Gormley
Adrien Grand
Shay Banon
Dawid Weiss
Colin Goodheart-Smithe
Alexander Reelsen
Lee Hinman