Merge master to java7 #44

lrytz · 2015-05-11T17:45:54Z

This merges the current master branch into java7.

Note the importance of having osgiSettings in the main build.

Osgify

Reactions are PartialFunctions, so if events come through indiscriminately that the listener is not defined for, errors occur. Eg: -- Exception in thread "AWT-EventQueue-0" scala.MatchError: FocusGained(scala.swing wrapper scala.swing.TextField -- A Coursera thread with people affected by this issue: https://class.coursera.org/reactive-001/forum/thread?thread_id=1315

…pf-defined SI-8019 Make Publisher check PartialFunction is defined for Event

Switch to scala-module-plugin, sbt 0.13.1

- Update project version to 1.0.2-SNAPSHOT, give that 1.0.1 is already released - Use _2.11 as the snapshot binary version for 2.12.0-SNAPSHOT PR validation. - Use 1.0.1 as the MiMa baseline - Use Scala 2.11.0 for Travis CI builds

Version bumps

Update to README to show location of scaladocs (and to promote java7 branch)

Modify travis build to derive the project version from TRAVIS_TAG (when set). as well as to have sbt run the `publish-signed` task if the environment is right. The tag must match the semver regex `^v[0-9]+\.[0-9]+\.[0-9]+(-[A-Za-z0-9-]+)?`, and the jdk we're running on must match PUBLISH_JDK (set in .travis.yml). For every repo, you must create the following files (not included here) according to the instructions in admin/gpg.sbt: - admin/pubring.asc (commit) - admin/secring.asc (DO NOT COMMIT) - sensitive.sbt (DO NOT COMMIT) - passphrase for secring.asc - api token for staging to sonatype Generate these using `admin/encryptAll.sh`: - admin/secring.asc.enc (commit) - sensitive.sbt.enc (commit) Note that `encryptAll.sh` spits out a "- secure .... " line, that you need to add to `.travis.yml`'s `env` section, so that travis can supply the SECRET env variable, which is used to decrypt the sensitive files above.

Support for tag-driven publishing on Travis.

…ava7

lrytz · 2015-05-11T17:56:38Z

Hi @andy1138

I think there's a few things that we can do for the Scala 2.12 release (there's still time!).

In general, the master branch is in maintenance mode, I don't think there will be many commits to it. Instead, we should make the current java7 branch the main branch. I'd propose to rename the branches: master -> 1.0.x and java7 -> 1.1.x.

In terms of workflow, I think we should continuously merge 1.0.x into 1.1.x (just like this PR is doing). This way we can make sure things (like release scripts) stay in synch. We do the same in scala/scala, and also for example in the scala/scala-parser-combinators module.

For Scala 2.11, we will continue using 1.0.x. For Scala 2.12 we can then use 1.1.x versions.
But these are just the default versions shipped with the Scala distribution: we can easily cross-build and release both branches against 2.11 and 2.12 (and even include 2.10). So users of 2.11 for example can just add scala-swing 1.1.x to their project.

Once we switch make the 1.1.x branch the default, we will also see its README as the default for the repository, so we can clean up a few things.

Let me know if this all sounds good. I'm happy to do the changes (I'll @-mention you).

andy1138 · 2015-05-11T19:45:40Z

Hi @lrytz
Thanks for the help.
Scala 2.12 has creeped-up on me. :-)

You seem to be matching what I had in mind. The idea was to have java7 branch included with scala2.12 and also moved to 'master' (as you suggest).
The only difference is that I versioned java7 -> 2.0.x instead of 1.1.x ( showing not only code change but also when it moved from typesafe/epfl to community supported). There has already been on milestone/tagged builds under the 2.0.x numbering system.

As for what gets released with what, 1.x.x (compiled with java6) should go with scala2.10/11 and 2.0.x' goesscala2.12+(and compiled, I assume, withjava8but could bejava7`)

As your git-fu is probably better than mine then I'm happy to let you do the changes, if not then I'll do it over the weekend. I'm happy to tidy things up afterwards if you just want to get the basics working.

Note: there is a binary compatible break in java7 (it's still code level compatible) so mima was throwing errors when testing 1.0.x build with 2.0.x so I ended up disabling that check on 2.x.x (java7) branch

andy1138 · 2015-05-11T19:51:52Z

@lrytz :-) good timing, build has just failed, looks like binary compatibility check, I suggest disabling it for the moment its the first build for this branch.

lrytz · 2015-05-12T08:57:26Z

Thanks @andy1138 for your answer!

Indeed we have to disable MiMa until 2.0.0 is out - that's very easy now, I just had to set mimaPreviousVersion := None.

Using 2.0.x instead of 1.1.x is absolutely fine.

