Spring

[Steve-262]

Hi, how are you doing?

I was wondering what you guys thought of the "New Spring maintenance policy"?

http://www.theserverside.com/news/thread.tss?thread_id=50727

What impact (if any) will this have on Grails?

I brought this very point up to Guillaume after one of his sessions at Java One and he said "he wasn't concerned".  Does this still hold true?

Just curious...

Thanks,

-Steve

[Graeme Rocher-2]

We have a good relationship with the guys at SpringSource and don't
have any immediate concerns no. I think there is a slight overreaction
to the policy in that thread

Cheers

On Mon, Sep 22, 2008 at 3:44 PM, Steve <sel162@...> wrote:

> Hi, how are you doing?
> I was wondering what you guys thought of the "New Spring maintenance
> policy"?
> http://www.theserverside.com/news/thread.tss?thread_id=50727
> What impact (if any) will this have on Grails?
> I brought this very point up to Guillaume after one of his sessions at Java
> One and he said "he wasn't concerned".  Does this still hold true?
> Just curious...
> Thanks,
> -Steve
>
>

--
Graeme Rocher
Grails Project Lead
G2One, Inc. Chief Technology Officer
http://www.g2one.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Erik Pragt]

Graeme Rocher-2 wrote:

We have a good relationship with the guys at SpringSource and don't
have any immediate concerns no. I think there is a slight overreaction
to the policy in that thread

Sorry Graeme, but I think your taking things a bit to lightly here.

This change in policy is a huge risk for any Spring related project, but also for any project which relies on Spring. I don't think that having 'a good relationship' will result in: Instead of charging $25.000 for it, we give it for free. If that was the case, people would just download Grails to get the latest Spring version from it.

Since I think the future of Spring as a framework (especially with the new money focusses approach) is a bit uncertain, I also fear a little bit for Grails, since it so strongly depends on Spring. I'm not about to start a panic here, but I think I need to be a little be more convinced about the future of Grails + Spring before I'm at not concerned about the future of Grails anymore.

So: any idea on how this relationship could help Grails?

Erik

PS: This is not theoretical at all: Grails Remoting needs Spring 2.5.5. Whith this policy in effect, Spring 2.5.5 would never have been released to the public, I wouldn't have been able to use Grails in combination with Grails Remoting, and I would have to find a different solution. Just some context for my worries.

[tomasz brymora]

... DZone had this piece just recently as a response to the situation:
http://java.dzone.com/news/qa-with-rod-johnson-over-sprin
It seems to make a bit more sense now imho.

--- On Fri, 9/26/08, Erik Pragt <erik@...> wrote:

> From: Erik Pragt <erik@...>
> Subject: Re: [grails-user] Spring
> To: user@...
> Date: Friday, September 26, 2008, 8:43 AM
> Graeme Rocher-2 wrote:
> >
> > We have a good relationship with the guys at
> SpringSource and don't
> > have any immediate concerns no. I think there is a
> slight overreaction
> > to the policy in that thread
> >
>
> Sorry Graeme, but I think your taking things a bit to
> lightly here.
>
> This change in policy is a huge risk for any Spring related
> project, but
> also for any project which relies on Spring. I don't
> think that having 'a
> good relationship' will result in: Instead of charging
> $25.000 for it, we
> give it for free. If that was the case, people would just
> download Grails to
> get the latest Spring version from it.
>
> Since I think the future of Spring as a framework
> (especially with the new
> money focusses approach) is a bit uncertain, I also fear a
> little bit for
> Grails, since it so strongly depends on Spring. I'm not
> about to start a
> panic here, but I think I need to be a little be more
> convinced about the
> future of Grails + Spring before I'm at not concerned
> about the future of
> Grails anymore.
>
> So: any idea on how this relationship could help Grails?
>
> Erik
>
> PS: This is not theoretical at all: Grails Remoting needs
> Spring 2.5.5.
> Whith this policy in effect, Spring 2.5.5 would never have
> been released to
> the public, I wouldn't have been able to use Grails in
> combination with
> Grails Remoting, and I would have to find a different
> solution. Just some
> context for my worries.
> --
> View this message in context:
> http://www.nabble.com/Spring-tp19609427p19687736.html
> Sent from the grails - user mailing list archive at
> Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Tom Nichols]

Ok, say 2.5.5 is the last community maintenance release before Spring
v3.  Now assume there is some code in Spring's trunk or 2.5.x branch
that Grails needs.  They will just bundle a non-official build of
Spring.

