Solves a single thing in the build configurations, resulting in a few
wins.
1. Reduced number of warnings in the output.
1. In release branch:
```
mvn clean package -DskipTests | grep --fixed-strings --count '[WARNING]'
3233
```
1. In this PR's branch:
```
mvn clean package -DskipTests | grep --fixed-strings --count '[WARNING]'
172
```
2. All uber-jar files are shaded twice, currently. Once with the default
execution of `maven-shade-plugin`, and again with the `shade-plugin-jar`
execution in these `pom.xml` files. This is double-work, and is the
cause of most of the warnings we see.
1. This `shade-plugin-jar` was added to have the plugin information
included in the `/META-INF/MANIFEST.MF` file, since we can't configure
the default execution of the shade plugin (it comes to us from Spring
Boot).
2. Instead, we switch to configuring plugin information in a
`/plugin.properties` file.
3. Previously, we used `/plugin.properities` for plugin information in
dev time, and `/META-INF/MANIFEST.MF` in production. This PR will change
it so that we use `/plugin.properties` all the time. We configure PF4J
with a custom plugin manager to achieve this.
3. Moved all `plugin.properties` into `src/main/resources`, so that they
land up in the root of the final jar files. But this means, during
development, loading the plugin fails since it looks for a
`plugin.properties` at the root of the plugin module, i.e., next to the
`src` folder.
1. For this, in the custom plugin manager class, we change where we look
for the `plugin.properties` file during development mode. In this mode,
we look at the `target/classes/plugin.properties` file, which is where
maven saves this file, taken from
`src/main/resources/plugin.properties`.
2. This also solves the duplication of the plugin properties that's
currently present, between `plugin.properties` and the `<properties>`
section of `pom.xml` files.
Here's the shade plugin's default execution and configuration, from
Spring Boot:
https://github.com/spring-projects/spring-boot/blob/v3.0.1/spring-boot-project/spring-boot-starters/spring-boot-starter-parent/build.gradle#L174.
## Description
This PR updates the error logs
- Establishing a consistent format for all error messages.
- Revising error titles and details for improved understanding.
- Compiling internal documentation of all error categories,
subcategories, and error descriptions.
Updated Error Interface:
https://www.notion.so/appsmith/Error-Interface-for-Plugin-Execution-Error-7b3f5323ba4c40bfad281ae717ccf79b
PRD:
https://www.notion.so/appsmith/PRD-Error-Handling-Framework-4ac9747057fd4105a9d52cb8b42f4452?pvs=4#008e9c79ff3c484abf0250a5416cf052
>TL;DR
Fixes #
Media
> A video or a GIF is preferred. when using Loom, don’t embed because it
looks like it’s a GIF. instead, just link to the video
## Type of change
- New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
- Manual
- Jest
- Cypress
### Test Plan
### Issues raised during DP testing
## Checklist:
### Dev activity
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [x] I have added tests that prove my fix is effective or that my
feature works
- [x] New and existing unit tests pass locally with my changes
- [x] PR is being merged under a feature flag
### QA activity:
- [ ] Test plan has been approved by relevant developers
- [ ] Test plan has been peer reviewed by QA
- [ ] Cypress test cases have been added and approved by either SDET or
manual QA
- [ ] Organized project review call with relevant stakeholders after
Round 1/2 of QA
- [ ] Added Test Plan Approved label after reveiwing all Cypress test
---------
Co-authored-by: subrata <subrata@appsmith.com>
This upgrade takes care of our move to JDK 17, Spring Boot 3.0.1 and a
few other security upgrades along the way.
Fixes#18993
TODO:
- [x] Check CI changes for Java 17
- [x] Check vulnerability report
- [x] Mongock needs an upgrade
- [x] Add JVM args at all possible places for exposing java.time module
- [x] Add type adapters everywhere / use the same config for type
adapters everywhere
* Changes to testDatasource interface method and archive flow
* Tests for plugin level testDatasource implementations
* Added test for refreshing cache on deleting datasource
* Modified warnings to errors in logs
* Fixed test
* Fixed test
Upgrades vulnerable dependencies in all plugins except for MySQL. That one is still failing and I'll fix it in a separate PR. Issue #14475
Co-authored-by: Nayan <nayan@appsmith.com>
Co-authored-by: Anagh Hegde <anagh@appsmith.com>
* ArangoDB has two types of command - one that fetches a response and the other that updates a document. Currently, ArangoDB plugin treats all cmds like the one that returns a response, hence when update cmds are run then an empty response is returned to the client since there is nothing to fetch. This PR adds a check to fetch the response based on the type of cmd. Hence, for an update cmd the number of writes succeeded or failed would be returned as a response.
* Added field to autogenerate values in DB column
* Added comment and refactor
* Autogenerate field update according to names instead of type for ArangoDB
