| 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
|
|\ |
|
| | |
|
|\| |
|
| | |
|
| | |
|
| |
| |
| |
| | |
The 2.12 distribution will no longer ship an akka-actors jar.
|
| | |
|
|/ |
|
| |
|
| |
|
|
|
|
| |
Made scala.xml.* import optional and removed scala.util.parsing.json import.
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While we must use full version, rather than the cross version
(12720e699), we need to use latest non-snapshot version.
This should avoid failures like:
https://jenkins.scala-ide.org:8496/jenkins/view/Scala%20Xsource%20flag%20nightlies/job/Akka/63/console
Such as:
[warn] ::::::::::::::::::::::::::::::::::::::::::::::
[warn] :: UNRESOLVED DEPENDENCIES ::
[warn] ::::::::::::::::::::::::::::::::::::::::::::::
[warn] :: org.scala-lang.plugins#scala-continuations-plugin_2.11.0-SNAPSHOT;1.0.1:
not found
[warn] ::::::::::::::::::::::::::::::::::::::::::::::
sbt.ResolveException: unresolved dependency:
org.scala-lang.plugins#scala-continuations-plugin_2.11.0-SNAPSHOT;1.0.1:
|
|
|
|
|
|
| |
The continuations plugin should instead be a dependency of scala-dist,
as scala-library-all should be a drop-in replacement for scala-library,
and as such should not (indirectly) depend on plugins/the compiler.
|
|
|
|
|
| |
The distpack-maven-* targets no longer create said dir/build.
Use the publish tasks directly instead.
|
|
|
|
|
| |
My understanding is distributionManagement is only needed to configure
maven locally for publishing. Since we do that it ant, getting rid of it.
|
|
|
|
|
|
|
|
|
| |
Duplicated from scala-compiler's pom (where it's optional),
so that resolving scala-dist's transitive dependencies include jline.
We won't see scala-compiler's optional dependency on jline when depending on
scala-compiler.
TODO: remove duplication once we have the scala-compiler-repl module
|
| |
|
|
|
|
|
|
|
| |
If you'd rather depend on all Scala has to offer, module-wise,
depend on scala-library-all. This dependency determines the
jars that ship with the Scala distribution. To achieve parity
via maven resolution, this is the artifact to depend on.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We now publish a scala-dist artifact every time we publish to maven.
It captures everything needed to build a Scala distribution.
The packager should resolve all transitive dependencies of scala-dist,
put the class-file jars in the lib/ directory,
the scaladoc jars in the api/ directory,
and the source jars in the src/ directory,
in addition to unpacking the scala-dist jar itself,
which contains the bin/, doc/ and man/ directories,
which previously weren't available on maven.
This also removes the `@{dir}` abstraction, which was used to
package the continuations plugin. Since it's moved out,
we can go back to hard-coding it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NOTE: `maven/latest/build.xml` is now deprecated.
To publish a Scala build, simply call `ant publish` or `ant publish-local`.
`maven/latest/build.xml` will soon disappear from `dists/`
The idea is that a Scala distribution is a simple
repackaging of artifacts already available on maven.
Already available: typical jars for the artifacts (classes, sources, scaladoc).
To add: the bin/, doc/, and man/ directories.
Thus, move the contents that should end up in the distribution
from docs/ to doc/, create the man/ directory with the manpages,
and include the scripts in bin/.
Next up: package these directories in a jar and publish to maven,
with a dependency on scala-library-all, scala-reflect and scala-compiler,
for the jars that should end up in the distribution.
Refactorings:
- Pull filter-pom out from deploy-one.
- Rename maven-base to dist.maven.
- Set all properties in the init target (dist.maven)
|
| |
|
|
|
|
|
| |
The Scala Swing library will still ship with 2.11 (albeit unsupported).
It now resides at https://github.com/scala/scala-swing.
|
|
|
|
|
| |
The continuations plugin and library will still ship with 2.11 (albeit unsupported).
They now reside at https://github.com/scala/scala-continuations.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use `unless` attribute in targets so that `docs.skip` influences dependency graph.
Create `scaladoc` task in `pack.core` so that we don't need `pack.done`
for publishing the core.
Move source bundle creation from `dist.src` to `osgi.core`/`osgi.done`.
Split dependencies of maven publishing into core/all variants:
`osgi.core` creates osgi bundles for just lib/reflect/comp.
|
|
|
|
|
|
|
|
|
|
|
| |
Publish to maven with `ant publish.local`,
`ant publish`, or `ant publish.signed`.
For now, we must keep copying `src/build/maven/maven-deploy.xml`
to `dists/maven/latest.build.xml`, along with its dependencies,
as it's used by jenkins jobs and PR validation.
TODO: `inline src/build/maven/maven-deploy.xml` into `build.xml`.
|
|
|
|
| |
It tended too easily to get out of synch with build.xml.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The staleness problem in our build had its roots in
the flawed uptodate check fixed in the previous commit,
but I spent a lot of time looking at these first. Maybe
one was also complicit.
We've got better things to worry about, so lets make
the all overwrite.
|
|
|
|
|
|
|
|
| |
- skip docs.lib, which doesn't route through the staged-docs
macro
- skip copying docs to the staged maven distribution
- skip maven local deploy of doc jar under this mode
- skip devel docs tarring
|
|\
| |
| | |
Remove build.number.maven
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I can't find any justification for having this information
in both build.number and build.number.maven.
They have drifted apart on the 2.10.x branch, although that
doesn't matter because build.number is correct, and loaded first,
and Ant properties are write-once.
I'm assuming that the Ant tasks in src/build/pack.xml are only
invoked through the <antcall>-s in ./build.xml.
Here's a test of that from the 2.10.x branch:
% cat build.number
#Tue Sep 11 19:21:09 CEST 2007
version.major=2
version.minor=10
version.patch=3
# This is the -N part of a version. if it's 0, it's dropped from maven versions.
version.bnum=0
# Note: To build a release run ant with -Dbuild.release=true
# To build an RC, run ant with -Dmaven.version.suffix=-RCN
% cat build.number.maven
version.major=2
version.minor=10
version.patch=0
% git diff
diff --git a/build.xml b/build.xml
index 3a83aa4..5cb952c 100644
--- a/build.xml
+++ b/build.xml
@@ -62,6 +62,9 @@ TODO:
<target name="distpack" depends="dist.done, docs.done">
<ant antfile="${src.dir}/build/pack.xml" target="pack-all.done" inheritall="yes" inh
+ <target name="distpack.maven.info">
+ <ant antfile="${src.dir}/build/pack.xml" target="pack-maven.info" inheritall="yes" i
+
<target name="distpack-maven" depends="dist.done, docs.done">
<ant antfile="${src.dir}/build/pack.xml" target="pack-maven.done" inheritall="yes" i
diff --git a/src/build/pack.xml b/src/build/pack.xml
index 20c4034..56863ff 100644
--- a/src/build/pack.xml
+++ b/src/build/pack.xml
@@ -133,6 +133,10 @@ MAIN DISTRIBUTION PACKAGING
<mkdir dir="${dists.dir}/maven/${version.number}"/>
</target>
+ <target name="pack-maven.info">
+ <echo message="version.patch = ${version.patch}"/>
+ </target>
+
<target name="pack-maven.libs" depends="pack-maven.start">
<macrodef name="mvn-copy-lib">
<attribute name="mvn.artifact.name"/>
% ant distpack.maven.info
Buildfile: /Users/jason/code/scala2/build.xml
distpack.maven.info:
pack-maven.info:
[echo] version.patch = 3
Notice how the stale `version.patch=0` in build.number.maven is
ignored.
|
|/
|
|
| |
In a sign of decreased optimism about that facility.
|
|
|
|
|
|
|
|
|
| |
That is, scaladoc is still in the scala-compiler artifact.
Let dbuild know so that it won't freak out.
ps: dbuild-meta.json should be kept in synch with
src/build/dbuild-meta-json-gen.scala until we can
automate that in the build
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These modules move to their own repositories:
- https://github.com/scala/scala-xml (v1.0-RC3)
- https://github.com/scala/scala-parser-combinators (v1.0-RC1)
The modularization depends on the new partest, as the old one's
classpath handling did not support a modularized scala.
The compiler pom now depends on the artifacts published separately,
with versions specified in versions.properties.
NOTES:
- The osgi tests resolve the xml and parsers jars and osgi-fy them,
as they are no longer built locally.
TODO: Can we move the osgification to the module builds?
- Disabled local repositories: don't want to accidentally include
unpublished artifacts in releases etc.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As partest is now resolved from maven, `test/partest` uses `ant test.suite.init`
to determine the classpath (serialized to build/pack/partest.properties)
that's necessary to run `scala.tools.partest.nest.ConsoleRunner`.
Thus, partest gets exactly the same classpath, whether run from
the command line through `test/partest` or via `ant test`.
The version of partest we're using is specified by
properties defined in versions.properties (formerly `starr.number`).
Currently, we're using:
```
scala.binary.version=2.11.0-M4
partest.version.number=1.0-RC3
```
NOTES:
- The version of Scala being tested must be backwards binary compatible with
the version of Scala that was used to compile partest.
- Once 2.11 goes final, `scala.binary.version=2.11`, and `starr.version=2.11.0`.
- Need scalacheck on classpath for test/partest scalacheck tests.
- Removed atrophied ant tests (haven't been run/changed for at least two years
I checked 81d659141a as a "random" sample).
- Removed scalacheck. It's resolved as a partest dependency.
- For now, use a locally built scalap
- Kept the trace macro in the main repo (partest-extras)
- New targets for faster pr validation: test-core-opt, test-stab-opt
- Reused partest eclipse/intellij project to partest-extras
(note: the partest dependency is hard-coded)
|
|
|
|
|
|
|
|
| |
Concretely, update scala-compiler's pom
to list scala-xml and scala-parser-combinators
on behalf of scaladoc.
NOTE: when spinning off scaladoc, move dependencies to its own pom
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The next version of [dbuild](http://typesafehub.github.io/distributed-build/0.5.3/index.html)
will parse `dbuild-meta.json` to determine which jars are produced by a Scala build.
This way we can modularize without changing dbuild itself.
Yes, I know `dbuild-meta.json` should be generated during the build.
However, given the state of our build.xml, I think this is pointless.
My goal is to generate build.xml, dbuild-meta.json and Eclipse projects
from a higher-level description of our build. Baby steps...
Including improvements by @cunei:
- Removing outdated field "uri" from ExtractedBuildMeta
- Changed "partest" to "scala-partest" (the actual jar name)
|
|
|
|
|
|
|
|
| |
Notes:
- no longer specifying terminal by class name in scripts (using 'unix')
- jline doesn't need a separate jansi dependency;
it includes its own version according to:
http://mvnrepository.com/artifact/jline/jline/2.11
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- Remove the last vestiges of xml from Predef and Contexts.
- Change build to compile scala.xml to scala-xml.jar.
- Deploy scala-xml module to maven.
- Update partest accordingly.
Note:
An older compiler cannot use the new standard library to
compile projects that use XML. Thus, skipping locker will
break the build until we use 2.11.0-M4 for STARR.
In the future build process, where we drop locker,
we would have to release a milestone that supports the old
and the new approach to xml. As soon as we'd be using that
new milestone for starr, we could drop support for the old approach.
|
|
|
|
|
| |
I just couldn't stand the incredible mess in there anymore. More cleanup to come.
For now, suffice it to say you need only add one line per new module.
|
|\
| |
| |
| |
| |
| | |
Conflicts:
src/compiler/scala/tools/nsc/typechecker/Implicits.scala
src/reflect/scala/reflect/runtime/JavaMirrors.scala
|