Here's what they (or someone) can do --
After the 3 month window, just do "unofficial builds" every x months
or whenever certain bugs are fixed.  Then release them to Maven as a
sort of "unofficial official" community build.  Someone could easily
provide maintenance builds without forking the code.  Would they be
able to support it?  Not really -- at least I wouldn't want to.  But
at least when the community is discussing issues with Spring they can
say "I'm running community build 2.5.17" and everyone will be on the
same page.  Doesn't that make sense? No forking, just a semi-official,
non-SpringSource community build repository.  Done.



On Fri, Sep 26, 2008 at 1:21 PM, tomasz brymora <tomekpilot@...> wrote:

> ... DZone had this piece just recently as a response to the situation:
> http://java.dzone.com/news/qa-with-rod-johnson-over-sprin
> It seems to make a bit more sense now imho.
>
> --- On Fri, 9/26/08, Erik Pragt <erik@...> wrote:
>
>> From: Erik Pragt <erik@...>
>> Subject: Re: [grails-user] Spring
>> To: user@...
>> Date: Friday, September 26, 2008, 8:43 AM
>> Graeme Rocher-2 wrote:
>> >
>> > We have a good relationship with the guys at
>> SpringSource and don't
>> > have any immediate concerns no. I think there is a
>> slight overreaction
>> > to the policy in that thread
>> >
>>
>> Sorry Graeme, but I think your taking things a bit to
>> lightly here.
>>
>> This change in policy is a huge risk for any Spring related
>> project, but
>> also for any project which relies on Spring. I don't
>> think that having 'a
>> good relationship' will result in: Instead of charging
>> $25.000 for it, we
>> give it for free. If that was the case, people would just
>> download Grails to
>> get the latest Spring version from it.
>>
>> Since I think the future of Spring as a framework
>> (especially with the new
>> money focusses approach) is a bit uncertain, I also fear a
>> little bit for
>> Grails, since it so strongly depends on Spring. I'm not
>> about to start a
>> panic here, but I think I need to be a little be more
>> convinced about the
>> future of Grails + Spring before I'm at not concerned
>> about the future of
>> Grails anymore.
>>
>> So: any idea on how this relationship could help Grails?
>>
>> Erik
>>
>> PS: This is not theoretical at all: Grails Remoting needs
>> Spring 2.5.5.
>> Whith this policy in effect, Spring 2.5.5 would never have
>> been released to
>> the public, I wouldn't have been able to use Grails in
>> combination with
>> Grails Remoting, and I would have to find a different
>> solution. Just some
>> context for my worries.
>> --
>> View this message in context:
>> http://www.nabble.com/Spring-tp19609427p19687736.html
>> Sent from the grails - user mailing list archive at
>> Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Marcel Overdijk]

I agree with Erik that this policy change should not be underestimated.

I think a lot of people (including myself) are trying to bring Grails under the attention of their managers and/or are starting their first commercial projects with Grails.

But now with Spring's change in policy people will be more careful and think twice. Also for management the risk to need expensive subscriptions could be a blocker in this. Especially for small to medium (startup) projects.


Cheers,
Marcel

Erik Pragt wrote:

Graeme Rocher-2 wrote:

We have a good relationship with the guys at SpringSource and don't
have any immediate concerns no. I think there is a slight overreaction
to the policy in that thread

Sorry Graeme, but I think your taking things a bit to lightly here.

This change in policy is a huge risk for any Spring related project, but also for any project which relies on Spring. I don't think that having 'a good relationship' will result in: Instead of charging $25.000 for it, we give it for free. If that was the case, people would just download Grails to get the latest Spring version from it.

Since I think the future of Spring as a framework (especially with the new money focusses approach) is a bit uncertain, I also fear a little bit for Grails, since it so strongly depends on Spring. I'm not about to start a panic here, but I think I need to be a little be more convinced about the future of Grails + Spring before I'm at not concerned about the future of Grails anymore.

So: any idea on how this relationship could help Grails?

Erik

PS: This is not theoretical at all: Grails Remoting needs Spring 2.5.5. Whith this policy in effect, Spring 2.5.5 would never have been released to the public, I wouldn't have been able to use Grails in combination with Grails Remoting, and I would have to find a different solution. Just some context for my worries.

[Robert Fischer]

Uh, why do you need expensive subscriptions?

Keep up-to-date on your Spring installs (which will happen automatically as you keep up with Grails)
and you're fine.

