updated site

1.x/docs/Combined+Pages+Pdf.md

@@ -19721,6 +19721,28 @@ libraryDependencies ++=
         Seq.empty
 ```
 
+### Publishing a plugin
+
+Plugins can be published like any other projects. When publishing your plugin to a Maven-layout repository, use sbt 1.9.x or above.
+
+However, there is one caveat if you attempt to publish your plugin to a repository that follows the Maven layout.
+
+If your artifacts repository expect artifacts to be compliant with Maven layout and rejects artifacts that do not adhere to it you can:
+1. (recommended) If you and consumers of your plugin use sbt 1.9.x or above
+
+   Since sbt 1.9, it tries to publish any plugin with both the new and legacy Maven style (for backward compatibility). The legacy Maven style is not fully compatible with Maven layout.
+   You need to disable it with:
+   `sbtPluginPublishLegacyMavenStyle := false`
+   Notice that you won't be able to consume this plugin with sbt older than 1.9, as it can only resolve the legacy Maven style (or you need to use the trick described in [sbt-vspp](https://github.com/esbeetee/sbt-vspp)).
+3. If you use sbt < 1.9.x
+
+   You can use https://github.com/esbeetee/sbt-vspp/
+5. If you cannot use sbt 1.9.x and you cannot/don't want to use sbt-vspp
+
+   There should be an option like `Suppress POM Consistency Checks` in your artifactory settings that will allow you to submit artifacts even if they don't fully follow Maven layout.
+
+You can find more details about this in the [following issue](https://github.com/sbt/sbt/issues/3410).
+
 ### Best Practices
 
 If you're a plugin writer, please consult the [Plugins Best Practices][Plugins-Best-Practices]

1.x/docs/Combined+Pages.html

@@ -12185,7 +12185,20 @@ <h4 class="toctitle">Contents</h4>
         Seq(&quot;org.example&quot; % &quot;windows-only&quot; % &quot;1.0&quot;)
     else
         Seq.empty
-</code></pre><h3 id="Best+Practices">Best Practices<a href="#Best+Practices" class="header-link"><span class="header-link-content">&nbsp;</span></a></h3><p>If you’re a plugin writer, please consult the <a href="Plugins-Best-Practices.html">Plugins Best Practices</a>
+</code></pre><h3 id="Publishing+a+plugin">Publishing a plugin<a href="#Publishing+a+plugin" class="header-link"><span class="header-link-content">&nbsp;</span></a></h3><p>Plugins can be published like any other projects. When publishing your plugin to a Maven-layout repository, use sbt 1.9.x or above.
+</p><p>However, there is one caveat if you attempt to publish your plugin to a repository that follows the Maven layout.
+</p><p>If your artifacts repository expect artifacts to be compliant with Maven layout and rejects artifacts that do not adhere to it you can:
+1. (recommended) If you and consumers of your plugin use sbt 1.9.x or above
+</p><p>   Since sbt 1.9, it tries to publish any plugin with both the new and legacy Maven style (for backward compatibility). The legacy Maven style is not fully compatible with Maven layout.
+   You need to disable it with:
+   <code>sbtPluginPublishLegacyMavenStyle := false</code>
+   Notice that you won’t be able to consume this plugin with sbt older than 1.9, as it can only resolve the legacy Maven style (or you need to use the trick described in <a href="https://github.com/esbeetee/sbt-vspp">sbt-vspp</a>).
+3. If you use sbt &lt; 1.9.x
+</p><p>   You can use https://github.com/esbeetee/sbt-vspp/
+5. If you cannot use sbt 1.9.x and you cannot/don’t want to use sbt-vspp
+</p><p>   There should be an option like <code>Suppress POM Consistency Checks</code> in your artifactory settings that will allow you to submit artifacts even if they don’t fully follow Maven layout.
+</p><p>You can find more details about this in the <a href="https://github.com/sbt/sbt/issues/3410">following issue</a>.
+</p><h3 id="Best+Practices">Best Practices<a href="#Best+Practices" class="header-link"><span class="header-link-content">&nbsp;</span></a></h3><p>If you’re a plugin writer, please consult the <a href="Plugins-Best-Practices.html">Plugins Best Practices</a>
 page; it contains a set of guidelines to help you ensure that your
 plugin is consistent and plays well with other plugins.
 </p><p>For cross building sbt plugins see also <a href="Cross-Build-Plugins.html">Cross building plugins</a>.

1.x/docs/Combined+Pages.md

@@ -19716,6 +19716,28 @@ libraryDependencies ++=
         Seq.empty
 ```
 
