Team management & cross-repository effort tracking
License: Apache License 2.0
This repository is for team management and to track cross-repository efforts in the Play ecosystem.
https://github.com/fthomas/scala-steward
For now, only covering 2.7.x for Play and 1.5.x for Lagom. This does not cover Gradle and Maven files.
As we no longer use Waffle let's remove it. (Internal conversation: https://typesafe.slack.com/archives/CFPVDLR41/p1556100851156800)
commons-lang3:3.4 and guava:19/guava:16.0.1maven-core to bump the transitive commons-lang3:3.4 lagom/lagom#1778guava:16.0.1 though sbt lists that version as evicted. @ignasi35lagom-{scala-java}-openshift-smoketestsHighlights15 @ignasi35 lagom/lagom#1779Using the same configurations we have for Play:
This must be done after releasing 1.5.0.
Note: There are some dependencies outside of our control and we can ping them to see the current status/plan.
Send a PR to mergify. If accepted and once deployed we can start using mergify for backports! <3
I noticed it's not on the checklist. Maybe it's missing in other places.
master (backported to 1.5.x) lagom/lagom#1883 @renatocavaljavafmt) Lagom
scalafmt bash script instead of sbt-scalafmt) lagom/lagom#1900I think we should introduce a "nominated" label to nominate issues to be discussed at the team meetings.
pros:
cons:
WDYT?
Easter Friday 19 & Monday 22.
javadoc) playframework/playframework#9112This is a list of Play repos that still need to be Mergified:
Mergify backports are back in Play and Lagom repos, but I realised now that it's not auto-merging when the build is green.
We need a new rule in which we don't require approval if the contributor is the mergify bot and it's on one of the stable branches.
Was trying out cargo run on repo-list-check. Got a reproducible failure:
$ cargo run
Compiling pest v2.1.0
Compiling crossbeam-channel v0.3.8
Compiling unicode-normalization v0.1.8
Compiling tokio-current-thread v0.1.4
error[E0658]: scoped lint `clippy::needless_pass_by_value` is experimental (see issue #44690)
--> /Users/ignasi/.cargo/registry/src/github.com-1ecc6299db9ec823/pest-2.1.0/src/error.rs:97:13
|
97 | #[allow(clippy::needless_pass_by_value)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
error[E0658]: scoped lint `clippy::needless_pass_by_value` is experimental (see issue #44690)
--> /Users/ignasi/.cargo/registry/src/github.com-1ecc6299db9ec823/pest-2.1.0/src/error.rs:137:13
|
137 | #[allow(clippy::needless_pass_by_value)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
error[E0658]: scoped lint `clippy::new_ret_no_self` is experimental (see issue #44690)
--> /Users/ignasi/.cargo/registry/src/github.com-1ecc6299db9ec823/pest-2.1.0/src/parser_state.rs:114:13
|
114 | #[allow(clippy::new_ret_no_self)]
| ^^^^^^^^^^^^^^^^^^^^^^^
error[E0658]: scoped lint `clippy::new_ret_no_self` is experimental (see issue #44690)
--> /Users/ignasi/.cargo/registry/src/github.com-1ecc6299db9ec823/pest-2.1.0/src/position.rs:52:13
|
52 | #[allow(clippy::new_ret_no_self)]
| ^^^^^^^^^^^^^^^^^^^^^^^
error[E0658]: scoped lint `clippy::new_ret_no_self` is experimental (see issue #44690)
--> /Users/ignasi/.cargo/registry/src/github.com-1ecc6299db9ec823/pest-2.1.0/src/span.rs:56:13
|
56 | #[allow(clippy::new_ret_no_self)]
| ^^^^^^^^^^^^^^^^^^^^^^^
error[E0658]: scoped lint `clippy::all` is experimental (see issue #44690)
--> /Users/ignasi/.cargo/registry/src/github.com-1ecc6299db9ec823/pest-2.1.0/src/unicode/mod.rs:6:10
|
6 | #![allow(clippy::all)]
| ^^^^^^^^^^^
Compiling tokio-timer v0.2.10
Compiling base64 v0.10.1
error: aborting due to 6 previous errors
For more information about this error, try `rustc --explain E0658`.
error: Could not compile `pest`.
warning: build failed, waiting for other jobs to finish...
error: build failed
ignasi at imslightbend in ~/git/projects/lightbend/playframework/play-meta/repos-list-check on master*
Current approach to enable and setup SSL for Dev Mode in Play and Lagom is differs. The main cause is Lagom's multi-project nature. Other differences are the use of a self-signed cert or a self-signed CA with custom certs, the existence of a service gateway, ...
For example: Currently Play uses -Dhttps.port=<valid number> to enable SSL in dev mode. That doesn't work on Lagom. A valid approach to Play later (and that can then be inherited by Lagom) is to have something like -Dhttps.enabled=true.
Credit: @marcospereira :-)
Similar to how Lagom starts/stops Cassandra and Kafka, it could be useful to register the startup/cleanup/destroy/etc... of external services to be managed by sbt or other build tools.
See https://www.playframework.com/documentation/2.6.x/SBTCookbook#Hooking-into-Plays-dev-mode
See https://github.com/lagom/lagom/pull/763/files (https://www.lagomframework.com/documentation/1.4.x/java/DevEnvironment.html#Managing-custom-services)
See https://discuss.lightbend.com/t/devhook-equivalent-for-sbt-test/586
We have discussed a few options for Mergify rules and here is what I remember so far. Feel free to add/modify it.
The ability to run multiple services in dev mode and having infrastructure services should exist in Play. There would probably be a different process for sbt and for Maven, since Play's support for Maven is third-party. It would also be nice to add these features to the Play Gradle plugin since customers have asked about Lagom support for Gradle.
This effectively makes the difference between "Play" and "Lagom" one of which modules are used.
I've been discussing with @mkurz about when to backport things.
See playframework/playframework#9192
We have previously said that we backport to latest stable (2.7.x) any bug fix that can be cleanly cherry-picked and that doesn't introduce binary compatible changes.
We have also said that we will only backport lib updates when there is a known security fix. Users can still update downstream libraries whenever they desire.
Alternatively, we could say, each lib update is backported if done automatically. If not, we just discard the backport PR.
I'm opening this issue so we can discuss it with all contributors and come to a consensus.
Lagom currently has sbt and Maven support. Play officially supports sbt, and there are third-party Maven and Gradle plugins that seem to work pretty well. Ideally I'd like to use the same thing for both Play and Lagom. It might make sense to start supporting the existing third-party plugins for Play, because they seem relatively complete.
It would be good to have a script that runs some logic ensuring that repos.md is complete, with filters and such.
lagom-samples repo consolidation (+TemplateControl/ExampleCodeService)Better to do this in advance:
Not applicable
Update the supported modules page - not applicable, minor bug fix relese on maintenance branch
Update Example Code Service - not applicable,
Split out of #32
lagom/lagom-java.g8And the whole set of examples:
akka-grpc)Play has:
And Lagom has:
Play should provide a base ObjectMapper and a way to register modules so that Lagom can use it instead of having its own configuration.
Here is a short TODO list of things I believe should be done in order to support Akka discovery for Lagom and Play.
Relates to #14
https://github.com/lagom/shopping-cart-scala now existing and as @jroper says:
is no more complex than the hello world sample that we have, except it actually models a real-world domain problem, so it actually makes sense.
Should we replace Lagom's hello world example app with it?
cc @ignasi35
akka-persistence-jdbc. I opted for a general message: lagom/lagom#1767"You had this, you need that, see [page] for more details
Users should handle env-specific plugins themselves.
(From https://github.com/lightbend/play-team/blob/master/docs/2018-10-plan.md)
Strongly recommend users to use sbt 1 now. Explain support will be dropped in an upcoming version.
This conversation was started by Eugene. We need to also migrate our own builds to use sbt 1.
Not a comprehensive list of current issues and pull requests.
When achieved netty-reactive-streams can go from being a supported module to community-driven.
Play/Lagom version of https://github.com/lightbend/platform-reconciliation/issues/30
Can we agree on an approach and migrate to it?
Or maybe just agree and set some guidelines for new APIs.
GH support organization-wide defaults for s few common files:
https://help.github.com/en/articles/creating-a-default-community-health-file-for-your-organization
playframework and lagom organizations could use these defaults.
needs-backport PRs.
Part of the discussion of Merge vs. Squash.
One thing about merge is that GitHub automatically add a title similar to:
"Merge pull request #pr-num from contributor/branch"
When the history gets full of this it becomes hard to understand what was done on the project. You need to navigate to the PR to get the context.
The idea is to change Mergify so it uses the PR title for both merge and squash.
There are a few options here:
Better to do this in advance:
No need to release upstream projects. ☝️
Update playframework templates and seeds
The sections below group tasks per type.
1.4.x and release 1.4.11
Below is the list of issues and pull-requests for Lagom milestone 1.5.0.
Should we copy https://github.com/akka/akka-meta/blob/master/README.md and have a process for persisting design decisions in this repo?
The Akka gRPC docs have a protobuf definition with 4 methods: unary call, client stream, server stream and bi-directional.
The quickstart for Akka has only two methods and the Play and Lagom only one method. We should use the same protobuf definition all over the place, in both Java and Scala.
There are a few advantages for that:
Akka gRPC Hands-on has an extracted (and currently adapted) version of each quickstart.
Better to do this in advance:
As discussed, I'd like my, and any other nicely laid out, multi-commit PR, to be merged and not squash-merged.
To do this I think we just need to duplicate and alter the existing configuration.
Originally posted by @dwijnand in https://github.com/lightbend/play-lagom-team/issues/84#issuecomment-457214509
I detailed the history in lightbend/ssl-config#142
The real solution will take time to review and land, so in Barcelona we agreed we'd just undo my mistake first, and then Marcos will start reviewing Will's changes.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.