The biggest issue for management is that there is industry-wide FUD being spouted.

~~ Robert.

Marcel Overdijk wrote:

> I agree with Erik that this policy change should not be underestimated.
>
> I think a lot of people (including myself) are trying to bring Grails under
> the attention of their managers and/or are starting their first commercial
> projects with Grails.
>
> But now with Spring's change in policy people will be more careful and think
> twice. Also for management the risk to need expensive subscriptions could be
> a blocker in this. Especially for small to medium (startup) projects.
>
>
> Cheers,
> Marcel
>
>
>
>
>
> Erik Pragt wrote:
>>
>>
>> Graeme Rocher-2 wrote:
>>> We have a good relationship with the guys at SpringSource and don't
>>> have any immediate concerns no. I think there is a slight overreaction
>>> to the policy in that thread
>>>
>> Sorry Graeme, but I think your taking things a bit to lightly here.
>>
>> This change in policy is a huge risk for any Spring related project, but
>> also for any project which relies on Spring. I don't think that having 'a
>> good relationship' will result in: Instead of charging $25.000 for it, we
>> give it for free. If that was the case, people would just download Grails
>> to get the latest Spring version from it.
>>
>> Since I think the future of Spring as a framework (especially with the new
>> money focusses approach) is a bit uncertain, I also fear a little bit for
>> Grails, since it so strongly depends on Spring. I'm not about to start a
>> panic here, but I think I need to be a little be more convinced about the
>> future of Grails + Spring before I'm at not concerned about the future of
>> Grails anymore.
>>
>> So: any idea on how this relationship could help Grails?
>>
>> Erik
>>
>> PS: This is not theoretical at all: Grails Remoting needs Spring 2.5.5.
>> Whith this policy in effect, Spring 2.5.5 would never have been released
>> to the public, I wouldn't have been able to use Grails in combination with
>> Grails Remoting, and I would have to find a different solution. Just some
>> context for my worries.
>>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Graeme Rocher-2]

Firstly, many people who adopt Grails don't even know they have
Spring. Grails is an abstraction layer over Spring. In other words
people, in my experience, don't consider upgrading the Spring jar
distributed with Grails, they think in terms of upgrading Grails not
upgrading Spring.

Its more an issue for us, the Grails developers, to make sure that we
are prompt with upgrading to the latest version of Spring after a
release. And to ensure any issues are reported. It may also be that
Grails releases become more aligned with Spring releases. And during
development we can always build a distribution of Spring from the
sources

The code in the Spring repo will be the latest code. Obviously some
feel its an issue, I  personally think that it will be less of an
issue than is made out to be.

Cheers

On Fri, Sep 26, 2008 at 4:34 PM, Marcel Overdijk
<marceloverdijk@...> wrote:

>
> I agree with Erik that this policy change should not be underestimated.
>
> I think a lot of people (including myself) are trying to bring Grails under
> the attention of their managers and/or are starting their first commercial
> projects with Grails.
>
> But now with Spring's change in policy people will be more careful and think
> twice. Also for management the risk to need expensive subscriptions could be
> a blocker in this. Especially for small to medium (startup) projects.
>
>
> Cheers,
> Marcel
>
>
>
>
>
> Erik Pragt wrote:
>>
>>
>>
>> Graeme Rocher-2 wrote:
>>>
>>> We have a good relationship with the guys at SpringSource and don't
>>> have any immediate concerns no. I think there is a slight overreaction
>>> to the policy in that thread
>>>
>>
>> Sorry Graeme, but I think your taking things a bit to lightly here.
>>
>> This change in policy is a huge risk for any Spring related project, but
>> also for any project which relies on Spring. I don't think that having 'a
>> good relationship' will result in: Instead of charging $25.000 for it, we
>> give it for free. If that was the case, people would just download Grails
>> to get the latest Spring version from it.
>>
>> Since I think the future of Spring as a framework (especially with the new
>> money focusses approach) is a bit uncertain, I also fear a little bit for
>> Grails, since it so strongly depends on Spring. I'm not about to start a
>> panic here, but I think I need to be a little be more convinced about the
>> future of Grails + Spring before I'm at not concerned about the future of
>> Grails anymore.
>>
>> So: any idea on how this relationship could help Grails?
>>
>> Erik
>>
>> PS: This is not theoretical at all: Grails Remoting needs Spring 2.5.5.
>> Whith this policy in effect, Spring 2.5.5 would never have been released
>> to the public, I wouldn't have been able to use Grails in combination with
>> Grails Remoting, and I would have to find a different solution. Just some
>> context for my worries.
>>
>
> --
> View this message in context: http://www.nabble.com/Spring-tp19609427p19690873.html
> Sent from the grails - user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