+### Publishing a plugin
+
+Plugins can be published like any other projects. When publishing your plugin to a Maven-layout repository, use sbt 1.9.x or above.
+
+However, there is one caveat if you attempt to publish your plugin to a repository that follows the Maven layout.
+
+If your artifacts repository expect artifacts to be compliant with Maven layout and rejects artifacts that do not adhere to it you can:
+1. (recommended) If you and consumers of your plugin use sbt 1.9.x or above
+
+   Since sbt 1.9, it tries to publish any plugin with both the new and legacy Maven style (for backward compatibility). The legacy Maven style is not fully compatible with Maven layout.
+   You need to disable it with:
+   `sbtPluginPublishLegacyMavenStyle := false`
+   Notice that you won't be able to consume this plugin with sbt older than 1.9, as it can only resolve the legacy Maven style (or you need to use the trick described in [sbt-vspp](https://github.com/esbeetee/sbt-vspp)).
+3. If you use sbt < 1.9.x
+
+   You can use https://github.com/esbeetee/sbt-vspp/
+5. If you cannot use sbt 1.9.x and you cannot/don't want to use sbt-vspp
+
+   There should be an option like `Suppress POM Consistency Checks` in your artifactory settings that will allow you to submit artifacts even if they don't fully follow Maven layout.
+
+You can find more details about this in the [following issue](https://github.com/sbt/sbt/issues/3410).
+
 ### Best Practices
 
 If you're a plugin writer, please consult the [Plugins Best Practices][Plugins-Best-Practices]

1.x/docs/Contents+in+Depth.html

@@ -221,7 +221,7 @@ <h4 class="toctitle">Contents</h4>
               <ul class="outline"> <li> <a href="Plugins.html#projectSettings+and+buildSettings">projectSettings and buildSettings </a> </li><li> <a href="Plugins.html#Implementing+plugin+dependencies">Implementing plugin dependencies </a> </li><li> <a href="Plugins.html#Root+plugins+and+triggered+plugins">Root plugins and triggered plugins </a> </li><li> <a href="Plugins.html#Controlling+the+import+with+autoImport">Controlling the import with autoImport </a> </li><li> <a href="Plugins.html#Example+Plugin">Example Plugin </a> </li><li> <a href="Plugins.html#Usage+example">Usage example </a> </li><li> <a href="Plugins.html#Global+plugins+example">Global plugins example </a> </li> </ul>
             </li><li> <a href="Plugins.html#Using+a+library+in+a+build+definition+example">Using a library in a build definition example </a>
               <ul class="outline"> <li> <a href="Plugins.html#1a%29+Manually+managed">1a) Manually managed </a> </li><li> <a href="Plugins.html#1b%29+Automatically+managed%3A+direct+editing+approach">1b) Automatically managed: direct editing approach </a> </li><li> <a href="Plugins.html#1c%29+Automatically+managed%3A+command-line+approach">1c) Automatically managed: command-line approach </a> </li><li> <a href="Plugins.html#1d%29+Project+dependency">1d) Project dependency </a> </li><li> <a href="Plugins.html#2%29+Use+the+library">2) Use the library </a> </li> </ul>
