Dependency issues while trying to run legacy projects with Flutter 2 (issue with i18n support)

Steps to Reproduce
Here is a project I created with Flutter 1.22.6 and I am now trying to build with Flutter 2.0.1. It runs fine with Flutter 1.22.6. Unfortunately I can't even get to run flutter run with 2.0.1, because flutter pub get fails with the following error:
% flutter pub get
Running "flutter pub get" in blindly_copy...
Because blindly depends on flutter_localizations any from sdk which depends on intl 0.17.0, intl 0.17.0 is required.

So, because blindly depends on intl 0.16.1, version solving failed.
pub get failed (1; So, because blindly depends on intl 0.16.1, version solving failed.)

I used this guide on all my projects to implement internationalization, which is why all my projects depend on intl and flutter_localizations. But apparently Flutter 2 required version 0.17.0 of intl. So I upgrade this dependency to 0.17.0, and comment out dependency on date_time_picker that still needs to be updated to depend on intl 0.17.0, now I'm getting the following dependency issue:
% flutter pub get
Running "flutter pub get" in blindly_copy...
Because no versions of firebase_auth match >0.20.1 <0.21.0 and firebase_auth 0.20.1 depends on firebase_auth_web ^0.3.3, firebase_auth ^0.20.1 requires firebase_auth_web ^0.3.3.

Because firebase_auth_web 0.3.3 depends on intl ^0.16.1 and no versions of firebase_auth_web match >0.3.3 <0.4.0, firebase_auth_web ^0.3.3 requires intl ^0.16.1.
Thus, firebase_auth ^0.20.1 requires intl ^0.16.1.

So, because blindly depends on both intl ^0.17.0 and firebase_auth ^0.20.1, version solving failed.
pub get failed (1; So, because blindly depends on both intl ^0.17.0 and firebase_auth ^0.20.1, version solving failed.)

So now pretty much all of my Firebase dependencies need to be updated to be compatible with intl 0.17.0. Which I do, and now I'm getting an issue with url_launcher:
% flutter pub get
Running "flutter pub get" in blindly_copy...
Because no versions of url_launcher match >5.7.10 <6.0.0 and url_launcher 5.7.10 depends on url_launcher_platform_interface ^1.0.9, url_launcher ^5.7.10 requires url_launcher_platform_interface ^1.0.9.

And because no versions of url_launcher_platform_interface match >1.0.9 <2.0.0 and url_launcher_platform_interface 1.0.9 depends on plugin_platform_interface ^1.0.1, url_launcher ^5.7.10 requires plugin_platform_interface ^1.0.1.
And because firebase_core >=1.0.0 depends on firebase_core_platform_interface ^4.0.0 which depends on plugin_platform_interface ^2.0.0, url_launcher ^5.7.10 is incompatible with firebase_core >=1.0.0.

So, because blindly depends on both firebase_core ^1.0.0 and url_launcher ^5.7.10, version solving failed.
pub get failed (1; So, because blindly depends on both firebase_core ^1.0.0 and url_launcher ^5.7.10, version solving failed.)

So now I'm trying to update url_launcher to 6.0.2 so that it is compatible with Flutter 2. But now I'm getting an issue with google_fonts, so I update this one as well, but this one conflicts with validators that's not been updated. And it goes on and on like that and I can't get my build to run anymore.
And I see that on other similar projects, simply because flutter_localizations embedded in Flutter 2 depends on intl 0.17.0 which is incompatible with so many other dependencies.
For now, I downgraded Flutter to 1.22.6 so that my projects can build again. But is the solution just to wait for all the dependencies to be updated. Shouldn't old projects still build with the new version of Flutter without this?
Logs
% flutter doctor -v
[✓] Flutter (Channel stable, 2.0.1, on macOS 11.2.2 20D80 darwin-x64, locale fr-FR)
    • Flutter version 2.0.1 at /Users/sarbogast/fvm/versions/stable
    • Framework revision c5a4b4029c (il y a 2 jours), 2021-03-04 09:47:48 -0800
    • Engine revision 40441def69
    • Dart version 2.12.0

