subject:"\[Vote\] Java 5 as minimum JDK requirement"


On 17.08.2006 01:29, Torsten Curdt wrote:


Is it appropriate to vote according to your employer's needs.


IMO PMC members should vote in the best interest of the project - not
in the best interest of their employers.


I just want to point out that I did not vote according to [my] 
employer's needs, but what IMHO is better for the project. Though we do 
not yet use Java 5, there is probably no problem to switch to it. The 
example I made with the bank was with a former employer of mine.


Jörg

Re: [Vote] Java 5 as minimum JDK requirement


On 15.08.2006 16:52, Vadim Gritsenko wrote:


If they are not willing to run a newer version of Websphere (with full
vendor support) that fixes 100s of know bugs then why would they
suddenly want to run some new version of Cocoon?


That's a good point.


This is indeed a very good point. And I agree to a certain extent. But 
there is still the minor difference that upgrading Cocoon is one webapp, 
upgrading the server means all webapps in that server.


And now we are talking about the Java version. This means you have to 
upgrade all applications on that server. Or run different Java version 
on one machine.


What I mean the impact of upgrading Cocoon is much lower than the Java 
one. And the other way around ... Cocoon would enforce that impact just 
for some developer goodies.


That's why I like the Spring approach so much. You can use it the 
standard way, but they provide the possibility to use the new features 
(e.g. transactional behaviour described in XML or via annotations).


I think Cocoon 2.2 can move to Java 1.5 this year 
as long as Cocoon 2.1 is not EOL-ed (End Of Life) for 1-2 years to 
give companies which are dragging their feet two more years of supported 
Cocoon 2.1 releases.


What does supported mean here? Just fixing critical bugs like memory 
looks? Or doing real development? There were ideas already one year ago 
to stop development on 2.1 completely, so I don't think the above has 
any chance.


Jörg

Re: [Result] [Vote] Java 5 as minimum JDK requirement


On 15.08.2006 22:18, Daniel Fagerstrom wrote:

Now if experiments with retroweaver/retrotranslator show that we can use 
Java 1.5 _and_ produce libraries that work in a Java 1.4 environment, 
the above problem should be resolved and Joerg should be able to retract 
his veto. Right Joerg?


In such a case (i.e. if Joerg retract his veto) we would not need a new 
vote for starting to use Java 5.


Now, AFAIU retroweaver/retrotranslator have some (small) limitations, so 
we probably would need a new proposal that says that we use the subset 
of Java 5 supported by retroweaver/retrotranslator.


Yes, especially with your new proposal I would retract the veto. But 
this addition is not unimportant as it shows that we care about our user 
base. It means we have tested our code base and it runs with the help of 
retro* in Java 1.4.


Without the addition it's a bit like There are tools that can make 
this. See, if you can get tehm running. Maybe they solve your problem. 
And nobody would probably care about it as there is no such clear guide 
line.



Now something about vetoing:


...

To me it seem to put a lot of emphasis on reaching a consensus. Right 
now we have a veto that most of the community don't agree with. That is 
far away from consensus and is IMO _not_ an acceptable situation from a 
community health POV. This means that we have to continue to work until 
we find a solution that we can get a consensus around.


From the community health POV I don't think we are that bad. Even IF 
the veto stands at the end, we had a good discussion with very different 
arguments. That we would not have agreed in this case does not mean that 
we have to worry about community health. And we are still working on an 
acceptable solution for ... everyone ... me :) Your proposal above 
strongly hints on it.


Btw, this was one of the few threads where I looked forward to every new 
mail. Other that huge threads often get unsettled, unorganized, 
confusing or boring. It also was not a one vs. all, but often people 
that do not agree with my position in general stand with me in some 
aspects. It was really fun :) Thanks.


Jörg

Re: [Result] [Vote] Java 5 as minimum JDK requirement


On 15.08.2006 17:28, Jason Johnston wrote:

I am interested (and I think the community needs to know) what 
Joerg's criteria for approving an eventual move to 1.5 would need to be, 
in some measurable way.  I'm sure he would agree that at some point in 
the future moving to 1.5+ will be appropriate, but how will we know when 
that time has come?


That's indeed a very difficult question. And there is probably nothing 
measurable. I argued with the silent user base still using Java 1.4 - 
they will probably also not stand up and shout Now we us Java 5, you 
can switch.


But I trust in our community health. Just have a look around on 
comparable frameworks and see what they are doing. I mentioned Spring. 
Geronimo is another case: Still a J2EE 1.4 server they think about JEE 5 
- and so Java 5. But they also think about Java 1.4 compatibility, be it 
via retro* or via plugins. Unfortunately they came not really into 
discussion about this topic [1], but went on to JPA.


Another question is about the efforts according to the libraries we are 
using. At the moment I don't know any actually requiring Java 5. And a 
framework should IMHO definitely not walk in the first line.


So, no, I don't have anything measurable. And we will probably have to 
think about this topic again, be it in one year or with the next minor 
or major version of Cocoon.


Jörg

[1] http://marc.theaimsgroup.com/?t=11550601875r=1w=4

Re: [Vote] Java 5 as minimum JDK requirement




Peter Hunsberger wrote:

On 8/15/06, Ralph Goers [EMAIL PROTECTED] wrote:



Peter Hunsberger wrote:
 Sorry, in my book that's not a valid reason.
I think it is inappropriate for you to judge whether his reason is valid
or not.


If one does not view a veto as valid then one has to challenge it.  To
do otherwise would not be taking your position as a committer
seriously.
His veto was challenged.  A reason was stated.  Now if the reason for 
the veto was the moon is not in alignment with the stars it would be 
reasonable to state that the reason isn't valid.  But the reason given 
was nothing of the kind.  That doesn't mean you can't try to convince 
him to change his mind using the two paragraphs that followed.  But the 
implication of the statement is that you don't recognize his -1 as being 
valid, when in fact it is.  You simply don't agree with it.



Furthermore, his veto won't be overturned by such a statement.
Although I agree with your argument below, I'm also not in favor of
questioning someone endlessly about a veto.


Ralph, I'm trying to be fair and ensure that Joerg has a real chance
to make his concerns known and that I'm not missing something.


Joerg did have a chance to make his concerns known and he did so. You 
disagreed with his opinion. That's fine.  I'm simply making a point that 
you should have left the sentence with  that's not a valid reason 
out.  To me, it sounds like a put down and that you won't recognize his 
veto unless he comes up with a reason more to your liking. 

Again, I don't happen to agree with his opinion either for much the same 
reasons you stated. But from what I understand of the rules on vetoing 
he has met his obligation and doesn't have to respond further if he 
doesn't choose to.


Ralph

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-16 Thread Reinhard Poetz


Ralph Goers wrote:
But from what I understand of the rules on vetoing 
he has met his obligation and doesn't have to respond further if he 
doesn't choose to.


