[jira] [Created] (DELTASPIKE-1101) Support aggregate functions

Daniel Cunha created DELTASPIKE-1101: Summary: Support aggregate functions Key: DELTASPIKE-1101 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1101 Project: DeltaSpike Issue Type:

[jira] [Created] (DELTASPIKE-1102) Support TOP and FIRST

Daniel Cunha created DELTASPIKE-1102: Summary: Support TOP and FIRST Key: DELTASPIKE-1102 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1102 Project: DeltaSpike Issue Type:

[jira] [Resolved] (DELTASPIKE-1100) Support remove expressions

[ https://issues.apache.org/jira/browse/DELTASPIKE-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Cunha resolved DELTASPIKE-1100. -- Resolution: Fixed > Support remove expressions > -- > >

[jira] [Created] (DELTASPIKE-1100) Support remove expressions

Daniel Cunha created DELTASPIKE-1100: Summary: Support remove expressions Key: DELTASPIKE-1100 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1100 Project: DeltaSpike Issue Type:

Re: Java EE 6 support

Think the question is: we'll we add any feature EE 6 users will start working with? If yes we should stick to it, if not then just target EE 7 and move EE 6 in a maintenance branch. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2016-03-25 15:44 GMT+01:00 John D. Ament

Re: Java EE 6 support

-1 for dropping Java EE 6, we still have Java EE 6 users. Also, as gerhard said, we don't gain much benefit from dropping it. What about moving forward to DS 2.0 with Java EE 8 and Java SE 8 after the release of Java EE 8? 2016-03-25 15:44 GMT+01:00 John D. Ament : >

Re: Java EE 6 support

IMHO we should target a major version change if we're going to drop EE 6. There's still some benefits to having EE 6, but they should start to die down. Maybe DeltaSpike 2.0 is EE 7 +? John On Fri, Mar 25, 2016 at 9:07 AM Christian Kaltepoth wrote: > I also think that

Re: Java EE 6 support

I also think that we should keep to support Java EE 6 for some time. But +1 for dropping Java SE 6 support 2016-03-25 14:00 GMT+01:00 Rudy De Busscher : > All, > > Most of my clients still work with Java EE 6 (on Java SE 7), so I think it > is too early to abandon that

Re: Java EE 6 support

All, Most of my clients still work with Java EE 6 (on Java SE 7), so I think it is too early to abandon that version. +1 for setting compile version to SE 7. Regards Rudy On 25 March 2016 at 13:48, Gerhard Petracek wrote: > hi @ all, > > imo the benefit is too limited.

Re: Java EE 6 support

hi @ all, imo the benefit is too limited. cdi 1.1 added some nice parts, but mainly for users. we would just drop the bv-module as well as some parts of the servlet module. the jsf-module already contains optional ee7 support (-> we would just get rid of one small workaround). for the rest the

Re: Java EE 6 support

Se 8 is surely too early (~1 year I think). +1 to drop ee6 from master. Le 25 mars 2016 13:27, "Harald Wellmann" a écrit : > Since John raised the question about Java SE 6 support, what about Java EE > 6? > > Dropping support for Java EE 6/CDI 1.0 would simplify the code

Java EE 6 support

Since John raised the question about Java SE 6 support, what about Java EE 6? Dropping support for Java EE 6/CDI 1.0 would simplify the code base significantly (a lot more so than moving from Java 1.6 to Java 1.7). How about starting a new release line DeltaSpike 2.x targeting Java EE 7+

Re: 1.6 to be the last release to support Java 1.6?

+1 2016-03-25 13:09 GMT+01:00 John D. Ament : > BTW, if we do agree to drop Java 6, do we create a 1.6 maintenance branch > or just leave the tag, and if need be cut a bug fix release then? > > John > > On Fri, Mar 25, 2016 at 8:06 AM John D. Ament

Re: 1.6 to be the last release to support Java 1.6?

BTW, if we do agree to drop Java 6, do we create a 1.6 maintenance branch or just leave the tag, and if need be cut a bug fix release then? John On Fri, Mar 25, 2016 at 8:06 AM John D. Ament wrote: > To me, dropping support for Java 6 doesn't mean rewriting the code base

Re: 1.6 to be the last release to support Java 1.6?

To me, dropping support for Java 6 doesn't mean rewriting the code base to only be compliant with Java 7 and up. It does allow for some new stuff in our codebase, if we want to go back and clean it up: - try-with-resources - automatic type inference on generics. But those are just clean ups, no

Re: Donating Microscoped code

Actually, the map functions aren't the problem. Those were easy to cut over. The problem is the new ThreadLocal behavior in Java 8 that just doesn't have an equivalent in older JDKs. I think I'm almost done, will raise a PR to prep it for inclusion. I do not envy the road warriors, mind you.

Re: 1.6 to be the last release to support Java 1.6?

+0 j6 is EOL so shouldn't really be used anymore and didnt use it since months but excepted multi catch feature j7 will not help us a lot I think - that's for dev side. For CI side I think it can make sense to get rid of the j6 constraint but I don't know if that's really a constraint for us.

Re: 1.6 to be the last release to support Java 1.6?

i agree with thomas regards, gerhard 2016-03-25 9:23 GMT+01:00 Thomas Andraschko : > basically +1 > Most of our customers are using 1.7 since this year. > > I just wonder whats the benefit for us? > I think there are no language features which would improve our

Re: 1.6 to be the last release to support Java 1.6?

basically +1 Most of our customers are using 1.7 since this year. I just wonder whats the benefit for us? I think there are no language features which would improve our code base. 2016-03-25 3:25 GMT+01:00 John D. Ament : > Hey guys, > > I've brought this topic up before