Dependency version bumps in advance of 3.0-RC1. #1773
Conversation
|
Looks like I didn't push to master the bump of common file upload, let me do that later tonight before this or gets in. |
|
disregard my comment, there have been other commits to master after I made the bump internally, and I only changed the version number so merging this one in is just fine. |
|
Hi Matt |
|
javax.servlet.servlet-api looks to only have a 3.0 alpha. Has package identifier changed for a 3.0 final? |
|
It looks like maybe it was moved to: http://mvnrepository.com/artifact/javax.servlet/javax.servlet-api |
|
Should we be using 3.1.0? |
|
Yea 3.1 seem like a good candidate (for JavaEE 7) if it dose not break things, what do you all think ? |
|
I think we should take advantage of a major version release and do it. Worst case scenario is we bump it back down during RC because it causes issues. |
|
Good point, 2.5 is more than 10 years old (September 2005). 3.0 is from December 2009 and 3.1 is from May 2013 so it would be a huge time leap forward ;) |
|
Regarding servlet, we should also bump our starter kit's |
|
I'm working on the Servlet bump now. |
|
Uh there are quite a lot of compile errors that resulted from this in the test kit. And quite a lot of: 😞 |
|
Alright, I fixed all of the type errors in return types. It looks like the new Servlet API using more restrictive types (yay!) but I had to stop before I could provide sensible implementations for the other stuff since I'm sick today. 😷 If this doesn't break any tests, then I'll look at getting on a bit later and actually finishing out the implementations we need. |
|
(I'm hacking away at scalaz issues… More to come.) |
There were about 16 million compile and execution errors... They're fixed. Mostly. Sort of. Hopefully.
specs2 can occasionally run in a context where our current stack trace inspection doesn't *quite* work.
I think specs2 used to provide a default Scala execution context, but it no longer does so we had to import our own.
specs2 stopped supporting mixing MatchersImplicits directly into something that extends Scope, but we can just import the implicits via the MatchersImplicits singleton.
|
Just pushed fixes for Scalaz issues, which include a bump to specs2 3.7 (latest) and Scalaz to 7.2.0 (latest). Had to tweak a few things along the way, including correct run mode detection for the latest specs2 and some implicit- and scalacheck-related issues. |
We can't everywhere, particularly generic methods that return a T. :/
|
Ok, I'm down to merge this. I think we should mention when we cut RC1 that support for Servlet 3.1 is partial, and that we'd like to hear feedback on what features that we haven't implemented are important for folks. If there are no objections, I'll merge tomorrow. |
|
+1 On Thu, Mar 10, 2016 at 1:46 PM, Antonio Salazar Cardozo <
Diego Medina |
|
Alllllll righty. In we go! 👍 |
Dependency version bumps in advance of 3.0-RC1. These are version bumps I want to submit for 3.0-RC1. They spawn a few deprecation warnings in the compile cycle so it may be worth taking care of those before merging. AFAICT these are the highest version bumps I can make without breaking the compile. I also bumped the version of Scala while I was at it.
|
@farmdawgnation @Shadowfiend I notice both in my own test and lifts FlexMenuBuilderSpec test that using ".... withSFor(url) in {...}" seems to silently drop the entire test. The current output from Lifts FlexMenuBuilder Specification, looks like the following, it has 0 example(s) and that's a bit strange it should have 4. So dose WebSpecSpec ,HtmlPropertiesSpec and RestHelperSpec [info] FlexMenuBuilder Specification |
|
Looking into this… Maybe the way that I fixed |
|
Awesome ! |
Okay here we go!
These are version bumps I want to submit for 3.0-RC1. They spawn a few deprecation warnings in the compile cycle so it may be worth taking care of those before merging.
AFAICT these are the highest version bumps I can make without breaking the compile. I also bumped the version of Scala while I was at it.