Bertrand Delacretaz wrote:
On 10/9/06, Antonio Gallardo <[EMAIL PROTECTED]> wrote:
...Because we claim 2.1 is java 1.3 when it
fact few of us care about this compatibility and some blocks does not
compile at all
I think we voted on this a while ago: the 2.1 core and most blocks
must work
Hi Simone,
I agree with you, basically, it is a chicken egg problem, if we don't
set java 1.5 as the minimal jvm, we will never start using typed
collections, for-each etc. The fact is that most of us is using this new
cool features and will be fine to use them in our cocoon code too.
Best R
On 10/9/06, Antonio Gallardo <[EMAIL PROTECTED]> wrote:
...Because we claim 2.1 is java 1.3 when it
fact few of us care about this compatibility and some blocks does not
compile at all
I think we voted on this a while ago: the 2.1 core and most blocks
must work with 1.3, but some blocks mi
Hello,
The samples:
http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/form2xml.flow
http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/form2simpleXML.flow
http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/form2bean.flow
is not working. The repeate
[Resending to dev]
Carsten Ziegeler wrote:
> Joerg Heinicke schrieb:
>> Wondering about your problem I had a look into the code - and the
>> environment abstraction indeed still exists. I thought it already has
>> been removed. I send this mail to dev list too, maybe somebody can
>> comment on
On 09.10.2006 23:03, Antonio Gallardo wrote:
I am thinking in 2.2 too. The above reference to 2.1 is just a sample of
what we are repeating for 2.2. Because we claim 2.1 is java 1.3 when it
fact few of us care about this compatibility and some blocks does not
compile at all. This somehow makes
Joerg Heinicke wrote:
>>> If you are interested, I could add the Ivy build system into
>>> tools/build...
>>
>> As it's still experimental IIUC, I'd prefer to have it somewhere
>> under http://svn.apache.org/repos/asf/cocoon/whiteboard/
>
> So much I dislike Maven, shouldn't we be honest and
Bertrand Delacretaz escribió:
On 10/9/06, Antonio Gallardo <[EMAIL PROTECTED]> wrote:
...Just some question: it is the same for 2.1, right? What is 2
different
blocks with different jvm requirement needs the same jar?...
I was mainly thinking about 2.2, but in your case, if a jar is
compiled
[ http://issues.apache.org/jira/browse/COCOON-1883?page=all ]
Jörg Heinicke closed COCOON-1883.
-
Fix Version/s: 2.2-dev (Current SVN)
2.1.10-dev (current SVN)
Resolution: Fixed
Yes, I think your fix is appropriate. The instantia
[ http://issues.apache.org/jira/browse/COCOON-1883?page=all ]
Jörg Heinicke reassigned COCOON-1883:
-
Assignee: Jörg Heinicke
> SOAPHelper only accepts replies with an XML declaration
> ---
>
>
Bertrand Delacretaz wrote:
Does anything prevent us from having some blocks that require 1.5,
while the core and "core blocks" (we might need to define which ones
these are, but most of them are evident I thin) require 1.4?
Nope, except that it could be a pain for users, but after all it would
g
Dear all,
I have created a new test release of the avalon/excalibur components
here [1]. The aim of this release was to convert a/e to maven2, so that
people could include it in their m2 based projects using proper
transitive dependency management based on clean poms.
If you want to get invo
[ http://issues.apache.org/jira/browse/COCOON-1869?page=all ]
Jörg Heinicke closed COCOON-1869.
-
Fix Version/s: 2.2-dev (Current SVN)
2.1.10-dev (current SVN)
Resolution: Fixed
> MailMessageSender.java eats exception chain
> ---
[ http://issues.apache.org/jira/browse/COCOON-1869?page=all ]
Jörg Heinicke updated COCOON-1869:
--
Summary: MailMessageSender.java eats exception chain (was:
MailMessageSender.java eats exception chain - which does not allow for proper
dubuging and lo
On 04.10.2006 09:30, Bertrand Delacretaz wrote:
At http://wiki.apache.org/cocoon/GT2006Presentations
Speakers, please add your stuff (or links to it) there!
No. 3 (Andreas Kühne) and no. 5 (Gianugo Rabellino) are still missing.
Could you please ask your presentations as well?
Thanks,
Jörg
If you are interested, I could add the Ivy build system into
tools/build...
As it's still experimental IIUC, I'd prefer to have it somewhere under
http://svn.apache.org/repos/asf/cocoon/whiteboard/
So much I dislike Maven, shouldn't we be honest and say there is no real
chance of switch
Carsten Ziegeler wrote:
I haven't followed the Maven mailing lists lately - is there any
timeframe for a 2.0.5 release?
If the jira roadmap[1] is anything to go by (53 of 235 issues have been
resolved) then we're still quite far off a new release.
OTOH, i'm using 2.0.5-snapshot at work and
On 10/9/06, Antonio Gallardo <[EMAIL PROTECTED]> wrote:
...Just some question: it is the same for 2.1, right? What is 2 different
blocks with different jvm requirement needs the same jar?...
I was mainly thinking about 2.2, but in your case, if a jar is
compiled for 1.4 it will work with 1.5, r
Bertrand Delacretaz escribió:
I think the only way to handle this is to decide on a JVM version for
the core, and accept that some "non-core" blocks might have different
requirements.
+1.
Just some question: it is the same for 2.1, right? What is 2 different
blocks with different jvm requireme
Antonio Gallardo wrote:
Ralph Goers escribió:
1. I don't see the point. There was a -1 that is unlikely to be changed.
I am providing more reasons as brain food. I think people can change
his mind over the time when more facts arises.
2. Since we will be distributing binaries with Maven - I
Bertrand Delacretaz wrote:
I think the only way to handle this is to decide on a JVM version for
the core, and accept that some "non-core" blocks might have different
requirements.
+1
Vadim
On 10/9/06, Antonio Gallardo <[EMAIL PROTECTED]> wrote:
...I was updating some jars for cocoon 2.1.0. Qdox[1] version 1.6 was
released in August 2006 (we are using now qdox 1.5) and it is
distributed only for java 1.5! I know qdox is not the most used block,
but it rings a bell!...
Does anythi
Lars Trieloff wrote:
> Hi Christopher,
>
> as the individual JS files are rather small, the most costly part is
> requesting them from the web server, not downloading them. With an
> aggregated file, there is only one single request.
>
> I agree that it does not make sense to create a JS file per f
Jeremy Quinn said the following on 6/10/06 20:47:
On 6 Oct 2006, at 18:46, hepabolu wrote:
Jeremy Quinn said the following on 6/10/06 16:42:
Hi All
We had an informal group discussion on Tuesday at the Hackathon about
CForms.
The purpose of the discussion was to find a consensus on the
dire
Hi Christopher,
as the individual JS files are rather small, the most costly part is
requesting them from the web server, not downloading them. With an
aggregated file, there is only one single request.
I agree that it does not make sense to create a JS file per form
because that would re
Hi Christofer
On 9 Oct 2006, at 08:26, [EMAIL PROTECTED] wrote:
Hi,
I am following this discussion since the beginning. There is one
thing I don't quite understand. I had a lot of problems with dojo,
because it does a lot of caching on its own. If we package and
compress the scripts on a
Hi all,
hepabolu wrote:
Jeremy Quinn said the following on 6/10/06 16:42:
Hi All
We had an informal group discussion on Tuesday at the Hackathon about
CForms.
The purpose of the discussion was to find a consensus on the direction
to take CForms, so that everybody who would like to work on it
Hi,
I am following this discussion since the beginning. There is one thing I don't
quite understand. I had a lot of problems with dojo, because it does a lot of
caching on its own. If we package and compress the scripts on a
"per-form-basis" we get tons of different compressed js-files with lot
Ralph Goers escribió:
1. I don't see the point. There was a -1 that is unlikely to be changed.
I am providing more reasons as brain food. I think people can change his
mind over the time when more facts arises.
2. Since we will be distributing binaries with Maven - I would think
that as long
29 matches
Mail list logo