I agree, except that he has to provide information *when* he thinks that we can 
switch to Java 5 (see Jason's mail). Otherwise we have to discuss this over and 
over again.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc



___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Vetoing (was [Result] [Vote] Java 5 as minimum JDK requirement)


Daniel Fagerstrom wrote:

Now something about vetoing:

According to 
http://www.apache.org/foundation/how-it-works.html#management


The rules require that a negative vote includes an alternative 
proposal or a detailed explanation of the reasons for the negative vote.


The community then tries to gather consensus on an alternative 
proposal that resolves the issue. In the great majority of cases, the 
concerns leading to the negative vote can be addressed.


This process is called consensus gathering and we consider it a very 
important indication of a healthy community.


To me it seem to put a lot of emphasis on reaching a consensus. Right 
now we have a veto that most of the community don't agree with. That 
is far away from consensus and is IMO _not_ an acceptable situation 
from a community health POV. This means that we have to continue to 
work until we find a solution that we can get a consensus around.
In this I absolutely agree.  As Reinhard reminded me vetoing is 
something that is very serious and should be used sparingly.


From this standpoint I think we should be even more specific than the 
first sentence. I would reword it to read The rules require that a 
negative vote includes a detailed explanation of the reasons for the 
negative vote and an alternative proposal or a statement defining what 
would be required for the negative vote to be rescinded


Ralph

Re: [Vote] Java 5 as minimum JDK requirement




Reinhard Poetz wrote:

Ralph Goers wrote:
But from what I understand of the rules on vetoing he has met his 
obligation and doesn't have to respond further if he doesn't choose to.


I agree, except that he has to provide information *when* he thinks 
that we can switch to Java 5 (see Jason's mail). Otherwise we have to 
discuss this over and over again.

From the consensus building perspective, that would be appropriate.

But please read my other email on vetoing.  Perhaps in the future we can 
build this into the process.


Ralph

Re: Re: [Vote] Java 5 as minimum JDK requirement

2006-08-16 Thread Torsten Curdt


 If one does not view a veto as valid then one has to challenge it.  To
 do otherwise would not be taking your position as a committer
 seriously.
His veto was challenged.  A reason was stated.  Now if the reason for
the veto was the moon is not in alignment with the stars it would be
reasonable to state that the reason isn't valid.  But the reason given
was nothing of the kind.  That doesn't mean you can't try to convince
him to change his mind using the two paragraphs that followed.  But the
implication of the statement is that you don't recognize his -1 as being
valid, when in fact it is.  You simply don't agree with it.


I think you are simplifying this situation a bit...

Let's say I am working for company A. Company A has a policy to only
use really stable and proven software. Don't change if you don't
have to. Basically they are still using JDK 1.3. I am a PMC member of
an OS project the company is using. Now is the non-upgrade policy of
that company A a valid reason for the individual PMC member to veto
the upgrade of the JDK requirement for the OS project?

...now I am curious

cheers
--
Torsten

Re: [Vote] Java 5 as minimum JDK requirement




Torsten Curdt wrote:

I think you are simplifying this situation a bit...

Let's say I am working for company A. Company A has a policy to only
use really stable and proven software. Don't change if you don't
have to. Basically they are still using JDK 1.3. I am a PMC member of
an OS project the company is using. Now is the non-upgrade policy of
that company A a valid reason for the individual PMC member to veto
the upgrade of the JDK requirement for the OS project?

...now I am curious 
Well, one implication of where you are going with this is, Is it 
appropriate to vote according to your employer's needs. My answer to 
that is, yes.  In fact, I'm certain that it happens all the time.  If 
you are a consultant who works for various people at various times you 
will continually be adding features each of your employer's needs.  I 
see nothing wrong in using your real world experience to influence 
your votes.  What is not OK is for you to be directed by your employer 
on how to vote on issues.


Now, in the scenario you provided it could be (and should be) argued 
that the PMC member is not acting appropriately as an individual. But 
you wouldn't necessarily know that depending on how the justification 
for the veto is made. With the current policy, this PMC member would be 
required to state their objection. It is implied that they are also 
supposed to help find an alternative proposal that can be agreed upon. 
But it may never really be obvious that the driving factor is the 
employer's policy.


However, using a policy that says that to veto an upgrade I have to 
either a) provide an alternative or b) provide a statement as to what 
would be required to rescind the veto would put this person in an 
awkward position.  Clearly they can't provide an alternative. So what 
would their statement be - We can upgrade when my employer says its 
OK?  That, clearly, is a violation of policy.


OTOH, what if the statement is It is OK to upgrade when BEA and IBM 
both have versions that support version nnn of XYZ and those versions 
have been available for at least a year?   I would argue that this 
moves from the category of voting on code modification to voting on 
procedure, in which case majority rules and the veto can be ignored if 
the majority does not agree.


Ralph

Re: [Result] [Vote] Java 5 as minimum JDK requirement

2006-08-16 Thread Andrew Savory


Hi,

Daniel Fagerstrom wrote:


To summarize how I understand the situation:

Joerg's main reason for the veto against using Java 5 in Cocoon 2.2 is 
that we would risk losing some of our user base.


I would be happier hearing this argument after a poll of the user list 
to see how many people:


a) require a Java 1.4 version of Cocoon 2.2
b) require a Java 1.5 version of Cocoon 2.2

There's a potential user base we would lose if we don't move forward. 
Damned if we do, damned if we don't ;-) It's a question of picking which 
is least damaging to the project as a whole, considering all existing 
and potential users.



Thanks,

Andrew.
--
Andrew Savory, Managing Director, Luminas Limited
Tel: +44 (0)870 741 6658  Fax: +44 (0)700 598 1135
Web: http://www.luminas.co.uk/
Orixo alliance: http://www.orixo.com/

Re: [Result] [Vote] Java 5 as minimum JDK requirement

2006-08-16 Thread Daniel Fagerstrom


Andrew Savory skrev:

Hi,

Daniel Fagerstrom wrote:


To summarize how I understand the situation:

Joerg's main reason for the veto against using Java 5 in Cocoon 2.2 
is that we would risk losing some of our user base.


I would be happier hearing this argument after a poll of the user list 
to see how many people:


a) require a Java 1.4 version of Cocoon 2.2
b) require a Java 1.5 version of Cocoon 2.2

There's a potential user base we would lose if we don't move forward. 
Damned if we do, damned if we don't ;-) It's a question of picking 
which is least damaging to the project as a whole, considering all 
existing and potential users.
Already done by Reinhard, see 
http://marc.theaimsgroup.com/?t=11552024823r=1w=2. This far 9 
users have answered, all of them support Java 5 in Cocoon 2.2


/Daniel

Re: Re: [Vote] Java 5 as minimum JDK requirement

2006-08-16 Thread Torsten Curdt


 ...now I am curious
Well, one implication of where you are going with this is, Is it
appropriate to vote according to your employer's needs. My answer to
that is, yes.  In fact, I'm certain that it happens all the time.


Oh boy! ...I probably should better stop participating in this thread then.
IMO PMC members should vote in the best interest of the project - not
in the best interest of their employers.


If you are a consultant who works for various people at various times you
will continually be adding features each of your employer's needs.  I
see nothing wrong in using your real world experience to influence
your votes.  What is not OK is for you to be directed by your employer
on how to vote on issues.


There is a difference in adding and blocking stuff.

snip/


OTOH, what if the statement is It is OK to upgrade when BEA and IBM
both have versions that support version nnn of XYZ and those versions
have been available for at least a year?   I would argue that this
moves from the category of voting on code modification to voting on
procedure, in which case majority rules and the veto can be ignored if
the majority does not agree.


...interesting! So do I dare to ask: what is the veto statement in our
case then?

cheers
--
Torsten

Re: [Result] [Vote] Java 5 as minimum JDK requirement

2006-08-16 Thread Antonio Gallardo


Reinhard Poetz escribió:
If I interpret our voting rules correctly, the proposal has been 
rejected because of the -1 vote.


Yes, please stop this thread. We can revisit this issue later. Perhaps 
our next major version will use java 1.5 as the minimal version. After 
all this is not stopping developers to use java 1.5 for his development 
needs, it is just cocoon that needs to be 1.4 compatible that's all. ;-)


Best Regards,

Antonio Gallardo.

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-15 Thread Joerg Heinicke

Joerg Heinicke joerg.heinicke at gmx.de writes:

 No, no. Please stay serious. There are other playgrounds to explore Java 
 5. It must not be Cocoon.

I made a typical error of Germans here. While must in English and muss in
German can be translated directly into eachother their negations have quite
different meanings. The sentence should read: It does not need to be Cocoon.

Jörg

Re: Re: [Vote] Java 5 as minimum JDK requirement

2006-08-15 Thread Torsten Curdt


 I still stand with my -1 vote. I don't want to be attacked personally
 for it. Sorry for it, but we don't agree here.

In that case I think it is time to put this discussion to rest. It
sounds like we have consensus for servlet 2.4 but not for Java 5.


Why does that sound like retroweaver/translater is not an option?

I haven't personally used it for such a huge project yet but obviously
other projects are using it - successfully. For the API differences they
provide a runtime jar btw.

I would rather give that a try than adjusting our project to the speed
of IT departments in large banks or organizations in general.

...and whoever thinks these little things don't make a difference in
coding should listen to some of the ruby talks available on the net.
Or even better - play a bit with it.

There is a fine line between getting stuck in legacy and loosing users.

From the feedback we got so far it sounds people are happy with

1.5. If we now can satisfy the legacy with some bytecode magic...

Please, let's do so!

cheers
--
Torsten

[Result] [Vote] Java 5 as minimum JDK requirement


Reinhard Poetz wrote:


As Java 5 was released almost 2 years ago, I propose making it the 
minimum requirement for trunk and all artifacts released from there.


here are the results:
15 binding   +1
 1 non-binding   +1
 1 binding   +0
 1 binding   -0
 1 binding   -1

If I interpret our voting rules correctly, the proposal has been rejected 
because of the -1 vote.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc






___ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de

Re: [Vote] Java 5 as minimum JDK requirement


Torsten Curdt wrote:

 I still stand with my -1 vote. I don't want to be attacked personally
 for it. Sorry for it, but we don't agree here.

In that case I think it is time to put this discussion to rest. It
sounds like we have consensus for servlet 2.4 but not for Java 5.


Why does that sound like retroweaver/translater is not an option?

I haven't personally used it for such a huge project yet but obviously
other projects are using it - successfully. For the API differences they
provide a runtime jar btw.

I would rather give that a try than adjusting our project to the speed
of IT departments in large banks or organizations in general.