-            </li><li> <a href="Plugins.html#Best+Practices">Best Practices </a> </li></ul></li><li><div><a href="Plugins-Best-Practices.html">Plugins Best Practices</a></div><ul class="outline"><li> <a href="Plugins-Best-Practices.html#Key+naming+convention%3A+Use+prefix">Key naming convention: Use prefix </a> </li><li> <a href="Plugins-Best-Practices.html#Artifact+naming+convention">Artifact naming convention </a> </li><li> <a href="Plugins-Best-Practices.html#%28optional%29+Plugin+naming+convention">(optional) Plugin naming convention </a> </li><li> <a href="Plugins-Best-Practices.html#Don++t+use+default+package">Don  t use default package </a> </li><li> <a href="Plugins-Best-Practices.html#Get+your+plugins+known">Get your plugins known </a> </li><li> <a href="Plugins-Best-Practices.html#Reuse+existing+keys">Reuse existing keys </a> </li><li> <a href="Plugins-Best-Practices.html#Use+settings+and+tasks.+Avoid+commands.">Use settings and tasks. Avoid commands. </a> </li><li> <a href="Plugins-Best-Practices.html#Provide+core+feature+in+a+plain+old+Scala+object">Provide core feature in a plain old Scala object </a> </li><li> <a href="Plugins-Best-Practices.html#Configuration+advice">Configuration advice </a>
+            </li><li> <a href="Plugins.html#Publishing+a+plugin">Publishing a plugin </a> </li><li> <a href="Plugins.html#Best+Practices">Best Practices </a> </li></ul></li><li><div><a href="Plugins-Best-Practices.html">Plugins Best Practices</a></div><ul class="outline"><li> <a href="Plugins-Best-Practices.html#Key+naming+convention%3A+Use+prefix">Key naming convention: Use prefix </a> </li><li> <a href="Plugins-Best-Practices.html#Artifact+naming+convention">Artifact naming convention </a> </li><li> <a href="Plugins-Best-Practices.html#%28optional%29+Plugin+naming+convention">(optional) Plugin naming convention </a> </li><li> <a href="Plugins-Best-Practices.html#Don++t+use+default+package">Don  t use default package </a> </li><li> <a href="Plugins-Best-Practices.html#Get+your+plugins+known">Get your plugins known </a> </li><li> <a href="Plugins-Best-Practices.html#Reuse+existing+keys">Reuse existing keys </a> </li><li> <a href="Plugins-Best-Practices.html#Use+settings+and+tasks.+Avoid+commands.">Use settings and tasks. Avoid commands. </a> </li><li> <a href="Plugins-Best-Practices.html#Provide+core+feature+in+a+plain+old+Scala+object">Provide core feature in a plain old Scala object </a> </li><li> <a href="Plugins-Best-Practices.html#Configuration+advice">Configuration advice </a>
               <ul class="outline"> <li> <a href="Plugins-Best-Practices.html#You+probably+won++t+need+your+own+configuration">You probably won  t need your own configuration </a> </li><li> <a href="Plugins-Best-Practices.html#When+to+define+your+own+configuration">When to define your own configuration </a> </li><li> <a href="Plugins-Best-Practices.html#Playing+nice+with+configurations">Playing nice with configurations </a> </li><li> <a href="Plugins-Best-Practices.html#Provide+raw+settings+and+configured+settings">Provide raw settings and configured settings </a> </li> </ul>
             </li><li> <a href="Plugins-Best-Practices.html#Scoping+advice">Scoping advice </a>
               <ul class="outline"> <li> <a href="Plugins-Best-Practices.html#Provide+default+values+in++globalSettings">Provide default values in  globalSettings </a> </li><li> <a href="Plugins-Best-Practices.html#Using+a+++main+++task+scope+for+settings">Using a   main   task scope for settings </a> </li><li> <a href="Plugins-Best-Practices.html#Rewiring+existing+keys+in++globalSettings">Rewiring existing keys in  globalSettings </a> </li> </ul>