--
Graeme Rocher
Grails Project Lead
G2One, Inc. Chief Technology Officer
http://www.g2one.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jay Guidos]

Hi Graeme et al.

Cutting away at the hyperbole and foaming-at-the-mouth comments I have
been reading on other forums/blogs (nice to see most people here
discussing this rationally), I think there is still some perplexing
issues that might affect grails.

First, I think that the SS guys deserve to make money. They make a damn
good product that IMHO has revolutionized the industry. I am not certain
this is the best approach for other open-source projects though, and
community cooperation is open-source's bread and butter.

For instance, say Graeme decides to fork out the dough to get on a
maintenance release. But Grails is open source, and he knows that the
Grails community rightfully expects to be able to build the grails
source themselves.  How do they get access to the pay-only jars?

Also, people supplying their on spring jars built off the tips of
maintenance branches (to get their needed patches) are now running
grails against untested Spring versions. You start up your beautiful web
app, see a deep-dish groovy stack trace, who do blame?  Right, you blame
Grails, even thought somewhere around line 475 of the stack trace (if
you looked) you would find a "method not found" exception caused by
grails not finding a spring method that the official Grails build jar
has.

Graeme, as an important user and contributor to Spring, have you had any
discussions internally or with the SS folks on how to get around these
issues?

Jay Guidos

-----Original Message-----
From: Marcel Overdijk [mailto:marceloverdijk@...]
Sent: September 26, 2008 9:35 AM
To: user@...
Subject: Re: [grails-user] Spring


I agree with Erik that this policy change should not be underestimated.

I think a lot of people (including myself) are trying to bring Grails
under
the attention of their managers and/or are starting their first
commercial
projects with Grails.

But now with Spring's change in policy people will be more careful and
think
twice. Also for management the risk to need expensive subscriptions
could be
a blocker in this. Especially for small to medium (startup) projects.


Cheers,
Marcel





Erik Pragt wrote:
>
>
>
> Graeme Rocher-2 wrote:
>>
>> We have a good relationship with the guys at SpringSource and don't
>> have any immediate concerns no. I think there is a slight
overreaction
>> to the policy in that thread
>>
>
> Sorry Graeme, but I think your taking things a bit to lightly here.
>
> This change in policy is a huge risk for any Spring related project,
but
> also for any project which relies on Spring. I don't think that having
'a
> good relationship' will result in: Instead of charging $25.000 for it,
we
> give it for free. If that was the case, people would just download
Grails
> to get the latest Spring version from it.
>
> Since I think the future of Spring as a framework (especially with the
new
> money focusses approach) is a bit uncertain, I also fear a little bit
for
> Grails, since it so strongly depends on Spring. I'm not about to start
a
> panic here, but I think I need to be a little be more convinced about
the
> future of Grails + Spring before I'm at not concerned about the future
of
> Grails anymore.
>
> So: any idea on how this relationship could help Grails?
>
> Erik
>
> PS: This is not theoretical at all: Grails Remoting needs Spring
2.5.5.
> Whith this policy in effect, Spring 2.5.5 would never have been
released
> to the public, I wouldn't have been able to use Grails in combination
with
> Grails Remoting, and I would have to find a different solution. Just
some
> context for my worries.
>

--
View this message in context:
http://www.nabble.com/Spring-tp19609427p19690873.html
Sent from the grails - user mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[mingfai]

to my understanding Spring may still do bug fixing and put into svn. Given Grails will not use very old version of Spring, the worst case is just to build Spring by ourselves. Maybe we could make a nightly build of Spring+Groovy+Grails.

i wonder if we have concern over Spring's new policy, what could we do? drop Spring from Grails? Ask G2One to pay for subscription? there are any sensible options to consider, so i would not concern about it personally.


>Firstly, many people who adopt Grails don't even know they have
>Spring. Grails is an abstraction layer over Spring. In other words

I'm not one of those people. I use Spring and Hibernate directly and keep my Spring library up-to-date all the time. It's not too good to do in this way, but it's not good to make too many request to update library either. Anyway, it would be great if there is a clear policy and mechanism of updating Grails dependency libraries. two suggestions are as follows:

