-
Notifications
You must be signed in to change notification settings - Fork 308
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace sbt dependency with zinc #1117
Conversation
Lots of changes in this commit. It is difficult to split it up in smaller more meaningful commits. Basically, there are only these two changes: - The build had to be updated. The sbt module is now disabled and can be removed once it is verified that everything works as it should. zinc is split up into multiple modules. Therefore there are a lot of new dependencies even though they all belong to zinc. - Because of source incompatibilities, our source code had to be updated. There are a few TODOs left in the code, we need to figure out later if the new code is ok or if it needs to be improved.
These dependencies were not necessary to compile the code. Instead the code failed at runtime.
With this change, the IDE no longer depends directly on sbt but only on zinc. The most important advantage is that we no longer need to build zinc by ourselves - instead we can rely on the prebuilt zinc artifacts. We still need to build compiler-bridge (former compiler-interface) because it depends on scalac and therefore is binary incompatible between minor versions but since the infrastructure to build it already exists the only change that was needed is to add different artifacts.
The zinc artifact has been renamed from compiler-interface to compiler-bridge.
This renames everything that has to do with compiler-interface to compiler-bridge. The artifact has been renamed in zinc therefore we want to do it as well.
I don't know why these entries were on the gitignore list.
They were missed in an earlier commit. sbt.ide.version is removed because it is unused.
sbt.version is no longer used.
diffutils is no longer used and therefore removed.
Class based dependency tracking in zinc doesn't allow to disable name hashing. Since this is the only dependency tracking algorithm available we no longer need this option.
They were accidentally removed earlier.
Another artifact that is needed on the classpath.
Test FAILed. |
val nameHashingProperty = SettingConverterUtil.convertNameToProperty(ScalaPluginSettings.nameHashing.name) | ||
project.storage.setValue(nameHashingProperty, isOn) | ||
private def whenNameHashingIsOn(otherwise: => Unit): Unit = { | ||
project.storage.setValue("nameHashing", true) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand that nameHashing
has got one value true
looks promising 👍 |
Conflicts: org.scala-ide.sdt.core.tests/src/org/scalaide/TestsSuite.scala org.scala-ide.sdt.core/src/org/scalaide/core/internal/builder/zinc/JavaEclipseCompiler.scala
Test FAILed. |
retest this please |
Test FAILed. |
I looked at tests and seems like javac is not called by incremental compiler |
I try to build it but I have problem with following p2 repo: http://download.eclipse.org/releases/luna/ btw isn't be more like http://download.eclipse.org/releases/neon/ ? |
The test failures are weird. On my system all of them pass. Where do you have any problems with the luna p2 update site? Everything should point to neon. |
I cannot build it. Ends up with: |
I see my mistake, forgot to run git fetch origin |
I have 8 failed tests in core on Win. Looking into.... |
Test PASSed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the biggest point is to make a trial of conversion from Analysis
to CompileAnalysis
, other things are minor one
store.purgeCache() | ||
|
||
Assert.assertTrue("successful compiler bridge compilation", store.compilerBridgeFor(platformInstallation)(null).isRight) | ||
Assert.assertEquals("Zero hits and one miss", (0, 1), store.getStats) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is hit and what is miss (I suspect the cache but don't impel me to look deeper).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first number is hits, the second one is misses. It is explained in Scaladoc of getStats
. Too lazy to convert that to convert that to a case class.
@@ -61,26 +59,21 @@ object NameHashingVulnerabilityTest extends IProjectOperations { | |||
|
|||
class NameHashingVulnerabilityTest extends IProjectOperations with IProjectHelpers { | |||
import NameHashingVulnerabilityTest._ | |||
private val On = true | |||
private val Off = false | |||
private val errorTypes = Array(SdtConstants.ProblemMarkerId, IJavaModelMarker.JAVA_MODEL_PROBLEM_MARKER) | |||
|
|||
@Test def shouldCorrectlyBuildProjectForAllPossibleSettingsOfNameHashingFlag(): Unit = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need this test now? cannot purge it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you are right, I removed it
@@ -42,8 +42,8 @@ Require-Bundle: org.eclipse.core.expressions, | |||
org.scala-lang.scala-compiler;bundle-version="[2.12,2.13)", | |||
org.scala-refactoring.library, | |||
org.scala-lang.modules.scala-xml;bundle-version="[1.0.2,1.0.10]", | |||
org.scala-ide.sbt.full.library;bundle-version="[0.13,0.14)", | |||
org.scala-ide.sbt.compiler.interface;bundle-version="[0.13,0.14)", | |||
org.scala-ide.zinc.library;bundle-version="[0.13,0.14)", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wonder if [0.13,0.14)
is relevant to zinc version... 1.0.0-X2?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
def compile(in: SbtInputs, comps: Compilers): Analysis = { | ||
val lookup = new PerClasspathEntryLookup { | ||
override def analysis(classpathEntry: File) = | ||
in.analysisMap(classpathEntry).asInstanceOf[xsbti.Maybe[CompileAnalysis]] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
need to change/update SbtInputs
analysis functions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
@@ -186,7 +185,7 @@ class EclipseSbtBuildManager(val project: IScalaProject, settings: Settings, ana | |||
|
|||
// take by-name argument because we need incOptions only when we have a cache miss | |||
override def latestAnalysis(incOptions: => IncOptions): Analysis = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Analysis
should be turned into CompileAnalysis
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately CompileAnalysis
is just a marker interface, we can't do anything with it.
override def outputGroups = sourceOutputFolders.map { | ||
case (src, out) => new MultipleOutput.OutputGroup { | ||
override def sourceDirectory = { | ||
val loc = src.getLocation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Option with map? Just proposal
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can't return an Option here
}) | ||
|
||
def readAnalysis(cacheFile: File, incOptions: => IncOptions): Analysis = | ||
readCache(cacheFile).map(_._1).getOrElse(Analysis.empty(nameHashing = incOptions.nameHashing())) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nameHashing
is true
only?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
The former is a marker interface and therefore preferred to use. However, it doesn't have any functionality therefore we can't use it very often.
Name hashing is always true and we don't need to access any other options.
zinc requires that name hashing is always enabled, therefore we no longer need this test.
Not entirely sure what this thing is doing or if it is needed but TransactionalManagerType seems to be the replacement for ClassfileManager and we did use the latter so far, therefore we continue to use it.
No behavior changes introduced.
I fixed all remaining TODOs and applied all review comments. Looks ready to merge now. |
Test PASSed. |
if you are sure about |
Please note that anything in It's part of the effort of exposing a smaller api so that it's less painful and limiting to sbt or zinc to evolve. /cc @eed3si9n |
We always dependent on zinc internals, from this point of view nothing changed. If there are larger changes planned, we would welcome if you could drop us a message (or drop it on gitter, I'm following sbt-dev anyway) ---- On Wed, 21 Sep 2016 23:02:56 +0200 notifications@github.com wrote ---- Please note that anything in sbt.internal can change in any way, so it's a risk to depend on them. It's part of the effort of exposing a smaller api so that it's less painful and limiting to sbt or zinc to evolve. /cc @eed3si9n — |
Nothing in zinc wasn't internal, ie. all of sbt was public API. Now things that are in sbt.internal are expressly internal, so caveat emptor. Things might continue to change in the future, I'll try to remember to ping you in sbt-dev. Note that you're depending on a milestone pre-release of zinc... |
Scala IDE so far did depend directly on sbt to build Scala sources. Because zinc has been extracted out of sbt into its own repo, we finally got the chance to get rid of the sbt dependency by only relying on zinc.
This greatly simplifies uber-build (see the PR: scala-ide/uber-build#87) but not so much the scala-ide build itself because packaging zinc in a way that Eclipse likes it is still a major act.
In the following a short description of the changes:
org.scala-ide.sbt.compiler.interface
has been renamed toorg.scala-ide.zinc.compiler.bridge
. This is because the sbt dependencycompiler-interface
has been renamed tocompiler-bridge
in zinc. However, there is a newly introduced dependency also calledcompiler-interface
in zinc (but it has a different purpose than the one in sbt).org.scala-ide.sbt.full.library
has been renamed toorg.scala-ide.zinc.library
org.scala-ide.sbt.build
has been renamed toorg.scala-ide.zinc
org.scala-ide.zinc
is still needed as an Eclipse bundle is that I didn't find another way to bundle zinc together withorg.scala-ide.sdt.core
. The following things had to be achieved:compiler-bridge
depends on scalac and is therefore binary incompatible between minor versions. We need to build it from source. This is done at runtime by the IDE inCompilerBridgeStore
.CompilerBridgeStore
we need to ship the sources ofcompiler-bridge
and all of its dependencies as binaries (the dependencies do not depend on scalac and therefore can be shipped as binaries).org.scala-ide.zinc.library
contains the said binaries.org.scala-ide.zinc.compiler.bridge.source
contains the said sources.org.scala-ide.zinc
bundles both as an Eclipse bundle.org.scala-ide.zinc.library
andorg.scala-ide.zinc.compiler.bridge.source
can't be done inorg.scala-ide.sdt.core
because the maven build first checks if the bundle is available before the building happens. Only withorg.scala-ide.zinc
we could achieve that the bundle is available at the dependency checking phase of maven. This is also the reason whybuild-all.sh
exists, whose purpose it is to make the zinc and Scala dependencies available to scala-ide. With a single maven build this can't be achieved, because the bundles are created in a maven phase that happens after the dependency-checking phase and therefore these bundles can't be made available to other bundles of scala-ide.TODO:
ClassfileManager
inSbtInputs