* add copyright/scope configuration for intellij
This commit introduces a section discussing the ability to define
copyright rules in intellij for inserting the appropriate copyright
headers into files across both apache2-Elasticsearch, as well as the
commercial code under `x-pack`.
Some other re-organization was made to create more sub-structure
* update to reflect reviewer comments
The "Shorten Command Line" setting in Intellij's JUnit test configuration
was recommended to change to `classpath file`. This setting has been
causing issues with JDK9 where some modules were not being found at
runtime. This PR removes the recommendation to change this setting and
instead asks that users verify that it is set to `user-local default:none`.
This commit modifies the build to require JDK 9 for
compilation. Henceforth, we will compile with a JDK 9 compiler targeting
JDK 8 as the class file format. Optionally, RUNTIME_JAVA_HOME can be set
as the runtime JDK used for running tests. To enable this change, we
separate the meaning of the compiler Java home versus the runtime Java
home. If the runtime Java home is not set (via RUNTIME_JAVA_HOME) then
we fallback to using JAVA_HOME as the runtime Java home. This enables:
- developers only have to set one Java home (JAVA_HOME)
- developers can set an optional Java home (RUNTIME_JAVA_HOME) to test
on the minimum supported runtime
- we can test compiling with JDK 9 running on JDK 8 and compiling with
JDK 9 running on JDK 9 in CI
We have agreed to introduce the Gradle wrapper to simplify workflows for
developers, and managing infrastructure (e.g., CI, release builds, etc.)
as well as consideration for the fact that other projects in our stack
use Gradle and do not necessarily want to be tied to our Gradle version.
Relates #28065
* Improved paragraph describing how to run unit tests from Intellij.
* Added information about how to run a local copy of elasticsearch from the source.
When running unit tests direct from the IDE this setting change is needed
in addition to the idea.no.launcher property that previous versions of IntelliJ
needed.
This commit clarifies that the preferences menu in IntelliJ can differ
by OS (IntelliJ -> Preferences on macOS and Settings on Linux/Windows).
Relates #27575
This commit clarifies the minimum IDE versions that we support for
development. We need to formally state that the minimum that we support
for Eclipse is Eclipse Oxygen because Eclipse Neon and prior releases
have type inference bugs that lead to compilation issues that cause us
to have to contort our code to support Eclipse and it appears that
Eclipse Oxygen is less-prone to these issue. And the recent high-level
REST shading work seems to work best in Intellij 2017.2. Therefore, we
state these versions explicitly.
Relates #26194
This reverts the line limit change in #23623 - this PR doesn't touch the suppression file since we are moving towards automatic code formatting which makes it mainly obsolete.
This will allow us to get rid of deprecation warnings that appear when
using 3.3, and also get rid of extra logic for 2.13 required because of
the progress logger.
This commit rewords the note regarding the squashing of pull request
commits to make it clearer that the note applies to everyone and not
just external contributors.
The CONTRIBUTING.md file can be in the root directory or
in the .github directory and will still be used for
the contributing guidelines on Github.
Moved back to the root directory so that it is more
visible outside Github
This commits adds an issue template for contributors that open bug
reports or feature requests.
Additionally, this commit adds a .github subdirectory to the project and
moves the CONTRIBUTING.md file to that directory.
Closes#16773
Currently when importing projects into eclipse you need to run 'mvn
eclipse:eclipse' on the command line to generate the poject files. This
means that when the pom changes you need to re-run the command on the
command line to reflect those changes in the project in eclipse. This
commit allows the developer to import the project as an existing maven
project (can be shared using git after import) and then allows the
application to be run inside eclipse using the .launch file in
/dev-tools enabling easy debugging of the application within eclipse
without requiring a maven build.