Skip to content

Commit

Permalink
Merge pull request #1283 from eed3si9n/bport/1.x-changes
Browse files Browse the repository at this point in the history
[1.x] Backport 1.x contributions
  • Loading branch information
eed3si9n authored Feb 3, 2025
2 parents 2773885 + d5d3c3f commit 7b7c4ed
Show file tree
Hide file tree
Showing 3 changed files with 10 additions and 8 deletions.
2 changes: 1 addition & 1 deletion src/reference/00-Getting-Started/05-Basic-Def.md
Original file line number Diff line number Diff line change
Expand Up @@ -61,7 +61,7 @@ The key-value pairs are listed under the `.settings(...)` method as follows:
### How build.sbt defines settings

`build.sbt` defines subprojects, which holds a sequence of key-value pairs
called *setting expressions* using *build.sbt domain-specific language(DSL)*.
called *setting expressions* using *build.sbt domain-specific language (DSL)*.

```scala
ThisBuild / organization := "com.example"
Expand Down
2 changes: 1 addition & 1 deletion src/reference/00-Getting-Started/06-Task-Graph.md
Original file line number Diff line number Diff line change
Expand Up @@ -335,7 +335,7 @@ Compile / scalaSource := {

### What's the point of the build.sbt DSL?

We use the `build.sbt` domain-specific language(DSL) to construct a DAG of settings and tasks.
We use the `build.sbt` domain-specific language (DSL) to construct a DAG of settings and tasks.
The setting expressions encode settings, tasks and the dependencies among them.

This structure is common to [Make][Make] (1976), [Ant][Ant] (2000), and [Rake][Rake] (2003).
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -353,7 +353,7 @@ object Obfuscate {

#### Usage example

A build definition that uses the plugin might look like. `obfuscate.sbt`:
A build definition that uses the plugin might look like `obfuscate.sbt`:

```scala
obfuscate / obfuscateLiterals := true
Expand Down Expand Up @@ -515,17 +515,19 @@ Plugins can be published like any other projects. When publishing your plugin to
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


1. 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
1. 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).
Expand Down

0 comments on commit 7b7c4ed

Please sign in to comment.