yep, that's a pity. I guess if we wait for these organziations we can switch to 
1.5 in 2007 at the time when Java 7 will be released.



...and whoever thinks these little things don't make a difference in
coding should listen to some of the ruby talks available on the net.
Or even better - play a bit with it.

There is a fine line between getting stuck in legacy and loosing users.

From the feedback we got so far it sounds people are happy with

1.5. If we now can satisfy the legacy with some bytecode magic...

Please, let's do so!


Yes, I believe that would be a solution. The only question is *who* does the 
actual work of introducing the retroweaver, tests it, starts a vote on it ... 
any volunteers?


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc



___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: Re: [Vote] Java 5 as minimum JDK requirement

2006-08-15 Thread Torsten Curdt


 I would rather give that a try than adjusting our project to the speed
 of IT departments in large banks or organizations in general.

yep, that's a pity. I guess if we wait for these organziations we can switch to
1.5 in 2007 at the time when Java 7 will be released.


Yepp


 Please, let's do so!

Yes, I believe that would be a solution. The only question is *who* does the
actual work of introducing the retroweaver, tests it, starts a vote on it ...
any volunteers?


 http://mojo.codehaus.org/retroweaver-maven-plugin/index.html

Unless the site is just missing an update there is unfortunately still
some work to do.
It's just a skeleton :-( ...but there is an ant task

http://retroweaver.sourceforge.net/guide/retroweaver-guide.html

...so it should not be too hard. Still work though.

cheers
--
Torsten

Re: [Vote] Java 5 as minimum JDK requirement

On 8/14/06, Andrew Stevens [EMAIL PROTECTED] wrote:

From: Daniel Fagerstrom [EMAIL PROTECTED]
Date: Mon, 14 Aug 2006 22:19:28 +0200

Joerg Heinicke skrev:
Look, there might be excellent reasons for not upgrading and if there are
it is better that we find them. And I agree with Jorg that if many people
who otherwise would use 2.2 don't because of Java 5, that would be a good
reason for waiting with upgrading to Java 5. But this far no one have said
that they would have any problems with it, neither at cocoon-dev or
cocoon-user.

Okay, here's one :-)
I work for (a small part of) one of the big international banking groups.
In a brand new site that our team has only just started developing, we're
still restricted to servlet 2.3 and JDK 1.3 due to the version of Websphere
that's supported by another team over in the US that'll be hosting it for
us; if I'm very lucky they'll be willing to support a version that can
handle JDK 1.4 by the time we go live.  So switch to Java 5 if you wish, but
that'll leave me stuck on Cocoon 2.1.x for the forseeable future.

Sorry, in my book that's not a valid reason.

Can you give us a reason why being stuck on Cocoon 2.1 is a problem?
There are still sites running Cocoon 1...  Alternately, can you give
us something from Cocoon 2.2 that you need to have in order to run
your business?

Personally, from my experiences with Websphere I'd say being stuck on
a back release of Websphere is a far bigger problem than anything
Cocoon might cause...

--
Peter Hunsberger

Re: [Vote] Java 5 as minimum JDK requirement


On 8/14/06, Joerg Heinicke [EMAIL PROTECTED] wrote:

On 14.08.2006 22:19, Daniel Fagerstrom wrote:


snip/


This remains my main point though: losing some of our user base. You may
never have been working for a bank, but there such changes in the
requirements take years til they get applied. When we wrote an
application based on Mozilla 1.0 the customer still used Netscape 4.0.x,
not even the latest available version of Netscape at that time, which
was 4.7.x IIRC. We fought for weeks until it was allowed to get Mozilla
1.0 installed on their desktop computers. Andrew's mail from half an
hour ago seems to affirm this.


No, Andrews mail does not confirm anything. Why would any institution
that is so conservative that they run ancient versions of other
software suddenly jump to the bleeding edge of Cocoon?

If they are not willing to run a newer version of Websphere (with full
vendor support) that fixes 100s of know bugs then why would they
suddenly want to run some new version of Cocoon?

snip/


I still stand with my -1 vote.



Since you haven't given us any real reason to support your vote I
don't see how we can consider it a veto?

--
Peter Hunsberger

Re: [Result] [Vote] Java 5 as minimum JDK requirement


On 8/15/06, Reinhard Poetz [EMAIL PROTECTED] wrote:

Reinhard Poetz wrote:

 As Java 5 was released almost 2 years ago, I propose making it the
 minimum requirement for trunk and all artifacts released from there.

here are the results:
15 binding   +1
 1 non-binding   +1
 1 binding   +0
 1 binding   -0
 1 binding   -1

If I interpret our voting rules correctly, the proposal has been rejected
because of the -1 vote.



I disagree.  Joerg has not given us any real reason why Cocoon 2.2
needs to run on any of these older platforms.  In order for a veto to
be considered valid it must be based on a real problem.

I'll ask once more: if a company is so conservative with their
software upgrades that they are still running platforms that do not
support Java 1.5 then what possible reason would they have for wanting
to run Cocoon 2.2?

--
Peter Hunsberger

Re: [Vote] Java 5 as minimum JDK requirement


Peter Hunsberger wrote:

On 8/14/06, Joerg Heinicke [EMAIL PROTECTED] wrote:

On 14.08.2006 22:19, Daniel Fagerstrom wrote:


snip/


This remains my main point though: losing some of our user base. You may
never have been working for a bank, but there such changes in the
requirements take years til they get applied. When we wrote an
application based on Mozilla 1.0 the customer still used Netscape 4.0.x,
not even the latest available version of Netscape at that time, which
was 4.7.x IIRC. We fought for weeks until it was allowed to get Mozilla
1.0 installed on their desktop computers. Andrew's mail from half an
hour ago seems to affirm this.


No, Andrews mail does not confirm anything. Why would any institution
that is so conservative that they run ancient versions of other
software suddenly jump to the bleeding edge of Cocoon?


That's a very good point!

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc



___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-15 Thread Mark Lundquist



On Aug 15, 2006, at 6:56 AM, Peter Hunsberger wrote:


No, Andrews mail does not confirm anything. Why would any institution
that is so conservative that they run ancient versions of other
software suddenly jump to the bleeding edge of Cocoon?

If they are not willing to run a newer version of Websphere (with full
vendor support) that fixes 100s of know bugs then why would they
suddenly want to run some new version of Cocoon?


You hit the nail on the head!

—ml—

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-15 Thread Ralph Goers




Peter Hunsberger wrote:

Sorry, in my book that's not a valid reason.
I think it is inappropriate for you to judge whether his reason is valid 
or not.  Furthermore, his veto won't be overturned by such a statement.  
Although I agree with your argument below, I'm also not in favor of 
questioning someone endlessly about a veto.


Ralph


Can you give us a reason why being stuck on Cocoon 2.1 is a problem?
There are still sites running Cocoon 1...  Alternately, can you give
us something from Cocoon 2.2 that you need to have in order to run
your business?

Personally, from my experiences with Websphere I'd say being stuck on
a back release of Websphere is a far bigger problem than anything
Cocoon might cause...

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-15 Thread Antonio Gallardo


Reinhard Poetz escribió:

Torsten Curdt wrote:

 I still stand with my -1 vote. I don't want to be attacked personally
 for it. Sorry for it, but we don't agree here.

In that case I think it is time to put this discussion to rest. It
sounds like we have consensus for servlet 2.4 but not for Java 5.


Why does that sound like retroweaver/translater is not an option?

I haven't personally used it for such a huge project yet but obviously
other projects are using it - successfully. For the API differences they
provide a runtime jar btw.

I would rather give that a try than adjusting our project to the speed
of IT departments in large banks or organizations in general.


yep, that's a pity. I guess if we wait for these organziations we can 
switch to 1.5 in 2007 at the time when Java 7 will be released.



...and whoever thinks these little things don't make a difference in
coding should listen to some of the ruby talks available on the net.
Or even better - play a bit with it.

There is a fine line between getting stuck in legacy and loosing users.

From the feedback we got so far it sounds people are happy with

1.5. If we now can satisfy the legacy with some bytecode magic...

Please, let's do so!


Yes, I believe that would be a solution. The only question is *who* 
does the actual work of introducing the retroweaver, tests it, starts 
a vote on it ... any volunteers?
Why we should take care of the retroweaver option. A paragraph 
mentioning retroweaver for people using a lower java version should be 
enough. More than that I think it is out of the cocoon scope.


Best Regards

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-15 Thread Vadim Gritsenko


Peter Hunsberger wrote:

On 8/14/06, Joerg Heinicke [EMAIL PROTECTED] wrote:

On 14.08.2006 22:19, Daniel Fagerstrom wrote:


snip/