[!] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at /Users/sarbogast/Library/Android/sdk
    • Platform android-30, build-tools 30.0.3
    • Java binary at: /Users/sarbogast/Library/Application Support/JetBrains/Toolbox/apps/AndroidStudio/ch-0/201.7042882/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6915495)
    ! Some Android licenses not accepted.  To resolve this, run: flutter doctor --android-licenses

[✓] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.4, Build version 12D4e
    • CocoaPods version 1.10.1

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.1)
    • Android Studio at /Users/sarbogast/Library/Application Support/JetBrains/Toolbox/apps/AndroidStudio/ch-0/201.7042882/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6915495)

[✓] IntelliJ IDEA Ultimate Edition (version 2020.3.2)
    • IntelliJ at /Users/sarbogast/Applications/JetBrains Toolbox/IntelliJ IDEA Ultimate.app
    • Flutter plugin version 54.0.3
    • Dart plugin version 203.7759

[✓] VS Code (version 1.53.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.19.0

[✓] Connected device (2 available)
    • iPhone 12 Pro (mobile) • E85E5DC8-065D-4C10-9849-0C40CCB3C417 • ios            • com.apple.CoreSimulator.SimRuntime.iOS-14-4 (simulator)
    • Chrome (web)           • chrome                               • web-javascript • Google Chrome 88.0.4324.192
    ! Error: Séjour is busy: Waiting for Device. Xcode will continue when Séjour is finished. (code -10)

! Doctor found issues in 1 category.

Had a similar situation. Even wondered if it would a good idea to create a project setting called “flutter version” to easily manage incremental updates and flutter changes.

if you want to use flutter 2 and face such issues, update all packages to latest versions. if you still get errors, use dependency_overrides which forces to use some version with no respect to transitive dependencies

It's a never ending game of wack-a-mole. I tried to get rid of all the unmaintained deps and I end up with an incompatibility between the latest version of google_fonts and the latest version of Firebase, both maintained by Google. This is insane.

Hi @sarbogast
For the flutter_localizations package, it is now part of the framework, so to avoid ints conflicts, your dependency should depend in the framework:
flutter_localizations:
  sdk: flutter

Of other dependencies, please try to upgrade them to their latest version and see if that works for you.
Thank you

I am trying to be able to run my flutter app on the newest Flutter. After some version fiddling I am ending up with:
pub get failed (1; So, because labplus depends on both http ^0.13.0 and firebase_analytics ^7.1.0, version solving failed.)

again both packages are maintained by Google. Unfortunately, I can't see an easy way out of this.
Flutter doctor included:
[✓] Flutter (Channel stable, 1.22.5, on macOS 11.0.1 20B29 darwin-x64, locale en-GB)
    • Flutter version 1.22.5 at /Users/luke/Frameworks/flutter
    • Framework revision<PHONE_NUMBER> (3 months ago), 2020-12-10 11:54:40 -0800
    • Engine revision ae90085a84
    • Dart version 2.10.4`

@pedromassango I already tried that and I'm getting the same issue as @lukeurban: 2 packages maintained by Google incompatible with each other:
% flutter pub get
Running "flutter pub get" in blindly_copy...
Because google_fonts >=2.0.0-nullsafety.0 depends on http ^0.13.0 and firebase >=5.0.3 <9.0.0 depends on http >=0.11.3 <0.13.0, google_fonts >=2.0.0-nullsafety.0 is incompatible with firebase >=5.0.3 <9.0.0.

And because firebase_analytics >=7.1.0 depends on firebase_analytics_web ^0.2.0 which depends on firebase ^7.3.0, google_fonts >=2.0.0-nullsafety.0 is incompatible with firebase_analytics >=7.1.0.
So, because blindly depends on both firebase_analytics ^7.1.0 and google_fonts ^2.0.0, version solving failed.
pub get failed (1; So, because blindly depends on both firebase_analytics ^7.1.0 and google_fonts ^2.0.0, version solving failed.)

You can try it for yourself with my project here. All the dependencies are up-to-date, and flutter pub get still fails.

As suggested above, you can use dependecy overrides to avoid those conflicts!

2 packages maintained by Google incompatible with each other

Those packages are not part of the Flutter team's packages (they are third-party package/plugins), I would suggest you to file an issue in their related repositories and probably close this issue.
For Firebase related issues:
https://github.com/FirebaseExtended/flutterfire/issues
For Google Fonts:
https://github.com/material-foundation/google-fonts-flutter/
I don't think there is much the Flutter team can do to help with this.
Thank you

@pedromassango I already tried that and I'm getting the same issue as @lukeurban: 2 packages maintained by Google incompatible with each other:
% flutter pub get
Running "flutter pub get" in blindly_copy...
Because google_fonts >=2.0.0-nullsafety.0 depends on http ^0.13.0 and firebase >=5.0.3 <9.0.0 depends on http >=0.11.3 <0.13.0, google_fonts >=2.0.0-nullsafety.0 is incompatible with firebase >=5.0.3 <9.0.0.

And because firebase_analytics >=7.1.0 depends on firebase_analytics_web ^0.2.0 which depends on firebase ^7.3.0, google_fonts >=2.0.0-nullsafety.0 is incompatible with firebase_analytics >=7.1.0.
So, because blindly depends on both firebase_analytics ^7.1.0 and google_fonts ^2.0.0, version solving failed.
pub get failed (1; So, because blindly depends on both firebase_analytics ^7.1.0 and google_fonts ^2.0.0, version solving failed.)

You can try it for yourself with my project here. All the dependencies are up-to-date, and flutter pub get still fails.

hi @sarbogast did you managed to resolve this? I had the same issue with firebase_analytics 7.1.0 and google_fonts 2.0.0. But there were new releases for FlutterFire dependencies a few days ago and I managed to resolve this by updating firebase_analytics to 7.1.1.

I have another issue with firebase packages flutterfire#5322. @benedictkhoo I am still waiting for the solution.
@pedromassango my app is live and I don't want to rush into temporary solutions as dependency overrides. I wish it to be resolved with a viable dependency connection. I'll wait with my upgrade. But thank you very much for the suggestion! ;)

Without additional information, we are unfortunately not sure how to resolve this issue.
We are therefore reluctantly going to close this bug for now.
Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.
Could everyone who still has this problem please file a new issue with the exact description of what happens, logs, and the output of flutter doctor -v.
All system setups can be slightly different, so it's always better to open new issues and reference related issues.

Re-opening to track the ecosystem upgrade that needs to happen.

Note that you can override intl to ^0.17.0 as a temporary workaround, but that will in itself cause issues later down the line even if it happens to work right now:
dependency_overrides:
  intl: ^0.17.0

The root of the problem here though is sdk vendored packages which have pub package dependencies. NNBD definitely highlights this because of the large number of packages with breaking changes, but it will always be a potential version lock problem. Note that this is regardless of pinning or version constraints (in this case it would have been a ^0.17.0 dep anyways presumably, which would have the same problem).
That is a very difficult problem to solve, but if we want to resolve the core issue that is the place to start IMO.

@amirh had written a tool that was "like Rosie but for GitHub" - I wonder if we might be able to drive some updates to the newer intl in the ecosystem, since in some cases it may trivially pass without substantive code updates?

There's at least one breaking change in called out in intl 0.17 in addition to potential breaking changes from the migration itself; trying to apply an LSC without knowing anything about whether the packages are affected by those breaking changes, or have sufficient test coverage that the PR would fail if they were, seems extremely risky.
@kevmoo Have you run the 0.16 query discussed above? Do we know how many packages are still using 0.16?

I don't think that information is public, so we'd need to enlist pub.dev folks.

https://pub.dev/api/packages/retry/metrics

Any updates here?

Sorting by popularity, the top ten plugins that are using something older than 0.17 (number in parentheses is its place on the list of all intl dependencies sorted by popularity:

flutter_money_formatter (32): ^0.15.8—Apparently abandoned, and doesn't work with previous stable versions of Flutter either.
angular (33): ^0.16.0—Has a fix on master, but unpublished
dash_chat (36): ^0.16.0—Has a fix on master, but unpublished
angular_components (41)  ^0.16.0
webfeed (45): ^0.16.0
bezier_chart (46):  ^0.16.0
horizontal_calendar_widget (56): ^0.16.1
flutter_clean_calendar  (63): ^0.16.1
commons (64): ^0.16.1
flutter_calendar (68): ^0.16.0

@kevmoo Can we just fix angular and angular_components?
(I'm skeptical about the utility of this sort, given that the one with the highest popularity score has been broken since well before Flutter 2.)

angular and angular_components are...tough. We need to get test passing
with all of the latest stuff.
Hoping to spend a bit more time here this week.
On Tue, Apr 13, 2021 at 7:41 PM stuartmorgan @.***>
wrote:

Sorting by popularity, the top ten plugins that are using something older
than 0.17 (number in parentheses is its place on the list of all intl
dependencies sorted by popularity:

flutter_money_formatter (32): ^0.15.8—Apparently abandoned, and
doesn't work with previous stable versions of Flutter either.
angular (33): ^0.16.0—Has a fix on master, but unpublished
dash_chat (36): ^0.16.0—Has a fix on master, but unpublished
angular_components (41) ^0.16.0
webfeed (45): ^0.16.0
bezier_chart (46): ^0.16.0
horizontal_calendar_widget (56): ^0.16.1
flutter_clean_calendar (63): ^0.16.1
commons (64): ^0.16.1
flutter_calendar (68): ^0.16.0

@kevmoo https://github.com/kevmoo Can we just fix angular and
angular_components?
(I'm skeptical about the utility of this sort, given that the one with the
highest popularity score has been broken since well before Flutter 2.)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/77491#issuecomment-819179614,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAEFCUCYEKEQCX2WM4FNGLTIT6GXANCNFSM4YXGEEZQ
.

I don't think there is a reason to depend on both angular and flutter in the same project is there? If that assumption that is correct then these shouldn't be affected by flutter package dependencies.

...that, too!
On Wed, Apr 14, 2021 at 8:42 AM Jacob MacDonald @.***>
wrote:

I don't think there is a reason to depend on both angular and flutter in
the same project is there? If that assumption that is correct then these
shouldn't be affected by flutter package dependencies.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/77491#issuecomment-819618275,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAEFCXBS3A4N7SJJDE3E3LTIWZVZANCNFSM4YXGEEZQ
.

What is actionable here at this point? I'm eager for us to make progress but it's not clear to me what progress actually looks like here.

I don't know how many apps are flutter + angular. We are getting a bit closer to releasing the latest angular, but it's not going to be soon.
Otherwise, it's a matter of going after these other big blockers and getting them to migrate – right?

Otherwise, it's a matter of going after these other big blockers and getting them to migrate – right?

I think the issue is whether we know what the "big blockers" actually are. It seems very unlikely that an abandoned project to format money that didn't work in Flutter 1.20 either is actually a major blocker, but it's at the top of the popularity sort.
@jonasfj How much do we trust that the popularity score reflects real, current usage?

@stuartmorgan There are lots of caveats to our current popularity metrics.
As a relative number it's not entirely unfair, but it's biased in many unfortunate ways.
We also had a bug not long ago where pub would not send correct metadata about whether or not a dependency was direct or transitive.
On pub.dev we count transitive a weight of 0.1 and direct dependencies with a weight of 1, so getting that metadata wrong probably increased the popularity metric for a lot of packages like win32 and ffi which are frequently fetched as transitive dependencies.
If you look at things that depend on package:ffi, ordered by popularity you'll see:
https://pub.dev/packages?q=dependency%3Affi&sort=popularity
I'm guessing path_provider_windows which is used by path_provider, causes package:ffi and package:win32 to become very popular.
I think we've fixed the metadata, but that might not have reached the entirely population yet, I don't recall when/if it shipped.
The thing is that we only count requests going to pub.dev, and this depends a lot on client behavior.
For example, flutter pub get won't necessarily try to discover new versions for all dependencies, because it already has a version in pubspec.lock, so it's not attempted to upgrade.
And pub will rarely download package versions, because they are cached once in PUB_CACHE...
Add to this, the constant risk that we may not be successfully filtering out all CI platforms, and any one of those could skew our popularity metrics quite a bit.
Just saying: there are many ways in which these numbers aren't perfect.
I think they are reasonably good within an order of magnitude, there is a big difference between 100%, 99%, 90%, 10%, 1% popularity.
We are working to build better metrics in the future. If you have a specify package you're wondering about it might be worth looking at what depends on it.. maybe something there is popular. I can also go digging through a few logs to see what Dart / Flutter versions is using if that's interesting.

I think the issue is whether we know what the "big blockers" actually are. It seems very unlikely that an abandoned project to format money that didn't work in Flutter 1.20 either is actually a major blocker, but it's at the top of the popularity sort.

Jonas helped me dig into the numbers on this a bit, and it looks like the correct interpretation is not that the sort is wrong, but that the high end of that sort just isn't actually that high; there are so many packages that being 94% doesn't actually mean there are all that many users.
And looking at the issue tracker for the project, many of the bugs are about the compat issue with intl 0.15—from before Flutter 2—and people have suggested to each other to override that dependency, so it's likely that the reason there's still usage is that a certain number of people were already overriding intl to use it. That makes the level of usage it has much more plausible.
So it seems like the take-away from the list we have is that we don't actually have big blockers. Instead we have a long tail, which means there's not much we can reasonably do here; the LSC seems like the only thing that would have appreciable impact, but as mentioned above I don't see this as a safe candidate for an LSC.
My suggestion is that we close this as unactionable, unfortunately. We may want to file an issue about trying to come up with a generic solution for the problem of pinning third-party dependencies in the framework though, as this has happened before (like the 0.15/0.16 mismatch in the package above) and will happen again, even though it won't be at the scale of the Flutter 2/NNBD impact unless a similar ecosystem-wide migration happens again. @Hixie, thoughts?

Seems reasonable. Let's keep an eye out for whether something needs to change though.

Filed #81472 to consider whether we can reduce this kind of problem in the future.


Manage work python claim.py

Hello! How I can stop python claim.py? After CTRL+C I see that .sh still work in system monitor and auto added folder Selenium to project folder?

Example

My claim.py not work corrent and I want to stop it
Was start claim.py without option debugIsOn and I want to continue work with true value,

Hey Sergey,
It sounds like the script stopped prematurely, and it didn't manage to close the Chrome/Chrome Driver sessions.
If you want to close these sessions manually, you can find the active processes with:
```bash
pgrep chrome
pgrep chromedriver
```
To shut down all the active processes immediately and start fresh, you can use:
```bash
pgrep chrome | xargs kill
pgrep chromedriver | xargs kill
```
Alternatively, if it's convenient, you might consider saving any open work and rebooting your system. This will also terminate these processes.

Also, please let me know if you still have issues with the script.

I think fount solution. Firrst step need to delete session from PM2. pm2 delete .... Next to kill process chromedriver

Also work CTRL + Z

Hey Sergey,
It seems things didn't quite work out as I had hoped! I tested the code several times yesterday before rolling it out, and it worked perfectly each time.
I've just pushed today's changes up as version 1.4.2, which I hope will resolve your issues. Again, I tested it in various scenarios (QR code/OTP, with and without 2FA), and all are working as expected for me.
Please let me know how you get on.


Inserted a note to add references

Added assemblies Microsoft.Extensions.Logging and Microsoft.Extensions.Configuration as Visual Studio auto-suggestion is also not recognising them.
Fixes #13106

@theswanand  thanks!


CEF Troubleshooter script not getting SELinux status.

[Enter feedback here]
The troubleshooter script(https://github.com/Azure/Azure-Sentinel/blob/master/DataConnectors/CEF/cef_troubleshoot.py) provided in this doc is running check for SELinux. but from the last two times with different customers, it is not detecting the right SELinux status and its giving wrong impression to customer. wasting their lot of time to fix CEF connector.
Can we have that script fixed?

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: e06c3338-b68b-be74-c8fa-8a3afa5c3428
Version Independent ID: ec19a987-4616-8d19-b0df-34bceecacff3
Content: Troubleshoot a connection between Microsoft Sentinel and a CEF or Syslog data connector
Content Source: articles/sentinel/troubleshooting-cef-syslog.md
Service: microsoft-sentinel
GitHub Login: @limwainstein
Microsoft Alias: lwainstein

@ankkp
Thanks for your feedback! We will investigate and update as appropriate.

@ankkp
I'm going to assign this to the document author so they can take a look at it accordingly
@limwainstein
Could you Please review this and update as appropriate.

Hi @kochavis can the team help look at this issue?

The team was unable to replicate this issue. Closing for now, following engineering's sync with @ankkp. Ankit, please let the engineering team know if this happens again.

#please-close


sql: add maker for sqlfluff

I'm hoping to add a maker for an alternate sql linter named sqlfluff.
I'm new to vim's errorformat and got a partially working &efm for sqlfluff's default output format.
@blueyed seems really responsive and helpful in PRs, so I am hoping to get some feedback and get this PR working and tested!
Questions:

sqlfluff takes a --dialect argument.  Is there an example maker I could reference for providing a config option for this?
sqlfluff has three output format options: human, json, & yaml,  my &efm is attempting to match the human output format as I wanted to avoid multi-line errorformats, and json doesn't have line breaks.  But after getting message-continuations working, I suspect yaml would be easier than the human format.  Suggestions?  I can provide example output.
sqlfluff has error codes of PRS and L003  the efm of %t%n breaks when the error code is PRS. How should I handle this case?

Here is an example snippet of the human format output:
== [models/redacted/foobie_bletch.sql] FAIL
L:   6 | P: 101 | L016 | Line is too long.
L:   8 | P: 112 | L016 | Line is too long.
L:  10 | P:   3 | L003 | Indentation not hanging or a multiple of 4 spaces
L:  11 | P:   3 | L003 | Indentation not hanging or a multiple of 4 spaces
L:  12 | P:   3 | L003 | Indentation not hanging or a multiple of 4 spaces
L:  13 | P:   3 | L003 | Indentation not hanging or a multiple of 4 spaces
L:  14 | P:   3 | L003 | Indentation not hanging or a multiple of 4 spaces
L:  15 | P:   3 | L003 | Indentation not hanging or a multiple of 4 spaces
L:  16 | P:   3 | L003 | Indentation not hanging or a multiple of 4 spaces
L:  17 | P:  47 | L011 | Implicit aliasing of table not allowed. Use explicit
                       | `AS` clause.
L:  18 | P:  63 | L011 | Implicit aliasing of table not allowed. Use explicit
                       | `AS` clause.
L:  19 | P:   3 | L003 | Indentation not hanging or a multiple of 4 spaces
L:  19 | P:  45 |  PRS | Found unparsable section: '\n-- need this because there
                       | can be multi...'

I took a pass at parsing the YAML output format and am having similar issues:
let &efm='-\ filepath:\ %f,%E\ \ - code: %t%n,%C\ %#line_no:\ %l,%C\ %#%l,%C\ %#line_pos:\ %c,%C\ %#description:\ %m,%C\ \ \ \ \ \ %m'
On input of:
- filepath: models/foobie/applications_a.sql
  violations:
  - code: PRS
    line_no: 19
    line_pos: 45
    description: 'Found unparsable section: ''\n-- need this because there can be
      multi...'''
  - code: L003
    line_no: 10
    line_pos: 3
    description: Indentation not hanging or a multiple of 4 spaces
  - code: L003
    line_no: 11
    line_pos: 3
    description: Indentation not hanging or a multiple of 4 spaces
  - code: L003
    line_no: 12
    line_pos: 3
    description: Indentation not hanging or a multiple of 4 spaces
  - code: L003
    line_no: 13
    line_pos: 3
    description: Indentation not hanging or a multiple of 4 spaces
  - code: L003
    line_no: 14
    line_pos: 3
    description: Indentation not hanging or a multiple of 4 spaces
  - code: L003
    line_no: 15
    line_pos: 3
    description: Indentation not hanging or a multiple of 4 spaces
  - code: L003
    line_no: 16
    line_pos: 3
    description: Indentation not hanging or a multiple of 4 spaces
  - code: L003
    line_no: 19
    line_pos: 3
    description: Indentation not hanging or a multiple of 4 spaces
  - code: L011
    line_no: 17
    line_pos: 47
    description: Implicit aliasing of table not allowed. Use explicit `AS` clause.
  - code: L011
    line_no: 18
    line_pos: 63
    description: Implicit aliasing of table not allowed. Use explicit `AS` clause.
  - code: L016
    line_no: 6
    line_pos: 101
    description: Line is too long.
  - code: L016
    line_no: 8
    line_pos: 112
    description: Line is too long.

for anyone interested: I made a wrapper on sqlfluff that can be used with neomake. it prints one error per line
https://codeberg.org/FelipeLema/sqlfluff-oneliner


[BACKLOG-20601] - Kafka: Create New Sub-transformation Flow

Goes with https://github.com/pentaho/big-data-plugin/pull/1207

@kurtwalker @DFieldFL
Please review.

Build Completed
:fire: This pull request has some issues. It would be preferable to fix them in order for it to be just perfect. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
mvn -Dsurefire.runOrder=alphabetical -B -fn -f 'pom.xml' -pl 'ui,core' -P '!assemblies' -amd clean install && mvn -B -f 'pom.xml' -pl 'ui,core' -P '!assemblies' -amd site

Cleanup Commands
mvn -B -f 'pom.xml' -pl 'ui,core' -P '!assemblies' -amd build-helper:remove-project-artifact

Changed files
  core/src/main/java/org/pentaho/di/core/Props.java
  ui/src/main/java/org/pentaho/di/ui/spoon/dialog/NewSubtransDialog.java
  ui/src/main/java/org/pentaho/di/ui/trans/step/BaseStreamingDialog.java
  ui/src/main/resources/org/pentaho/di/ui/core/default.properties
  ui/src/main/resources/org/pentaho/di/ui/spoon/dialog/messages/messages_en_US.properties
  ui/src/main/resources/org/pentaho/di/ui/trans/step/messages/messages_en_US.properties

Unit Test Coverage
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.

:warning: Coverage Changes: <0.1% (click to expand)
org.pentaho.di.core.injection.bean.BeanInjector

Branch Change: -0.8% :small_red_triangle_down:
Complexity Change: -1.3% :small_red_triangle_down:

org.pentaho.di.job.entries.getpop.MailConnectionMeta

Branch Change: -1% :small_red_triangle_down:
Complexity Change: -1.5% :small_red_triangle_down:
Instruction Change: -0.3% :small_red_triangle_down:

org.pentaho.di.trans.steps.calculator.CalculatorMetaFunction

Branch Change: -8.7% :small_red_triangle_down:
Complexity Change: -3% :small_red_triangle_down:
Instruction Change: -0.7% :small_red_triangle_down:
Line Change: -0.9% :small_red_triangle_down:

org.pentaho.di.trans.steps.checksum.CheckSumMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.dimensionlookup.DimensionLookupMeta

Branch Change: -1.2% :small_red_triangle_down:
Complexity Change: -0.7% :small_red_triangle_down:
Instruction Change: -0.3% :small_red_triangle_down:

org.pentaho.di.trans.steps.groupby.GroupByMeta

Branch Change: -3% :small_red_triangle_down:
Complexity Change: -3.2% :small_red_triangle_down:
Instruction Change: -0.2% :small_red_triangle_down:
Line Change: -0.7% :small_red_triangle_down:

org.pentaho.di.trans.steps.replacestring.ReplaceStringMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.systemdata.SystemDataMeta

Branch Change: -2% :small_red_triangle_down:
Complexity Change: -2% :small_red_triangle_down:
Instruction Change: -0.3% :small_red_triangle_down:
Line Change: -0.8% :small_red_triangle_down:

org.pentaho.di.trans.steps.tableoutput.TableOutputMeta

Branch Change: -0.9% :small_red_triangle_down:
Complexity Change: -0.8% :small_red_triangle_down:

org.pentaho.di.trans.steps.textfileinput.TextFileInputMeta

Branch Change: -0.5% :small_red_triangle_down:

org.pentaho.di.trans.steps.uniquerows.UniqueRowsMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.www.TransformationMap

Branch Change: -3.4% :small_red_triangle_down:
Complexity Change: -1.5% :small_red_triangle_down:
Instruction Change: -5.5% :small_red_triangle_down:
Line Change: -4.6% :small_red_triangle_down:

org.pentaho.di.trans.steps.gpload.GPLoadMeta

Branch Change: -0.9% :small_red_triangle_down:
Complexity Change: -0.8% :small_red_triangle_down:
Instruction Change: -0.2% :small_red_triangle_down:

org.pentaho.di.trans.steps.salesforceupdate.SalesforceUpdateMeta

Instruction Change: -0.2% :small_red_triangle_down:

:new: org.pentaho.di.ui.spoon.dialog.NewSubtransDialog

Coverage: 0% :exclamation:

Note: The list of offending coverage changes extends beyond the presented results and was truncated to prevent reaching the comment size limit.