You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ralph Goers <Ra...@dslextreme.com> on 2007/09/25 19:41:44 UTC
Re: Java 1.5 [was svn commit: r579132 - in
/cocoon/trunk/core/cocoon-core/src/test/java/org/apache/cocoon/transfo
rmation:I18NTransformerTestCase.java
I18NTransformerTestCase.java.disabled]
Carsten Ziegeler said:
> Although I guess everyone understood what I meant above, just a
> clarification: of course I meant that it only makes sense to stick with
> 1.4 if the people working on and using 2.2 *with jdk 1.4* is a critical
> mass. There is no doubt that currently there are many people
> using/develeoping 2.2 in general.
We just switched our Cocoon deployment in production from IBM 1.4 to Sun
1.5 and got at least a 25% performance improvement. Java 1.6 is out. It
seems nuts to me to continue to target 1.4 on an as yet unreleased new
version of Cocoon. However, if you view this as a code change then the
voting rules state that a single -1 vetoes the proposal, and we got that
before. Unless the -1 is rescinded I fear we will be stuck at 1.4 until
2010.
Ralph
Re: Java 1.5 [was svn commit: r579132 - in /cocoon/trunk/core/cocoon-core/src/test/java/org/apache/cocoon/transfo rmation:I18NTransformerTestCase.java I18NTransformerTestCase.java.disabled]
Posted by Vadim Gritsenko <va...@reverycodes.com>.
On May 5, 2008, at 3:08 AM, Ralph Goers wrote:
> I sure am glad we decided to go with Java 1.4 for 2.2. See the nice
> bulletin at http://java.sun.com/j2se/1.4.2/download.html. At least
> now I'm certain we won't be supporting 1.4 until 2010.
>
> Ralph Goers wrote:
>> Carsten Ziegeler said:
>>
>>
>>> Although I guess everyone understood what I meant above, just a
>>> clarification: of course I meant that it only makes sense to stick
>>> with
>>> 1.4 if the people working on and using 2.2 *with jdk 1.4* is a
>>> critical
>>> mass. There is no doubt that currently there are many people
>>> using/develeoping 2.2 in general.
>>>
>>
>> We just switched our Cocoon deployment in production from IBM 1.4
>> to Sun
>> 1.5 and got at least a 25% performance improvement. Java 1.6 is
>> out. It
>> seems nuts to me to continue to target 1.4 on an as yet unreleased
>> new
>> version of Cocoon. However, if you view this as a code change then
>> the
>> voting rules state that a single -1 vetoes the proposal, and we got
>> that
>> before. Unless the -1 is rescinded I fear we will be stuck at 1.4
>> until
>> 2010.
We can bump version number to 2.3 and require Java 1.5 for it. In fact
I'd proposed this already sometime before. 2.2 can be branched off for
those few unfortunate who are stuck with Java 1.4.
Vadim
Re: Java 1.5 [was svn commit: r579132 - in /cocoon/trunk/core/cocoon-core/src/test/java/org/apache/cocoon/transfo
rmation:I18NTransformerTestCase.java I18NTransformerTestCase.java.disabled]
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alfred Nathaniel wrote:
| On Mon, 2008-05-05 at 00:08 -0700, Ralph Goers wrote:
|> I sure am glad we decided to go with Java 1.4 for 2.2. See the nice
|> bulletin at http://java.sun.com/j2se/1.4.2/download.html. At least now
|> I'm certain we won't be supporting 1.4 until 2010.
|
| No hope to get rid of 1.4 anytime soon. Java 1.3 is EOL since Dec 2006,
| and we are still "supporting" it for 2.1.
|
| http://java.sun.com/j2se/1.3/download.html
Well, have you seen this: http://java.sun.com/javase/downloads/index_jdk5.jsp
Ciao
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkgzrksACgkQLNdJvZjjVZCcYQCgp60DT2ZuDPaAOT/XaJlROS8Z
WQcAmgM23UUr/mXrjSftiwYRoaDqLpZD
=XoKL
-----END PGP SIGNATURE-----
Re: Java 1.5 [was svn commit: r579132 - in
/cocoon/trunk/core/cocoon-core/src/test/java/org/apache/cocoon/transfo
rmation:I18NTransformerTestCase.java
I18NTransformerTestCase.java.disabled]
Posted by Alfred Nathaniel <an...@apache.org>.
On Mon, 2008-05-05 at 00:08 -0700, Ralph Goers wrote:
> I sure am glad we decided to go with Java 1.4 for 2.2. See the nice
> bulletin at http://java.sun.com/j2se/1.4.2/download.html. At least now
> I'm certain we won't be supporting 1.4 until 2010.
No hope to get rid of 1.4 anytime soon. Java 1.3 is EOL since Dec 2006,
and we are still "supporting" it for 2.1.
http://java.sun.com/j2se/1.3/download.html
Cheers, Alfred.
Re: Java 1.5 [was svn commit: r579132 - in /cocoon/trunk/core/cocoon-core/src/test/java/org/apache/cocoon/transfo
rmation:I18NTransformerTestCase.java I18NTransformerTestCase.java.disabled]
Posted by Ralph Goers <Ra...@dslextreme.com>.
I sure am glad we decided to go with Java 1.4 for 2.2. See the nice
bulletin at http://java.sun.com/j2se/1.4.2/download.html. At least now
I'm certain we won't be supporting 1.4 until 2010.
Ralph Goers wrote:
> Carsten Ziegeler said:
>
>
>> Although I guess everyone understood what I meant above, just a
>> clarification: of course I meant that it only makes sense to stick with
>> 1.4 if the people working on and using 2.2 *with jdk 1.4* is a critical
>> mass. There is no doubt that currently there are many people
>> using/develeoping 2.2 in general.
>>
>
> We just switched our Cocoon deployment in production from IBM 1.4 to Sun
> 1.5 and got at least a 25% performance improvement. Java 1.6 is out. It
> seems nuts to me to continue to target 1.4 on an as yet unreleased new
> version of Cocoon. However, if you view this as a code change then the
> voting rules state that a single -1 vetoes the proposal, and we got that
> before. Unless the -1 is rescinded I fear we will be stuck at 1.4 until
> 2010.
>
> Ralph
>
>
Re: Java 1.5
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Reinhard Poetz wrote:
> I think for 2.2 it is fine to stick with Java 1.4 and go for Java 5 with
> 2.3. This should also give the Websphere 6 users enough time and is for
> all the Java 5 fans motivation to make 2.3 happen soon ;-)
Exactly.
Vadim
Re: Java 1.5
Posted by Reinhard Poetz <re...@apache.org>.
Joerg Heinicke wrote:
> On 25.09.2007 15:45 Uhr, Vadim Gritsenko wrote:
>
>> Our problem is not minimum Java requirement for Cocoon 2.2. The
>> problem is release time lines. [..] Java requirements? Nah, that's
>> peanuts...
>
> Thanks, you hit the nail. When was the vote? 1 year ago?
>
> Despite being still convinced that raising the requirement to Java 5
> does not buy as a lot if anything (Just think of java.nio, which is
> supposed to bring a big performance gain and would so be a real
> advantage for the user. I never saw ANY code in Cocoon using it.) I
> herewith withdraw my -1 since I'm just tired of discussing this over and
> over again.
I finally managed to create all the release artifacts. The problem was that
hardly any (or nobody) of the committers is using Maven 2 with Java 1.4. (The
funny thing is that our Continuum instance does not suffer from this problems.)
This combination leads to some problems and I was tired of fixing them just for
the sake of a release.
I think for 2.2 it is fine to stick with Java 1.4 and go for Java 5 with 2.3.
This should also give the Websphere 6 users enough time and is for all the Java
5 fans motivation to make 2.3 happen soon ;-)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Java 1.5 [was svn commit: r579132 - in /cocoon/trunk/core/cocoon-core/src/test/java/org/apache/cocoon/transfo
rmation:I18NTransformerTestCase.java I18NTransformerTestCase.java.disabled]
Posted by Joerg Heinicke <jo...@gmx.de>.
On 25.09.2007 15:45 Uhr, Vadim Gritsenko wrote:
> Our problem is not minimum Java requirement for Cocoon 2.2. The problem
> is release time lines. [..] Java requirements? Nah, that's peanuts...
Thanks, you hit the nail. When was the vote? 1 year ago?
Despite being still convinced that raising the requirement to Java 5
does not buy as a lot if anything (Just think of java.nio, which is
supposed to bring a big performance gain and would so be a real
advantage for the user. I never saw ANY code in Cocoon using it.) I
herewith withdraw my -1 since I'm just tired of discussing this over and
over again.
So if you really think it's worth it go ahead. Otherwise I'm with
Vadim's plan:
> I'm completely expecting Cocoon 2.3 to be at Java 1.5 level, and 2.4 may be at Java 1.6 level.
Joerg
Re: Java 1.5
Posted by Andrew Savory <a....@sourcesense.com>.
Hi,
On 28 Sep 2007, at 05:38, Joerg Heinicke wrote:
> And what's the use of it? I just don't get it why a framework
> should set restrictions on its user base.
Well, by that argument we should make cocoon work with Ruby, C++,
Lisp, Erlang, etc etc ... don't want to restrict our users to just
one language ;-)
There's a strong argument for not adding restrictions to an existing
tree (2.1), but for an unreleased framework (2.2+), it makes sense
that the best available solutions should be used -- otherwise there's
never an incentive for those using it to upgrade.
Thanks,
Andrew.
--
Sourcesense: Making sense of Open Source
Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135
Web: http://www.sourcesense.com/
Re: Java 1.5
Posted by Joerg Heinicke <jo...@gmx.de>.
On 28.09.2007 0:46 Uhr, Ralph Goers wrote:
> However, the language features of 1.5 are worth it.
> For example, I would love to replace some pieces of
> code that require synchronized blocks with java.util.concurent. I would
> love to be able to specify the object types on Maps and Lists. It just
> makes for better code.
That's unlikely to happen before the release I guess. Maybe you should
have this in mind when deciding about the requirement for Cocoon 2.2 -
even if this locks it to 1.4. java.util.concurrent is also available as
backwards-compatible version for 1.4.
Joerg
Re: Java 1.5
Posted by Joerg Heinicke <jo...@gmx.de>.
On 28.09.2007 0:46 Uhr, Ralph Goers wrote:
> I'm sure we could find a way to take advantage of NIO if we
> really thought about it. But we can't do any of that
> because we are stuck at 1.4.
NIO is 1.4.
Joerg
Re: Java 1.5
Posted by Ralph Goers <Ra...@dslextreme.com>.
Joerg Heinicke wrote:
> On 25.09.2007 16:20 Uhr, Felix Knecht wrote:
>
>> May I ask why can't just make a jump and goto java 1.6?
>> What's the benefit of using not the latest version - do any contracts
>> exists that we can't jump over a java version?
>
> And what's the use of it? I just don't get it why a framework should
> set restrictions on its user base. While nothing prevents you to use 1.6.
>
I don't necessarily agree with setting 1.6 as the minimum myself. Mostly
because it doesn't add much over 1.5. However, the language features of
1.5 are worth it. For example, I would love to replace some pieces of
code that require synchronized blocks with java.util.concurent. I would
love to be able to specify the object types on Maps and Lists. It just
makes for better code. I'm sure we could find a way to take advantage
of NIO if we really thought about it. But we can't do any of that
because we are stuck at 1.4.
Ralph
Re: Java 1.5
Posted by Joerg Heinicke <jo...@gmx.de>.
On 25.09.2007 16:20 Uhr, Felix Knecht wrote:
> May I ask why can't just make a jump and goto java 1.6?
> What's the benefit of using not the latest version - do any contracts
> exists that we can't jump over a java version?
And what's the use of it? I just don't get it why a framework should set
restrictions on its user base. While nothing prevents you to use 1.6.
Joerg
Re: Java 1.5
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Felix Knecht wrote:
>> 4. Let's start working on 2.3 in trunk with clearly set of general features we would like to see in
>> clearly set time-frame with preference of time-frame over feature-set. I mean, if something does not
>> make it into 2.3 in planned time-frame it must be rescheduled for 2.4. At the same time, we could
>> set Java 1.5 for trunk.
>
> May I ask why can't just make a jump and goto java 1.6?
> What's the benefit of using not the latest version - do any contracts
> exists that we can't jump over a java version?
Some (most?) platforms are lagging 1.6 support.
For example, Java 1.6 is not officially out yet for OS X - it is in beta test.
BEA does not have yet a WebLogic release with Java 6. IBM WebSphere is usually
the last one to upgrade.
Vadim
Re: Java 1.5
Posted by Felix Knecht <fe...@apache.org>.
> 4. Let's start working on 2.3 in trunk with clearly set of general features we would like to see in
> clearly set time-frame with preference of time-frame over feature-set. I mean, if something does not
> make it into 2.3 in planned time-frame it must be rescheduled for 2.4. At the same time, we could
> set Java 1.5 for trunk.
May I ask why can't just make a jump and goto java 1.6?
What's the benefit of using not the latest version - do any contracts
exists that we can't jump over a java version?
Felix
Re: Java 1.5
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Daniel Fagerstrom wrote:
> The current plan is that Spring-OSGi will be released in december, so we
> should most definitively not let Cocoon 2.2 wait for it. Right now,
> I'm the only one working on Cocoon-OSGi so it must be more of a
> community effort before we include it in any release.
>
> OSGi does not work woth "split packages", i.e. that some of the classes
> of a package is defined in one bundle and others in another bundle. So
> some reorganization of package structure in Cocoon is needed. This
> probably means that Cocoon-OSGi would need to be in 2.3 or maybe 3.0 for
> the core blocks.
Cocoon 2.2 now, and Cocoon 2.3 in Jan/Feb - sounds good to me.
Let's start a thread on minimum Java requirement for Cocoon 2.3 now, so that we
have a vote result by January :-P
Vadim
Re: Java 1.5
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Ralph Goers pisze:
...
>> Version 2.3 should only be created if we have some new feature for it ..
>> like OSGi (and it might even be possible to do that on 2.2 since it is
>> leveraging Spring - but you'd have to ask the guys working on it). I am
>> not in favor of creating a new release branch just to increase the minimum
>> Java version. If that is done I doubt 2.2 will get any new features or
>> support so what is the point.
>
> What about some less distant and less ambitious goals like further splitting of cocoon core, less
> number of dependencies on Avalon and new EL stuff as default for sitemap?
> I would like to include in this list other goals like finished implementation of postable source and
> its infrastructure (like caching) but this is not going to be in 2.3 or even 2.4 of Cocoon core.
> It's going to be feature of 1.1 version of servlet service fw.
> I mean that we should be less ambitious about cocoon core when it comes to feature-set for
> particular release because most of the interesting stuff will be *outside* core.
>
> When it comes to OSGi integration I keep my fingers crossed for this effort and I even would like to
> join into this camp eventually but I think OSGi should not block any release. It must be desire and
> labour of community to act as lifeblood not just our wishes.
The current plan is that Spring-OSGi will be released in december, so we
should most definitively not let Cocoon 2.2 wait for it. Right now,
I'm the only one working on Cocoon-OSGi so it must be more of a
community effort before we include it in any release.
OSGi does not work woth "split packages", i.e. that some of the classes
of a package is defined in one bundle and others in another bundle. So
some reorganization of package structure in Cocoon is needed. This
probably means that Cocoon-OSGi would need to be in 2.3 or maybe 3.0 for
the core blocks.
/Daniel
Re: Java 1.5
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Ralph Goers pisze:
>
> 2.1 is Java 1.3. No release of 2.1 should be anything else.
I don't want to change Java compatibility in 2.1, even more I don't want to change anything in 2.1
any more.
I didn't make it clear: I want to kill 2.1.x because I believe we should maintain at most two
branches. Killing 2.1.x should enable us to maintain 2.2.x and focus on trunk introducing Java 1.5
as minimal requirement and some other incompatibilities.
> What happened to item 2?
Good question. I was having bad night.
If I recall what it was I'll post it :)
>> 3. Let's release 2.2 final just few weeks after RC2 (probably at the
>> beginning of November) and
>> start 2.2 branch just for the core modules
>
> 2.2 has never been formally released. The way I understand it the way our
> versioning rules work we can make this dependent on any Java version we
> want.
Yep, but changing contracts when second RC is just about being pushed is not the best solution IMO.
>> 4. Let's start working on 2.3 in trunk with clearly set of general
>> features we would like to see in
>> clearly set time-frame with preference of time-frame over feature-set. I
>> mean, if something does not
>> make it into 2.3 in planned time-frame it must be rescheduled for 2.4. At
>> the same time, we could
>> set Java 1.5 for trunk.
>
> Version 2.3 should only be created if we have some new feature for it ..
> like OSGi (and it might even be possible to do that on 2.2 since it is
> leveraging Spring - but you'd have to ask the guys working on it). I am
> not in favor of creating a new release branch just to increase the minimum
> Java version. If that is done I doubt 2.2 will get any new features or
> support so what is the point.
What about some less distant and less ambitious goals like further splitting of cocoon core, less
number of dependencies on Avalon and new EL stuff as default for sitemap?
I would like to include in this list other goals like finished implementation of postable source and
its infrastructure (like caching) but this is not going to be in 2.3 or even 2.4 of Cocoon core.
It's going to be feature of 1.1 version of servlet service fw.
I mean that we should be less ambitious about cocoon core when it comes to feature-set for
particular release because most of the interesting stuff will be *outside* core.
When it comes to OSGi integration I keep my fingers crossed for this effort and I even would like to
join into this camp eventually but I think OSGi should not block any release. It must be desire and
labour of community to act as lifeblood not just our wishes.
>> I think it's the right time to refer to Marc's Portier e-mail[1],
>> especially that we are just before GT:
>>
>> I agree, let's move on.
>>
>
> Hmm. I hope you don't mean that in terms of moving on to Wicket or Ruby on
> Rails or whatever the newest web framework is. ;-)
In no case! :-)
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: Java 1.5
Posted by Ralph Goers <Ra...@dslextreme.com>.
I definitely think you misunderstood my point. As Vadim rightly pointed
out, I should have ONLY been talking about 2.2 (i.e. trunk). See below
for more.
Grzegorz Kossakowski said:
> Vadim Gritsenko pisze:
>> Ralph Goers wrote:
>>> Unless the -1 is rescinded I fear *2.2* will be stuck at 1.4 until
>>> 2010.
>>
>> Here, fixed it for you :)
>>
>> You are saying it like a bad thing. Cocoon 2.1 will be stuck at Java 1.3
>> until cows come home. And Cocoon 1.8.2 will be stuck at... Well, you get
>> an idea. I'm completely expecting Cocoon 2.3 to be at Java 1.5 level,
>> and 2.4 may be at Java 1.6 level.
>>
>> Our problem is not minimum Java requirement for Cocoon 2.2. The problem
>> is release time lines. Cocoon 2.2 was supposed to be "Cocoon 2.1 +
>> ECM+". Now we don't have ECM+, it went through Spring migration, there
>> seems to be second wave of OSGi activity - and 2.2 ain't released yet.
>> Now *that* would be a good reason to flame. Java requirements? Nah,
>> that's peanuts...
>
> Vadim, you have a really good point, here.
>
> Not to respond to all e-mails I will summarize my standpoint:
> I agree that Java 1.4 compatibility becomes more and more illusory as
> people are abandoning Java
> 1.4. I agree that we should drop support for Java 1.4 ASAP but I strongly
> insist on respecting
> versioning rules and keep our word at the same time. Here we come to
> Vadim's point that we release
> much too rarely.
> That's why I would like to:
> 1. Release 2.1.11 ASAP (I would take care of it after GT) and we should
> agree on the fact that
> 2.1.12 will be released soon (after two months from 2.1.11 release) and it
> kills 2.1.X branch
> *definitively* (except serious security flaws, of course).
2.1 is Java 1.3. No release of 2.1 should be anything else.
What happened to item 2?
> 3. Let's release 2.2 final just few weeks after RC2 (probably at the
> beginning of November) and
> start 2.2 branch just for the core modules
2.2 has never been formally released. The way I understand it the way our
versioning rules work we can make this dependent on any Java version we
want.
> 4. Let's start working on 2.3 in trunk with clearly set of general
> features we would like to see in
> clearly set time-frame with preference of time-frame over feature-set. I
> mean, if something does not
> make it into 2.3 in planned time-frame it must be rescheduled for 2.4. At
> the same time, we could
> set Java 1.5 for trunk.
Version 2.3 should only be created if we have some new feature for it ..
like OSGi (and it might even be possible to do that on 2.2 since it is
leveraging Spring - but you'd have to ask the guys working on it). I am
not in favor of creating a new release branch just to increase the minimum
Java version. If that is done I doubt 2.2 will get any new features or
support so what is the point.
>
> I think it's the right time to refer to Marc's Portier e-mail[1],
> especially that we are just before GT:
>
>> If I'm missing anything in our 2.2. moves then it is a "clean slate" and
>> some freshly burnt down bush and rainforest to start growing new ideas.
>> It feels (from some distance, I admit) as if we keep dragging our
>> history with us, rather then only our witty experience.
>>
>>
>> As Stefano clearly stated almost 2 years ago: "It is time to move on".
>> The biggest difference now is that there might be a bigger base of
>> people ready to do so, and with a more clear view on 'where to'.
>
> I agree, let's move on.
>
Hmm. I hope you don't mean that in terms of moving on to Wicket or Ruby on
Rails or whatever the newest web framework is. ;-)
Ralph
Re: Java 1.5
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Vadim Gritsenko pisze:
> Ralph Goers wrote:
>> Unless the -1 is rescinded I fear *2.2* will be stuck at 1.4 until
>> 2010.
>
> Here, fixed it for you :)
>
> You are saying it like a bad thing. Cocoon 2.1 will be stuck at Java 1.3
> until cows come home. And Cocoon 1.8.2 will be stuck at... Well, you get
> an idea. I'm completely expecting Cocoon 2.3 to be at Java 1.5 level,
> and 2.4 may be at Java 1.6 level.
>
> Our problem is not minimum Java requirement for Cocoon 2.2. The problem
> is release time lines. Cocoon 2.2 was supposed to be "Cocoon 2.1 +
> ECM+". Now we don't have ECM+, it went through Spring migration, there
> seems to be second wave of OSGi activity - and 2.2 ain't released yet.
> Now *that* would be a good reason to flame. Java requirements? Nah,
> that's peanuts...
Vadim, you have a really good point, here.
Not to respond to all e-mails I will summarize my standpoint:
I agree that Java 1.4 compatibility becomes more and more illusory as people are abandoning Java
1.4. I agree that we should drop support for Java 1.4 ASAP but I strongly insist on respecting
versioning rules and keep our word at the same time. Here we come to Vadim's point that we release
much too rarely.
That's why I would like to:
1. Release 2.1.11 ASAP (I would take care of it after GT) and we should agree on the fact that
2.1.12 will be released soon (after two months from 2.1.11 release) and it kills 2.1.X branch
*definitively* (except serious security flaws, of course).
3. Let's release 2.2 final just few weeks after RC2 (probably at the beginning of November) and
start 2.2 branch just for the core modules
4. Let's start working on 2.3 in trunk with clearly set of general features we would like to see in
clearly set time-frame with preference of time-frame over feature-set. I mean, if something does not
make it into 2.3 in planned time-frame it must be rescheduled for 2.4. At the same time, we could
set Java 1.5 for trunk.
I think it's the right time to refer to Marc's Portier e-mail[1], especially that we are just before GT:
> If I'm missing anything in our 2.2. moves then it is a "clean slate" and some freshly burnt down bush and rainforest to start growing new ideas. It feels (from some distance, I admit) as if we keep dragging our history with us, rather then only our witty experience.
>
>
> As Stefano clearly stated almost 2 years ago: "It is time to move on". The biggest difference now is that there might be a bigger base of people ready to do so, and with a more clear view on 'where to'.
I agree, let's move on.
[1] http://article.gmane.org/gmane.text.xml.cocoon.devel/74314
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: Java 1.5 [was svn commit: r579132 - in /cocoon/trunk/core/cocoon-core/src/test/java/org/apache/cocoon/transfo
rmation:I18NTransformerTestCase.java I18NTransformerTestCase.java.disabled]
Posted by Carsten Ziegeler <cz...@apache.org>.
Vadim Gritsenko wrote:
>
> Our problem is not minimum Java requirement for Cocoon 2.2. The problem
> is release time lines. Cocoon 2.2 was supposed to be "Cocoon 2.1 +
> ECM+". Now we don't have ECM+, it went through Spring migration, there
> seems to be second wave of OSGi activity - and 2.2 ain't released yet.
> Now *that* would be a good reason to flame. Java requirements? Nah,
> that's peanuts...
>
Yepp, this is true as well - and this is very sad.
But if using 1.4 makes releasing harder for Reinhard, well why not just
switch and this aids in getting out 2.2 a little bit sooner.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Java 1.5 [was svn commit: r579132 - in /cocoon/trunk/core/cocoon-core/src/test/java/org/apache/cocoon/transfo
rmation:I18NTransformerTestCase.java I18NTransformerTestCase.java.disabled]
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Ralph Goers wrote:
> Unless the -1 is rescinded I fear *2.2* will be stuck at 1.4 until
> 2010.
Here, fixed it for you :)
You are saying it like a bad thing. Cocoon 2.1 will be stuck at Java 1.3 until
cows come home. And Cocoon 1.8.2 will be stuck at... Well, you get an idea. I'm
completely expecting Cocoon 2.3 to be at Java 1.5 level, and 2.4 may be at Java
1.6 level.
Our problem is not minimum Java requirement for Cocoon 2.2. The problem is
release time lines. Cocoon 2.2 was supposed to be "Cocoon 2.1 + ECM+". Now we
don't have ECM+, it went through Spring migration, there seems to be second wave
of OSGi activity - and 2.2 ain't released yet. Now *that* would be a good reason
to flame. Java requirements? Nah, that's peanuts...
PS IIRC my vote was 0.
Vadim
Re: Java 1.5 [was svn commit: r579132 - in /cocoon/trunk/core/cocoon-core/src/test/java/org/apache/cocoon/transfo
rmation:I18NTransformerTestCase.java I18NTransformerTestCase.java.disabled]
Posted by Antonio Gallardo <ag...@agssa.net>.
I agree. I am optimistic adn believe people opinions changes with time.
I would like to start a new vote since we have now a new jave version
scenario in front of us. :)
wdyt?
Best Regards,
Antonio Gallardo.
Ralph Goers escribió:
> Carsten Ziegeler said:
>
>
>> Although I guess everyone understood what I meant above, just a
>> clarification: of course I meant that it only makes sense to stick with
>> 1.4 if the people working on and using 2.2 *with jdk 1.4* is a critical
>> mass. There is no doubt that currently there are many people
>> using/develeoping 2.2 in general.
>>
>
> We just switched our Cocoon deployment in production from IBM 1.4 to Sun
> 1.5 and got at least a 25% performance improvement. Java 1.6 is out. It
> seems nuts to me to continue to target 1.4 on an as yet unreleased new
> version of Cocoon. However, if you view this as a code change then the
> voting rules state that a single -1 vetoes the proposal, and we got that
> before. Unless the -1 is rescinded I fear we will be stuck at 1.4 until
> 2010.
>
> Ralph
>