This remains my main point though: losing some of our user base. You may
never have been working for a bank, but there such changes in the
requirements take years til they get applied. When we wrote an
application based on Mozilla 1.0 the customer still used Netscape 4.0.x,
not even the latest available version of Netscape at that time, which
was 4.7.x IIRC. We fought for weeks until it was allowed to get Mozilla
1.0 installed on their desktop computers. Andrew's mail from half an
hour ago seems to affirm this.


No, Andrews mail does not confirm anything. Why would any institution
that is so conservative that they run ancient versions of other
software suddenly jump to the bleeding edge of Cocoon?

If they are not willing to run a newer version of Websphere (with full
vendor support) that fixes 100s of know bugs then why would they
suddenly want to run some new version of Cocoon?


That's a good point. I think Cocoon 2.2 can move to Java 1.5 this year as long 
as Cocoon 2.1 is not EOL-ed (End Of Life) for 1-2 years to give companies 
which are dragging their feet two more years of supported Cocoon 2.1 releases.


Vadim

Re: [Result] [Vote] Java 5 as minimum JDK requirement

2006-08-15 Thread Jason Johnston


Peter Hunsberger wrote:

On 8/15/06, Reinhard Poetz [EMAIL PROTECTED] wrote:

If I interpret our voting rules correctly, the proposal has been rejected
because of the -1 vote.



I disagree.  Joerg has not given us any real reason why Cocoon 2.2
needs to run on any of these older platforms.  In order for a veto to
be considered valid it must be based on a real problem.



While I'm not personally interested in trying at this point to overturn 
his veto, I am interested (and I think the community needs to know) what 
Joerg's criteria for approving an eventual move to 1.5 would need to be, 
in some measurable way.  I'm sure he would agree that at some point in 
the future moving to 1.5+ will be appropriate, but how will we know when 
that time has come?


So far I've seen the following rationales (please add any I missed):

* Spring supports 1.3, we're both frameworks, so we should follow.
* Can't see any significant advantages of 1.5.
* Some users (who may not be active on these mailing lists) are stuck 
with older containers and cannot upgrade.


This last point is IMO the most relevant, but is still very abstract. 
How do we measure how many of these users there are, who could not get 
by using 2.1.x?  At what point do we say enough is enough and make the 
cut; how many users can we afford to leave behind?  The answer 
obviously can't be none since there will always be someone.  If a 
workable tool like Retroweaver were available would that change these 
criteria?


I'd like to hear Joerg's opinion especially on these questions, since 
his criteria seem to be different than most others'.

--Jason

Re: Re: [Vote] Java 5 as minimum JDK requirement

2006-08-15 Thread Torsten Curdt


Peter Hunsberger wrote:
 Sorry, in my book that's not a valid reason.
I think it is inappropriate for you to judge whether his reason is valid
or not.


He said in my book


 Furthermore, his veto won't be overturned by such a statement.
Although I agree with your argument below, I'm also not in favor of
questioning someone endlessly about a veto.


As a mater of fact a veto needs to have a good reason.

Especially now with the argument Peter was giving I am
also questioning whether that is actually a good reason.

I don't think that this thread is endless yet. We already had
much longer discussions about much less. If someone vetos
something he needs to be prepared to stand up for that and face
the discussion ...as long as we keep this on a professional
level (...no pointing fingers, other communities in mind)

cheers
--
Torsten

Re: [Vote] Java 5 as minimum JDK requirement


On 8/15/06, Ralph Goers [EMAIL PROTECTED] wrote:



Peter Hunsberger wrote:
 Sorry, in my book that's not a valid reason.
I think it is inappropriate for you to judge whether his reason is valid
or not.


If one does not view a veto as valid then one has to challenge it.  To
do otherwise would not be taking your position as a committer
seriously.


Furthermore, his veto won't be overturned by such a statement.
Although I agree with your argument below, I'm also not in favor of
questioning someone endlessly about a veto.


Ralph, I'm trying to be fair and ensure that Joerg has a real chance
to make his concerns known and that I'm not missing something.



Ralph

 Can you give us a reason why being stuck on Cocoon 2.1 is a problem?
 There are still sites running Cocoon 1...  Alternately, can you give
 us something from Cocoon 2.2 that you need to have in order to run
 your business?

 Personally, from my experiences with Websphere I'd say being stuck on
 a back release of Websphere is a far bigger problem than anything
 Cocoon might cause...




--
Peter Hunsberger

Re: [Result] [Vote] Java 5 as minimum JDK requirement

2006-08-15 Thread Jorg Heymans


On 15 Aug 2006, at 16:01, Peter Hunsberger wrote:


I disagree.  Joerg has not given us any real reason why Cocoon 2.2
needs to run on any of these older platforms.  In order for a veto to
be considered valid it must be based on a real problem.


He has, but it seems you're not accepting them :-P


I'll ask once more: if a company is so conservative with their
software upgrades that they are still running platforms that do not
support Java 1.5 then what possible reason would they have for wanting
to run Cocoon 2.2?



But this has _nothing_ to do with being conservative!  The impact of  
upgrading the app server platform site-wide, ie globally in case of a  
multinational, is huge when there are hundreds of apps running on it.  
This does not mean however that those apps individually cannot  
upgrade their cocoon version from 2.1 to 2.2 .


I'ld say we stop argueing about this and use our time more  
constructively to experiment with the retroweaver. I hear it has an  
ant task, integrating it into our build process should be a breeze then.


Regards
Jorg

Re: [Result] [Vote] Java 5 as minimum JDK requirement

2006-08-15 Thread Daniel Fagerstrom


Jorg Heymans skrev:
...
I'ld say we stop argueing about this and use our time more 
constructively to experiment with the retroweaver. I hear it has an ant 
task, integrating it into our build process should be a breeze then.


This seem like a reasonable proposal to me.



To summarize how I understand the situation:

Joerg's main reason for the veto against using Java 5 in Cocoon 2.2 is 
that we would risk losing some of our user base.


Now if experiments with retroweaver/retrotranslator show that we can use 
Java 1.5 _and_ produce libraries that work in a Java 1.4 environment, 
the above problem should be resolved and Joerg should be able to retract 
his veto. Right Joerg?


In such a case (i.e. if Joerg retract his veto) we would not need a new 
vote for starting to use Java 5.


Now, AFAIU retroweaver/retrotranslator have some (small) limitations, so 
we probably would need a new proposal that says that we use the subset 
of Java 5 supported by retroweaver/retrotranslator.