• for every major release, Grails will update all it's core depending libraries, that incl. Spring, Hibernate, Jetty, Groovy etc.
• make dependency library wiki page, whoever want a library be updated could add an entry to the page, and indicate if it's unofficially tested or not. And whenever there are Grails release, dev just check the list and make sure all requested libraries are up to date
  

just my 2 cents

regards,
mingfai

On Fri, Sep 26, 2008 at 11:50 PM, Graeme Rocher <graeme@...> wrote:

Firstly, many people who adopt Grails don't even know they have
Spring. Grails is an abstraction layer over Spring. In other words
people, in my experience, don't consider upgrading the Spring jar
distributed with Grails, they think in terms of upgrading Grails not
upgrading Spring.

Its more an issue for us, the Grails developers, to make sure that we
are prompt with upgrading to the latest version of Spring after a
release. And to ensure any issues are reported. It may also be that
Grails releases become more aligned with Spring releases. And during
development we can always build a distribution of Spring from the
sources

The code in the Spring repo will be the latest code. Obviously some
feel its an issue, I  personally think that it will be less of an
issue than is made out to be.

Cheers

On Fri, Sep 26, 2008 at 4:34 PM, Marcel Overdijk
<marceloverdijk@...> wrote:
>
> I agree with Erik that this policy change should not be underestimated.
>
> I think a lot of people (including myself) are trying to bring Grails under
> the attention of their managers and/or are starting their first commercial
> projects with Grails.
>
> But now with Spring's change in policy people will be more careful and think
> twice. Also for management the risk to need expensive subscriptions could be
> a blocker in this. Especially for small to medium (startup) projects.
>
>
> Cheers,
> Marcel
>
>
>
>
>
> Erik Pragt wrote:
>>
>>
>>
>> Graeme Rocher-2 wrote:
>>>
>>> We have a good relationship with the guys at SpringSource and don't
>>> have any immediate concerns no. I think there is a slight overreaction
>>> to the policy in that thread
>>>
>>
>> Sorry Graeme, but I think your taking things a bit to lightly here.
>>
>> This change in policy is a huge risk for any Spring related project, but
>> also for any project which relies on Spring. I don't think that having 'a
>> good relationship' will result in: Instead of charging $25.000 for it, we
>> give it for free. If that was the case, people would just download Grails
>> to get the latest Spring version from it.
>>
>> Since I think the future of Spring as a framework (especially with the new
>> money focusses approach) is a bit uncertain, I also fear a little bit for
>> Grails, since it so strongly depends on Spring. I'm not about to start a
>> panic here, but I think I need to be a little be more convinced about the
>> future of Grails + Spring before I'm at not concerned about the future of
>> Grails anymore.
>>
>> So: any idea on how this relationship could help Grails?
>>
>> Erik
>>
>> PS: This is not theoretical at all: Grails Remoting needs Spring 2.5.5.
>> Whith this policy in effect, Spring 2.5.5 would never have been released
>> to the public, I wouldn't have been able to use Grails in combination with
>> Grails Remoting, and I would have to find a different solution. Just some
>> context for my worries.
>>
>
> --
> View this message in context: http://www.nabble.com/Spring-tp19609427p19690873.html
> Sent from the grails - user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

--
Graeme Rocher
Grails Project Lead
G2One, Inc. Chief Technology Officer

http://www.g2one.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Steve Tekell]

> Firstly, many people who adopt Grails don't even know they have Spring.

That's more of a reason for concern than comfort.

> Its more an issue for us, the Grails developers.

Well, at least I hope Groovy/Grails doesn't go the route of Spring as a result of this.
Since Groovy/Grails isn't backed by an independent foundation like Apache, Eclipse, or Dojo, it's does require a leap of faith.

> I  personally think that it will be less of an issue than is made out to be.

While I won't try to argue that this will be terrible in the near future, people do have a valid reason to feel uncomfortable about this.  And nothing I read so far has eased this discomfort.  Some of Rod's comments can read as saying that Spring may be open source now but they are in total control because no one could succeed with forking Spring.  I've have seen this game before with "professional open source" and one should be prepared for things to get more closed over time.

I would feel much better if there were Spring and Groovy/Grails were backed by some independent non-profit foundation (existing or new).  Having a commercial entity say "trust me" - isn't nearly as good.

F/OSS was previously defined only by a license which assured the source code was available.  But, large projects will need more than just source code to remain truly "open".  These need an independent foundation to protect an open and cooperative community from the private interests of a single commercial entity.  I am starting to see more of a dividing line between Apache, Eclipse, Dojo, et al, and "professional open source" like Alfresco, and now SpringSource.