1.x/docs/Plugins.html

@@ -404,7 +404,20 @@ <h2 id="Plugins">Plugins<a href="#Plugins" class="header-link"><span class="head
         Seq(&quot;org.example&quot; % &quot;windows-only&quot; % &quot;1.0&quot;)
     else
         Seq.empty
-</code></pre><h3 id="Best+Practices">Best Practices<a href="#Best+Practices" class="header-link"><span class="header-link-content">&nbsp;</span></a></h3><p>If you’re a plugin writer, please consult the <a href="Plugins-Best-Practices.html">Plugins Best Practices</a>
+</code></pre><h3 id="Publishing+a+plugin">Publishing a plugin<a href="#Publishing+a+plugin" class="header-link"><span class="header-link-content">&nbsp;</span></a></h3><p>Plugins can be published like any other projects. When publishing your plugin to a Maven-layout repository, use sbt 1.9.x or above.
+</p><p>However, there is one caveat if you attempt to publish your plugin to a repository that follows the Maven layout.
+</p><p>If your artifacts repository expect artifacts to be compliant with Maven layout and rejects artifacts that do not adhere to it you can:
+1. (recommended) If you and consumers of your plugin use sbt 1.9.x or above
+</p><p>   Since sbt 1.9, it tries to publish any plugin with both the new and legacy Maven style (for backward compatibility). The legacy Maven style is not fully compatible with Maven layout.
+   You need to disable it with:
+   <code>sbtPluginPublishLegacyMavenStyle := false</code>
+   Notice that you won’t be able to consume this plugin with sbt older than 1.9, as it can only resolve the legacy Maven style (or you need to use the trick described in <a href="https://github.com/esbeetee/sbt-vspp">sbt-vspp</a>).
+3. If you use sbt &lt; 1.9.x
+</p><p>   You can use https://github.com/esbeetee/sbt-vspp/
+5. If you cannot use sbt 1.9.x and you cannot/don’t want to use sbt-vspp
+</p><p>   There should be an option like <code>Suppress POM Consistency Checks</code> in your artifactory settings that will allow you to submit artifacts even if they don’t fully follow Maven layout.
+</p><p>You can find more details about this in the <a href="https://github.com/sbt/sbt/issues/3410">following issue</a>.
+</p><h3 id="Best+Practices">Best Practices<a href="#Best+Practices" class="header-link"><span class="header-link-content">&nbsp;</span></a></h3><p>If you’re a plugin writer, please consult the <a href="Plugins-Best-Practices.html">Plugins Best Practices</a>
 page; it contains a set of guidelines to help you ensure that your
 plugin is consistent and plays well with other plugins.
 </p><p>For cross building sbt plugins see also <a href="Cross-Build-Plugins.html">Cross building plugins</a>.

1.x/docs/es/offline/pamflet.manifest

@@ -1,5 +1,5 @@
 CACHE MANIFEST
-# Wed Jan 31 13:25:57 UTC 2024
+# Sat Feb 17 13:23:48 UTC 2024
 index.html
 Getting-Started.html
 Setup.html

1.x/docs/ja/offline/pamflet.manifest

@@ -1,5 +1,5 @@
 CACHE MANIFEST
-# Wed Jan 31 13:25:51 UTC 2024
+# Sat Feb 17 13:23:38 UTC 2024
 index.html
 Getting-Started.html
 Setup.html

1.x/docs/offline/Combined+Pages.html

@@ -12185,7 +12185,20 @@ <h4 class="toctitle">Contents</h4>
         Seq(&quot;org.example&quot; % &quot;windows-only&quot; % &quot;1.0&quot;)
     else
         Seq.empty