(Here is a link about how retrotranslator is used in Stripes 
http://stripes.mc4j.org/confluence/display/stripes/Java+1.4+and+Stripes.)




Now something about vetoing:

According to http://www.apache.org/foundation/how-it-works.html#management

The rules require that a negative vote includes an alternative proposal 
or a detailed explanation of the reasons for the negative vote.


The community then tries to gather consensus on an alternative proposal 
that resolves the issue. In the great majority of cases, the concerns 
leading to the negative vote can be addressed.


This process is called consensus gathering and we consider it a very 
important indication of a healthy community.


To me it seem to put a lot of emphasis on reaching a consensus. Right 
now we have a veto that most of the community don't agree with. That is 
far away from consensus and is IMO _not_ an acceptable situation from a 
community health POV. This means that we have to continue to work until 
we find a solution that we can get a consensus around.


/Daniel

Re: [Result] [Vote] Java 5 as minimum JDK requirement


On 8/15/06, Jorg Heymans [EMAIL PROTECTED] wrote:

On 15 Aug 2006, at 16:01, Peter Hunsberger wrote:

 I disagree.  Joerg has not given us any real reason why Cocoon 2.2
 needs to run on any of these older platforms.  In order for a veto to
 be considered valid it must be based on a real problem.

He has, but it seems you're not accepting them :-P


With all due respect I don't think that is the case.  So far, the only
argument we have against using Java 5 is abstract: there might be
users who need to run Cocoon 2.2 on platforms that don't support Java
5.  No one has given any real reason why this would be the case!



 I'll ask once more: if a company is so conservative with their
 software upgrades that they are still running platforms that do not
 support Java 1.5 then what possible reason would they have for wanting
 to run Cocoon 2.2?


But this has _nothing_ to do with being conservative!  The impact of
upgrading the app server platform site-wide, ie globally in case of a
multinational, is huge when there are hundreds of apps running on it.
This does not mean however that those apps individually cannot
upgrade their cocoon version from 2.1 to 2.2 .


I've been one of the people in charge of systems strategy in a company
with over 40,000 people. I'm pretty aware of what it takes to move
forward in such an organization.  That's part of the reason I think
the argument is bogus.  Any company that can't move to a Java 5
compatible web server is many years away from using Cocoon 2.2.


I'ld say we stop argueing about this and use our time more
constructively to experiment with the retroweaver. I hear it has an
ant task, integrating it into our build process should be a breeze then.


Personally, I think it would be not to have to spend time
experimenting with retroweaver or such in the first place...

--
Peter Hunsberger

Re: [Result] [Vote] Java 5 as minimum JDK requirement


Jason Johnston wrote:

Peter Hunsberger wrote:

On 8/15/06, Reinhard Poetz [EMAIL PROTECTED] wrote:
If I interpret our voting rules correctly, the proposal has been 
rejected

because of the -1 vote.



I disagree.  Joerg has not given us any real reason why Cocoon 2.2
needs to run on any of these older platforms.  In order for a veto to
be considered valid it must be based on a real problem.



While I'm not personally interested in trying at this point to overturn 
his veto, I am interested (and I think the community needs to know) what 
Joerg's criteria for approving an eventual move to 1.5 would need to be, 
in some measurable way.  I'm sure he would agree that at some point in 
the future moving to 1.5+ will be appropriate, but how will we know when 
that time has come?


So far I've seen the following rationales (please add any I missed):

* Spring supports 1.3, we're both frameworks, so we should follow.
* Can't see any significant advantages of 1.5.
* Some users (who may not be active on these mailing lists) are stuck 
with older containers and cannot upgrade.


This last point is IMO the most relevant, but is still very abstract. 
How do we measure how many of these users there are, who could not get 
by using 2.1.x?  At what point do we say enough is enough and make the 
cut; how many users can we afford to leave behind?  The answer 
obviously can't be none since there will always be someone.  If a 
workable tool like Retroweaver were available would that change these 
criteria?


I'd like to hear Joerg's opinion especially on these questions, since 
his criteria seem to be different than most others'.


Yes, that needs to be the outcome of this discussion so that we don't have to 
discuss the same topic again.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc



___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-14 Thread Peter Hunsberger


On 8/11/06, Jorg Heymans [EMAIL PROTECTED] wrote:

On 11 Aug 2006, at 20:34, Peter Hunsberger wrote:

 On 8/11/06, Jorg Heymans [EMAIL PROTECTED] wrote:
 I felt that my current involvement in cocoon is not big enough to
 warrant a veto, hence the -0 here. WLS 8.1 was just an example
 from my
 past experience, but technically you're right ofcourse.

 Based on the Voting Policies thread I think it's legitimate for me
 to ask if you can give us a _compelling_ reason why you need to run
 Cocoon 2.2 on a platform that does not have Java 5 support and why
 running Cocoon 2.1 instead isn't sufficient?  If you have a real use
 case that requires Cocoon 2.2 on some platform that does not support
 Java 5 then I think a veto would be appropriate. Otherwise, I think a
 -0 would be a good indication of concern.


Just as much as i can't give a more compelling reason than i already
have, there is no compelling reason to do the switch either. The core
of my concern, _bluntly put_, was to limit our possible target
audience for the sake of being able to write enhanced for loops.


We've already run into problems deploying Coccon with third party Java
5.0 libraries.  At this point it appears that our config. has to run
under a Java 5 compatible JVM in any case, and this is with Cocoon
2.1.  Better type safety may not be compelling but it's a pretty big
selling feature in my book.

The way any product or project moves forward is usually by small
incremental changes; these should never be blocked unless there is a
real reason.  In other words, the reasons for blocking a project from
going forward must be compelling.  The reasons to move forward need
simply to be that the project is better than before.

snip/

--
Peter Hunsberger

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-14 Thread Daniel Fagerstrom


Joerg Heinicke skrev:

On 10.08.2006 11:41, Daniel Fagerstrom wrote:


As Java 5 was released almost 2 years ago, I propose making it the
minimum requirement for trunk and all artifacts released from there.


-0, because this means eliminating cocoon 2.2 on older application
servers eg weblogic 8.1.
IIUC weblogic 8.1 uses servlet 2.3 so I guess you need to veto the 
use of servlet 2.4 to make this a valid point.


Don't know about Weblogic (it was not my argument),
Joerg, vetoing a proposal is a serious issue as your single vote blocks 
everyone else vote. That means that all argument for the veto must be 
scrutinized so that we as a community can find a consensus based on facts.


And as your veto is based on among other things servlet container 
compatibility we need to know if there are containers that we find it 
important to support for 2.2 that doesn't work with Java 5.


but servlet spec does not matter that deeply IMO. I voted +1 on 
servlet 2.4 mostly because of the request listeners. As long as the 
2.4 features are kept out of core (which of them can surface 
coincidentally?) we still can claim 2.3 compatibility and provide 2.4 
features like request listeners as optional features. The same way 
Spring is handling the request/session scoped beans by providing a 
listener [1] (see Javadoc) and a filter [2].
The servlet API has always been a central part of Cocoon and with 2.2 it 
becomes even more important as it is used instead of the Processor 
interface. To follow what you say above means in practice that core 
parts of Cocoon must not use 2.4 and that 2.4 can only be used in 
optional blocks that no important functionality should depend on. The 
vote about Servlet 2.4 was about using Servlet 2.4 in trunk. If you want 
to achieve what you describe above you must veto that proposal and make 
an alternative proposal.


If there are other use cases that require Java 1.4 you should 
seriously consider if Simones proposal of using the Retroweaver would 
be enough.


This works only as long as you don't use extensions made to the JDK 
classes. Different JDK versions are not just about language features 
but also about APIs. So this is no replacement IMO.
OK. So that bring us back to the key question: what specific problem 
would we get by using Java 5?



Frankly, I don't see the point in upgrading unless there's a killer
feature in 1.5 that
1) we are likely to use and implement in the near future (2006) and,
2) will improve cocoon by a significant margin.
We never require something like that when we update the version on 
libraries we depend on. For libraries we depend on the latest stable 
version as long as it doesn't create any problems, we never require 
that anybody is going to use the latest features.


Don't understand that point.
Our policy is to always use the latest stable version of all libraries 
that we depend on. There are many good reasons for that: we get 
presumably less buggy and better versions of the libraries, our adaption 
becomes to newer versions becomes gradual instead of abrupt as we update 
often and we help both the communities we depend on and ourselves by 
testing early.


So our policy for updating libraries is far for what you require for 
updating JDK. Also, not updating JDK will give us increasing problems in 
using the latest stable version of used libraries as they are starting 
to require Java 5.


For the killer features, lots of people have said that they are 
interested in using various features in Java 5, do you find your lack of 
interest in these features a strong enough reason to prevent others from 
using them?


I second this, but vote even -1. I wonder why a framework should set 
such high requirements. Have a look on spring. They have a Java 1.3 
as minimum requirement and only need Java 5 for special features.


IMO we should do it in a similar manner and not set the general 
requirement to Java 5.
Cocoon is both a framework and a set of applications. Compared to 
Spring, Cocoon is less framework oriented.


Understand what you want to claim, but can't follow. Why do you think so?
The core offering from the Spring framework is the bean factory, which 
is a low level framework that is used in numerous other projects many of 
which are used by still other projects in turn. Cocoon is a much higher 
level framework, and is with a few exceptions used directly to build 
applications with. This means that it is enough to ask our users what 
they think, while Spring need to understand their users users. And 
because of that need to be more conservative.


So, Cocoon and Spring are quite different kind of beasts, so we need to 
understand why they support Java 1.3 to know if their reasons are 
relevant for us.


If you want to follow the Spring policy I think you should formulate 
an alternative proposal which describes when it is OK to use Java 5 
and when it is not.


Isn't this quite easy? Always provide a Java 1.4 alternative and make 
Java 5 features

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-14 Thread Jorg Heymans


On 14 Aug 2006, at 15:48, Peter Hunsberger wrote:


On 8/11/06, Jorg Heymans [EMAIL PROTECTED] wrote:



Just as much as i can't give a more compelling reason than i already
have, there is no compelling reason to do the switch either. The core
of my concern, _bluntly put_, was to limit our possible target
audience for the sake of being able to write enhanced for loops.


The way any product or project moves forward is usually by small
incremental changes; these should never be blocked unless there is a
real reason.  In other words, the reasons for blocking a project from
going forward must be compelling.  The reasons to move forward need
simply to be that the project is better than before.


I think you're oversimplifying the situation here (and quite possibly  
i'm overcomplicating it).


- A JDK requirement change is neither small nor incremental.
- The reason to move a project forward should indeed be that the  
project is better than before, but not at all costs (read userbase).



Regards
Jorg

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-14 Thread Joerg Heinicke


On 11.08.2006 20:41, Don Brown wrote:


Actually, you'd be surprised to what Retroweaver/Retrotranslator can
handle.  Stripes, a Java 5 annotation-heavy web framework recently
used it to allow Java 1.4 apps to use Stripes, despite using new Java
5 methods, annotations, and other features quite heavily.  We (Struts)
are planning on using Retrotranslator to support Java 1.4, while
taking full advantage of Java 5 annotations and new class methods.