[Marcel Overdijk]

Graeme,

I agree with you that for many Grails users it doesn't matter which version of Spring is used. If Grails works fine everything is ok for them. Spring is more or less hidden.

But I think as mentioned by Erik Pragt the future around Spring is a little bit uncertain. And this is, sadly, not a plus for Grails. Specially not for companies which are in the process of deciding to use Grails (or Spring) or not for projects. People and specially management don't like uncertainty.

I''m however convinced that G2One/Grails team have a way to workaround this as you mentioned in your post, and that it's more of a problem for the Grails devs.


Cheers,
Marcel

Graeme Rocher-2 wrote:

Firstly, many people who adopt Grails don't even know they have
Spring. Grails is an abstraction layer over Spring. In other words
people, in my experience, don't consider upgrading the Spring jar
distributed with Grails, they think in terms of upgrading Grails not
upgrading Spring.

Its more an issue for us, the Grails developers, to make sure that we
are prompt with upgrading to the latest version of Spring after a
release. And to ensure any issues are reported. It may also be that
Grails releases become more aligned with Spring releases. And during
development we can always build a distribution of Spring from the
sources

The code in the Spring repo will be the latest code. Obviously some
feel its an issue, I  personally think that it will be less of an
issue than is made out to be.

Cheers

On Fri, Sep 26, 2008 at 4:34 PM, Marcel Overdijk
<[e-mail]> wrote:
>
> I agree with Erik that this policy change should not be underestimated.
>
> I think a lot of people (including myself) are trying to bring Grails under
> the attention of their managers and/or are starting their first commercial
> projects with Grails.
>
> But now with Spring's change in policy people will be more careful and think
> twice. Also for management the risk to need expensive subscriptions could be
> a blocker in this. Especially for small to medium (startup) projects.
>
>
> Cheers,
> Marcel
>
>
>
>
>
> Erik Pragt wrote:
>>
>>
>>
>> Graeme Rocher-2 wrote:
>>>
>>> We have a good relationship with the guys at SpringSource and don't
>>> have any immediate concerns no. I think there is a slight overreaction
>>> to the policy in that thread
>>>
>>
>> Sorry Graeme, but I think your taking things a bit to lightly here.
>>
>> This change in policy is a huge risk for any Spring related project, but
>> also for any project which relies on Spring. I don't think that having 'a
>> good relationship' will result in: Instead of charging $25.000 for it, we
>> give it for free. If that was the case, people would just download Grails
>> to get the latest Spring version from it.
>>
>> Since I think the future of Spring as a framework (especially with the new
>> money focusses approach) is a bit uncertain, I also fear a little bit for
>> Grails, since it so strongly depends on Spring. I'm not about to start a
>> panic here, but I think I need to be a little be more convinced about the
>> future of Grails + Spring before I'm at not concerned about the future of
>> Grails anymore.
>>
>> So: any idea on how this relationship could help Grails?
>>
>> Erik
>>
>> PS: This is not theoretical at all: Grails Remoting needs Spring 2.5.5.
>> Whith this policy in effect, Spring 2.5.5 would never have been released
>> to the public, I wouldn't have been able to use Grails in combination with
>> Grails Remoting, and I would have to find a different solution. Just some
>> context for my worries.
>>
>
> --
> View this message in context: http://www.nabble.com/Spring-tp19609427p19690873.html
> Sent from the grails - user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>



--
Graeme Rocher
Grails Project Lead
G2One, Inc. Chief Technology Officer
http://www.g2one.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Dustin Barnes]

After talking to some of the Spring guys at a NFJS, the big issue seemed
to be that their product was just too good for enterprise people to
shell out for "support" and "training." It was just too easy to learn
and didn't have enough problems. Training people with general sysadmin
knowledge on the specifics of managing MySQL, with all its complexities
(storage engine, live backups, performance optimization, clustering,
scaling) is very different, and there's a much larger market for it.
Spring is "just a library" to a lot of people, and the users are
programmers. They can follow the docs and in a day's time be up and
running. There's less appeal for formal training when a book or can get
you just as far.

I hope the big driver in this change is the time between major
revisions. 2.0 final was released on 2006-03-10, 2.5 final was
2007-11-19, a full 20 months later. 3 months of 2.5 support would have
gotten us to 2.5.2.

