After installation from the marketplace we want to invite the user to explore the capabilities of the toolkit and potentially include a gesture to set up initial credentials etc. Some extensions use a subtle pop-up window in the lower right to welcome the user, or invite the user to view details of an update.

This issue is to define what we want to do and will spawn additional refinement issues for the implementation.

Discuss and settle on one assertion framework (assertj, assertk, hamcrest)

Port the current invoke screen below:

To be a Run Configuration similar to the Local Invoke

Including having it "created from context (right-click on function in explorer)"

Java SDK v2 includes a semi-automated change-log generation. This was borrowed from the Python SDK team. Change-log entries are included along with a commit in the form of .json files generated by a script included with the repository. In our case we could use a gradle task.

These json files are put into a directory called .changes/next-release, when the next release is run they are collected up, formatted and the CHANGELOG.md file is generated. Java team uses a Python script for this, but for our purposes this could be written easily again in groovy and included as a gradle build-task - no external dependencies needed.

In our case we'd also want that changelog to be put into the plugin.xml and this can be done via the gradle plugins' patchXml task.

Only wrinkle is that github's CHANGELOG.md needs to be in Git-Flavoured Markdown (GFM) and JetBrains plugins expect their change-log's to be HTML. We need to find a way to convert from one to the other.

And add linting rule to ensure all future files include the appropriate license header.

Package and deploy Java, Kotlin & Scala Lambda's from a gutter icon in the editor.

1. Make the details text boxes consistently sized for all lambdas
2. Add a box around the time so it looks the same
3. Add account indicator (credential profile display name? Account ID?)
4. Add region
5. Add runtime?

Walk through a sample Java project that packages a docker image and can be deployed to an ECS cluster.

A new project wizard that sets up a Java-based project to be deployed to AWS Lambda using SAM Templates and a CFN deployment

The ability to load a lambda input from a file in the workspace

From the gutter icon display a "re-publish" option that will update an existing lambda (if detected).

• We need to have extensions for other profile credentials like Env Var credentials, ECS credentials
• Refactor the profile credentials extensions a bit for allowing each extension to define their own init logics.

compile "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"
compile "com.amazonaws:aws-java-sdk-s3:$awsSdkVersion"
compile "com.amazonaws:aws-java-sdk-lambda:$awsSdkVersion"
compile "com.amazonaws:aws-java-sdk-iam:$awsSdkVersion"
compile "com.amazonaws:aws-java-sdk-codecommit:$awsSdkVersion"
testCompile group: 'junit', name: 'junit', version: '4.12'
testCompile group: 'org.assertj', name: 'assertj-core', version: '3.8.0'

Filter where AssumeRolePolicyDocument contains lambda.amazonaws.com

Extend the UI to allow user to select a credential provider.
If one is added, we need to fetch credentials and pass them to the local lambda invoke process as the standard env vars.

Integrate the Toolkit with the AWS Toolkit telemetry system.

Depends on #81

Ability to invoke any lambda in a customers account using pre-canned templates available here: http://vstoolkit.amazonwebservices.com/LambdaSampleFunctions/SampleRequests/manifest.xml

A service that allows fetching (and caching) of remote resources. This service should handle exceptions gracefully and fallback to either previously-cached versions if possible and then finally pre-shipped resources when no cache and no remote version is available.

Examples for usage:

• Lambda project templates (e.g. http://vstoolkit.amazonwebservices.com/LambdaSampleFunctions/SampleRequests/CloudFormationCreateRequest.json)
• Region flags (http://vstoolkit.amazonwebservices.com/flags/ap-northeast-2.png)

Enable the 'source_profile" credential file property to assume a role

Java & Python

Given a handler, try to find the PSI reference for it so we can navigate to it

Integrate a Jump To Source action based on it, and add to Lambda editor UI
Stretch goal: Add to explorer as well

Exposing S3 buckets as a File System would create a nice UI to allow customers to drag and drop objects to and from there buckets.

An initial implementation was begun -
https://github.com/aws/aws-toolkit-jetbrains/blob/ad6e3694ae9bd1295ed9da0206102214dacc0f36/jetbrains-core/src/software/aws/toolkits/jetbrains/services/s3/S3BucketViewer.kt

Current Docker setup in IDEA requires a static username/password - AWS uses a rolling token that expires every 12 hours. See get-authorization-token

Need to extend the docker plugin to allow ECR registries to be setup.

Extend the UI to allow user to select a region. (Default to active region)
If one is added, we need to pass it to local lambda invoke process as the standard env vars.

Clicking the lambda in the explorer multiple times should give focus to the already open editor, not open a new one.

Allow streaming of a selected log-group to a console within the IDE.

Add the ability to determine Lambda handlers from Kotlin code

The toolkit needs to be able to support internationalization in the future, in order to do this we need to move all public facing / UI strings to a ResourceBundle

The partition loader used in AwsRegionProvider.kt is the only usage of Java SDK V1. The API in V2 is marked as internal.

Do one of the following:

1. Ask Java SDK if that can be marked as public
2. Write our own loader. May need to go this route if we want to enhance the endpoints.json with flag and geographic region metadata

Enable local debugging of Java Lambda through an invocation wrapper that simulates (with low fidelity) invocations through Lambda.

Before open-sourcing we should create/update the following documents:

• Update README.md
• Create CONTRIBUTING, CODE_OF_CONDUCT
• Settle of licenses
• Include license text as a comment header in all source-files
• Add linting rule to ensure header is always present in source-files.

Today the create Lambda dialog's Create role makes a role that can't be used with that lambda due to an empty document is attached.

We should replace the current modal with a custom Dialog form that contains a role name box, and a JSON editor that is pre-filled with a valid minimal template for such use. (i.e. lambda creator gives a doc that uses the service principal and cloudwatch logs support)

Reference the Kotlin for Plugin Developer page for replacing code like this.

• Add extension functions for various log levels & associated tests
• Update usages of 'deprecated use'
• Add ktlint rule that forbids use of 'bare' log calls like LOG.debug("message") instead favouring the above extension function: LOG.debug{ "message" }

Depends on #139

Consoles templates:
Trust doc:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Policy doc:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "arn:aws:logs:*:*:*"
        }
    ]
}

• automated release pipelines
• operational readiness review
• jetbrains plugin repo account
• UX review

We'd like the ability to track usage - an easy way to do this is to add details to the User-Agent string that is sent with AWS requests.

Port existing load event template to new run configuration