It can handle changes in the APIs like 
https://svn.apache.org/viewvc?view=revrevision=422219 (Java 1.3 vs. 
1.4)? Or maybe even JDBC 3.0 vs JDBC 2.0? How is it doing it?


Jörg

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-14 Thread Don Brown


Its Ant or command line task uses a bytecode scanner to detect Java 5
features and either replace them with their pre-Java 5 equivilent
(StringBuilder - StringBuffer) or a third party library (Doug Lea's
Concurrency library).  In the more extreme cases such as annotations,
to be honest, I'm not sure exactly how it works, only that it does and
Stripes is proof of that.

FWIW, Java 5 has had a big impact on Struts 2 development that we feel
justifies the jump:
* Cleaner API's with var args and generics
* Annotations where externalized XML isn't necessary
* Rich concurrency classes
* Solid XML support w/o lib/endorsed
* Type-safe enums to minimize unimplemented interfaces

Each of the features can be implemented in other ways, but taken as a
whole, they make your framework easier to use, understand, and
support.

Don

On 8/14/06, Joerg Heinicke [EMAIL PROTECTED] wrote:

On 11.08.2006 20:41, Don Brown wrote:

 Actually, you'd be surprised to what Retroweaver/Retrotranslator can
 handle.  Stripes, a Java 5 annotation-heavy web framework recently
 used it to allow Java 1.4 apps to use Stripes, despite using new Java
 5 methods, annotations, and other features quite heavily.  We (Struts)
 are planning on using Retrotranslator to support Java 1.4, while
 taking full advantage of Java 5 annotations and new class methods.

It can handle changes in the APIs like
https://svn.apache.org/viewvc?view=revrevision=422219 (Java 1.3 vs.
1.4)? Or maybe even JDBC 3.0 vs JDBC 2.0? How is it doing it?

Jörg

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-14 Thread Andrew Stevens

From: Daniel Fagerstrom [EMAIL PROTECTED]
Date: Mon, 14 Aug 2006 22:19:28 +0200

Joerg Heinicke skrev:
Look, there might be excellent reasons for not upgrading and if there are 
it is better that we find them. And I agree with Jorg that if many people 
who otherwise would use 2.2 don't because of Java 5, that would be a good 
reason for waiting with upgrading to Java 5. But this far no one have said 
that they would have any problems with it, neither at cocoon-dev or 
cocoon-user.

Okay, here's one :-)
I work for (a small part of) one of the big international banking groups.  
In a brand new site that our team has only just started developing, we're 
still restricted to servlet 2.3 and JDK 1.3 due to the version of Websphere 
that's supported by another team over in the US that'll be hosting it for 
us; if I'm very lucky they'll be willing to support a version that can 
handle JDK 1.4 by the time we go live.  So switch to Java 5 if you wish, but 
that'll leave me stuck on Cocoon 2.1.x for the forseeable future.

Andrew.

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-14 Thread Joerg Heinicke


On 14.08.2006 22:19, Daniel Fagerstrom wrote:

And as your veto is based on among other things servlet container 
compatibility we need to know if there are containers that we find it 
important to support for 2.2 that doesn't work with Java 5.


As I already said: servlet containers have not been my argument! I only 
added a comment to your first answer.


but servlet spec does not matter that deeply IMO. I voted +1 on 
servlet 2.4 mostly because of the request listeners. As long as the 
2.4 features are kept out of core (which of them can surface 
coincidentally?) we still can claim 2.3 compatibility and provide 2.4 
features like request listeners as optional features. The same way 
Spring is handling the request/session scoped beans by providing a 
listener [1] (see Javadoc) and a filter [2].
The servlet API has always been a central part of Cocoon and with 2.2 it 
becomes even more important as it is used instead of the Processor 
interface.


Of course.

To follow what you say above means in practice that core 
parts of Cocoon must not use 2.4 and that 2.4 can only be used in 
optional blocks that no important functionality should depend on. The 
vote about Servlet 2.4 was about using Servlet 2.4 in trunk. If you want 
to achieve what you describe above you must veto that proposal and make 
an alternative proposal.


The above walk just talking in large. In the meantime I had a look into 
the 2.4 spec what actually changed since 2.3. And indeed besides minor 
refinements (IMO unimportant to Cocoon) it's only the request listener 
that's new. And even if Cocoon uses these features and does not provide 
alternatives I can live with it as it is only a small amount of code 
that would be needed to be implemented in case somebody needs really 
2.3. That's why I support the change to 2.4. The impact is very low. A 
bigger change in the API would probably have not gotten my approval as 
well ...


Besides this I don't really see how it is related to Java 5.

OK. So that bring us back to the key question: what specific problem 
would we get by using Java 5?


So our policy for updating libraries is far for what you require for 
updating JDK. Also, not updating JDK will give us increasing problems in 
using the latest stable version of used libraries as they are starting 
to require Java 5.


I don't care that much about that point. There are not many libraries 
actually requiring Java 5. And besides that those might provide Java 1.4 
compatible releases as well.


For the killer features, lots of people have said that they are 
interested in using various features in Java 5, do you find your lack of 
interest in these features a strong enough reason to prevent others from 
using them?


Missing interest is for sure not my reason to veto the change.

(This is getting me too personal here ... please don't imply such 
ignorance.)


The core offering from the Spring framework is the bean factory, which 
is a low level framework that is used in numerous other projects many of 
which are used by still other projects in turn. Cocoon is a much higher 
level framework, and is with a few exceptions used directly to build 
applications with. This means that it is enough to ask our users what 
they think, while Spring need to understand their users users. And 
because of that need to be more conservative.


So, Cocoon and Spring are quite different kind of beasts, so we need to 
understand why they support Java 1.3 to know if their reasons are 
relevant for us.


I absolutely can't agree. Both are just application frameworks - with 
Cocoon being more web-tied.


Isn't this quite easy? Always provide a Java 1.4 alternative and make 
Java 5 features optional. See declarative transaction demarcation in 
Spring. It's completely possible without Java 5. But you can use 
annotations for it as well. And even those can be used with Java 1.4 
and commons attributes IIRC.
Always providing a 1.4 alternative means a lot of extra, and fairly 
boring, work. I think we better focus on one version.


Might be. That was just my proposal instead of switching to Java 5.


I simply still can't see how Java 5 will help us significantly.
And if you keep your veto you will prevent all the rest of us who 
believe that it would help us to explore if it will help us as well.


No, no. Please stay serious. There are other playgrounds to explore Java 
5. It must not be Cocoon.



But this far no one have said that they would have any problems with
it, neither at cocoon-dev or cocoon-user.


This remains my main point though: losing some of our user base. You may 
never have been working for a bank, but there such changes in the 
requirements take years til they get applied. When we wrote an 
application based on Mozilla 1.0 the customer still used Netscape 4.0.x, 
not even the latest available version of Netscape at that time, which 
was 4.7.x IIRC. We fought for weeks until it was allowed to get Mozilla 
1.0 installed on their desktop

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-14 Thread Ralph Goers




Joerg Heinicke wrote:
I still stand with my -1 vote. I don't want to be attacked personally 
for it. Sorry for it, but we don't agree here.


In that case I think it is time to put this discussion to rest. It 
sounds like we have consensus for servlet 2.4 but not for Java 5.


Ralph

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-11 Thread Jorg Heymans


Daniel Fagerstrom wrote:

 -0, because this means eliminating cocoon 2.2 on older application
 servers eg weblogic 8.1.
 IIUC weblogic 8.1 uses servlet 2.3 so I guess you need to veto the use
 of servlet 2.4 to make this a valid point.


I felt that my current involvement in cocoon is not big enough to
warrant a veto, hence the -0 here. WLS 8.1 was just an example from my
past experience, but technically you're right ofcourse.


Jorg

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-11 Thread Antonio Gallardo


Jorg Heymans escribió:

Daniel Fagerstrom wrote:

  

-0, because this means eliminating cocoon 2.2 on older application
servers eg weblogic 8.1.


IIUC weblogic 8.1 uses servlet 2.3 so I guess you need to veto the use
of servlet 2.4 to make this a valid point.




I felt that my current involvement in cocoon is not big enough to
warrant a veto, hence the -0 here. WLS 8.1 was just an example from my
past experience, but technically you're right ofcourse.
  

Jorg,

you (as any other pmc member) have the right to veto. Please keep in 
mind that everybody collaborate as much as he can. Feedback providing is 
a fact that you care about this project. :-)


We should not accept you vote change due this reason, because it seems 
to be more an emotional reason than a technical reason.


Best Regards,

Antonio Gallardo.

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-11 Thread Peter Hunsberger


