WIP

README.md

@@ -1,6 +1,6 @@
 # MDK
 
-To derail you want MDK is, see https://en.wikipedia.org/wiki/MDK
+To derail you learning about MDK, see https://en.wikipedia.org/wiki/MDK
 
 ## What is this about?
 
@@ -20,8 +20,8 @@ The crux MDK tries to implement is following:
 
 This experiment contains 3 modules:
 * `plugin` is 1:1 copy of [maven-deploy-plugin](https://github.com/apache/maven-deploy-plugin) with all of it ITs
-* `api` is a small API artifact that defines SPI for m-deploy-p
-* `kurt` is one SPI implementation
+* `api` (TBD rename to `spi`) is a small artifact that defines SPI for plugin
+* `kurt` is one SPI implementation and Maven extension
 
 The goal is ability to "take over" behaviour of `maven-deploy-plugin` with smallest interference into project itself.
 
@@ -56,23 +56,35 @@ With MDK present, user does following change to `.mvn/extensions.xml`:
 
 And Maven Core activates this extension. Following change happens (see [extension.xml](kurt/src/main/resources/META-INF/maven/extension.xml)).
 * The extension is pulled into Maven Extension (along with dependencies)
-* the `api` artifact becomes "core provided" (see `exportedArtifact`).
+* the `api` artifact becomes "Maven provided" (see `exportedArtifact`).
 
 In essence, when MDK Extension is present in Maven, the plugin execution changes like this:
 
 ```txt
-<m-deploy-p> <--depends-- <api (provided from extension)>
+<m-deploy-p> <--depends-- <api (provided from Maven)>
 ```
 
 This ensures that there is one `api` in system, hence there are no classloading issues. Next, MDK itself defines
 `DeployerSPI` implementation, the `Kurt`, which at this moment "takes over" `maven-deploy-plugin` duties, the plugins
 really becoming "just a messenger".
 
 Kurt integrates into Maven Lifecycle, and provides following deployers:
-* "resolver" -- is almost same as `maven-deploy-plugin` is
+* "resolver" -- is almost same as `maven-deploy-plugin` is (this is the default, ensures that Maven w/ Kurt installed but not configured behaves in same way as without it)
 * "local-staging" -- stages all artifacts locally, into (by default) top level project `target/staging-deploy` directory.
 * "remote-staging" -- stages all artifacts into (explicitly given) remote repository TBD
 * "jreleaser" -- this will combine "local-staging" and JReleaser "full-release" workflow TBD
 
-In short, idea is to be least intrusive and future-proof, while have access to always changing current (and 
-possible future) services for Artifact publishing.
+In short, idea is to be the least intrusive and future-proof, while have access to always changing current (and 
+possible future) services for Artifact publishing.
+
+# JReleaser reuse
+
+Frankly, MDK was inspired by Sonatype Central publishing changes, but also by the fact that JReleaser already
+provided solutions to all problems. Still, JReleases needs some [hoops and loops](https://jreleaser.org/guide/latest/examples/maven/index.html)
+to make it work, and these all require non-trivial changes to POMs. The idea is that MDK could handle all this: 
+it can "stage locally", and then just invoke JReleases pointing it locally staged repository, and it that "takes over" 
+from that point. 
+
+Another good improvement would be to use JReleaser "-sdk" solutions for use cases like:
+* Enhance "remote-staging" to create a new staging repository, or point build at existing (already created) staging repository,
+  basically making possible staging together artifacts coming from different builds (like different OSes)