On Wed, Nov 12, 2008 at 8:03 PM, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> Robert Burrell Donkin wrote:
>
>> OSGi is fine for containing coursely grained services but avoiding
>> spring for configuration and assembly of these services is going to
>> make a *lot* of work.
>
> OSGi is about assemb
Robert Burrell Donkin wrote:
> OSGi is fine for containing coursely grained services but avoiding
> spring for configuration and assembly of these services is going to
> make a *lot* of work.
OSGi is about assembly. What do you have in mind for Spring? And
configuration can be pretty nicely han
On Nov 10, 2008, at 1:23 PM, Noel J. Bergman wrote:
Norman Maurer asked:
Why we would need java 6 ? Which feature you miss in java 5 ?
JSR-223, for one. Yes, we could backport using BSF, but deployment
would be
easier if we went with Java 6.
Also, "little features include SSLParameters
On Mon, Nov 10, 2008 at 9:23 PM, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> Norman Maurer asked:
>> What's wrong with spring ?
>
> Non-standard and unnecessary. OSGi is the standard.
OSGi is fine for containing coursely grained services but avoiding
spring for configuration and assembly of t
Norman Maurer asked:
> Why we would need java 6 ? Which feature you miss in java 5 ?
JSR-223, for one. Yes, we could backport using BSF, but deployment would be
easier if we went with Java 6.
Also, "little features include SSLParameters class that encapsulates the
configuration of SSL connectio
On Mon, Nov 10, 2008 at 8:05 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Noel J. Bergman ha scritto:
>>> i quite fancy experimenting with some stuff (for example OpenJPA) that
>>> requires java 5.
>>
>> I want to see annotations, myself. And favor a move to Java 6, as long as
>> we are making
Noel J. Bergman ha scritto:
>> i quite fancy experimenting with some stuff (for example OpenJPA) that
>> requires java 5.
>
> I want to see annotations, myself. And favor a move to Java 6, as long as
> we are making the big switch.
>
>> following long term strategy: we use the same module system
On Mon, Nov 10, 2008 at 21:01, Robert Burrell Donkin
<[EMAIL PROTECTED]> wrote:
> On Mon, Nov 10, 2008 at 7:54 PM, Norman Maurer <[EMAIL PROTECTED]> wrote:
>> 2008/11/10 Noel J. Bergman <[EMAIL PROTECTED]>
>
>>> > following long term strategy: we use the same module system but ship
>>> > the phoeni
On Mon, Nov 10, 2008 at 19:58, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
>> i quite fancy experimenting with some stuff (for example OpenJPA) that
>> requires java 5.
>
> I want to see annotations, myself. And favor a move to Java 6, as long as
> we are making the big switch.
-1 to Java6 ATM. It
On Mon, Nov 10, 2008 at 7:54 PM, Norman Maurer <[EMAIL PROTECTED]> wrote:
> 2008/11/10 Noel J. Bergman <[EMAIL PROTECTED]>
>> > following long term strategy: we use the same module system but ship
>> > the phoenix built under 1.4 (without new features) and spring built
>> > under 1.5 (with the new
2008/11/10 Noel J. Bergman <[EMAIL PROTECTED]>
> > i quite fancy experimenting with some stuff (for example OpenJPA) that
> > requires java 5.
>
> I want to see annotations, myself. And favor a move to Java 6, as long as
> we are making the big switch.
Why we would need java 6 ? Which feature y
On Mon, Nov 10, 2008 at 6:58 PM, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
>> following long term strategy: we use the same module system but ship
>> the phoenix built under 1.4 (without new features) and spring built
>> under 1.5 (with the new features).
>
> -1 to Spring. +1 for OSGi.
i don'
> i quite fancy experimenting with some stuff (for example OpenJPA) that
> requires java 5.
I want to see annotations, myself. And favor a move to Java 6, as long as
we are making the big switch.
> following long term strategy: we use the same module system but ship
> the phoenix built under 1.4
On Mon, Nov 3, 2008 at 10:04 AM, Danny Angus <[EMAIL PROTECTED]> wrote:
> I agree with Norman, we should possibly poll the users/dev lists but I
> can't believe that 1.4 is still a requirement.
we've POLLed the user list and everyone says 1.5 :-)
perhaps we should find somewhere to record this on
I agree with Norman, we should possibly poll the users/dev lists but I
can't believe that 1.4 is still a requirement.
d.
On Sun, Nov 2, 2008 at 11:42 AM, Norman Maurer <[EMAIL PROTECTED]> wrote:
> Hi Robert,
>
> I'm very limited in free time atm. So I think the descision should be made
> by the a
On Sun, Nov 2, 2008 at 9:11 PM, Bernd Fondermann
<[EMAIL PROTECTED]> wrote:
> On Sun, Nov 2, 2008 at 12:43, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>> Robert Burrell Donkin ha scritto:
>>> i'm increasingly convinced that the 3.0 codebase contains some
>>> compelling reasons to upgrade. i think i
On Sun, Nov 2, 2008 at 12:43, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Robert Burrell Donkin ha scritto:
>> i'm increasingly convinced that the 3.0 codebase contains some
>> compelling reasons to upgrade. i think it's important to offer an
>> upgrade path for existing installations including re
Robert Burrell Donkin ha scritto:
> i'm increasingly convinced that the 3.0 codebase contains some
> compelling reasons to upgrade. i think it's important to offer an
> upgrade path for existing installations including retaining 1.4 JVM
> support. this means preserving 1.4 compatibility in the API
Hi Robert,
I'm very limited in free time atm. So I think the descision should be made
by the active developers. Anyway I think we should drop java 1.4 support at
all. I see no real reason to support such old / outdated jvm.
Cheers,
Norman
2008/11/2 Robert Burrell Donkin <[EMAIL PROTECTED]>
> i
i'm increasingly convinced that the 3.0 codebase contains some
compelling reasons to upgrade. i think it's important to offer an
upgrade path for existing installations including retaining 1.4 JVM
support. this means preserving 1.4 compatibility in the API and
library layers and in any functions th
20 matches
Mail list logo