On 8/11/06, Jorg Heymans [EMAIL PROTECTED] wrote:


Daniel Fagerstrom wrote:

 -0, because this means eliminating cocoon 2.2 on older application
 servers eg weblogic 8.1.
 IIUC weblogic 8.1 uses servlet 2.3 so I guess you need to veto the use
 of servlet 2.4 to make this a valid point.


I felt that my current involvement in cocoon is not big enough to
warrant a veto, hence the -0 here. WLS 8.1 was just an example from my
past experience, but technically you're right ofcourse.


Based on the Voting Policies thread I think it's legitimate for me
to ask if you can give us a _compelling_ reason why you need to run
Cocoon 2.2 on a platform that does not have Java 5 support and why
running Cocoon 2.1 instead isn't sufficient?  If you have a real use
case that requires Cocoon 2.2 on some platform that does not support
Java 5 then I think a veto would be appropriate. Otherwise, I think a
-0 would be a good indication of concern.

--
Peter Hunsberger

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-11 Thread Don Brown


On 8/10/06, Joerg Heinicke [EMAIL PROTECTED] wrote:

 If there are other use cases that require Java 1.4 you should seriously
 consider if Simones proposal of using the Retroweaver would be enough.

This works only as long as you don't use extensions made to the JDK
classes. Different JDK versions are not just about language features but
also about APIs. So this is no replacement IMO.


Actually, you'd be surprised to what Retroweaver/Retrotranslator can
handle.  Stripes, a Java 5 annotation-heavy web framework recently
used it to allow Java 1.4 apps to use Stripes, despite using new Java
5 methods, annotations, and other features quite heavily.  We (Struts)
are planning on using Retrotranslator to support Java 1.4, while
taking full advantage of Java 5 annotations and new class methods.

Don

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-11 Thread Jorg Heymans


On 11 Aug 2006, at 20:34, Peter Hunsberger wrote:


On 8/11/06, Jorg Heymans [EMAIL PROTECTED] wrote:

I felt that my current involvement in cocoon is not big enough to
warrant a veto, hence the -0 here. WLS 8.1 was just an example  
from my

past experience, but technically you're right ofcourse.


Based on the Voting Policies thread I think it's legitimate for me
to ask if you can give us a _compelling_ reason why you need to run
Cocoon 2.2 on a platform that does not have Java 5 support and why
running Cocoon 2.1 instead isn't sufficient?  If you have a real use
case that requires Cocoon 2.2 on some platform that does not support
Java 5 then I think a veto would be appropriate. Otherwise, I think a
-0 would be a good indication of concern.



Just as much as i can't give a more compelling reason than i already  
have, there is no compelling reason to do the switch either. The core  
of my concern, _bluntly put_, was to limit our possible target  
audience for the sake of being able to write enhanced for loops.


Having said all this, the retroweaver stuff looks quite funky and  
might very well make this whole discussion obsolete in a few months.


Cheers,
Jorg

Re: Re: [Vote] Java 5 as minimum JDK requirement

2006-08-10 Thread Bertrand Delacretaz


On 8/10/06, Reinhard Poetz [EMAIL PROTECTED] wrote:


...There are many new features in Java 5 which make the life of
developers easier...


IMHO most of the Java 5 features are syntactic sugar (generics, enums,
etc.) which make little difference to the final product, they are
just convenience for code writers.

The one feature that could make an actual difference would be the use
of annotations, to generate code or configs, for automatic
documentation, etc.

Considering Jorg's points, we might want to wait for a compelling
reason to require Java 5, which might be some creative use of
annotations.

-Bertrand

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-10 Thread Daniel Fagerstrom


Joerg Heinicke skrev:

On 08.08.2006 18:47, Jorg Heymans wrote:


As Java 5 was released almost 2 years ago, I propose making it the
minimum requirement for trunk and all artifacts released from there.


-0, because this means eliminating cocoon 2.2 on older application
servers eg weblogic 8.1.
IIUC weblogic 8.1 uses servlet 2.3 so I guess you need to veto the use 
of servlet 2.4 to make this a valid point.


If there are other use cases that require Java 1.4 you should seriously 
consider if Simones proposal of using the Retroweaver would be enough.



Frankly, I don't see the point in upgrading unless there's a killer
feature in 1.5 that
1) we are likely to use and implement in the near future (2006) and,
2) will improve cocoon by a significant margin.
We never require something like that when we update the version on 
libraries we depend on. For libraries we depend on the latest stable 
version as long as it doesn't create any problems, we never require that 
anybody is going to use the latest features.


I second this, but vote even -1. I wonder why a framework should set 
such high requirements. Have a look on spring. They have a Java 1.3 as 
minimum requirement and only need Java 5 for special features.


IMO we should do it in a similar manner and not set the general 
requirement to Java 5.
Cocoon is both a framework and a set of applications. Compared to 
Spring, Cocoon is less framework oriented. If you want to follow the 
Spring policy I think you should formulate an alternative proposal which 
describes when it is OK to use Java 5 and when it is not.


/Daniel

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-10 Thread Joerg Heinicke

On 10.08.2006 11:41, Daniel Fagerstrom wrote:

As Java 5 was released almost 2 years ago, I propose making it the
minimum requirement for trunk and all artifacts released from there.

-0, because this means eliminating cocoon 2.2 on older application
servers eg weblogic 8.1.
IIUC weblogic 8.1 uses servlet 2.3 so I guess you need to veto the use
of servlet 2.4 to make this a valid point.

Don't know about Weblogic (it was not my argument), but servlet spec
does not matter that deeply IMO. I voted +1 on servlet 2.4 mostly
because of the request listeners. As long as the 2.4 features are kept
out of core (which of them can surface coincidentally?) we still can
claim 2.3 compatibility and provide 2.4 features like request listeners
as optional features. The same way Spring is handling the
request/session scoped beans by providing a listener [1] (see Javadoc)
and a filter [2].

If there are other use cases that require Java 1.4 you should seriously
consider if Simones proposal of using the Retroweaver would be enough.

This works only as long as you don't use extensions made to the JDK
classes. Different JDK versions are not just about language features but
also about APIs. So this is no replacement IMO.

Frankly, I don't see the point in upgrading unless there's a killer
feature in 1.5 that
1) we are likely to use and implement in the near future (2006) and,
2) will improve cocoon by a significant margin.
We never require something like that when we update the version on
libraries we depend on. For libraries we depend on the latest stable
version as long as it doesn't create any problems, we never require that
anybody is going to use the latest features.

Don't understand that point.

I second this, but vote even -1. I wonder why a framework should set
such high requirements. Have a look on spring. They have a Java 1.3 as
minimum requirement and only need Java 5 for special features.

IMO we should do it in a similar manner and not set the general
requirement to Java 5.
Cocoon is both a framework and a set of applications. Compared to
Spring, Cocoon is less framework oriented.

Understand what you want to claim, but can't follow. Why do you think so?

If you want to follow the
Spring policy I think you should formulate an alternative proposal which
describes when it is OK to use Java 5 and when it is not.

Isn't this quite easy? Always provide a Java 1.4 alternative and make
Java 5 features optional. See declarative transaction demarcation in
Spring. It's completely possible without Java 5. But you can use
annotations for it as well. And even those can be used with Java 1.4 and
commons attributes IIRC.

I simply still can't see how Java 5 will help us significantly.

Regards,
Jörg

[1]
http://springframework.cvs.sourceforge.net/springframework/spring/src/org/springframework/web/context/request/RequestContextListener.java
[2]
http://springframework.cvs.sourceforge.net/springframework/spring/src/org/springframework/web/filter/RequestContextFilter.java

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-10 Thread Simone Gianni



Joerg Heinicke wrote:


 I simply still can't see how Java 5 will help us significantly.

I've been thinking the same for two years, recently started a new
project on java 5, and yes, it is better from a coding point of view.
Brings more or less nothing to the final user, except better written
code, which is not nothing at all.

But again, for those users that have a strict need for 1.4, what about
tools like http://retroweaver.sourceforge.net/ or
http://retrotranslator.sourceforge.net/ which also have a maven plugin?
I'm testing my java 5 application, retro-compiled to java 4, and it
seems to work correctly.

Simone

-- 
Simone Gianni

Re: Re: [Vote] Java 5 as minimum JDK requirement

2006-08-10 Thread Torsten Curdt


I've been thinking the same for two years, recently started a new
project on java 5, and yes, it is better from a coding point of view.
Brings more or less nothing to the final user, except better written
code, which is not nothing at all.


+1


But again, for those users that have a strict need for 1.4, what about
tools like http://retroweaver.sourceforge.net/ or
http://retrotranslator.sourceforge.net/ which also have a maven plugin?
I'm testing my java 5 application, retro-compiled to java 4, and it
seems to work correctly.


