On 12/18/06, Antonio Gallardo [EMAIL PROTECTED] wrote:
...Seems like all us is too busy. :)..
Exactly - and I think it's better to be realistic than to pretend
supporting something without having the resources to actually do it.
(BTW it's good to hear that you're busy for good reasons like
Niclas Hedhman wrote:
If we have made a prior commitment of keeping the 2.1.x compatible with
JDK1.3, then that should stand. It should not be a matter of what a handful
developers think. They are usually on the curring edge anyway, but what the
user community are depending on. It is these
I assembled the release candidate for 2.1.10 (vote mail will follow
soon), so this ends the code freeze.
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Please cast your votes on the 2.1.10 release.
The release candidate can be downloaded from:
http://people.apache.org/~cziegeler/cocoon/
The corresponding sources are under:
https://svn.apache.org/repos/asf/cocoon/tags/RC_2_1_10/
The vote will be open for 72 hours.
If the vote passes, I will
Hi,
I found a problem with the cocoon-batik-impl block. When I add a
dependency to this block, I end up with two different versions of Batik
on my classpath. The first (and correct) one is batik-1.6-1. But due to
a dependency to fop 0.20.5, batik-1.5-fop gets included (which is not
compatible
Carsten Ziegeler wrote:
Please cast your votes on the 2.1.10 release.
The release candidate can be downloaded from:
http://people.apache.org/~cziegeler/cocoon/
The corresponding sources are under:
https://svn.apache.org/repos/asf/cocoon/tags/RC_2_1_10/
+1
Carsten
--
Carsten Ziegeler
On 12/18/06, Carsten Ziegeler [EMAIL PROTECTED] wrote:
...The release candidate can be downloaded from:
http://people.apache.org/~cziegeler/cocoon/..
On my macosx system with either JDK 1.4.2 or 1.5, all the automated
tests from org.apache.cocoon.forms.datatype fail
Automated build for cocoon-docs FAILED
Log attached.
--
Forrestbot run ended at 18 December 12:26 PM
Using Forrest 0.8-dev
Forrestbot administrator: ForrestBot
--
[echo]
... Forrest render START 2006-12-18 12:02:20
... Rendering docs in
Bertrand Delacretaz wrote:
On 12/18/06, Carsten Ziegeler [EMAIL PROTECTED] wrote:
...The release candidate can be downloaded from:
http://people.apache.org/~cziegeler/cocoon/..
On my macosx system with either JDK 1.4.2 or 1.5, all the automated
tests from org.apache.cocoon.forms.datatype
On Monday 18 December 2006 16:26, Ralph Goers wrote:
So
I would think trunk should be released as 3.0, if for no other reason
than allow the next 2.1 release to be 2.2.0 without jdk 1.3 support.
I agree (and with Helma's elaboration).
Personally, I don't understand the intense resistence of
On 12/18/06, hepabolu [EMAIL PROTECTED] wrote:
...- rename the current branch to Cocoon 2.2 without the 1.3 compatibility..
Not 2.2, please...we've been talking about 2.2 for so long that
releasing the 2.1 branch as 2.2 might be very confusing.
I'm not against renumbering things, no problem
As of my tests a block configured to handle root sitemap does only
strictly answer to / resource call. The rest of its context seems to be
inaccessible.
Thus, for instance, if a block testblock1 is configured to handle root
sitemap and should serve:
a welcome page at /
some content at
- stop the development of Cocoon 2.1 after the release of 2.1.10
- rename the current branch to Cocoon 2.2 without the 1.3 compatibility
(and maybe other minor changes that are now prevented by the versioning
contract)
- rename the current trunk to Cocoon 3.0
My goal was not to open
The root servlet should be mounted at not /. Alexander had the same
problem. So even if I find the current behavior intuitive, no one else
seem to agree ;). So we should probably have special handling of / as
you suggest.
/Daniel
Patrick Refondini skrev:
As of my tests a block configured to
On 12/18/06, Bertrand Delacretaz [EMAIL PROTECTED] wrote:
On 12/18/06, hepabolu [EMAIL PROTECTED] wrote:
...- rename the current branch to Cocoon 2.2 without the 1.3 compatibility..
Not 2.2, please...we've been talking about 2.2 for so long that
releasing the 2.1 branch as 2.2 might be very
On 12/18/06, Peter Hunsberger [EMAIL PROTECTED] wrote:
I'd bet every single person
that has actually downloaded Trunk and built it can cope with having
it called 3.0 instead of 2.2...
Agreed, my problem is not this one.
What I fear is that, if we release an evolution of 2.1.x and name it
Hi. Is any posibility to use jx generator or JPath logicsheets without
flowscript.
I mean how to acces request, context or session params.
Greetings
Piotr
--
View this message in context:
http://www.nabble.com/JX-or-JPath-without-flowscript-tf2840359.html#a7930025
Sent from the Cocoon - Dev
Bertrand Delacretaz wrote:
What I fear is that, if we release an evolution of 2.1.x and name it
2.2, people will be confused. For example by searching our lists for
2.2 and finding lots of messages about Maven, while *that* 2.2
version would not use Maven.
That is a valid concern. We kind of
Ralph Goers wrote:
Bertrand Delacretaz wrote:
What I fear is that, if we release an evolution of 2.1.x and name it
2.2, people will be confused. For example by searching our lists for
2.2 and finding lots of messages about Maven, while *that* 2.2
version would not use Maven.
That is a valid
Carsten Ziegeler wrote:
Perhaps we should rethink this drop jdk1.3 support stuff, remove the
comment from the status file and get 2.1.10 out.
I agree.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache
On 12/18/06, Bertrand Delacretaz [EMAIL PROTECTED] wrote:
On 12/18/06, Peter Hunsberger [EMAIL PROTECTED] wrote:
I'd bet every single person
that has actually downloaded Trunk and built it can cope with having
it called 3.0 instead of 2.2...
Agreed, my problem is not this one.
What I
Hi Piotr,
I'm afraid that questions like these should go to the cocoon user list
instead of the developers list.
To answer your question:
Yes you can use the jx generator without flowscript.
From the jx you can access:
the request by using cocoon.request.someFunction();
the context by
Daniel Fagerstrom wrote:
The root servlet should be mounted at not /. Alexander had the same
problem. So even if I find the current behavior intuitive, no one else
seem to agree ;). So we should probably have special handling of / as
you suggest.
I just tested configuration and it does
Patrick Refondini wrote:
Daniel Fagerstrom wrote:
The root servlet should be mounted at not /. Alexander had the
same problem. So even if I find the current behavior intuitive, no one
else seem to agree ;). So we should probably have special handling of
/ as you suggest.
I just tested
Carsten Ziegeler wrote:
Perhaps we should rethink this drop jdk1.3 support stuff, remove the
comment from the status file and get 2.1.10 out.
get 2.1.10 out, close 2.1.x branch, and work on getting 2.2 out - i'm completely
+1 on this line of thinking. Why do we need to keep on dragging 2.1.x
Vadim Gritsenko skrev:
Carsten Ziegeler wrote:
Perhaps we should rethink this drop jdk1.3 support stuff, remove the
comment from the status file and get 2.1.10 out.
get 2.1.10 out, close 2.1.x branch, and work on getting 2.2 out - i'm
completely +1 on this line of thinking. Why do we need to
Reinhard Poetz wrote:
Patrick Refondini wrote:
Daniel Fagerstrom wrote:
The root servlet should be mounted at not /. Alexander had the
same problem. So even if I find the current behavior intuitive, no
one else seem to agree ;). So we should probably have special
handling of / as you
Gianugo Rabellino wrote:
On 12/13/06, Matthias Epheser [EMAIL PROTECTED] wrote:
According to the documentation here
http://cocoon.zones.apache.org/daisy/documentation/components/1063/g1/939.html
it should be possible to declare the expires time in mod_expires style
(e.g..
access plus 4
On Dec 18, 2006, at 3:59 AM, hepabolu wrote:
Guys,
[snipped: proposal to rebadge 2.1.11 = 2.2, 2.2 = 3.0]
No, no... please, no!!
The mailing list archives and JIRA are loaded with references to the
current version number scheme.
2.2 = Mavenization
3.0 = OSGi
Don't change it now, that
On Dec 18, 2006, at 7:15 AM, Ralph Goers wrote:
That is a valid concern. We kind of painted ourselves in a box by
calling trunk 2.2 way before it was ready to be anything.
Agreed, IMHO all future releases beyond 2.2 (will that actually be
2.2.0?) should use internal code names until right
On Dec 18, 2006, at 8:14 AM, Vadim Gritsenko wrote:
get 2.1.10 out, close 2.1.x branch, and work on getting 2.2 out - i'm
completely +1 on this line of thinking. Why do we need to keep on
dragging 2.1.x branch forward? Just say that 2.1.10 is last on jdk 1.3
(and last of 2.1.x), and 2.2
On 18.12.2006 10:42, Bertrand Delacretaz wrote:
all the automated tests from org.apache.cocoon.forms.datatype fail
(DynamicSelectionListTestCase,EnumSelectionListTestCase,FlowJXPathSelectionListTestCase).
IIRC the same tests passed last week, anyone know what could have changed?
This is
On Dec 17, 2006, at 8:26 PM, Antonio Gallardo wrote:
I would be voting -1 in behalf of unheard users.
Thanks Niclas, here we go: I vote -1 for the reasons stated above.
Changing the user contracts is not fair.
I'd say that you owe to users the chance to become heard by asking on
the
Vadim Gritsenko said the following on 18/12/06 17:14:
get 2.1.10 out, close 2.1.x branch, and work on getting 2.2 out - i'm
completely +1 on this line of thinking. Why do we need to keep on
dragging 2.1.x branch forward? Just say that 2.1.10 is last on jdk 1.3
(and last of 2.1.x), and 2.2
Just to clarify... I had a typo/braino:
On Dec 18, 2006, at 11:37 AM, Mark Lundquist wrote:
If users *do* give a rip, then the answer might *still* be too
freakin' bad! What else? Bummer about Cocoon, they could never
release 2.1.11 because they couldn't do it without 'changing the
On 18.12.2006 20:34, Joerg Heinicke wrote:
all the automated tests from org.apache.cocoon.forms.datatype fail
(DynamicSelectionListTestCase,EnumSelectionListTestCase,FlowJXPathSelectionListTestCase).
IIRC the same tests passed last week, anyone know what could have
changed?
As forms block
On Mon, 2006-12-18 at 16:24 +0100, Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Perhaps we should rethink this drop jdk1.3 support stuff, remove the
comment from the status file and get 2.1.10 out.
I agree.
I agree, too.
The last thing I want is to hold up the 2.1.10. If I had known
On 18.12.2006 16:22, Carsten Ziegeler wrote:
Perhaps we should rethink this drop jdk1.3 support stuff, remove the
comment from the status file and get 2.1.10 out.
+1
Jörg
Automated build for cocoon-docs FAILED
Log attached.
--
Forrestbot run ended at 19 December 12:29 AM
Using Forrest 0.8-dev
Forrestbot administrator: ForrestBot
--
[echo]
... Forrest render START 2006-12-19 12:02:21
... Rendering docs in
Mark Lundquist escribió:
On Dec 17, 2006, at 8:26 PM, Antonio Gallardo wrote:
I would be voting -1 in behalf of unheard users.
Thanks Niclas, here we go: I vote -1 for the reasons stated above.
Changing the user contracts is not fair.
I'd say that you owe to users the chance to become
On Tuesday 19 December 2006 00:14, Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Perhaps we should rethink this drop jdk1.3 support stuff, remove the
comment from the status file and get 2.1.10 out.
get 2.1.10 out, close 2.1.x branch, and work on getting 2.2 out - i'm
completely +1 on
On Tuesday 19 December 2006 03:13, Mark Lundquist wrote:
On Dec 18, 2006, at 7:15 AM, Ralph Goers wrote:
That is a valid concern. We kind of painted ourselves in a box by
calling trunk 2.2 way before it was ready to be anything.
Agreed, IMHO all future releases beyond 2.2 (will that
Alfred Nathaniel wrote:
I agree, too.
The last thing I want is to hold up the 2.1.10. If I had known what I
stirred up here, I would not have started it.
I guess most of us did not expect this :(
I apologize for the short time for discusion and vote but the idea was
to get it into
43 matches
Mail list logo