Hopefully, with some people willing to pay more (and in the grand scheme
of things, it's probably worth it), it will mean more frequent major
releases with fewer breaking changes. Keeping on top of them should be
easier. So, instead of a 3.0 release, then 20 months to 3.5, they'll
release a 3.1 somewhere in there. Catering to the people who want to
stay on 2.0 is hampering them from developing 3.0 faster, and forcing
some of those 2.0 people to pay for the developers that support them
frees up resources to get 3.0 out faster.

At least, that's the hope.



>> Graeme Rocher-2 wrote:
>>>
>>> We have a good relationship with the guys at SpringSource and don't
>>> have any immediate concerns no. I think there is a slight
overreaction
>>> to the policy in that thread
>>>
>>
>> Sorry Graeme, but I think your taking things a bit to lightly here.
>>
>> This change in policy is a huge risk for any Spring related project,
but
>> also for any project which relies on Spring. I don't think that
having 'a
>> good relationship' will result in: Instead of charging $25.000 for
it, we
>> give it for free. If that was the case, people would just download
Grails
>> to get the latest Spring version from it.
>>
>> Since I think the future of Spring as a framework (especially with
the new
>> money focusses approach) is a bit uncertain, I also fear a little bit
for
>> Grails, since it so strongly depends on Spring. I'm not about to
start a
>> panic here, but I think I need to be a little be more convinced about
the
>> future of Grails + Spring before I'm at not concerned about the
future of
>> Grails anymore.
>>
>> So: any idea on how this relationship could help Grails?
>>
>> Erik
>>
>> PS: This is not theoretical at all: Grails Remoting needs Spring
2.5.5.
>> Whith this policy in effect, Spring 2.5.5 would never have been
released
>> to the public, I wouldn't have been able to use Grails in combination
with
>> Grails Remoting, and I would have to find a different solution. Just
some
>> context for my worries.
>>
>
> --
> View this message in context:
http://www.nabble.com/Spring-tp19609427p19690873.html

> Sent from the grails - user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

--
Graeme Rocher
Grails Project Lead
G2One, Inc. Chief Technology Officer
http://www.g2one.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Dmitriy Kopylenko-3]

Just FYI: SS has amended their original 'maintenance policy': http://blog.springsource.com/2008/10/07/a-question-of-balance-tuning-the-maintenance-policy/

Cheers,
Dmitriy.

2008/9/26 Dustin Barnes <dustin@...>

After talking to some of the Spring guys at a NFJS, the big issue seemed
to be that their product was just too good for enterprise people to
shell out for "support" and "training." It was just too easy to learn
and didn't have enough problems. Training people with general sysadmin
knowledge on the specifics of managing MySQL, with all its complexities
(storage engine, live backups, performance optimization, clustering,
scaling) is very different, and there's a much larger market for it.
Spring is "just a library" to a lot of people, and the users are
programmers. They can follow the docs and in a day's time be up and
running. There's less appeal for formal training when a book or can get
you just as far.

I hope the big driver in this change is the time between major
revisions. 2.0 final was released on 2006-03-10, 2.5 final was
2007-11-19, a full 20 months later. 3 months of 2.5 support would have
gotten us to 2.5.2.

Hopefully, with some people willing to pay more (and in the grand scheme
of things, it's probably worth it), it will mean more frequent major
releases with fewer breaking changes. Keeping on top of them should be
easier. So, instead of a 3.0 release, then 20 months to 3.5, they'll
release a 3.1 somewhere in there. Catering to the people who want to
stay on 2.0 is hampering them from developing 3.0 faster, and forcing
some of those 2.0 people to pay for the developers that support them
frees up resources to get 3.0 out faster.

At least, that's the hope.

>> Graeme Rocher-2 wrote:
>>>
>>> We have a good relationship with the guys at SpringSource and don't
>>> have any immediate concerns no. I think there is a slight
overreaction
>>> to the policy in that thread
>>>
>>
>> Sorry Graeme, but I think your taking things a bit to lightly here.
>>
>> This change in policy is a huge risk for any Spring related project,
but
>> also for any project which relies on Spring. I don't think that
having 'a
>> good relationship' will result in: Instead of charging $25.000 for
it, we
>> give it for free. If that was the case, people would just download
Grails
>> to get the latest Spring version from it.
>>
>> Since I think the future of Spring as a framework (especially with
the new
>> money focusses approach) is a bit uncertain, I also fear a little bit
for
>> Grails, since it so strongly depends on Spring. I'm not about to
start a
>> panic here, but I think I need to be a little be more convinced about
the
>> future of Grails + Spring before I'm at not concerned about the
future of
>> Grails anymore.
>>
>> So: any idea on how this relationship could help Grails?
>>
>> Erik
>>
>> PS: This is not theoretical at all: Grails Remoting needs Spring
2.5.5.
>> Whith this policy in effect, Spring 2.5.5 would never have been
released
>> to the public, I wouldn't have been able to use Grails in combination
with
>> Grails Remoting, and I would have to find a different solution. Just
some
>> context for my worries.
>>
>
> --
> View this message in context:
http://www.nabble.com/Spring-tp19609427p19690873.html
> Sent from the grails - user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>



--
Graeme Rocher
Grails Project Lead
G2One, Inc. Chief Technology Officer
http://www.g2one.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Marcel Overdijk]

Just read their blog post. Really good news!

I'm glad the listened to the concerns of the community.


Cheers,
Marcel

Dmitriy Kopylenko-3 wrote:

Just FYI: SS has amended their original 'maintenance policy':
http://blog.springsource.com/2008/10/07/a-question-of-balance-tuning-the-maintenance-policy/

Cheers,
Dmitriy.


2008/9/26 Dustin Barnes <[e-mail]>

> After talking to some of the Spring guys at a NFJS, the big issue seemed
> to be that their product was just too good for enterprise people to
> shell out for "support" and "training." It was just too easy to learn
> and didn't have enough problems. Training people with general sysadmin
> knowledge on the specifics of managing MySQL, with all its complexities
> (storage engine, live backups, performance optimization, clustering,
> scaling) is very different, and there's a much larger market for it.
> Spring is "just a library" to a lot of people, and the users are
> programmers. They can follow the docs and in a day's time be up and
> running. There's less appeal for formal training when a book or can get
> you just as far.
>
> I hope the big driver in this change is the time between major
> revisions. 2.0 final was released on 2006-03-10, 2.5 final was
> 2007-11-19, a full 20 months later. 3 months of 2.5 support would have
> gotten us to 2.5.2.
>
> Hopefully, with some people willing to pay more (and in the grand scheme
> of things, it's probably worth it), it will mean more frequent major
> releases with fewer breaking changes. Keeping on top of them should be
> easier. So, instead of a 3.0 release, then 20 months to 3.5, they'll
> release a 3.1 somewhere in there. Catering to the people who want to
> stay on 2.0 is hampering them from developing 3.0 faster, and forcing
> some of those 2.0 people to pay for the developers that support them
> frees up resources to get 3.0 out faster.
>
> At least, that's the hope.
>
>
>
> >> Graeme Rocher-2 wrote:
> >>>
> >>> We have a good relationship with the guys at SpringSource and don't
> >>> have any immediate concerns no. I think there is a slight
> overreaction
> >>> to the policy in that thread
> >>>
> >>
> >> Sorry Graeme, but I think your taking things a bit to lightly here.
> >>
> >> This change in policy is a huge risk for any Spring related project,
> but
> >> also for any project which relies on Spring. I don't think that
> having 'a
> >> good relationship' will result in: Instead of charging $25.000 for
> it, we
> >> give it for free. If that was the case, people would just download
> Grails
> >> to get the latest Spring version from it.
> >>
> >> Since I think the future of Spring as a framework (especially with
> the new
> >> money focusses approach) is a bit uncertain, I also fear a little bit
> for
> >> Grails, since it so strongly depends on Spring. I'm not about to
> start a
> >> panic here, but I think I need to be a little be more convinced about
> the
> >> future of Grails + Spring before I'm at not concerned about the
> future of
> >> Grails anymore.
> >>
> >> So: any idea on how this relationship could help Grails?
> >>
> >> Erik
> >>
> >> PS: This is not theoretical at all: Grails Remoting needs Spring
> 2.5.5.
> >> Whith this policy in effect, Spring 2.5.5 would never have been
> released
> >> to the public, I wouldn't have been able to use Grails in combination
> with
> >> Grails Remoting, and I would have to find a different solution. Just
> some
> >> context for my worries.
> >>
> >
> > --
> > View this message in context:
> http://www.nabble.com/Spring-tp19609427p19690873.html
> > Sent from the grails - user mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >    http://xircles.codehaus.org/manage_email
> >
> >
> >
>
>
>
> --
> Graeme Rocher
> Grails Project Lead
> G2One, Inc. Chief Technology Officer
> http://www.g2one.com
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>