It should as the byte-code itself is not really different at all.
IMO an alternative worth thinking about.

cheers
--
Torsten

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-09 Thread Carsten Ziegeler

Ralph Goers wrote:
 The folks who are decided to maintain their blocks this way did it with 
 the clear understanding that this was the price they would have to pay, 
 so I don't think the clarification is necessary.  I can recall at least 
 one instance where a change to one of these blocks had to be backed or 
 modified because it broke the 2.1.x branch.  Remember, we voted a while 
 ago for trunk to only support 1.4 and up while 2.1.x supports 1.3, so 
 this problem already exists.
 
Yepp, and I think as soon as we have 2.2 out, we should not share these
blocks with 2.1.x anymore as all new features should go to 2.2 only.
2.1.x is then a real maintenance branch where we only do minor
improvements and bugfixing.

Carsten

-- 
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-09 Thread Marc Portier



Reinhard Poetz wrote:
 
 As Java 5 was released almost 2 years ago, I propose making it the
 minimum requirement for trunk and all artifacts released from there.
 

+1
-marc=
-- 
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java  XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: Re: [Vote] Java 5 as minimum JDK requirement

2006-08-09 Thread Bertrand Delacretaz


On 8/9/06, Carsten Ziegeler [EMAIL PROTECTED] wrote:


...Yepp, and I think as soon as we have 2.2 out, we should not share these
blocks with 2.1.x anymore as all new features should go to 2.2 only.
2.1.x is then a real maintenance branch where we only do minor
improvements and bugfixing...


Agreed.

-Bertrand

Re: [Vote] Java 5 as minimum JDK requirement


Carsten Ziegeler wrote:

Ralph Goers wrote:
The folks who are decided to maintain their blocks this way did it with 
the clear understanding that this was the price they would have to pay, 
so I don't think the clarification is necessary.  I can recall at least 
one instance where a change to one of these blocks had to be backed or 
modified because it broke the 2.1.x branch.  Remember, we voted a while 
ago for trunk to only support 1.4 and up while 2.1.x supports 1.3, so 
this problem already exists.



Yepp, and I think as soon as we have 2.2 out, we should not share these
blocks with 2.1.x anymore as all new features should go to 2.2 only.
2.1.x is then a real maintenance branch where we only do minor
improvements and bugfixing.


completly agreed

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc



___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: [Vote] Java 5 as minimum JDK requirement


Antonio Gallardo wrote:

Jason Johnston escribió:

On Tue, 2006-08-08 at 08:05 -0600, Jason Johnston wrote:
 

Reinhard Poetz wrote:
   
As Java 5 was released almost 2 years ago, I propose making it the 
minimum requirement for trunk and all artifacts released from there.


  

+1



Thinking about this a bit more, I have a question.

As I understand it there are several blocks (CForms comes to mind) that
are shared between trunk and the 2.1.x branch via svn:external
properties.  Unless I'm mistaken this would prevent the minimum JDK
requirement from being raised for these blocks, since it would affect
the branch where Java 1.3 is still supported.  Using any new JDK
features in these blocks would break that 1.3 support in the branch.

Should the vote be qualified with an ...except for those blocks that
are shared by the 2.1.x branch?
  
Good point. BTW, what if we vote to upgrade 2.1. branch to at least 1.4? 
:-)


I don't see much value in this as we should stop to add new features to the 
2.1.x branch rather sooner than later. I guess that there will only be one 
further _planned_ release (2.1.10) and then we should only backport critical bug 
fixes and release on demand.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc



___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-09 Thread Giacomo Pati


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 8 Aug 2006, Reinhard Poetz wrote:

As Java 5 was released almost 2 years ago, I propose making it the minimum 
requirement for trunk and all artifacts released from there.


+1

- -- 
Giacomo Pati

Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE2af8LNdJvZjjVZARAqrVAKDKrbP83/H7Y3yNS7Ff6mxGwIOyVgCgkEM6
iNLvm2J3R9zNqlGRMwUT+Xc=
=kdRs
-END PGP SIGNATURE-

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-09 Thread David Crossley

Reinhard Poetz wrote:
 
 As Java 5 was released almost 2 years ago, I propose making it the minimum 
 requirement for trunk and all artifacts released from there.

+1 ... although it might limit our user base,   

i reckon that Cocoon 2.2 should move on.



This will have impact for Forrest, as we use trunk. 

We can move forward to use the recent 2.2 release.  

If we decide Java 5 too, then we can move on.   



-David

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-09 Thread Jason Johnston


Carsten Ziegeler wrote:

Ralph Goers wrote:
The folks who are decided to maintain their blocks this way did it with 
the clear understanding that this was the price they would have to pay, 
so I don't think the clarification is necessary.  I can recall at least 
one instance where a change to one of these blocks had to be backed or 
modified because it broke the 2.1.x branch.  Remember, we voted a while 
ago for trunk to only support 1.4 and up while 2.1.x supports 1.3, so 
this problem already exists.



Yepp, and I think as soon as we have 2.2 out, we should not share these
blocks with 2.1.x anymore as all new features should go to 2.2 only.
2.1.x is then a real maintenance branch where we only do minor
improvements and bugfixing.


Cool, thanks guys for the clarification.  My +1 stands then.  :-)

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-09 Thread Mark Lundquist



On Aug 9, 2006, at 3:56 AM, David Crossley wrote:


Reinhard Poetz wrote:


As Java 5 was released almost 2 years ago, I propose making it the 
minimum

requirement for trunk and all artifacts released from there.


+1 ... although it might limit our user base,
i reckon that Cocoon 2.2 should move on.


+1

—ml—

Re: [Vote] Java 5 as minimum JDK requirement

2006-08-09 Thread Simone Gianni

Reinhard Poetz wrote:


 As Java 5 was released almost 2 years ago, I propose making it the
 minimum requirement for trunk and all artifacts released from there.

+1

What about http://retroweaver.sourceforge.net/ ? With that we could
develop for 1.5 and still make a binary version for 1.4 (since, in the
end, 1.5 only has compile time features that prevent the programmer
from making big mistakes, but actually can run on 1.4).

Simone

-- 
Simone Gianni

Re: [Vote] Java 5 as minimum JDK requirement


Jorg Heymans wrote:

Reinhard Poetz wrote:

As Java 5 was released almost 2 years ago, I propose making it the
minimum requirement for trunk and all artifacts released from there.



-0, because this means eliminating cocoon 2.2 on older application
servers eg weblogic 8.1.

Frankly, I don't see the point in upgrading unless there's a killer
feature in 1.5 that
1) we are likely to use and implement in the near future (2006) and,
2) will improve cocoon by a significant margin.



I've been thinking about your reasoning some time and believe you're right, 
there is no killer argument that makes it impossible to continue the development 
of Cocoon. There are many new features in Java 5 which make the life of 
developers easier and as Java 5 was released almost 2 years ago I and many other 
people on this list believe that's long enough. Additionally there is no 
existing user base.


As Vadim pointed out that this is our _framework developer_ point of view that 
might not reflect the community as a whole. He proposed to poll [EMAIL PROTECTED] 
which I will do today.


I will keep the vote open till next week so that you can consider the outcome of 
the poll. Having said this I want to stress that there is no pressure to change 
your opinion because of the poll in any way.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc



___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: [Vote] Java 5 as minimum JDK requirement


Joerg Heinicke wrote:

On 08.08.2006 18:47, Jorg Heymans wrote:


As Java 5 was released almost 2 years ago, I propose making it the
minimum requirement for trunk and all artifacts released from there.


-0, because this means eliminating cocoon 2.2 on older application
servers eg weblogic 8.1.

Frankly, I don't see the point in upgrading unless there's a killer
feature in 1.5 that
1) we are likely to use and implement in the near future (2006) and,
2) will improve cocoon by a significant margin.


I second this, but vote even -1. I wonder why a framework should set 
such high requirements. Have a look on spring. They have a Java 1.3 as 
minimum requirement and only need Java 5 for special features.


IMO we should do it in a similar manner and not set the general 
requirement to Java 5.


I've been thinking about your reasoning some time and believe you're right, 
there is no killer argument that makes it impossible to continue the development 
of Cocoon. There are many new features in Java 5 which make the life of 
developers easier and as Java 5 was released almost 2 years ago I and many other 
people on this list believe that's long enough. Additionally there is no 
existing user base.


As Vadim pointed out that this is our _framework developer_ point of view that 
might not reflect the community as a whole. He proposed to poll [EMAIL PROTECTED] 
which I will do today.


I will keep the vote open till next week so that you can consider the outcome of 
the poll. Having said this I want to stress that there is no pressure to change 
your opinion because of the poll in any way.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc



___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: [Vote] Java 5 as minimum JDK requirement