| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
<h1>Allow mixed builds in ant</h1>
The `JFunction` classes depend on the `FunctionN` traits, so the
Java compiler needs the Scala library on the classpath.
At the same time, while compiling the Scala library, the symbols for
`JFunction` classes need to be available to emit indy-lambda closures.
Therefore we pass the `JFunctions` as Java sources while compiling the
Scala library.
<h1>Upgrade versions of osgi tools</h1>
Set the required java version in bnd files (JavaSE-1.8).
Introduce `scala-swing.version.osgi` as a quick hack to
allow manually deriving an osgi-friendly version number
for the `scala-swing.version.number`. The latter is used
to resolve the artifact, the osgi version is just so we
can generate a bundle that osgi will accept.
Bnd 1.50 doesn't work with Java 8 classfiles, so upgrade to 2.4.1.
Also upgrade all other tools to make tests pass.
For `org.eclipse.osgi` we moved to the group ID `org.eclipse.tycho`,
where there's a newer version available. The osgi tests would fail
with the most recent version available in the `org.eclipse.osgi` groupID.
The new version of bnd only copies *classfiles* from the
original into the resulting jar, while the old version also copied
all other files. This caused osgi test failure with a `NoClassDefFound`,
which was really due to a `NumberFormatException` in `ScalaVersion`,
as it couldn't find the properties file to parse the version in...
Include resources from source jar into osgi bundle as follows:
```
Include-Resource: @@SOURCE_JARNAME@
```
This makes bnd copy all resources from the source jar. I ran the
following on the osgi artifacts of this branch, and on 2.11.x:
```
for f in `find build/osgi -name '*.jar' -a -not -name '*src.jar'`; do unzip -l $f | grep -v '\.class' ; done
```
Comparing the two file lists, things look OK:
https://gist.github.com/lrytz/be08db051a53eded192d
|
|
|
|
| |
Without it, Equinox on Java 7 might spit out some warnings, which might lead to the wrong impression, that the Scala bundles are not well supported for newer platforms.
|
|
|
|
|
|
|
|
| |
Restrict the Import-Package OSGi manifest entry to match only binary compatible scala.* packages. This is necessary, because the Scala OSGi versions do not match the OSGi semantic versioning policy and are not binary compatible between their OSGi minor versions. This means that e.g. the scala-compiler-2.11 bundle will never work if it imports a scala.* package from 2.10 or 2.12. Thus this patch enforces a tight version range, only accepting versions within the same minor version. E.g. Applied to version 2.11.1 the range would expand to "[2.11,2.12)".
Additionally, a Java 6 execution environment will be enforced for OSGi.
All module bundles need to have their own version numbers. This was not the case before this commit. Although these module bundles were only build for testing, they are needed to be correct, now, that we have stricter package import constraints and some test cases rely on them.
|
|
Actual modularization is delayed until 2.12.
The one big (one-line) change is to make the interactive compiler independent
of scaladoc. We have one "integration test": `MemoryLeaksTest`.
This commit adds a bunch of comments marked `TODO: modularize the compiler`,
that should be uncommented when we're ready to continue the modularization
effort.
I decided to merge them commented out to avoid having to rebase xml patches.
There's still some chance of bitrot, but I'm willing to take my chances.
I previously refactored the build to make it easier to add jars in a coherent
way, which hinges on the `init-project-prop` mechanism, so the relevant
properties are already injected there.
|