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

[Daniel Cunha (JIRA)]

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: Sub-task
  Components: Data-Module
Reporter: Daniel Cunha
Assignee: Daniel Cunha






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[Daniel Cunha (JIRA)]

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: Sub-task
  Components: Data-Module
Reporter: Daniel Cunha
Assignee: Daniel Cunha






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[Daniel Cunha (JIRA)]

 [ 
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
> --
>
> Key: DELTASPIKE-1100
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1100
> Project: DeltaSpike
>  Issue Type: Sub-task
>  Components: Data-Module
>Reporter: Daniel Cunha
>Assignee: Daniel Cunha
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[Daniel Cunha (JIRA)]

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: Sub-task
  Components: Data-Module
Reporter: Daniel Cunha
Assignee: Daniel Cunha






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Java EE 6 support

[Romain Manni-Bucau]

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 :
> 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 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 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.
>> > > 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 benefit is minimal as well (or there won't be a change
>> > at
>> > > all).
>> > > ee7 is great for users and therefore we support it already, however,
>> > > internally the benefit is too limited and ee6 servers will be around
>> the
>> > > next few years.
>> > >
>> > > -> imo v2 should be based on cdi 2.0 (-> ee8).
>> > >
>> > > regards,
>> > > gerhard
>> > >
>> > >
>> > >
>> > > 2016-03-25 13:29 GMT+01:00 Romain Manni-Bucau :
>> > >
>> > > > 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 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+
>> > > > > and Java SE 8+, with continued support for Java EE 6 on the 1.x
>> > branch
>> > > > for
>> > > > > as long as people are willing to work on backward compatibility?
>> > > > >
>> > > > > Regards,
>> > > > > Harald
>> > > > >
>> > > >
>> > >
>> >
>>
>>
>>
>> --
>> Christian Kaltepoth
>> Blog: http://blog.kaltepoth.de/
>> Twitter: http://twitter.com/chkal
>> GitHub: https://github.com/chkal
>>

Re: Java EE 6 support

[Thomas Andraschko]

-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 :

> 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 <
> christ...@kaltepoth.de>
> wrote:
>
> > 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 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.
> > > > 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 benefit is minimal as well (or there won't be a
> change
> > > at
> > > > all).
> > > > ee7 is great for users and therefore we support it already, however,
> > > > internally the benefit is too limited and ee6 servers will be around
> > the
> > > > next few years.
> > > >
> > > > -> imo v2 should be based on cdi 2.0 (-> ee8).
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > >
> > > >
> > > > 2016-03-25 13:29 GMT+01:00 Romain Manni-Bucau  >:
> > > >
> > > > > 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
> 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+
> > > > > > and Java SE 8+, with continued support for Java EE 6 on the 1.x
> > > branch
> > > > > for
> > > > > > as long as people are willing to work on backward compatibility?
> > > > > >
> > > > > > Regards,
> > > > > > Harald
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Christian Kaltepoth
> > Blog: http://blog.kaltepoth.de/
> > Twitter: http://twitter.com/chkal
> > GitHub: https://github.com/chkal
> >
>

Re: Java EE 6 support

[John D. Ament]

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 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 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.
> > > 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 benefit is minimal as well (or there won't be a change
> > at
> > > all).
> > > ee7 is great for users and therefore we support it already, however,
> > > internally the benefit is too limited and ee6 servers will be around
> the
> > > next few years.
> > >
> > > -> imo v2 should be based on cdi 2.0 (-> ee8).
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2016-03-25 13:29 GMT+01:00 Romain Manni-Bucau :
> > >
> > > > 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 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+
> > > > > and Java SE 8+, with continued support for Java EE 6 on the 1.x
> > branch
> > > > for
> > > > > as long as people are willing to work on backward compatibility?
> > > > >
> > > > > Regards,
> > > > > Harald
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Christian Kaltepoth
> Blog: http://blog.kaltepoth.de/
> Twitter: http://twitter.com/chkal
> GitHub: https://github.com/chkal
>

Re: Java EE 6 support

[Christian Kaltepoth]

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 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.
> > 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 benefit is minimal as well (or there won't be a change
> at
> > all).
> > ee7 is great for users and therefore we support it already, however,
> > internally the benefit is too limited and ee6 servers will be around the
> > next few years.
> >
> > -> imo v2 should be based on cdi 2.0 (-> ee8).
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2016-03-25 13:29 GMT+01:00 Romain Manni-Bucau :
> >
> > > 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 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+
> > > > and Java SE 8+, with continued support for Java EE 6 on the 1.x
> branch
> > > for
> > > > as long as people are willing to work on backward compatibility?
> > > >
> > > > Regards,
> > > > Harald
> > > >
> > >
> >
>



-- 
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal

Re: Java EE 6 support

[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 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.
> 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 benefit is minimal as well (or there won't be a change at
> all).
> ee7 is great for users and therefore we support it already, however,
> internally the benefit is too limited and ee6 servers will be around the
> next few years.
>
> -> imo v2 should be based on cdi 2.0 (-> ee8).
>
> regards,
> gerhard
>
>
>
> 2016-03-25 13:29 GMT+01:00 Romain Manni-Bucau :
>
> > 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 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+
> > > and Java SE 8+, with continued support for Java EE 6 on the 1.x branch
> > for
> > > as long as people are willing to work on backward compatibility?
> > >
> > > Regards,
> > > Harald
> > >
> >
>

Re: Java EE 6 support

[Gerhard Petracek]

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 benefit is minimal as well (or there won't be a change at
all).
ee7 is great for users and therefore we support it already, however,
internally the benefit is too limited and ee6 servers will be around the
next few years.

-> imo v2 should be based on cdi 2.0 (-> ee8).

regards,
gerhard



2016-03-25 13:29 GMT+01:00 Romain Manni-Bucau :

> 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 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+
> > and Java SE 8+, with continued support for Java EE 6 on the 1.x branch
> for
> > as long as people are willing to work on backward compatibility?
> >
> > Regards,
> > Harald
> >
>

Re: Java EE 6 support

[Romain Manni-Bucau]

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 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+
> and Java SE 8+, with continued support for Java EE 6 on the 1.x branch for
> as long as people are willing to work on backward compatibility?
>
> Regards,
> Harald
>

Java EE 6 support

[Harald Wellmann]

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+ and Java SE 8+, with continued support for Java EE 6 on the 1.x 
branch for as long as people are willing to work on backward compatibility?


Regards,
Harald

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

[Harald Wellmann]

+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 
> wrote:
>
> > 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 real new functionality.
> >
> > John
> >
> >
> > On Fri, Mar 25, 2016 at 4:24 AM Thomas Andraschko <
> > andraschko.tho...@gmail.com> wrote:
> >
> >> 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 without much positive response.  I
> >> figure
> >> > I'll bring it up again.
> >> >
> >> > I'd like to propose that DeltaSpike 1.6 be the last minor release to
> >> > support Java 1.6.  I suspect that most users are already using Java 7
> or
> >> > higher.  None of our builds in CI (builds.apache.org) currently run
> on
> >> 1.6
> >> > either, so while we can say from a syntax standpoint we're 1.6
> compliant
> >> > I'm not sure we can say from a JDK Library standpoint we don't rely on
> >> > anything from Java 7.
> >> >
> >> > We're one of the few projects that probably still supports Java 6 as a
> >> > mainline development, so I was hoping we could just cut 1.6 as 1.6
> >> > compliant, if we need to cut patch releases of 1.6 to apply patches,
> but
> >> > with DeltaSpike 1.7 and on, focus on Java 7 and up.
> >> >
> >> > John
> >> >
> >>
> >
>

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

[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  wrote:

> 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 real new functionality.
>
> John
>
>
> On Fri, Mar 25, 2016 at 4:24 AM Thomas Andraschko <
> andraschko.tho...@gmail.com> wrote:
>
>> 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 without much positive response.  I
>> figure
>> > I'll bring it up again.
>> >
>> > I'd like to propose that DeltaSpike 1.6 be the last minor release to
>> > support Java 1.6.  I suspect that most users are already using Java 7 or
>> > higher.  None of our builds in CI (builds.apache.org) currently run on
>> 1.6
>> > either, so while we can say from a syntax standpoint we're 1.6 compliant
>> > I'm not sure we can say from a JDK Library standpoint we don't rely on
>> > anything from Java 7.
>> >
>> > We're one of the few projects that probably still supports Java 6 as a
>> > mainline development, so I was hoping we could just cut 1.6 as 1.6
>> > compliant, if we need to cut patch releases of 1.6 to apply patches, but
>> > with DeltaSpike 1.7 and on, focus on Java 7 and up.
>> >
>> > John
>> >
>>
>

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

[John D. Ament]

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 real new functionality.

John

On Fri, Mar 25, 2016 at 4:24 AM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> 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 without much positive response.  I
> figure
> > I'll bring it up again.
> >
> > I'd like to propose that DeltaSpike 1.6 be the last minor release to
> > support Java 1.6.  I suspect that most users are already using Java 7 or
> > higher.  None of our builds in CI (builds.apache.org) currently run on
> 1.6
> > either, so while we can say from a syntax standpoint we're 1.6 compliant
> > I'm not sure we can say from a JDK Library standpoint we don't rely on
> > anything from Java 7.
> >
> > We're one of the few projects that probably still supports Java 6 as a
> > mainline development, so I was hoping we could just cut 1.6 as 1.6
> > compliant, if we need to cut patch releases of 1.6 to apply patches, but
> > with DeltaSpike 1.7 and on, focus on Java 7 and up.
> >
> > John
> >
>

Re: Donating Microscoped code

[John D. Ament]

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.

John

On Thu, Mar 24, 2016 at 11:05 PM David Blevins 
wrote:

> The code is significantly harder without the Java 8 computeIfAbsent on
> hashmap.
>
> In terms of time, I wish I had more to give.  I was on the road 49 out of
> 52 weeks last year and this year is no different.
>
> I've pretty much sacrificed every bit of time and work-life balance
> possible in hopes to produce more for others.  It's a work in progress
>
>
> -David
>
>
> On Thu, Mar 24, 2016 at 6:47 PM, John D. Ament 
> wrote:
>
> > I don't mind looking at it a bit further.  You're the only contributor
> and
> > you're a long standing ASF guy.  Of course one big issue is that you're
> > using a modern, supported JVM version.  We're still on the archaic 1.6
> JDK.
> >
> > One thing to point out, your license is already assigning ownership to
> the
> > ASF -
> >
> >
> https://github.com/tomitribe/microscoped/blob/master/microscoped-timer/pom.xml#L3
> > not
> > sure if that's intentional or not.
> >
> > Here's a reference to what it looks like when its not licensed to the
> ASF.
> > https://github.com/johnament/hammock/blob/master/pom.xml#L1
> >
> > The big difference - licensed under vs licensed to.
> >
> > John
> >
> > On Thu, Mar 24, 2016 at 9:39 PM David Blevins 
> > wrote:
> >
> > > John had asked on twitter if this code could be donated.  Absolutely.
> > >
> > > https://tomitribe.io/projects/microscoped <
> > > https://tomitribe.io/projects/microscoped>
> > >
> > > I feel bad writing a “come and get it” email.  90% of the code was
> > written
> > > between 12am and 5am the night before the related JavaOne talk. Not by
> > > choice. :)
> > >
> > > Is there anyone with time to help?
> > >
> > >
> > > --
> > > David Blevins
> > > http://twitter.com/dblevins
> > > http://www.tomitribe.com
> > >
> > >
> >
>

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

[Romain Manni-Bucau]

+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.

Romain Manni-Bucau
@rmannibucau |  Blog | Github | LinkedIn | Tomitriber


2016-03-25 9:35 GMT+01:00 Gerhard Petracek :
> 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 code base.
>>
>> 2016-03-25 3:25 GMT+01:00 John D. Ament :
>>
>> > Hey guys,
>> >
>> > I've brought this topic up before without much positive response.  I
>> figure
>> > I'll bring it up again.
>> >
>> > I'd like to propose that DeltaSpike 1.6 be the last minor release to
>> > support Java 1.6.  I suspect that most users are already using Java 7 or
>> > higher.  None of our builds in CI (builds.apache.org) currently run on
>> 1.6
>> > either, so while we can say from a syntax standpoint we're 1.6 compliant
>> > I'm not sure we can say from a JDK Library standpoint we don't rely on
>> > anything from Java 7.
>> >
>> > We're one of the few projects that probably still supports Java 6 as a
>> > mainline development, so I was hoping we could just cut 1.6 as 1.6
>> > compliant, if we need to cut patch releases of 1.6 to apply patches, but
>> > with DeltaSpike 1.7 and on, focus on Java 7 and up.
>> >
>> > John
>> >
>>

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

[Gerhard Petracek]

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 code base.
>
> 2016-03-25 3:25 GMT+01:00 John D. Ament :
>
> > Hey guys,
> >
> > I've brought this topic up before without much positive response.  I
> figure
> > I'll bring it up again.
> >
> > I'd like to propose that DeltaSpike 1.6 be the last minor release to
> > support Java 1.6.  I suspect that most users are already using Java 7 or
> > higher.  None of our builds in CI (builds.apache.org) currently run on
> 1.6
> > either, so while we can say from a syntax standpoint we're 1.6 compliant
> > I'm not sure we can say from a JDK Library standpoint we don't rely on
> > anything from Java 7.
> >
> > We're one of the few projects that probably still supports Java 6 as a
> > mainline development, so I was hoping we could just cut 1.6 as 1.6
> > compliant, if we need to cut patch releases of 1.6 to apply patches, but
> > with DeltaSpike 1.7 and on, focus on Java 7 and up.
> >
> > John
> >
>

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

[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 code base.

2016-03-25 3:25 GMT+01:00 John D. Ament :

> Hey guys,
>
> I've brought this topic up before without much positive response.  I figure
> I'll bring it up again.
>
> I'd like to propose that DeltaSpike 1.6 be the last minor release to
> support Java 1.6.  I suspect that most users are already using Java 7 or
> higher.  None of our builds in CI (builds.apache.org) currently run on 1.6
> either, so while we can say from a syntax standpoint we're 1.6 compliant
> I'm not sure we can say from a JDK Library standpoint we don't rely on
> anything from Java 7.
>
> We're one of the few projects that probably still supports Java 6 as a
> mainline development, so I was hoping we could just cut 1.6 as 1.6
> compliant, if we need to cut patch releases of 1.6 to apply patches, but
> with DeltaSpike 1.7 and on, focus on Java 7 and up.
>
> John
>