your recent commits, what is now the minimum Java version : 1.5,
1.6, 1.8 ?
Cédric
Le 19/02/2019 à 12:25, Nathaniel, Alfred a écrit :
> Thanks, it was quite a long shot to develop on Java 8 and then Jenkins on 1.5.
>
> -Original Message-
> From: Francesco Chicchiriccò
>
to run with JDK 1.6 (it used to be 1.5).
Now it seems to be back working, cool!
Regards.
On 19/02/19 11:36, Nathaniel, Alfred wrote:
> Yes, that's me although I don't know this error came into being.
> Must be a time bomb set off by a deeper recompile.
> I'll put in a
Yes, that's me although I don't know this error came into being.
Must be a time bomb set off by a deeper recompile.
I'll put in a fix.
Cheers, Alfred.
-Original Message-
From: Francesco Chicchiriccò
Sent: Dienstag, 19. Februar 2019 08:42
To: dev@cocoon.apache.org
Subject: [External Send
+1 but I would go straight to 6, 7, or even 8.
Past experience is that it is a real nuisance trying to support an ancient JDK
no developer is actually using anymore.
Cheers, Alfred.
-Original Message-
From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
Sent: Freitag, 7. Oktober 20
Hi Miguel,
In a file upload request, there is no length indicator which would allow to
detect oversized files immediately.
The file data is embedded with a special multipart encoding in the normal HTTP
request stream.
There may be more requests following in the same persistent HTTP connection.
T
Wild guess: somewhere you add the map to itself
map.put("map", map);
creating an infinite recursion in map.toString().
HTH, Alfred.
-Original Message-
From: Robby Pelssers [mailto:robby.pelss...@nxp.com]
Sent: Freitag, 22. Februar 2013 11:54
To: dev@cocoon.apache.org
Subject: RE: R
+1
Cheers, Alfred.
-Original Message-
From: Thorsten Scherler [mailto:thors...@apache.org]
Sent: Montag, 28. Mai 2012 10:26
To: dev@cocoon.apache.org
Subject: [VOTE] Javier Puerto as cocoon committer
I propose Javier Puerto as a new Cocoon committer and PMC member.
Connect to our new c
I am also for (2) although I can't promis much help.
I think moving the docs to a CMS was one of the big mis-decisions of C2.
The wishful thinking was that non-developers would come forward to improve the
documentation which were before discouraged by the xdoc and svn.
Sad reality was that the CM
Hi Simone,
Why this special API call to add it to the pipeline?
I think is should be a regular transformer you can add any number of time
wherever you need it:
VariableExpander expander = new VariableExpander();
expander.addProperty( "build.base", "/Users/cocoon" );
expa
Cocoon 2.1.11 should be working with any JVM 1.3 and up.
Because nobody is actually using 1.3 anymore for development, there were
several occasions that library features not available in 1.3 crept in.
Therefore it was decided that the next release 2.1.12 should require 1.4.
I would not recommend a
Have a look at the a.o.c.util.location package.
That provides the machinery to print the sitemap component / filename / line
number / column in an exception traceback.
That should allow you to learn how to get hold of these values at component
entry.
Instrument the code with logger.debug calls an
Hi all,
URL.setURLStreamHandlerFactory is singleton call which should only be used when
you own the JVM.
Calling it from C3 which is expected to play nicely with other servlets in the
same container, it is a no-no.
Jnet should be changed, for example by providing a createURL(String spec)
facto
Hi all,
Here are the results for the vote [1].
There were 9 binding +1 from:
* Alfred Nathaniel
* David Crossley
* David Legg
* Francesco Chicchiriccò
* Joerg Heinicke
* Peter Hunsberger
* Reinhard Pötz
* Steven Dolg
* Thorsten Scherler
There were no other votes.
It i
+1
Is there an option to delay the dev@ mail to give the committer a head start
for fixing his own mess?
Cheers, Alfred.
-Original Message-
From: simone.trip...@gmail.com [mailto:simone.trip...@gmail.com] On Behalf Of
Simone Tripodi
Sent: Freitag, 16. September 2011 17:13
To: dev@coco
Hi all,
A few weeks ago we had a discussion [1] whether to increase for Cocoon3 the
minimum Java version from 1.5 to 1.6.
There were a number of advantages identified to be gained by using Java6, which
I don't want to repeat here,
The only downside is the exclusion of potential C3 users locked
> -Original Message-
> From: Thorsten Scherler [mailto:scher...@gmail.com]
> Sent: Montag, 29. August 2011 14:16
> To: dev@cocoon.apache.org
> Subject: Re: svn commit: r1162745 - in /cocoon/cocoon3/trunk: cocoon-
> optional/pom.xml cocoon-stax/pom.xml parent/pom.xml
>
> On Mon, 2011-08-29
Hi Igor,
It's a nice show case that C3 has reached one of its design goals to
be embeddable in other frameworks.
Whilst C2 is the 500lb gorilla squatting the driverseat, C3 is a neat
little monkey who knows how to driver but also fits onto the backseat.
I was first confused by the term "springif
Please plan it as a 2-day event with a late morning start on day1 and
an early afternoon finish on day2 that one can fly in and out with
one overnight stay for the social GT.
NB traditional GT dinner is spare ribs. Do you have those in L'Aquila?
Cheers, Alfred.
-Original Message-
From:
Hi Francesco,
I am a big fan of Findbugs and persueing a zero-warnings policy.
In other projects we use a Findbugs exclude filter file to
disable warnings and document the deliberation for doing so.
Sonar should foresee to pull such an exclude filter from the
project's code base.
NB we also excl
Peter Hunsberger wrote:
> We seem to have this discussion every few years. There's always
> people that can't upgrade. Personally I think it's time to do it and
> I wish we had done it long ago. With C3 in particular, people should
> have no dependencies in production since it is still officiall
Hi all,
C3 is still set to 1.5 as source and target version.
Java5 is end of life since almost two years now.
Is there any good reason not to go 1.6?
Cheers, Alfred.
The content of this e-mail is intended only for the confidential use of the
person addressed.
If you are not the intended reci
Jorg Heymans wrote:
> We aren't providing snapshot builds and people want to try out the new
> features. This currently means they have to compile themselves. Failing
> unit tests are a hurdle that might stop their attempt to explore
> completely - the huge 'BUILD FAILED' banner at the end doesn
> From: Joerg Heinicke [mailto:[EMAIL PROTECTED]
> > Selling to management another
> > migration project before 2008 would be very hard, especially since
> > the current 2.2 has new feature really interesting to us.
>
> Something is wrong with that sentence I guess. I miss the logic: You
> can'
+1 to release 2.2-M2
+1 to release 2.1.10
+1 to drop block sharing
-1 to put 2.1.x into *pure* bug fixing mode
We should try to attract people to 2.2 rather than pushing them
away from 2.1 (because they may go somewhere else).
I expect to be stuck with 2.1.x for the next 1-2 years. That's a bit
> I think time has come for Lars Trieloff to become a Cocoon
> committer,
+1
Cheers, Alfred.
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or privilege
is waived or lost by any mistran
ompared to the complete request handling taking tens of
milliseconds.
Cheers, Alfred.
-Original Message-
From: Joerg Heinicke [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 21. September 2006 19:53
To: dev@cocoon.apache.org
Subject: Re: Wildcard matcher matching wild things
On 20.09.2006 1
I committed the new code. It passes all test including the new one which
illustrated
the reason for the rewrite.
We are currently migrating our corporate websites to 2.1.10-dev that core and
the
XSP block will get pretty good real-life test coverage.
Cheers, Alfred.
-Original Message
The head of 2.1 contains a new WildcardMatcherHelper [1] to replace the
rather obscure WildcardHelper [2] implementation. WMH is now used for
matching wildcard patterns in map:match.
Although the code is a lot clearer than WH, it is still very complex
logic. A number of bugs in the original WM
Hi Hussayn,
thanks for sharing your patch.
I'll have a look at it.
Cheers, Alfred.
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Hussayn dabbous
Sent: Mittwoch, 30. August 2006 22:48
To: dev@cocoon.apache.org
Subject: patch for an entityResolver problem in xsl styl
> What do people think about making Java 5, which was released almost _2
years
> ago_, the minimum requirement for trunk?
+1
Cheers, Alfred.
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or pri
+1, even though he doesn't want to work for me :-)
Cheers, Alfred.
-Original Message-
From: Reinhard Poetz [mailto:[EMAIL PROTECTED]
Sent: Freitag, 28. Juli 2006 07:45
To: dev@cocoon.apache.org
Subject: [Vote] Ard Schrijvers as a new Cocoon committer
...
Please cast your votes!
Thi
The Geneva branch office of SWX Swiss Exchange has a job opening for an
experienced developer.
We are using Cocoon as framework for building highly dynamic websites
containing financial data.
The post requires skills in Cocoon, Java, XSP, XSLT, JDBC, and related
technologies.
More details and how
down at such a time, and not our SVN repo too."
Simone
Nathaniel Alfred wrote:
>Why not keep the MVN repo in the Cocoon SVN repository like we used to
>do with the lib directory? That would allow close control of updates
>only by committers, and with a MVN file repo pointing
Why not keep the MVN repo in the Cocoon SVN repository like we used to
do with the lib directory? That would allow close control of updates
only by committers, and with a MVN file repo pointing to the user's
Cocoon checkout, builds remain stable between SVN updates.
Sure that requires again 100+
Wouldn't it make sense to put the jars back into SVN that a checkout
itself is used as the local master M2 repository?
Distributions for user installation could still be kept small by
downloading there dependencies from a public M2 site at build time.
Cheers, Alfred.
This message is for the na
> It's spring time, new committers are blossoming! I'd like to propose
> Simone Gianni for Cocoon committership.
+1
I think I know Simone from my earlier life at CERN?
Cheers, Alfred.
This message is for the named person's use only. It may contain confidential,
proprietary or legally privil
> I'd like to propose Niclas Hedhman as a new Cocoon committer.
+1
Cheers, Alfred.
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or privilege
is waived or lost by any mistransmission. If you re
> So the proposed plan to release 2.1.9 is:
> - Start code freeze on the 31st of March
> - Release on the 6th of April (if nothing bad happens)
+1
Cheers, Alfred.
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No c
>Please cast your votes!
+1
Cheers, Alfred.
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or privilege
is waived or lost by any mistransmission. If you receive this message in error,
please no
-Original Message-
From: Andrew Savory [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 22. Dezember 2005 14:43
To: dev@cocoon.apache.org
Subject: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re:
Problem with CachingPointProcessingPipeline)
Hi,
On 20 Dec 2005, at 15:56, Jean-Bapti
Good idea, thanks. I'll do that.
Cheers, Alfred.
-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 23. November 2005 14:10
To: dev@cocoon.apache.org
Subject: Re: [jira] Updated: (COCOON-1691) ESQL compilation error
Alfred Nathaniel (JIRA) wrote:
> [
>Le 20 oct. 05, à 10:54, Bertrand Delacretaz a écrit :
>> I have fixed a few things so that all htmlunit-tests pass here (JDK
>> 1.4.2, macosx 10.3.8).
>>
>> It would be cool if people could run these tests on other platforms
>> and report results here...
>FWIW, I've received a success report o
The JIRA import seems to have a UTF-8 vs. LATIN-1 encoding problem.
The reporter field is messed up in
http://issues.apache.org/jira/browse/COCOON-1603
http://issues.apache.org/jira/browse/COCOON-1627
On the hand Jörg is spelled correctly in
http://issues.apache.org/jira/browse/COCOON-1624
Cheers
> So I have the pleasure of proposing Max as our new committer!
+1
Cheers, Alfred.
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or privilege
is waived or lost by any mistransmission. If you re
> I'd like to propose Ross Gardler as a Cocoon committer.
Sure +1.
Cheers, Alfred.
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or privilege
is waived or lost by any mistransmission. If you r
> Please cast your votes!
+1
Cheers, Alfred.
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or privilege
is waived or lost by any mistransmission. If you receive this message in error,
please n
> -Original Message-
> From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]
> Sent: Freitag, 26. August 2005 13:53
> To: dev@cocoon.apache.org
> Subject: Re: JUnit Tests and maven status
>
>
> Le 26 août 05, à 13:17, Daniel Fagerstrom a écrit :
>
> > Bertrand Delacretaz wrote:
> >
> >> Ma
> So, I'm pleased to propose Jorg Heymans, as a committer.
> Please cast your votes:
+1
Cheers, Alfred.
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or privilege
is waived or lost by any mist
Hi Antonio,
The fix was actually quite simple: replace CharSequence by String
because that is the only type for which consume is called.
1.3 compatibility is becoming more and more of a problem since
most developers are now using 1.4 or even 1.5. One more reason
to stabilize C2.2 and release it
-Original Message-
From: Antonio Gallardo [mailto:[EMAIL PROTECTED]
Sent: Sonntag, 31. Juli 2005 09:27
To: dev@cocoon.apache.org
Subject: java 1.3 and cocoon 2.1.x branch.
Hi:
I know most of us usually write java code for 1.4. We need keep a
contract with our users, the backward compati
> I think we should really start seeing branch as what it should be: a
> maintenance branch ;) And try to get a 2.2 out asap.
>
> Carsten
+1
Alfred.
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentialit
> Please cast your votes!
>
> -Bertrand
+1
Cheers, Alfred.
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or privilege
is waived or lost by any mistransmission. If you receive this message in
Yes, I'm thinking of attending the Cocoon GetTogether 2005 in
Amsterdam, preferably on
[X] 3/4/5 October (Mon->Wed)
[ ] 5/6/7 October (Wed->Fri)
Cheers, Alfred.
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged informatio
Twice static final int MODE_xxx = 8 looks like copy-waste error?
Cheers, Alfred.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Freitag, 17. Juni 2005 13:46
To: cvs@cocoon.apache.org
Subject: svn commit: r191131 -
/cocoon/branches/BRANCH_2_1_X/src/blocks/mail/ja
>-Original Message-
>From: Upayavira [mailto:[EMAIL PROTECTED]
>Sent: Donnerstag, 9. Juni 2005 11:52
>To: dev@cocoon.apache.org
>Subject: [VOTE] Document Editors, and a new Committer
>On this basis, I'd like to propose Helma Van Der Linden as a Cocoon
>committer, and thus our first 'publi
>-Original Message-
>From: Jochen Kuhnle [mailto:[EMAIL PROTECTED]
>Sent: Mittwoch, 8. Juni 2005 19:04
>To: dev@cocoon.apache.org
>Subject: Re: Why does XSPMarkupLanguage wrap text in xsp:text?
>Hope I'm not too annoying on this issue, but on further work on logic
>sheets, I believe the a
> -Original Message-
> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
> Sent: Dienstag, 31. Mai 2005 15:30
> To: dev@cocoon.apache.org
> Subject: Re: [RFE] Some enhancements to XSP
> > Instead of "?" one could also use another character provided it is
> > sufficiently
> > unlikely that t
> -Original Message-
> From: Jochen Kuhnle [mailto:[EMAIL PROTECTED]
> Sent: Dienstag, 31. Mai 2005 14:07
> To: dev@cocoon.apache.org
> Subject: RE: [RFE] Some enhancements to XSP
> > Any preferrences which character to use?
>
> Out of purely unrational affection, I prefer "#{" and "}".
The server is waiting for data from the client and times out.
Could be the client being stuck, or a protocol mismatch that
both sides wait for each other. Putting on a network trace
and analysing the HTTP exchange could give the answer.
File upload is quite a complicated part of the HTTP protocol
> -Original Message-
> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
> Sent: Dienstag, 31. Mai 2005 15:47
> To: dev@cocoon.apache.org
> Subject: Re: XSP: EclipseJavaCompiler chokes on warings
>
>
> Jochen Kuhnle wrote:
> > Vadim Gritsenko <[EMAIL PROTECTED]> wrote on 31.05.2005
> 05:00
> -Original Message-
> From: Jochen Kuhnle [mailto:[EMAIL PROTECTED]
> Sent: Freitag, 27. Mai 2005 15:02
> To: dev@cocoon.apache.org
> Subject: RE: [RFE] Some enhancements to XSP
> If we filter the logic sheets, too, we can still move code back and forth
> between XSP and logic sheet. Th
>-Original Message-
>From: Daniel Fagerstrom [mailto:[EMAIL PROTECTED]
>Sent: Donnerstag, 26. Mai 2005 15:42
>To: dev@cocoon.apache.org
>Subject: Re: [RT] Block usage
>>> a block deployer block
>>
>> Basically the block deployer will be a stand-alone application (Ant
>> task, Maven plug-i
>-Original Message-
>From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
>Sent: Mittwoch, 25. Mai 2005 20:47
>To: dev@cocoon.apache.org
>Subject: Re: [RFE] Some enhancements to XSP
>>>3. A mechanism for expression replacement as in XSLT or JXTG, replacing
>>>"{expression}" with a xsp:attribut
> -Original Message-
> From: Antonio Gallardo [mailto:[EMAIL PROTECTED]
> Sent: Dienstag, 24. Mai 2005 23:53
> To: dev@cocoon.apache.org
> Subject: RE: [RFE] Some enhancements to XSP
>
>
> On Mar, 24 de Mayo de 2005, 15:40, Nathaniel Alfred dijo:
> > Also f
>-Original Message-
>From: Jochen Kuhnle [mailto:[EMAIL PROTECTED]
>Sent: Dienstag, 24. Mai 2005 13:45
>To: dev@cocoon.apache.org
>Subject: [RFE] Some enhancements to XSP
>
>
>Hi, I know XSPs are supposed to go away, but I still like 'em... I would
>like to propose some enhancements, and i
> -Original Message-
> From: Daniel Fagerstrom [mailto:[EMAIL PROTECTED]
> Sent: Dienstag, 24. Mai 2005 13:40
> To: dev@cocoon.apache.org
> Subject: Re: [RT] Micro kernel based Cocoon
>
>
> Sylvain Wallez wrote:
>
> > Daniel Fagerstrom wrote:
> >
> >> Sylvain Wallez wrote:
> >>
> >>
> >
ache.org
Subject: Re: Synchronization on session object (was svn commit: r169856
-
/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/environment/htt
p/HttpRequest.java)
On 13.05.2005 11:37, Nathaniel Alfred wrote:
> I think synchronized(session) should never be used as vehicle to
> coor
> -Original Message-
> From: Ralph Goers [mailto:[EMAIL PROTECTED]
> Sent: Freitag, 13. Mai 2005 08:57
> To: dev@cocoon.apache.org
> Subject: Re: svn commit: r169856 -
> /cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/environment/http/HttpRequest.java
> >
> >You don't want to rep
One must synchonize the put and get operation on the map itself
in order to protect its internal consistency.
Map map = Collections.synchronizedMap(new HashMap());
...
map.put(key, value);
...
value = map.get(key);
is just easier to read than
Map map = new HashMap();
...
synchron
n.getId();
> syncronized(map) {
> if (!map.contains(id)) {
> return (Session)map.get(id);
> }
> else {
> Session session = new HttpSession(serverSession);
> map.put(id, session);
> return session;
> }
> }
>
&g
Daniel Fagerstrom wrote:
> To simplify and make the environment handling in flow, jxtg, modules and
> possibly other places more coherent, I propose that we extend the Cocoon
> environment apis with some utility methods that makes the environment
> more reflection friendly. See
> http://marc.th
>-Original Message-
>From: news [mailto:[EMAIL PROTECTED] Behalf Of Joerg Heinicke
>Sent: Donnerstag, 12. Mai 2005 11:16
>To: dev@cocoon.apache.org
>Subject: Re: [IMP] synchronization on session object in Cocoon
>I have an implementation with map in HttpRequest and without
>"double-checke
>-Original Message-
>From: Sebastien Arbogast [mailto:[EMAIL PROTECTED]
>Sent: Mittwoch, 11. Mai 2005 23:16
>To: dev@cocoon.apache.org
>Subject: Re: Community health
>Personally I think of mailing lists as really old-fashioned ways of
>communicate, all the more so as they are more and more
>-Original Message-
>From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
>Sent: Mittwoch, 11. Mai 2005 18:04
>To: dev@cocoon.apache.org
>Subject: Re: [IMP] synchronization on session object in Cocoon
>
>
>Joerg Heinicke wrote:
>
>>Sylvain Wallez apache.org> writes:
>>
>>>Or more simply we
> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] Behalf Of Joerg Heinicke
> Sent: Mittwoch, 11. Mai 2005 17:22
> To: dev@cocoon.apache.org
> Subject: Re: [IMP] synchronization on session object in Cocoon
> I have implemented the session attribute solution. Would be
> nice if y
> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] Behalf Of Joerg Heinicke
> Sent: Mittwoch, 11. Mai 2005 13:50
> To: dev@cocoon.apache.org
> Subject: Re: [IMP] synchronization on session object in Cocoon
...
> > But the String pool comes to the rescue. This should work for all
>
> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] Behalf Of Joerg Heinicke
> Sent: Dienstag, 10. Mai 2005 18:56
> To: dev@cocoon.apache.org
> Subject: [IMP] synchronization on session object in Cocoon
> As you can see on every request a new wrapper is instantiated
> which is re
>-Original Message-
>From: Torsten Curdt [mailto:[EMAIL PROTECTED]
>Sent: Montag, 9. Mai 2005 18:26
>To: dev@cocoon.apache.org
>Subject: Re: Managing credits for contributors
>
>> IMO status.xml and the svn logs serve different purpose.
>
>seriously? ...are the commit message much differen
> -Original Message-
> From: Rajaneesh [mailto:[EMAIL PROTECTED]
> Sent: Mittwoch, 4. Mai 2005 08:04
> To: dev@cocoon.apache.org
> Subject: How do I unsubscribe from this mailing list
>
>
> How do I unsubscribe from this mailing list
Send an emtpy mail to [EMAIL PROTECTED] and acknowlege
> -Original Message-
> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
> Sent: Montag, 2. Mai 2005 23:53
> To: dev@cocoon.apache.org
> Subject: [VOTE] Removing author tags
> So I propose to remove @author tags with people names from all our
> source files.
+1
> Additionally, if you agre
> -Original Message-
> From: Leszek Gawron [mailto:[EMAIL PROTECTED]
> Sent: Montag, 25. April 2005 20:54
> To: dev@cocoon.apache.org
> Subject: Re: [PROPOSAL] Download of jars with Maven ant tasks
>
>
> All of the tasks can optionally take one or more remote
> repositories to download
> I counted eighteen +1s and no other votes, welcome Alfred!
> -Bertrand
With my account in the works, it's time to introduce myself.
I am team leader of Internet Service Development at SWX Swiss Exchange.
Our business unit SWX e-Services (current staff 18, half of them
developers) is in charge
> From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]
> So, I'm pleased to propose Alfred, should he accept the nomination, as
> a committer. Of course, my secret hope is that he will contribute many
> additional automated tests, but the committment is to the project, not
> to a particular task
> -Original Message-
> From: Upayavira [mailto:[EMAIL PROTECTED]
> I think the crucial bit you missed is "embedded". Jetty is
> (aparently -
> I haven't yet tried) easy to embed into other Java apps. So, when the
> junit JVM stops, so does Jetty.
Currently htmlunit requires a more adva
> -Original Message-
> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
> To solve this problem and clarify the different test categories, I
> propose to split them into disctinct directories :
> - src/test/internal for current junit tests
> - src/test/external for htmlunit tests.
>
> Usi
Sylvain Wallez wrote:
> So I propose to remove src/core and move all its content to src/java.
Good idea also on purely technical grounds. When importing a snapshot of the
Cocoon sources as vendor branch into CVS one has to do some special gymnastics
to avoid that the "core" directory falls vic
[x] there is a chance I gonna make it
Cheers, Alfred.
This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, pleas
>-Original Message-
>From: Ralph Goers [mailto:[EMAIL PROTECTED]
>Sent: Mittwoch, 12. Januar 2005 17:30
>To: dev@cocoon.apache.org
>Subject: Re: [VOTE] Creation of a french-speaking users list
>As far as the list goes, I'm generally OK with it but it makes me
wonder
>what happens when some
>Re: code reuse. I'm quite eager too reuse code, usually, but I'm -1 on
>adding another JAR (and another dependency) only for 30 lines of code.
>
> Ugo
The 30 lines are already in an available JAR, only normalize() is
currently private there:
http://cvs.apache.org/viewcvs.cgi/avalon-excali
Checking all dependencies sounds first to be the right thing to do
but it can introduce a new performance bottleneck. Just think of
a well structured hierarchy of stylesheets stored on a filer,
where now the cache validity check requires dozens of NFS-stat
calls.
Caching on a production server is
The Eclipse compiler has not yet resolved the issue of generating
larger bytecode than Pizza or Javac:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=38637
Last time I tried, Javac wouldn't work for XSPs, so Pizza seems to
be the best shot for those borderline cases of complex XSPs.
Please remove
> -Original Message-
> From: Antonio Gallardo [mailto:[EMAIL PROTECTED]
> Sent: Mittwoch, 16. Juli 2003 07:31
> To: [EMAIL PROTECTED]
> Subject: Woody - Validation of 2 fields to be equals
>
> How to make Woody to validate 2 fields when the 2 fields can
> have the same
> value to be
The latest version of excalibur.source.SourceResolver packaged
with Cocoon-2.1m3 normalizes URIs containing "/foo/../bar" to "/bar".
At first sight this looks a good idea and is according to RFC 2396.
But when dealing with file: URIs foo can be a symbolic link
(aka short-cut) such as "foo -> some
93 matches
Mail list logo
