Re: [Vote] Java 5 as minimum JDK requirement
Andrew Stevens skrev: From: Sylvain Wallez <[EMAIL PROTECTED]> ... All this discussion makes me sad, as it gives the impression the overall Cocoon developer community doesn't want to move forward and is frightened by moves that would cause some disruption among _some_ users. Not so much frightened as that they care, and not only want to move forward but bring existing users forward with them. At least, that's the impression I receive. It is not that simple either. The last few years we have lost a considerable number of very talented developers, (with Sylvain as a prominent example), because Cocoon have been moving to slowly for their tastes. Some of them have moved on to other projects where they think there is more action. /Daniel
Re: [Vote] Java 5 as minimum JDK requirement
From: Sylvain Wallez <[EMAIL PROTECTED]> Date: Fri, 18 Aug 2006 10:00:59 +0200 Joerg Heinicke wrote: > 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. Folks, this discussion considers the problem from the wrong perspective. Large IT departments don't bother upgrading their environments unless there's a compelling reason to do that, Oh, we already have a compelling reason - Websphere 5.0's end-of-lifed at the end of next month. Unfortunately, I was informed by the team that looks after the servers that they hadn't finished testing a newer version (and had found some issues with it affecting some of our apps that would need to be fixed before they'd sign it off) and were negotiating with IBM to continue supporting the older version for us in the meantime. And we're big enough that they'll probably do it :-( and if we listen to them, we'll never move forward. Now being told "the new version of the application needs the great things brought by the new Cocoon, but requires Java 1.5" can be such an incentive for them. Even if I don't think people frightened by the migration from Java 1.4 (or 1.3) to 1.5 will even consider migrating from Cocoon 2.1 to 2.2. If only life were that simple. Personally, I'd love to switch to 1.5, and in fact am using it on my "spare time" projects at home. But I have no influence on which version to use at work - if our site it to be hosted on the robust, scalable infrastructure in the US datacentre, then we have to code to the server that they support. For internal apps it's another matter, but for internet sites we're stuck with the "group standard" platform. If I argue "but Cocoon needs 1.5", they'll just tell me I should instead migrate our app to the proprietary web app framework we inherited in a takeover a while back, and which is supported & maintained by yet another team over in the States. I only get to use Cocoon (which is a much better fit with our CMS, that uses XML-based data records) because they also support bare servlets/JSPs and we told them it's "just" an XML processing servlet :-) It is IMO our role, as technology builders, to invite our users to progress towards more modern stuff. What's the purpose of Sun releasing a new JDK? What's the reason for Cocoon to release 2.2? What's the reason to upgrade to the latest Xalan? What's the reason for Struts to start with a blank page learning from the oldish Struts 1.x and Webwork? Providing more to users, providing something that works better, providing something that brings more development productivity. There's a difference between "inviting users to progress towards more modern stuff" and forcing them to leap to the cutting edge, though. What's wrong with one step at a time? JDK 1.3 for Cocoon 2.1.x, JDK 1.4 for Cocoon 2.2, JDK 1.5 for Cocoon 3 or 2.3 or whatever the next version gets called? One of the good things about Cocoon (IMO) is that it cares about backwards compatibility - 2.1.x requires only java 1.3 and servlet 2.2 so will run on just about anything. There was a recent vote to move trunk/2.2 to servlet 2.4, justified by Tomcat 5.0 being available since 2003; since Tomcat 5.0 requires JDK 1.4 or later, why not keep in line with that? If you're going to switch to 1.5 just because it's the current version, you might as well go the whole hog and jump to servlet 2.5/J2EE 5 too... All this discussion makes me sad, as it gives the impression the overall Cocoon developer community doesn't want to move forward and is frightened by moves that would cause some disruption among _some_ users. Not so much frightened as that they care, and not only want to move forward but bring existing users forward with them. At least, that's the impression I receive. Note also that the poll on the user list showed an evident interest in using JDK 1.5... If I remember rightly, the summary that was posted here a couple of days ago was that 9 users said it wouldn't be a problem for them. Count me as 1 against that and extrapolate, and we could conclude jumping to 1.5 is a problem for 10% of your users. Given the statistical error on such a small sample size, I could probably come up with figures to prove it inconveniences anything between one user and most of the user base. But that's what a couple of years studying statistics gets you :-) Andrew.
Re: [Vote] Java 5 as minimum JDK requirement
Joerg Heinicke wrote: > 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. Folks, this discussion considers the problem from the wrong perspective. Large IT departments don't bother upgrading their environments unless there's a compelling reason to do that, and if we listen to them, we'll never move forward. Now being told "the new version of the application needs the great things brought by the new Cocoon, but requires Java 1.5" can be such an incentive for them. Even if I don't think people frightened by the migration from Java 1.4 (or 1.3) to 1.5 will even consider migrating from Cocoon 2.1 to 2.2. It is IMO our role, as technology builders, to invite our users to progress towards more modern stuff. What's the purpose of Sun releasing a new JDK? What's the reason for Cocoon to release 2.2? What's the reason to upgrade to the latest Xalan? What's the reason for Struts to start with a blank page learning from the oldish Struts 1.x and Webwork? Providing more to users, providing something that works better, providing something that brings more development productivity. All this discussion makes me sad, as it gives the impression the overall Cocoon developer community doesn't want to move forward and is frightened by moves that would cause some disruption among _some_ users. Note also that the poll on the user list showed an evident interest in using JDK 1.5... My 0.02 euros... Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [Vote] Java 5 as minimum JDK requirement
Joerg Heinicke wrote: 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. I certainly didn't think you were. I think Torsten was asking a hypothetical question of me. However, your response above is exactly what I was trying to point out. What we think is in the "best interest of the project" is colored by our experiences with our current and former employers. While you aren't voting "according to your employer's needs" you are certainly considering them as well as your former employers when making decisions. If you didn't then Cocoon would just be a toy with no practical value. Ralph
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: [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
Hi, Torsten Curdt wrote: 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. Splitting hairs here, but it's not PMC members, it's users, developers and committers, surely? 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: Re: [Vote] Java 5 as minimum JDK requirement
> ...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. 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: [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: Re: [Vote] Java 5 as minimum JDK requirement
> 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
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: [Vote] Java 5 as minimum JDK requirement
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
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
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: Re: [Vote] Java 5 as minimum JDK requirement
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
Peter Hunsberger wrote:
On 8/14/06, Joerg Heinicke <[EMAIL PROTECTED]> wrote:
On 14.08.2006 22:19, Daniel Fagerstrom wrote:
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: [Vote] Java 5 as minimum JDK requirement
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
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
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
Peter Hunsberger wrote:
On 8/14/06, Joerg Heinicke <[EMAIL PROTECTED]> wrote:
On 14.08.2006 22:19, Daniel Fagerstrom wrote:
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
On 8/14/06, Joerg Heinicke <[EMAIL PROTECTED]> wrote: On 14.08.2006 22:19, Daniel Fagerstrom wrote: 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? 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: [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: Re: [Vote] Java 5 as minimum JDK requirement
> 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
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
> 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
Re: [Vote] Java 5 as minimum JDK requirement
Joerg Heinicke 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: [Vote] Java 5 as minimum JDK requirement
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
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 computer
Re: [Vote] Java 5 as minimum JDK requirement
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
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=rev&revision=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
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=rev&revision=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
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
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 feature
Re: [Vote] Java 5 as minimum JDK requirement
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. -- Peter Hunsberger
Re: [Vote] Java 5 as minimum JDK requirement
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: [Vote] Java 5 as minimum JDK requirement
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
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
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
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: Re: [Vote] Java 5 as minimum JDK requirement
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
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: [Vote] Java 5 as minimum JDK requirement
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
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: Re: [Vote] Java 5 as minimum JDK requirement
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
sorry for answering to the wrong mail. I'veresent it to the right one now.
--
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
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
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
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
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
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
-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
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
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: Re: [Vote] Java 5 as minimum JDK requirement
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
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: [Vote] Java 5 as minimum JDK requirement
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, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [Vote] Java 5 as minimum JDK requirement
Jason Johnston wrote: 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"? 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. Ralph
Re: [Vote] Java 5 as minimum JDK requirement
Antonio Gallardo wrote: 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? :-) That has been discussed and rejected several times. Ralph
Re: [Vote] Java 5 as minimum JDK requirement
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? :-) Best Regards, Antonio Gallardo.
Re: [Vote] Java 5 as minimum JDK requirement
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"?
Re: [Vote] Java 5 as minimum JDK requirement
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. Jörg
Re: [Vote] Java 5 as minimum JDK requirement
* Jorg Heymans: > > 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. Agreed. Here is my: +0 -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: [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. > -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. Jorg
Re: [Vote] Java 5 as minimum JDK requirement
Reinhard Poetz skrev: 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 /Daniel
Re: [Vote] Java 5 as minimum JDK requirement
On Tue, 2006-08-08 at 15:14 +0200, 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 -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [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. > +1 Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [Vote] Java 5 as minimum JDK requirement
On 8/8/06, Reinhard Poetz <[EMAIL PROTECTED]> 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 (assuming this is a separate vote?) -- Peter Hunsberger
Re: [Vote] Java 5 as minimum JDK requirement
Reinhard Poetz escribió: 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 is my 1 year old "+1" ;-) Best Regards, Antonio Gallardo.
Re: [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. +1 Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [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.
+1
--
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
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
Re: [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. +1 Ralph
Re: [Vote] Java 5 as minimum JDK requirement
On 8/8/06, Reinhard Poetz <[EMAIL PROTECTED]> 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 -Bertrand
Re: [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. +1 -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
