Windows CMD interprets parentheses as special syntax for command grouping.
When the project directory path contains parentheses (e.g., in username),
the batch script fails with ') was unexpected at this time.' error.
This fix stores the current directory in a variable using delayed expansion
(!CURRENT_DIR!) instead of using %CD% directly, which properly handles
paths containing parentheses and other special characters.
Fixes#8644
**Problem**
We enforce same-version policy for scala-reflect in Scala 2.13.
However due to sandwich dependency, the graph can bump
scala-library to 3.8.1, which is missing scala-reflect counterpart.
**Solution**
Drop the same-version policy.
Previously, passing JVM options like -Xmx1G directly on the command
line would result in an error:
sbt -v -Xmx1G
[error] Expected ';'
[error] -Xmx1G
[error] ^
This was because -X options were being passed to sbt as commands
instead of being recognized as JVM arguments.
Changes:
- Added handling for -X options in sbt.bat to pass them to the JVM
- Updated help text to document this feature
- Added integration tests for the new functionality
- Change from prepend to append for machine/dist sbtopts
- Change project .sbtopts from prepend to append so it appears last
- Project-level .sbtopts now correctly overrides machine-wide configs
- Add integration tests to verify sbtopts priority order
- Extend testOutput to support dist and machine sbtopts testing
- Copy staging directory to temp location to avoid modifying staging dir
Fixes#7826
Changes:
- Upgrade sbt version from 0.13.18 to 1.10.7 in launcher-package/project/build.properties
- Remove dead dispatch-http 0.8.10 dependency from plugins.sbt
- Update sbt-native-packager from 1.7.6 to 1.10.4 (com.github.sbt)
- Update sbt-pgp from 2.1.2 to 2.3.1
- Replace all dispatch.classic._ HTTP calls with Java URL.openStream()
The dispatch-http library is dead and doesn't support sbt 1.x. This change
uses standard Java networking APIs for HTTP downloads, eliminating the
dependency on outdated libraries.
All HTTP download operations now use:
- java.net.URL.openConnection()
- InputStream with buffered reading
- Proper resource cleanup with try-finally blocks
- Removes the sbt-export-repo plugin dependency
- Defines exportRepo and exportRepoDirectory settings locally
- Removes ExportRepoPlugin from dist project
- Fixes exportRepo task to not reference itself
* fix: Update PackageSignerPlugin.scala for sbt 1.x compatibility
- Use withExtension instead of copy(extension = ...) for Artifact
- Update Classpaths.publishConfig to use sbt 1.x signature with all required parameters
- Use new slash syntax for scoped keys (pgpSigner / skip instead of skip in pgpSigner)
* fix: Use computed status instead of status key in PackageSignerPlugin
* fix: Use withRevision instead of copy for ModuleID in build.sbt
- Add scala.sys.process._ import for shell command execution (! method)
- Fix resolvers setting to use new slash syntax and proper Option handling
- Fix publish/publishLocal to use {} instead of () to avoid deprecation warning
- Fix Classpaths.publishTask to use variant without delivery key (deprecated since 1.1.1)
- Add scala.sys.process._ import for shell command execution
- Fix publish/publishLocal to use {} instead of ()
- Remove problematic resolvers setting that caused task/setting dependency issues
- Use IvyActions.publish directly instead of deprecated Classpaths.publishTask
- Fix ModuleID.copy to use withRevision
- Fix Artifact.copy to use withExtension
- Use computed status value instead of status key
Build now compiles successfully with sbt 1.10.7.
**Problem**
There's a disconnect between what is perceived to be the current
Scala version, and what sbt uses internally, and thus what it
chooses to be the default scalaVersion.
**Solution**
This displays a warning if scalaVersion setting is missing.
**Problem**
On IntelliJ the users are getting the hint to upgrade to -Xsource:3
style, however the supported syntax do not parse.
**Solution**
This adds -Xsource:3 to the parser. The metabuild compilation uses
-Xsource:3 since sbt 1.6.0.
**Problem**
dependency-tree currently doesn't include Provided configuration,
because technically it isn't part of the Compile configuration,
however, Provided does become part of the Compile classpath during compilation.
**Solution**
This changes the implementation to use the internal configuration,
e.g. CompileInternal, which includes the auxilary configurations.
There's a tradeoff here since it means that we lose the tree view of
the platonic Compile configuration.