# j-m-p does not seem to download all the dependencies: https://github.com/jmeter-maven-plugin/jmeter-maven-plugin/issues/187
-name:jmeter-maven-plugin tests
-name:jmeter-maven-plugin tests on s390x
-name:Tests with OpenJDK 11 on s390x
include:
-name:Tests with OpenJDK 8 + code coverage
jdk:openjdk8
script:
-xvfb-run ./gradlew build jacocoReport $SKIP_TAR
after_success:
-bash <(curl -s https://codecov.io/bash)
-name:Tests with OpenJDK 11
jdk:openjdk11
addons:
apt:
packages:
-language-pack-fr
env:
-TZ=Pacific/Chatham# flips between +12:45 and +13:45
-LANG=fr_FR.UTF-8
-LC_ALL=fr_FR.UTF-8
script:
# This job verifies headless mode to ensure Apache JMeter is workable in headless as well
# Spotless and Checkstyle are skipped here to save some time. They are verified anyway in Java 8 and Java 13 builds, so skipping them for Java 11 does not harm
-TZ=Pacific/Chatham# flips between +12:45 and +13:45
-LANG=fr_FR.UTF-8
-LC_ALL=fr_FR.UTF-8
script:
# This job verifies headless mode to ensure Apache JMeter is workable in headless as well
# Spotless and Checkstyle are skipped here to save some time. They are verified anyway in Java 8 and Java 13 builds, so skipping them for Java 11 does not harm
This code of conduct applies to all spaces managed by the Apache Software Foundation, including IRC, all public and private mailing lists, issue trackers, wikis, blogs, Twitter, and any other communication channel used by our communities. A code of conduct which is specific to in-person events (ie., conferences) is codified in the published ASF anti-harassment policy.
We expect this code of conduct to be honored by everyone who participates in the Apache community formally or informally, or claims any affiliation with the Foundation, in any Foundation-related activities and especially when representing the ASF, in any role.
This code is not exhaustive or complete. It serves to distill our common understanding of a collaborative, shared environment and goals. We expect it to be followed in spirit as much as in the letter, so that it can enrich all of us and the technical communities in which we participate.
# Specific Guidelines
We strive to:
## **Be open**
we invite anyone to participate in our community. We preferably use public methods of communication for project-related messages, unless discussing something sensitive. This applies to messages for help or project-related support, too; not only is a public support request much more likely to result in an answer to a question, it also makes sure that any inadvertent mistakes made by people answering will be more easily detected and corrected.
## **Be empathetic**
welcoming, friendly, and patient. We work together to resolve conflict, assume good intentions, and do our best to act in an empathetic fashion. We may all experience some frustration from time to time, but we do not allow frustration to turn into a personal attack. A community where people feel uncomfortable or threatened is not a productive one. We should be respectful when dealing with other community members as well as with people outside our community.
## **Be collaborative**,
our work will be used by other people, and in turn we will depend on the work of others. When we make something for the benefit of the project, we are willing to explain to others how it works, so that they can build on the work to make it even better. Any decision we make will affect users and colleagues, and we take those consequences seriously when making decisions.
## **Be inquisitive**,
nobody knows everything! Asking questions early avoids many problems later, so questions are encouraged, though they may be directed to the appropriate forum. Those who are asked should be responsive and helpful, within the context of our shared goal of improving Apache project code.
## **Be careful in the words that we choose**,
Whether we are participating as professionals or volunteers, we value professionalism in all interactions, and take responsibility for our own speech. Be kind to others. Do not insult or put down other participants. Harassment and other exclusionary behaviour are not acceptable. This includes, but is not limited to:
* Violent threats or language directed against another person.
* Sexist, racist, or otherwise discriminatory jokes and language.
* Posting sexually explicit or violent material.
* Posting (or threatening to post) other people's personally identifying information ("doxing").
* Sharing private content, such as emails sent privately or non-publicly, or unlogged forums such as IRC channel history.
* Personal insults, especially those using racist or sexist terms.
* Unwelcome sexual attention.
* Excessive or unnecessary profanity.
* Repeated harassment of others. In general, if someone asks you to stop, then stop.
* Advocating for, or encouraging, any of the above behaviour.
## **Be concise**,
keep in mind that what you write once will be read by hundreds of persons. Writing a short email means people can understand the conversation as efficiently as possible. Short emails should always strive to be empathetic, welcoming, friendly and patient. When a long explanation is necessary, consider adding a summary.
Try to bring new ideas to a conversation so that each mail adds something unique to the thread, keeping in mind that the rest of the thread still contains the other messages with arguments that have already been made.
Try to stay on topic, especially in discussions that are already fairly large.
## **Step down considerately**,
members of every project come and go. When somebody leaves or disengages from the project they should tell people they are leaving and take the proper steps to ensure that others can pick up where they left off. In doing so, they should remain respectful of those who continue to participate in the project and should not misrepresent the project's goals or achievements. Likewise, community members should respect any individual's choice to leave the project.
# Diversity Statement
Apache welcomes and encourages participation by everyone. We are committed to being a community that everyone feels good about joining. Although we may not be able to satisfy everyone, we will always work to treat everyone well.
No matter how you identify yourself or how others perceive you: we welcome you. Though no list can hope to be comprehensive, we explicitly honour diversity in: age, culture, ethnicity, genotype, gender identity or expression, language, national origin, neurotype, phenotype, political beliefs, profession, race, religion, sexual orientation, socioeconomic status, subculture and technical ability.
Though we welcome people fluent in all languages, Apache development is conducted in English.
Standards for behaviour in the Apache community are detailed in the Code of Conduct above. We expect participants in our community to meet these standards in all their interactions and to help others to do so as well.
# Reporting Guidelines
While this code of conduct should be adhered to by participants, we recognize that sometimes people may have a bad day, or be unaware of some of the guidelines in this code of conduct. When that happens, you may reply to them and point out this code of conduct. Such messages may be in public or in private, whatever is most appropriate. However, regardless of whether the message is public or not, it should still adhere to the relevant parts of this code of conduct; in particular, it should not be abusive or disrespectful.
If you believe someone is violating this code of conduct, you may reply to them and point out this code of conduct. Such messages may be in public or in private, whatever is most appropriate. Assume good faith; it is more likely that participants are unaware of their bad behaviour than that they intentionally try to degrade the quality of the discussion. Should there be difficulties in dealing with the situation, you may report your compliance issues in confidence to either:
* President of the Apache Software Foundation: Sam Ruby (rubys at intertwingly dot net)
or one of our volunteers:
* Mark Thomas
* Joan Touzet
* Sharan Foga
If the violation is in documentation or code, for example inappropriate pronoun usage or word choice within official documentation, we ask that people report these privately to the project in question at private@project.apache.org, and, if they have sufficient ability within the project, to resolve or remove the concerning material, being mindful of the perspective of the person originally reporting the issue.
# Endnotes
This Code defines empathy as "a vicarious participation in the emotions, ideas, or opinions of others; the ability to imagine oneself in the condition or predicament of another." Empathetic is the adjectival form of empathy.
* or ask question on [stackoverflow](https://stackoverflow.com/questions/tagged/jmeter).
## :bar_chart: What needs to be developed
See:
*[Open bug entries for JMeter](https://bz.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&bug_severity=Blocker&bug_severity=Critical&bug_severity=Major&bug_severity=Normal&bug_severity=Regression&bug_severity=Minor&bug_severity=Trivial&product=JMeter&order=Bug%20Number&list_id=164231)
*[Enhancement requests for JMeter](https://bz.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&bug_severity=Enhancement&product=JMeter&order=Bug%20Number&list_id=164232)
## Development setup
### Gradle
You might find useful Gradle commands in [gradle.md](gradle.md)
### <a name="intellij"></a>IntelliJ IDEA
You require IntelliJ 2018.3.1 or newer.
1. Open the build.gradle.kts file with IntelliJ IDEA and choose `Open as Project`
1. Make sure `Create separate module per source set` is selected
1. Make sure `Use default gradle wrapper` is selected
1. In the `File already exists` dialogue, choose `Yes` to overwrite
1. In the `Open Project` dialogue, choose `Delete Existing Project and Import`
### Eclipse
Eclipse can import Gradle projects automatically via `Import...->Gradle project` wizard.
Optionally you can generate an Eclipse project by running
./gradlew eclipse
The steps to import the sources (based on Eclipse 2019-06) into Eclipse are as follows:
1. Install `Eclipse IDE for Java Developers`
1. Install the Groovy Eclipse plugin and select Groovy Compiler 2.4 (some tests are written in Groovy)
1. Install `Kotlin for Eclipse` plugin (builds scripts are written in Kotlin)
1. Make sure you have a Java 8 compatible JDK configured in your workspace
1. Open `File->Import...`
1. Select `Existing Gradle Project` and click `Next`
1. Read `How to experience the best Gradle integration` and click `Next`
1. Then you might just click `Finish`
## :star2: Have a patch
The best way to make sure your issue or feature is addressed is to submit a patch.
We accept patches through:
* pull requests
* patch attached to bugzilla.
However, before sending a patch, please make sure that the following applies:
* Your commit message is descriptive.
* Your patch doesn't have useless merge commits.
* Your coding style is similar to ours.
* Your patch is 100% tested. JUnit are welcome.
* All tests checks pass (run `./gradlew check`)
* You understand that we're very grateful for your patch!
## :heart: Adding something new
We do love to enhance Apache JMeter with you to become more powerful!
The best way to work out your idea is to discuss it first at our dev mailing list:
