Merge branch 'master' into adobe/devToMaster

.circleci/config.yml

@@ -218,6 +218,7 @@ jobs:
   jsdocs-deploy:
     docker:
       - image: node:8.10.0
+    working_directory: /home/circleci/build
     steps:
       - checkout
       - attach_workspace:

.github/ISSUE_TEMPLATE/BUG_REPORT.md

@@ -14,6 +14,10 @@ about: Having an issue? Please create a report to explain what it is about.
 
 #### Platform and Version
 
+#### AEM Version (mention the exact version in case of cloud SDK)
+
+#### AEM Forms Version
+
 #### Sample Code that illustrates the problem
 
-#### Logs taken while reproducing problem
+#### Logs taken while reproducing problem

CODE_OF_CONDUCT.md

@@ -0,0 +1,74 @@
+# Adobe Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+nationality, personal appearance, race, religion, or sexual identity and
+orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at [email protected]. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

CONTRIBUTING.md

@@ -0,0 +1,111 @@
+# Contributing
+
+Thank you for choosing to contribute to the Adobe Experience Manager Forms Core Components project, we really appreciate your time and effort! 😃🎊
+
+The following are a set of guidelines for contributing to the project.
+
+#### Contents
+
+* [Code of Conduct](#code-of-conduct)
+* [Ways to Contribute](#ways-to-contribute)
+  * [Reporting and Fixing Bugs](#reporting-and-fixing-bugs-) 🐛
+  * [Reviewing Code](#reviewing-code-) 👀
+  * [Documenting](#documenting-) 📜
+  * [Questions and Enhancement Requests](#questions-and-enhancement-requests-) 💭
+* [Contributing Code](#contributing-code-)
+* [Issue Report Guidelines](#issue-report-guidelines)
+* [Contributor License Agreement](#contributor-license-agreement)
+
+## Code of Conduct
+
+This project adheres to the Adobe [Code of Conduct](CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code. Please report unacceptable behavior to the team.
+
+## Ways to Contribute
+
+There are many forms of contributions. New components or features, changes to existing features, tests, documentation, bug fixes, or just good suggestions. For any contribution to be considered, a related [issue](#issue-report-guidelines) is always required.
+
+The Core Component Engineering Team reviews all issues and contributions submitted by the community. During the review we might require clarifications from the contributor. If there is no response from the contributor within two weeks time, the issue will be closed.
+
+Once a contribution is being reviewed, the Core Engineering Team will apply a relevant label to the associated issue. You can see our [label list on GitHub](https://github.com/adobe/aem-core-forms-components/labels) to better understand what each label means.
+
+### Reporting and Fixing Bugs 🐛
+
+#### Before Reporting a Bug 
+* Have a quick search through the currently open [bug reports](https://github.com/adobe/aem-core-forms-components/labels/bug) to see if the issue has already been reported.
+* Ensure that the issue is repeatable and that the actual behavior versus the expected results can be easily described.
+* Check that the issue you are experiencing is related to the Core Components project. It may be that the problem derives from AEM itself, typically editor code, rather than the Core Components. If you're not sure, then feel free to report the issue anyway and the committers will clarify for you. Issues in the product can be reported via [Adobe Enterprise Support](https://helpx.adobe.com/contact/enterprise-support.ec.html).
+
+#### Filing a Bug
+1. Visit our [issue tracker on GitHub](https://github.com/adobe/aem-core-forms-components/issues).
+1. File a `New Issue` as a `Bug Report`.
+1. Ensure your issue follows the [issue report guidelines](#issue-report-guidelines).
+1. Thanks for the report! The committers will get back to you in a timely manner, typically within one week.
+
+#### Fixing a Bug
+If you have a fix ready for a bug, submit a [pull request](#contributing-code-) and reference it in the associated issue.
+
+
+### Reviewing Code 👀
+
+Reviewing others' code contributions is another great way to contribute - more eyes on the code help to improve its overall quality. To review a pull request, check the [open pull requests](https://github.com/adobe/aem-core-forms-components/pulls) for anything you can comment on. 
+
+### Documenting 📜
+
+We very much welcome issue reports or pull requests that improve our documentation pages. While the best effort is made to keep them error free, useful and up-to-date there are always things that could be improved. The component documentation pages (for example the [TextInput Component Documentation](https://github.com/adobe/aem-core-forms-components/tree/master/ui.af.apps/src/main/content/jcr_root/apps/core/fd/components/form/textinput/v1/textinput)), this contributing guide or our [GitHub Wiki](https://github.com/adobe/aem-core-forms-components/wiki) pages are good places to start.
+
+### Questions and Enhancement Requests
+
+You can also add your voice to discussions around new and existing component features by commenting on an RTC. New components and features that openly invite public comment are marked by an [RTC](https://github.com/adobe/aem-core-forms-components/labels/rtc) (Request to Comment) label.
+
+## Contributing Code 👾 
+High quality code is important to the project, and to keep it that way, all code submissions are reviewed by committers before being accepted. Close adherence to the guidelines below can help speed up the review process and increase the likelihood of the submission being accepted.
+
+### Before Contributing
+* Consider [joining developer discussions](#joining-developer-discussions-) to get feedback on what you are thinking of contributing. It's better to get this early feedback before going ahead and potentially having to rewrite everything later.
+* Create a [bug report](#reporting-bugs-) or [feature request](#requesting-features-) issue summarizing the problem that you will be solving. This will again help with early feedback and tracking.
+* Have a look at our [component checklist](Guidelines.md), for an idea of what certifies a production-ready component.
+* Ensure you have [signed the Adobe Contributor License Agreement](http://opensource.adobe.com/cla.html). If you are an Adobe employee, you do not have to sign the CLA.
+
+### Contributing
+
+The project accepts contributions primarily using GitHub pull requests. This process:
+* Helps to maintain project quality
+* Engages the community in working towards commonly accepted solutions with peer review
+* Leads to a more meaningful and cleaner git history
+* Ensures sustainable code management 
+
+Creating a pull request involves creating a fork of the project in your personal space, adding your new code in a branch and triggering a pull request. Check the GitHub [Using Pull Requests](https://help.github.com/articles/using-pull-requests) article on how to perform pull requests.
+
+Please base your pull request on the `main` branch and make sure to check you have incorporated or merged the latest changes!
+
+The title of the pull request typically matches that of the issue it fixes, see the [issue report guidelines](#issue-report-guidelines).
+Have a look at our [pull request template](.github/pull_request_template.md) to see what is expected to be included in the pull request description. The same template is available when the pull request is triggered. 
+
+### Your first contribution
+Would you like to contribute to the project but don't have an issue in mind? Or are you still fairly unfamiliar with the code? Then have a look at our [good first issues](https://github.com/adobe/aem-core-forms-components/labels/good%20first%20issue), they are fairly simple starter issues that should only require a small amount of code and simple testing.
+
+## Issue Report Guidelines
+
+A well defined issue report will help in quickly understanding and replicating the problem faced, or the feature requested. Below are some guidelines on what to include when reporting an issue. You can also see [this community reported issue](https://github.com/adobe/aem-core-wcm-components/issues/247) for an example of a well written issue report.
+
+##### Title
+
+* **Descriptive** - Should be specific, well described and readable at a glance.
+* **Concise** - If the issue can't be easily described in a short title, then it is likely unfocused.
+* **Keyword-rich** - Including keywords can help with quickly finding the issue in the backlog. Component related issues can be prefixed with a bracketed label with the component name, for example `[Image]` for the image component.
+
+Bad title: `Search component has security problems`  
+Good title: `[Search] Fulltext search of pages might lead to DDOS`
+
+##### Description
+See our [bug report template](.github/ISSUE_TEMPLATE/BUG_REPORT.md) or [feature request template](.github/ISSUE_TEMPLATE/FEATURE_REQUEST.md) for details on what is expected to be described. The same information is available when creating a new issue on GitHub.
+
+## Contributor License Agreement
+
+By contributing your code to the Adobe Marketing Cloud Github Organisation you grant Adobe a non-exclusive, irrevocable, worldwide, royalty-free, sublicensable, transferable license under all of Your relevant intellectual property rights (including copyright, patent, and any other rights), to use, copy, prepare derivative works of, distribute and publicly perform and display the Contributions on any licensing terms, including without limitation: (a) open source licenses like the Apache License, Version 2.0; and (b) binary, proprietary, or commercial licenses. Except for the licenses granted herein, You reserve all right, title, and interest in and to the Contribution.
+
+You confirm that you are able to grant us these rights. You represent that You are legally entitled to grant the above license. If Your employer has rights to intellectual property that You create, You represent that You have received permission to make the Contributions on behalf of that employer, or that Your employer has waived such rights for the Contributions.
+
+You represent that the Contributions are Your original works of authorship, and to Your knowledge, no other person claims, or has the right to claim, any right in any invention or patent related to the Contributions. You also represent that You are not legally obligated, whether by entering into an agreement or otherwise, in any way that conflicts with the terms of this license.
+
+YOU ARE NOT EXPECTED TO PROVIDE SUPPORT FOR YOUR SUBMISSION, UNLESS AND EXCEPT TO THE EXTENT YOU CHOOSE TO DO SO. UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING, THE SUBMISSION PROVIDED UNDER THIS AGREEMENT IS PROVIDED WITHOUT WARRANTY OF ANY KIND.

Guidelines.md

@@ -0,0 +1,160 @@
+# Component Checklist
+
+**Work in progress:** This page is a tech preview and is being worked on.
+
+
+## Introduction
+
+The items of the checklist will serve to certify [AEM Components](https://docs.adobe.com/docs/en/aem/6-2/develop/components.html), so that AEM project implementations can compare them and know which ones fit their needs and requirements. This checklist applies to AEM Components that render parts of a page, including their dependencies (Java classes, client libraries, etc.). Exceptions to the checklist are possible, but must be an explicitly listed in the documentation. The components can be built by Adobe or by the community, and a central list of all components will be hosted by Adobe, along with the summary of the checklist completeness.
+
+
+## The Checklist
+
+1. [Available](#1-available)
+2. [Documented](#2-documented)
+3. [Supported](#3-supported)
+4. [Production Ready](#4-production-ready)
+    1. [Secure](#4i-secure)
+    2. [Fast](#4ii-fast)
+    3. [Mobile-friendly](#4iii-mobile-friendly)
+    4. [Internationalized](#4iv-internationalized)
+    5. [Accessible](#4v-accessible)
+5. [Blends In](#5-blends-in)
+    1. [Compatible](#5i-compatible)
+    2. [Lean](#5ii-lean)
+    3. [Separated concerns](#5iii-separated-concerns)
+    4. [Standard](#5iv-standard)
+6. [Tested](#6-tested)
+
+
+### 1. Available
+
+Whether the component's code can be accessed and added as dependency on an AEM implementation project.
+
+- [ ] [Apache License](http://www.apache.org/licenses/LICENSE-2.0) or [similar in terms](http://www.apache.org/legal/resolved.html#category-a) with corresponding code headers.
+- [ ] Discoverable, publicly browseable and downloadable source code.
+- [ ] Maven project that can be used as dependency.
+
+
+### 2. Documented
+
+Whether the capabilities and intended use are described.
+
+- [ ] Description and intended use of the component.
+- [ ] List of exceptions to this checklist (possibly with some justification).
+- [ ] List of dependencies on back-end and front-end libraries and frameworks.
+- [ ] Features and edit/design dialog options (possibly with screenshots).
+- [ ] Content structure and properties.
+- [ ] Exported APIs and extension points.
+
+
+### 3. Supported
+
+Whether the documented capabilities are supported by the vendor/author of the component for production usage.
+
+- [ ] Link to contact support for the component.
+- [ ] Description of the conditions to get or purchase support.
+- [ ] Support for the documented intended use and options.
+
+
+### 4. Production Ready
+
+Whether the component matches the basic requirements to be used in production for the intended use.
+
+
+#### 4.i. Secure
+
+- [ ] No known security vulnerability.
+- [ ] No hard-coded or stored clear-text passwords.
+- [ ] Systematic XSS protection and string/URL encoding (as enforced by Sightly).
+- [ ] Outgoing network connections are disabled by default and duly documented.
+- [ ] Use service users for background processes (no loginAdministrative).
+
+
+#### 4.ii. Fast
+
+- [ ] Features that can have a global performance impact or performance bottlenecks are disabled by default and duly documented.
+- [ ] Cacheable output (eg. no user-specific data in the response, no query parameters).
+- [ ] No JCR queries, no servlet filters, and no custom binding values providers.
+- [ ] No server-side event handling without limited scope and explicit documentation.
+- [ ] JavaScript and CSS placed in client libraries that can loaded as desired on the page (on top, bottom, or asynchronously).
+
+
+#### 4.iii. Mobile-friendly
+
+- [ ] Optimized loading of media sizes (images and video).
+- [ ] Fluid and responsive layout using the AEM grid.
+- [ ] Touch UI component dialogs for edit and design dialogs.
+
+
+#### 4.iv. Internationalized
+
+- [ ] All publish-side labels are internationalized using the forms i18n library
+- [ ] All author-side labels are internationalized through a dictionary.
+- [ ] Accounts for variable text lengths.
+
+
+#### 4.v. Accessible
+
+- [ ] Follows WCAG 2.0 guidelines (eg. component can be used with a keyboard).
+- [ ] Extract acessibility related dialog settings to a specific tab.
+- [ ] For custom UI components, follows the ARIA and ATAG guidelines.
+
+
+### 5. Blends In
+
+Whether the component will fit into a project that follows best practice and will not interfere with other elements.
+
+
+#### 5.i. Compatible
+
+- [ ] Is multi-site friendly: it won't impact other sites, and it's configuration can be site-specific.
+- [ ] No assumption on the content structure, configuration or setup of the instance.
+- [ ] Is compatible with the AEM page / forms editor features (like Personalization, ContextHub, Layouting mode, Responsive preview, Launches, etc).
+- [ ] No page refresh when adding the component to the paragraph system, or when modifying it.
+- [ ] No usage of JCR API, of JCR observation, custom node types, or custom JCR namespaces.
+- [ ] No hardcoded resource types, paths, groups, etc.
+- [ ] Tolerant if the content structure is incorrect or outdated.
+- [ ] Namespaced CSS and JS selectors to apply only to the one component.
+
+
+#### 5.ii. Lean
+
+- [ ] No functionality that isn’t deemed necessary.
+- [ ] No abstraction layers that aren’t absolutely necessary.
+- [ ] No styles or scripts that are design or site specific (keep them to the bare minimum).
+
+
+#### 5.iii. Separated concerns
+
+- [ ] No JSP, use Sightly (default choice) or Handlebars (when client & server-side rendering is needed).
+- [ ] No HTML or CSS generated from Java or JavaScript code.
+- [ ] No styles, scripts, or script events inlined in HTML.
+- [ ] No client-side parsing of URL structures.
+
+
+#### 5.iv. Standard
+
+- [ ] No deprecated APIs.
+
+Follows naming, formatting and coding conventions:
+- [ ] Documentation
+- [ ] Maven
+- [ ] Bundles
+- [ ] Java
+- [ ] JCR
+- [ ] URL
+- [ ] Sightly/Handlebars (no JSP)
+- [ ] HTML
+- [ ] JavaScript
+- [ ] CSS
+- [ ] Logging
+
+
+### 6. Tested
+
+Whether the component can be verified to perform as expected once installed on a system, and won't suffer from regressions.
+
+- [ ] Unit and/or integration tests
+- [ ] Automated functional tests
+- [ ] Performance tests