As I spoke with Andreas and Kristian about my ideas now I am going to forward this email to Maven mailinglist. I can see the opportunity of Java 8 but I don't say that all artifacts must be necessarily compiled with Java8. I can imaging few of them which make sense. This is the email and you can tell us what you think of it. Maybe it's crazy.
After i made a post [1] in JUnit on GitHub I found that it might be useful in Maven. Usually JUnit committers are very reserved to new features if you push them somewhere they don't want to be. :-) So there are two things how we can utilize Java 8 in Surefire extensions. The first is simple abstraction of Runners independent of JUnit and TestNG and easily customized by the user. Second is the same Runner abstraction used with CLI console. --- [1] https://github.com/junit-team/junit/issues/1078#issuecomment-158706736 1. You should see [1]. JUnitTest is an interface and has default methods. The test(string, function) methods needs to be called in users code. These methods only register function -> test name. The function is real test name. Since JUnitTest is interface it can be implemented in extension. The Surefire Provider will only create a Proxy around it and around test() methods and simply only report to SurefireListener. That's all, simple. All features like parameterized producer, categories, filters, rules are up to AOP in SPI. Due to Java Proxy the AOP is possible. 2. With Nashorn console embedded in our CLI you can just halt the build in test phase and run tests and tune them as you like: >> surefire.run(MyTest.class) ... >> surefire.exit() You can just change the test or main code, recompile in IDEA and you do not need to trigger the buid again because you are still in the JavaScript console. So run the TDD round again: >> surefire.run(MyTest.class) WDYT ? Cheers Tibor On Mon, Nov 30, 2015 at 10:18 PM, Stephen Connolly < [email protected]> wrote: > Picking up from > > http://mail-archives.apache.org/mod_mbox/maven-dev/201511.mbox/%3CCA%2BnPnMyjogmqRweYbxLuULLB9ve2P6MPcQuH%2BPkxcNn-oN4GPg%40mail.gmail.com%3E > (and my follow up to that but archive.apache.org is being a tad slow) > > Here is our policy: > > The development line of Maven core should require a minimum JRE version > > that is no older than 18 months after the end of Oracle's public updates > > for that JRE version at the time that the first version of the > development > > line was released, but may require a higher minimum JRE version if other > > requirements dictate a higher JRE version > > > (Source: > https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy) > > OK, so it's a draft policy... but we've all been silent on the draft, so > lazy consensus! > > Now in http://www.oracle.com/technetwork/java/javase/eol-135779.html they > state: > > after April 2015, Oracle will not post further updates of Java SE 7 to its > > public download sites > > > So per our (draft) version number policy, we can keep Java 7 as the > baseline :-( or we can choose to upgrade code to Java 8 (because we want to > use lambdas... there's a requirement) > > > So assuming we bump the master branch of Maven core to 3.4.0, what Java > version do we want to use as the baseline? > > There are thankfully only two options: > > Java 7 > + Not actually changing things > + May make it easier to drive adoption > - Still can't use newer language features in core > - Java 7 is EOL and it may get harder for developers to source JDKs to > test and develop against > > Java 8 > + We're not as old hat any more > + We can use lambdas > + We can use Nashorn (may make integrating with Node easier... certainly > could make integrating with JavaScript tooling easier) > + EOL for Java 8 is at least Sep 2017 (and may be later) > - May be harder to drive adoption in shops that have issues upgrading > Java (but toolchains and they likely wouldn't upgrade to 3.4.x anyway > unless there are features dragging their change controlled heels over the > line) > > So... > > Let's have a heated debate! > > -Stephen > > P.S. > > I'm waiting for Chris to chime in about how IBM is still supporting Java > 1.3 or something like that ;-) > -- Cheers Tibor
