Skip to content
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

Merged
merged 32 commits into from
Sep 21, 2016
Merged

Replace sbt dependency with zinc #1117

merged 32 commits into from
Sep 21, 2016

Conversation

kiritsuku
Copy link
Member

@kiritsuku kiritsuku commented Aug 30, 2016

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 to org.scala-ide.zinc.compiler.bridge. This is because the sbt dependency compiler-interface has been renamed to compiler-bridge in zinc. However, there is a newly introduced dependency also called compiler-interface in zinc (but it has a different purpose than the one in sbt).
  • org.scala-ide.sbt.full.library has been renamed to org.scala-ide.zinc.library
  • org.scala-ide.sbt.build has been renamed to org.scala-ide.zinc
  • The reason why org.scala-ide.zinc is still needed as an Eclipse bundle is that I didn't find another way to bundle zinc together with org.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 in CompilerBridgeStore.
    • In order to allow the runtime compilation in CompilerBridgeStore we need to ship the sources of compiler-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.
    • The bundling of org.scala-ide.zinc.library and org.scala-ide.zinc.compiler.bridge.source can't be done in org.scala-ide.sdt.core because the maven build first checks if the bundle is available before the building happens. Only with org.scala-ide.zinc we could achieve that the bundle is available at the dependency checking phase of maven. This is also the reason why build-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.
  • The manifests need to depend on all zinc artifacts because these artifacts are not available through p2 update sites.

TODO:

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.
Another artifact that is needed on the classpath.
@ghprb-bot
Copy link

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)
Copy link
Member

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

@wpopielarski
Copy link
Member

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
@ghprb-bot
Copy link

Test FAILed.

@kiritsuku
Copy link
Member Author

retest this please

@ghprb-bot
Copy link

Test FAILed.

@wpopielarski
Copy link
Member

I looked at tests and seems like javac is not called by incremental compiler

@wpopielarski
Copy link
Member

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/ ?

@kiritsuku
Copy link
Member Author

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.

@wpopielarski
Copy link
Member

I cannot build it. Ends up with:
[ERROR] Internal error: java.lang.RuntimeException: Failed to load p2 repository with ID 'eclipse.luna' from location http://download.eclipse.org/releases/luna: Unable to read repository at http://download.eclipse.org/releases/luna. Unable to read repository at http://download.eclipse.org/releases/luna/201502271000/content.jar. Read timed out

@wpopielarski
Copy link
Member

I see my mistake, forgot to run git fetch origin

@wpopielarski
Copy link
Member

I have 8 failed tests in core on Win. Looking into....

@ghprb-bot
Copy link

Test PASSed.

Copy link
Member

@wpopielarski wpopielarski left a 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)
Copy link
Member

@wpopielarski wpopielarski Sep 20, 2016

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).

Copy link
Member Author

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 = {
Copy link
Member

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?

Copy link
Member Author

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)",
Copy link
Member

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?

Copy link
Member Author

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]]
Copy link
Member

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.

Copy link
Member Author

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 =
Copy link
Member

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?

Copy link
Member Author

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
Copy link
Member

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

Copy link
Member Author

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()))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nameHashing is true only?

Copy link
Member Author

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.
@kiritsuku
Copy link
Member Author

I fixed all remaining TODOs and applied all review comments. Looks ready to merge now.

@ghprb-bot
Copy link

Test PASSed.

@wpopielarski
Copy link
Member

if you are sure about CompileAnalysis and Analysis then LGTM 👍

@kiritsuku kiritsuku merged commit 3adba0e into scala-ide:master Sep 21, 2016
@kiritsuku kiritsuku deleted the zinc branch September 21, 2016 20:23
@dwijnand
Copy link

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

@kiritsuku
Copy link
Member Author

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


You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.

@dwijnand
Copy link

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants