copyfighter
rewrite-maven-plugin
| copyfighter | rewrite-maven-plugin | |
|---|---|---|
| 1 | 1 | |
| 198 | 124 | |
| - | 8.9% | |
| 10.0 | 9.7 | |
| about 3 years ago | 4 days ago | |
| Go | Java | |
| - | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
copyfighter
-
Making a Go program 70% faster with a one character change
Not actively using this, so I don't know if this needs an update for new syntax or anything, but https://github.com/jmhodges/copyfighter was written to audit for this sort of problem, in case you have a bunch of code floating around that you'd like to check for it.
rewrite-maven-plugin
-
Making a Go program 70% faster with a one character change
It would definitely be nice to have this generated from a deprecated like annotation!
The maven plug-in seems to use the recipes directly as dependencies: https://github.com/openrewrite/rewrite-maven-plugin
In our internal situation the parent Pom could already control this plug-in definition including versions of the recipes. At the very least the recipes could follow the same version as the artefact.
I thought I saw somewhere where the recipe was bundled with the artefact itself. That is very neat for simple usecase.
However, it suffers from the same flaw as the native-image configuration for GraalVM in artifacts. Sometimes the configuration/recipe needs to change. Eg because of new insights or because it is incompatible with new versions of GraalVM/open rewrite. So I suppose having an extra version dimension Could solve this. Then one can always depend on the latest version of the recipe for that artifact.