I have already done the following:
- forked https://github.com/JetBrains/kotlin
- cloned my fork and from there:
- git fetch upstream
- git merge upstream/master
- ant -f update_dependencies.xml (if needed)
-
ant dist (same as ant -f build.xml or even just ant from what I could see)
- cd libraries && mvn [-PlocalKotlin] clean package
If so, are steps 3 to 5 run by the Kotlin Compiler and Plugin build configuration? If not, why?
One of the reasons I ask is because I noticed that the version of the IDEA snapshot in update_dependencies.xml had recently been upgraded from 116 to 118 whilst the IDEA CE build itself had not been successful for a while and therefore the last successful build remained stuck at version 116. Yet, none of the Kotlin builds picked up this problem. Step 3 failed on the command line as expected.
Secondly, after locally downgrading the version back to 116, I got several compilation failures for stdlib on the command line (step 5) due to methods not being implemented or (Jet) classes/methods not being found after repeated attempts over the past 24 hours (see the attached mvn_libraries.log). Again, none of the Kotlin builds picks up these problems.
This made me wonder whether I had correctly followed the instructions from this thread and from the Getting Started guide, and arguably more importantly, it made me wish for an ideally new build configuration that faithfully mirrors the steps that existing and aspiring committers should be executing on the command line before eventually pushing back to https://github.com/JetBrains/kotlin. This configuration would have picked up both of the above issues.
How does that sound, folks?
ant_dist.log.zip (1.69 KB)
mvn_libraries.log.zip (3.38 KB)
ant_update_dependencies.log.zip (636 Bytes)
I don't know much about the teamcity builds am afraid; so can't really help figure out why the builds didn't barf when the 118 build wasn't available.
Certainly your summary matches my understanding of the current build & CI stuff. Currently the update_dependencies step is a little flaky - its hard to know exactly when you need to perform this step locally. I’ve had times when I did an update locally then couldn’t build anything as I got a newer version of IDEA which didn’t work yet.
Personally I’d prefer for these dependencies to be checked into source control then we’re all on the same page & when a new IDEA build is needed/required someone or some CI build checks them into source control. Then contributors don’t need to guess when they need to run the ant -f update_dependencies.xml script.
Those compile errors from the mvn build certainly look bad :). Seems like the tests are not seeing any of the extension methods defined in the standard library which looks pretty fatal to me; a sure sign something’s screwy.
Am just running a test locally to see how it works for me - if 118 is indeed borked we should just rollback the update_dependencies.xml to use 116 until it works. Not sure what to do about the TeamCity builds though as I don’t really grok what they’re doing 
Just grabbed a clean checkout, ran
ant -f update_dependencies.xml
ant dist
cd libraries
mvn install
and it worked fine for me here.
There was a slight gremlin earlier BTW with an incorrect repository URL; but it seems to be working fine for me here.
I wonder if the 118 build has worked or updated in the meantime or something? Maybe the working build on the 18th fixed your issue?
Going forward, checking in the IDEA dependencies would really help us avoid this issue. I guess its mostly the intellij-core.jar we use right?
Well, I've just given it another go, using mvn install in step 5 this time, with no joy, even after zapping my .m2 repository and .ivy2 cache. See the attached command line outputs once again.
I noticed the new Libraries - Maven Build configuration successfully executes the following steps in sequence:
ant -f TeamCityBuild.xml pre_build
- ant -f TeamCityBuild.xml zip
-
mvn package -PlocalKotlin
I’ve tried these too, without success. I’m beginning to think that there is something broken in my setup, so I’ll try all of the above on another machine next.
I cannot help but notice the many ways of building kotlin/libraries and I wonder whether anyone had a particular objection to consolidating build strategies across environments (CI, local) to make it clear and simple for contributers and maintainers alike. Thoughts anyone?
ant_dist.log.zip (1.71 KB)
ant_update_dependencies.log.zip (659 Bytes)
mvn_install.log.zip (13.5 KB)
What happens if you try:
cd libraries
mvn install
This will then use the released maven plugin and use its kotlin runtime - so not depend on any ant build at all in the root directory?
The build of kotlin/libraries is actually a regular maven project; there’s no magic or special stuff required (unless you use the localKotlin profile to reuse the Ant build - but only do that if you really want to - for example if you’re making local changes to the standard library.
I've finally figured out what the problem was: it was my local addition of a test case under kotlin/libraries/stdlib/test which had a package declaration beginning with kotlin as in:
package kotlin.subpackage
...
This somehow resulted in all these odd compilation errors. Renaming the package to:
package test.subpackage
…
fixed the issue once and for all.
We might want to highlight this restriction of not being able to mirror the package structure of production code in tests for stdlib classes.
Ah I've hit that bug quite a bit before
http://youtrack.jetbrains.com/issue/KT-1381
Yes, its painful. Seems that every compile generates a namespace.class which its very easy to hide other namespace.class files generated in other libraries - for example breaking the standard library if you create a class in the kotlin package.
Developers are used to creating test cases in the same package; which doesn’t work right now if that package has top level functions/methods or extension methods.
Thanks James! I've added a link to this thread to illustrate this bug.