-</code></pre><h3 id="Best+Practices">Best Practices<a href="#Best+Practices" class="header-link"><span class="header-link-content">&nbsp;</span></a></h3><p>If you’re a plugin writer, please consult the <a href="Plugins-Best-Practices.html">Plugins Best Practices</a>
+</code></pre><h3 id="Publishing+a+plugin">Publishing a plugin<a href="#Publishing+a+plugin" class="header-link"><span class="header-link-content">&nbsp;</span></a></h3><p>Plugins can be published like any other projects. When publishing your plugin to a Maven-layout repository, use sbt 1.9.x or above.
+</p><p>However, there is one caveat if you attempt to publish your plugin to a repository that follows the Maven layout.
+</p><p>If your artifacts repository expect artifacts to be compliant with Maven layout and rejects artifacts that do not adhere to it you can:
+1. (recommended) If you and consumers of your plugin use sbt 1.9.x or above
+</p><p>   Since sbt 1.9, it tries to publish any plugin with both the new and legacy Maven style (for backward compatibility). The legacy Maven style is not fully compatible with Maven layout.
+   You need to disable it with:
+   <code>sbtPluginPublishLegacyMavenStyle := false</code>
+   Notice that you won’t be able to consume this plugin with sbt older than 1.9, as it can only resolve the legacy Maven style (or you need to use the trick described in <a href="https://github.com/esbeetee/sbt-vspp">sbt-vspp</a>).
+3. If you use sbt &lt; 1.9.x
+</p><p>   You can use https://github.com/esbeetee/sbt-vspp/
+5. If you cannot use sbt 1.9.x and you cannot/don’t want to use sbt-vspp
+</p><p>   There should be an option like <code>Suppress POM Consistency Checks</code> in your artifactory settings that will allow you to submit artifacts even if they don’t fully follow Maven layout.
+</p><p>You can find more details about this in the <a href="https://github.com/sbt/sbt/issues/3410">following issue</a>.
+</p><h3 id="Best+Practices">Best Practices<a href="#Best+Practices" class="header-link"><span class="header-link-content">&nbsp;</span></a></h3><p>If you’re a plugin writer, please consult the <a href="Plugins-Best-Practices.html">Plugins Best Practices</a>
 page; it contains a set of guidelines to help you ensure that your
 plugin is consistent and plays well with other plugins.
 </p><p>For cross building sbt plugins see also <a href="Cross-Build-Plugins.html">Cross building plugins</a>.

1.x/docs/offline/Combined+Pages.md

@@ -19716,6 +19716,28 @@ libraryDependencies ++=
         Seq.empty
 ```
 
+### Publishing a plugin
+
+Plugins can be published like any other projects. When publishing your plugin to a Maven-layout repository, use sbt 1.9.x or above.
+
+However, there is one caveat if you attempt to publish your plugin to a repository that follows the Maven layout.
+
+If your artifacts repository expect artifacts to be compliant with Maven layout and rejects artifacts that do not adhere to it you can:
+1. (recommended) If you and consumers of your plugin use sbt 1.9.x or above
+
+   Since sbt 1.9, it tries to publish any plugin with both the new and legacy Maven style (for backward compatibility). The legacy Maven style is not fully compatible with Maven layout.
+   You need to disable it with:
+   `sbtPluginPublishLegacyMavenStyle := false`
+   Notice that you won't be able to consume this plugin with sbt older than 1.9, as it can only resolve the legacy Maven style (or you need to use the trick described in [sbt-vspp](https://github.com/esbeetee/sbt-vspp)).
+3. If you use sbt < 1.9.x
+
+   You can use https://github.com/esbeetee/sbt-vspp/
+5. If you cannot use sbt 1.9.x and you cannot/don't want to use sbt-vspp
+
+   There should be an option like `Suppress POM Consistency Checks` in your artifactory settings that will allow you to submit artifacts even if they don't fully follow Maven layout.
+
+You can find more details about this in the [following issue](https://github.com/sbt/sbt/issues/3410).
+
 ### Best Practices
 
 If you're a plugin writer, please consult the [Plugins Best Practices][Plugins-Best-Practices]