For cross-building: the 2.12.0-M1 release still uses scala-swing version 1.0.x, so for now I'll cross-build the 1.0.x branch with 2.10, 2.11 and 2.12. The 2.0.x branch we can cross-build with 2.11 and 2.12 - maybe some 2.11 users are also interested in using scala-swing 2.0.x.

I'll move to jdk 8 for the 2.0.x branch - soon, the Scala 2.12 compiler will only run on this anyway. There's no drawback in running the 2.11 compiler on jdk 8: the resulting classes will work fine on jdk 7, so 2.11 users on jdk 7 ca use scala-swing 2.0.x.

Lots of version numbers there :)

Merge master to java7

andy1138 · 2015-05-13T20:48:03Z

@lrytz Thanks for all the work :-)

I think you got the java/scala/scala-swing version numbering correct. I'm basically thinking that any changes will go into swing2.0 and backported to swing1.0 only if really asked for

Thanks again :-)

lrytz · 2015-05-14T05:08:35Z

absolutely, we can keep 1.0.x in maintenance mode, and backport individual
fixes on request.

On Wednesday, May 13, 2015, Andy Hicks notifications@github.com wrote:

@lrytz https://github.com/lrytz Thanks for all the work :-)

I think you got the java/scala/scala-swing version numbering correct. I'm
basically thinking that any changes will go into swing2.0 and backported to
swing1.0 only if really asked for

—
Reply to this email directly or view it on GitHub
#44 (comment).

adriaanm and others added 25 commits December 3, 2013 22:31

Only test on Java 6. See java7 branch.

23e1796

Remove redundant mappings setting.

276ccde

OSGify.

d18f424

Note the importance of having osgiSettings in the main build.

Merge pull request scala#1 from scala/osgify

2f06f61

Osgify

add build.properties, remove from .gitignore

2d358e1

Merge pull request scala#2 from rtyley/si-8019-swing-publisher-check-…

f0246d3

…pf-defined SI-8019 Make Publisher check PartialFunction is defined for Event

Switch to scala-module-plugin, sbt 0.13.1

3689632

Merge pull request scala#3 from adriaanm/master

e8f69af

Switch to scala-module-plugin, sbt 0.13.1

Check binary compatibility with MiMa

312cfce

Bump versions.

f2a13d6

Version bumps

42b475c

- Update project version to 1.0.2-SNAPSHOT, give that 1.0.1 is already released - Use _2.11 as the snapshot binary version for 2.12.0-SNAPSHOT PR validation. - Use 1.0.1 as the MiMa baseline - Use Scala 2.11.0 for Travis CI builds

Merge pull request scala#8 from retronym/topic/bump

440d2eb

Version bumps

Adds scaladoc notes to read me

8a32fc9

adds 'current work'

e90328c

Corrects path to demos

64b40bf

bit of readme.md layout cleanup

4552a5e

Merge pull request scala#14 from andy1138/master

57b9b72

Update to README to show location of scaladocs (and to promote java7 branch)

Secure config for publishing to sonatype

2b61b76

Merge pull request scala#33 from adriaanm/autopublish

8da0e7b

Support for tag-driven publishing on Travis.

Update the scala-modules plugin to 1.0.3

38bba36

update version number for v1.0.2

485d728

Update README.md

0fc44e2

Merge remote-tracking branch 'upstream/master' into merge-master-to-j…

deabbbb

…ava7

andy1138 added the in progress label May 11, 2015

Disable MiMa, minor cleanups in build.sbt

49b29fb

lrytz added a commit that referenced this pull request May 12, 2015

Merge pull request #44 from lrytz/merge-master-to-java7

9ed1989

Merge master to java7

lrytz merged commit 9ed1989 into scala:java7 May 12, 2015

andy1138 removed the in progress label May 12, 2015

lrytz deleted the merge-master-to-java7 branch May 12, 2015 09:28

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Merge master to java7 #44

Merge master to java7 #44

Uh oh!

lrytz commented May 11, 2015

Uh oh!

lrytz commented May 11, 2015

Uh oh!

andy1138 commented May 11, 2015

Uh oh!

andy1138 commented May 11, 2015

Uh oh!

lrytz commented May 12, 2015

Uh oh!

andy1138 commented May 13, 2015

Uh oh!

lrytz commented May 14, 2015

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Merge master to java7 #44

Merge master to java7 #44

Uh oh!

Conversation

lrytz commented May 11, 2015

Uh oh!

lrytz commented May 11, 2015

Uh oh!

andy1138 commented May 11, 2015

Uh oh!

andy1138 commented May 11, 2015

Uh oh!

lrytz commented May 12, 2015

Uh oh!

andy1138 commented May 13, 2015

Uh oh!

lrytz commented May 14, 2015

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants