Here's my +1 for
- Sylvain Wallez
A tough choice to make: I'd vote for all of you guys, but we have to
select someone.
I understand this is meant for one year as previously discussed.
With mucho thanks to Steven for doing his part!
-Bertrand
Le 4 juin 04, à 09:59, Torsten Curdt a écrit :
...What about...
our current behaviour would be "external".
I would like to have "always" andt the
"internal" option might be FS ;)
+1 for the declaration, looks clean enough!
-Bertrand
Le 4 juin 04, à 07:59, Joerg Heinicke a écrit :
...
1.1
cocoon-2.1/src/webapp/samples/hello-world/style/swf/hello.fla
<>
1.1
cocoon-2.1/src/webapp/samples/hello-world/style/swf/hello.swf
<>
Are they really binary?
fla and swf are definitely bina
Le 3 juin 04, à 14:36, Torsten Curdt a écrit :
If there aren't any objections I will
nuke the swf block and add the flash
sample.
+1
-Bertrand
Le 3 juin 04, à 11:45, Sylvain Wallez a écrit :
The ultimate source of information is
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/
cocoon/components/treeprocessor/
And it's not there :-(
So I've been running a placebo system in the last week - I like it ;-)
-Bertrand
Hi Cocoonistas,
Tomorrow is FirstFriday [1], and the cross-posting is intentional: you
don't necessarily need to be a committer to participate, there are
plenty of bugs and patches waiting for our collective squashing and
patching [2].
See you there! (on and off tomorrow for me)
[1] http://wiki
Le 3 juin 04, à 09:18, Steven Noels a écrit :
...I'll start the vote tomorrow, as the list of volunteers seems to be
stabilizing. Would candidates mind if this is a public vote? Also, I'd
like the vote to be held on the users list as well - to raise the
level of their awareness of Cocoon communi
Le 3 juin 04, à 09:22, Antonio Gallardo a écrit :
...Yep. I told switch, because it was not clear if all of us will
accept to
drop the Rhino merge effort...
Is anybody actually working on this merge?
(apart from the work done on clearing out the licensing issues)
As "he who does the work decides",
Le 3 juin 04, à 08:41, Antonio Gallardo a écrit :
...Yep. The Sylvain idea sound great! Can we switch the Rhino merge
for this
new task?
Well, if you have the resources I'd say: go for it!
-Bertrand
Le 3 juin 04, à 08:26, Sylvain Wallez a écrit :
- Flow/JS suffers from the legal situation of Rhino+cont and the
difficulty to merge the fork into the Mozilla trunk. I suggested as a
solution to use JavaFlow to instrument Rhino-generated bytecode. That
would lead to a unified code base allow
Le 3 juin 04, à 07:31, Antonio Gallardo a écrit :
...Cocoon is migrating to a new container architecture...
Is it really? Don't get me wrong, there is great work being done in
this area, but IMHO this will take some time to actually materialize as
a release.
...The question
remaining in my mind
Le 31 mai 04, à 12:25, Stefano Mazzocchi a écrit :
...Bertrand already rejected the nomination but I still wanted to
mention him as being part of my list
Thanks.
As this is now a public discussion, Let me just restate my reasons
publicly so that there's no mystery about this: I'd be willing t
Le 1 juin 04, à 11:48, David Crossley a écrit :
It is very confusing when people use the "+1" thing
in general conversation. What are you plussing?
In my case, showing agreement/appreciation about what's being said.
Sorry if this is confusing, point taken.
...The nominations should be made and the
Le 1 juin 04, à 10:48, Sylvain Wallez a écrit :
...Taking your example of news urgency, the corresponding algorithm
would certainly not fit into a single attribute (because of the "if"
constructs it's likely to contain), but could simply be written as :
Sounds good!
Moreover, I find that being
Le 1 juin 04, à 10:13, Sylvain Wallez a écrit :
...I see no problem with the PMC election process occuring in public.
There's nothing confidential in it.
+1
...Ah, and contrarily to last year, I do accept the nomination ;-)
Good news!
+1 for Sylvain.
(now, if several people accept, how do we choos
Le 1 juin 04, à 10:09, Sylvain Wallez a écrit :
...Well, it _could_ have a chance to work, but flowscript is
definitely not the appropriate location to compute cache information
for an element of the view pipeline
flowscript maybe not but how about backend java code?
Use-case: for a news site
Le 27 mai 04, à 02:04, Antonio Gallardo a écrit :
...I am podering if is a worth to merge Rhino jar or if is better to
create
another implementation with Groovy or both?:-D...
Why not both, but for me the priority is clearly to solve the Rhino
merge/license/whatever issues. As much as I'm a f
Le 26 mai 04, à 11:17, Carsten Ziegeler a écrit :
...we have to develop the blocks system separately from Cocoon
until the block system is stable enough to be "merged" into
Cocoon. This allows us to release new versions of Cocoon (like 2.2)
without waiting for blocks to be working/finished.
+1
...
Le 26 mai 04, à 10:56, Ugo Cei a écrit :
..."The Java language specification allows access and storage of
[variables of type double and long] (but not those of other scalar
types) to be non-atomic."...
Hmm..smells too much like something that could be interpreted
differently by different VMs.
Me
Le 26 mai 04, à 10:15, Nicola Ken Barozzi a écrit :
...So, let's all cut a deal: we move to SVN, and then I will rework
the build on a branch. If someone else wants to, he can do the same
with Maven or whatever on another branch. After this is done, we can
have a vote and decide which buildsyste
touch 12011200 sitemap.xmap
reproduces the disposed ComponentLocator problem!
Definitely reproducible, see new comments in
http://issues.apache.org/bugzilla/show_bug.cgi?id=27249
-Bertrand
Le 25 mai 04, à 13:22, Vadim Gritsenko a écrit :
Sylvain Wallez wrote:
...
Bertrand's problem related to CVS $Id$ in comments makes me think to
clock synchronisation problems between the CVS server and the Cocoon
server (e.g. modification date moved back in time).
I noticed sometime ago that set
Le 25 mai 04, à 11:31, Pier Fumagalli a écrit :
...Have you noticed, by any chance, a ConcurrentModificationException
somewhere in your tests?
Not that I remember, but I've attached some logs in bugzilla, you might
want to dig in them.
IIRC, hard restarts didn't help either in this case, the on
Le 25 mai 04, à 11:17, Sylvain Wallez a écrit :
...But what you describe here is really weird: there's absolutely no
data related to sitemap or component manager that is persisted to
disk.
Although in bug 27249 I've seen the problem persist after restarting
cocoon *and* deleting the Jetty temp d
Le 25 mai 04, à 10:49, Pier Fumagalli a écrit :
...Two problems... Definitely, under load, Excalibur fails
disposing/releasing components, and somehow, Cocoon keeps state EVEN
between hard restarts of the JVM...
Anyone ever saw something like this?
Might be related to this very mysterious bug
ht
Le 25 mai 04, à 00:11, Sylvain Wallez a écrit :
...- David, Bertrand and Gianugo (in last name alphabetical order)
have been elected members of the ASF,...
Thanks very much to all involved, I discovered this coming back from a
nice camping trip and it was a very nice surprise - I'll do my best to
Le 25 mai 04, à 10:02, Carsten Ziegeler a écrit :
Apache Cocoon 2.1.5 Released
Thanks very much Carsten, congratulations to all!
-Bertrand
Le 24 mai 04, à 22:18, Antonio Gallardo a écrit :
...Finally We can get rid of the JISP jar. :-D
How do you say +1 in finnish?
Anyway: here's my
+1
-Bertrand
...I propose to move Cocoon to Maven. Please VOTE:
I know the vote is canceled, but maybe we can talk about the problems
before looking at a solution?
IMHO these are the problems of the current build system:
1) Monolithic repository makes it impossible to include libraries
having non-ASF compati
Le 24 mai 04, à 20:07, Stefano Mazzocchi a écrit :
http://www.sleepycat.com/products/je.shtml
...Who's with me?
I am, assuming the license is ok.
It would be good to make this a block, so that JDK 1.3 users can still
compile Cocoon by excluding the block.
-Bertrand
Le 19 mai 04, à 14:43, Peter Lerche a écrit :
...After 2 weeks I have still not cracked how to change cocoon 2.1.5
to accept
other locations for its sitemap elements than the /lib and /classes
dir
hmmm...I'm no expert on servlet containers, but isn't that a limitation
(or rather a security f
Le 19 mai 04, à 10:49, Carsten Ziegeler a écrit :
...If noone objects I will release the current state on monday,
24th of May
+1, but won't be able to help (once again), leaving for a holiday
tomorrow till Sunday.
-Bertrand
Le 18 mai 04, à 14:37, Ugo Cei a écrit :
Bertrand Delacretaz wrote:
DOMBuilderTestCase.testMultipleCharactersEvents also fails:
Content of root element not what expected expected: but
was:
This was a problem with the testcase and not the class under test.
Should be OK now, but I cannot verify
Le 18 mai 04, à 08:52, Carsten Ziegeler a écrit :
..but unfortunately the data does not survive a Cocoon restart
on my system. Any idea?
IMHO this is not a blocker for the release, or is it?
(it's great that you guys are working on it, just trying to make sure
we don't let the release slip too muc
Le 17 mai 04, à 17:56, Bertrand Delacretaz a écrit :
...option 2. is certainly the best, to avoid "endorsing" XSP too much
as you mention. If you have time to do it, great, otherwise option 1.
is acceptable IMHO.
Sorry I was too quick, didn't notice that these were *Sources* s
Le 17 mai 04, à 17:48, Unico Hommes a écrit :
...Since XSP moved
to a block recently there remains this unresolved dependency of the
core on XSP
block. What to do?
1. Leave them there, provide a notice (there are some other places in
the core
samples that do this)
2. Move the samples into the XS
Le 17 mai 04, à 10:30, Antonio Gallardo a écrit :
...Cocoon is failing under Java 1.3.1_10: Here is the output:...
Just did a full compile with all blocks under macosx 10.3.3 / JDK 1.3.1.
Build went fine, tried a few samples which look ok.
Two JUnit tests fail:
CocoonBeanTestCase.testProcessToStrea
Le 17 mai 04, à 09:58, Carsten Ziegeler a écrit :
...I just commited the changes - so you only need to overwrite the
jcs jar
I have a JDK 1.3.1 setup ready here, so if you guys can let me known
when you're ready I can do a full 1.3.1 build and some tests (basic
tests only, I don't have a lot
Le 14 mai 04, à 20:35, Ugo Cei a écrit :
...I'm not saying that you cannot have JCS if you really need all the
features it has to offer. I'm just saying that, for the *default*
configuration, we should prefer simplicity over features.
In other words, offer both options but with EHCache as a defa
Le 14 mai 04, à 11:30, Carsten Ziegeler a écrit :
...So, what do you think about:
- switching to EHCache now
- testing it in the next days
- stick to the code freeze of course
- release on monday/tuesday if no issues arise
+1, but won't be able to help testing unfortunately.
-Bertrand
Le 14 mai 04, à 10:50, Sylvain Wallez a écrit :
...What's the status of EHCache and JCS? Can't we consider one of them
as the default persistent store?
I think there's an issue with JCS, something at shutdown IIRC?
And, also IIRC, Unico reported using EHCache with no problems.
-Bertrand
Le 14 mai 04, à 09:59, Carsten Ziegeler a écrit :
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26753
...
Hmm, yes this is a serious issue - but we have this in all
2.1.x releases :) - so perhaps we should simply add this
to the "known issues" category as well.
Ok - but isn't there a super-ea
Le 14 mai 04, à 09:35, Carsten Ziegeler a écrit :
Ok, so this is "fixed" for the release :)
What about the items that David mentions?
http://marc.theaimsgroup.com/?t=10835857253
To me the most serious issue is bugzilla 26753 (persistent store
corruption),
http://nagoya.apache.org/bugzilla/s
Le 14 mai 04, à 09:13, Ugo Cei a écrit :
..Personally, I wouldn't want to ship a release with a broken
testsuite. I know it amounts to sweeping it under the rug, but I'd
rather remove the testcase temporarily for the release and put it back
just after...
Agreed - removing or replacing the test
Le 13 mai 04, à 19:25, Nicola Ken Barozzi a écrit :
...Yeah, that's one of the things Forrest will tackle. Believe it or
not, I got both Javahelp and WinHelp generated from the same sources
in a couple of hours, but then all got buried in teh rest of my
copious free time :-/
You're right, sounds
Le 14 mai 04, à 08:32, Upayavira a écrit :
Ugo Cei wrote:
...
TEST org.apache.cocoon.bean.CocoonBeanTestCase FAILED
...Yup. This test case just shows up something that has been wrong for
a _very_ long time. I'm reluctant to remove it, as that which it shows
up should be fixed rather than ignored
Sorry about another wild idea about our docs, but this one looks closer
than many, so I'll try to inspire/motivate someone to jump in ;-)
JavaHelp [3], as the name implies, is a java-based help system that
runs client-side.
Uses HTML 3.2 files for content, with a couple of metadata files, and
Le 10 mai 04, à 21:21, Joerg Heinicke a écrit :
On 10.05.2004 14:28, Bertrand Delacretaz wrote:
...I think that it should be called the "tour" block, yet still
have the familiar name of "Supersonic Tour"...
Do others have the same opinion? If so I'm ok to rename the bl
Le 10 mai 04, à 05:59, David Crossley a écrit :
...I think that it should be called the "tour" block, yet still
have the familiar name of "Supersonic Tour"...
Do others have the same opinion? If so I'm ok to rename the block, I
agree that it's a more descriptive name.
-Bertrand
FYI, Stephan Schmidt said yesterday that he's getting the final
approval for a licence change for Radeox.
-Bertrand
Le 7 mai 04, à 14:04, [EMAIL PROTECTED] a écrit :
...i have add one of my flow examples in the same sturcture with
your's in
flow example in supersonic block.
this example use java classes for bussines logic calculations. those
classe are colled from flow.
do you want to add this example insuper
Le 5 mai 04, à 23:37, Sylvain Wallez a écrit :
...There are still many little things to solidify in the CForms API
until it can be marked stable, and therefore Cocoon 2.1.5 will not
contain a stable CForms
+1, let's not forget to release early, release often.
CForms can still mature after 2.1
Le 6 mai 04, à 07:51, Marc Portier a écrit :
...I don't want to rain on anyones parade here, but do we need it?
I understand it's useful and that 'it can be done' but for crying out
loud: is this really a sample of a fundamentally new thing to cocoon?
Or does it survive the 80/20 rule saying it's
Le 5 mai 04, à 20:28, leo leonid a écrit :
...Bruno seems to be the only one concerned about the current
situation, I'm still wondering why his v3 proposal didn't find any
resonance?
Don't know about others obviously, but I have a very hard time keeping
up with all that's happening here current
Le 5 mai 04, à 21:23, leo leonid a écrit :
...And it seems extensible, possibly a chance to demonstrate some O/R
practices with our lovely web glue...
Yes, maybe providing an alternate version of the beans using OBJ to
save themselves to a database would be a nice improvement.
...noticed you're
Le 5 mai 04, à 13:42, Bertrand Delacretaz a écrit :
...IMHO, the chaperon parser is very well suited to strict parsing but
a bit too rigid about the syntax, and harder to customize as it
requires people to understand the LALR grammar...
Just to be clear, I meant this in the context of wiki
I've been talking with Stephan Schmidt, author of the Radeox
(http://radeox.org/) wiki parser API and reference implementation,
about a possible integration of Radeox in Cocoon.
I know we have a wiki parser already, based on Chaperon, but I feel
Radeox is much more adaptable to variations in wi
Le 4 mai 04, à 23:04, Upayavira a écrit :
...In a block called tutorials, I think this could be an invaluable
addition.
but...me likes the name supersonic ;-)
The idea is a very quick, "supersonic" tour of the most important
things in Cocoon. Next step towards understanding is to take another
s
I've just committed the new "supersonic" block, a tutorial/example app
called "Supersonic Tour of Apache Cocoon", focused on Pipelines, Flow,
Forms (aka "the Power Trio").
It is accessible from the "blocks with samples" page if you run the
current Cocoon CVS version.
The tutorial is meant to b
Le 4 mai 04, à 15:55, Nicola Ken Barozzi a écrit :
...What about calling it simply: "tutorial"?
I guess there are already several tutorials out there, the idea between
the "supersonic tour" name is that it's not deep, but a quick overview
of the essentials. And I like the name ;-)
But it will be
I'd like to donate the contents of my "Supersonic Tour of Apache
Cocoon" tutorial to the project, as a new block named "supersonic".
There's more info on the tutorial contents at
http://lots.ch/Supersonic_Tour_of_Apache_Cocoon.html
The pros (IMHO):
-I think it's a good overview of the Power Trio
Le 1 mai 04, à 00:15, Sylvain Wallez a écrit :
..Sending announcements to -users doesn't seem more appropriate to me
than spamming grabbed email addresses...
Same as others, I have no problem with Cocoon-related commercial
announcements on our lists provided
a) sender is in some way a member of
Le 30 avr. 04, à 17:01, Roger I Martin PhD a écrit :
...I keep getting an email with an attachment that claims to be from
Andrew to Cocoon-dev. Anybody else getting this? If you find out the
address of the bastard doing this is in my corner of the world, I'm
willing to go thump some sense into
Le 30 avr. 04, à 16:24, Jorg Heymans a écrit :
...On a side note: Thunderbird is not keeping track of threads anymore
in the cocoon mailinglists, i trust that this is completely related to
it not being capable of threading quite a large number of messages and
*not* related to some server side kn
Le 29 avr. 04, à 20:41, Leszek Gawron a écrit :
...I am more than willing to help. What should I do ?
See this thread
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108204436515664&w=2
for some discussion and ideas about this.
I think the following steps would be enough to allow the
GroovySQL/Gr
Le 29 avr. 04, à 16:53, Leszek Gawron a écrit :
...This is also how I do it in standard web apps. But the performance
is a great
issue here. Creating 10k JavaBeans, keeping them in memory and than
processing
by JXTG is very memory and time consuming
Sounds like a use case for the (vaporware a
Le 29 avr. 04, à 16:57, Carsten Ziegeler a écrit :
...Basically I mostly agree with you. It's not that good to have user
docs in the Java Source, but it's better to have the JavaDocs as
a documentation than nothing :) (which is today the case - sometimes
at least).
Big +1
And Carsten said he was i
Le 29 avr. 04, à 11:52, Upayavira a écrit :
...Doesn't it replace, for example /cocoon/src/java/../webapp with
/cocoon/src/webapp? i.e. removing .. from paths?
FWIW, I have attached the results of
find src -type f -name *.java | xargs -n200 grep 'NetUtils.*normalize'
-Bertrand
results of
find
Le 27 avr. 04, à 11:57, Bruno Dumon a écrit :
...You could look at it that way, but I like enabled/disabled better
(IMHO)...
You're the one (or one of the ones) who's doing actual work here, so
your HO certainly wins over mine!
I was just suggesting anyway. But I find enabled/disabled more
consis
Le 27 avr. 04, à 10:19, Bruno Dumon a écrit :
On Tue, 2004-04-27 at 08:37, Bertrand Delacretaz wrote:
Le 27 avr. 04, à 08:30, Sylvain Wallez a écrit :
...At the time where we discussed this, I proposed
active/disabled/hidden, which is more traditional for GUI widgets:
- active is the normal
Le 27 avr. 04, à 08:30, Sylvain Wallez a écrit :
...At the time where we discussed this, I proposed
active/disabled/hidden, which is more traditional for GUI widgets:
- active is the normal behaviour (what we have today)
- disabled is like @type=output with the additional behaviour that the
reque
Le 23 avr. 04, à 14:46, Guido Casper a écrit :
...Once such a customized doclet mechanism is in-place (Does someone
know wether QDox already has an Ant task? Or maybe we should use
XDoclet for that?)...
There is a qdox block in Cocoon, which could certainly be used at the
documentation generatio
Le 23 avr. 04, à 11:56, Upayavira a écrit :
...I really think we should get away from this idea of multiple
repositories. Subversion should, I believe, fix the problems that led
us to our multiple repository situation, and therefore we should have
just two repositories: code and site. (Of course
Le 22 avr. 04, à 22:03, Carsten Ziegeler a écrit :
...So, I think we should vote now for the general tendency
outlined in the guide and not on every detail
+1
Thanks for your work, Carsten!
-Bertrand
Le 22 avr. 04, à 11:37, Upayavira a écrit :
...As Nicola Ken mentioned, there's:
https://svn.apache.org/repos/test
Thanks for the info - I have created
http://wiki.cocoondev.org/Wiki.jsp?page=SubversionMigration to help us
during the move.
-Bertrand
Le 22 avr. 04, à 10:27, Nicola Ken Barozzi a écrit :
...The result is that we have decided to move to subversion right
after the next 2.1 branch point release
Can you recommend a practice repository for people who need to test
their clients (before messing up with the Cocoon SVN repository ;
Le 21 avr. 04, à 10:29, Upayavira a écrit :
Carsten Ziegeler wrote:
What are the current problems we have with CVS that you want to solve
with such a move?
For example keeping everything in one big repository and using
branches?
would be a very good reason for me.
The reason why we don't use b
Le 21 avr. 04, à 08:46, Nicola Ken Barozzi a écrit :
Since we are working a lot with branches...
Are we really? I thought branches were unwelcome around here (although
I never really understood why).
...I propose that we move Cocoon to use SVN...
I'm +1 basically (or more precisely +0.5, cannot
Le 19 avr. 04, à 21:37, Ugo Cei a écrit :
...Hey, that's not my fault. CalendarGenerator's was ;-).
It's fixed now, please cross-check.
Sorry, I should have done the change myself, it was...not so complex ;-)
I just did a complete build under 1.3.1, successfully, thanks.
Note that I'm not partic
(sorry, hit send by mistake on previous message)
Le 19 avr. 04, à 17:59, Ugo Cei a écrit :
...I just committed a fix. Can you tell me if there are other
problems, as I don't have a JDK 1.3 here, please?
CalendarGenerator now compiles, thanks!
There is the same problem (Locale constructor) in
sr
Le 19 avr. 04, à 17:59, Ugo Cei a écrit :
Bertrand Delacretaz wrote:
cocoon-2.1/src/java/org/apache/cocoon/generation/
CalendarGenerator.java:152:
cannot resolve symbol
symbol : constructor Locale (java.lang.String)
location: class java.util.Locale
locale = new Locale
cocoon-2.1/src/java/org/apache/cocoon/generation/
CalendarGenerator.java:152:
cannot resolve symbol
symbol : constructor Locale (java.lang.String)
location: class java.util.Locale
locale = new Locale(langString);
It looks like the Locale(String language) constructor is not
Le 19 avr. 04, à 11:08, Reinhard Poetz a écrit :
...I have to think more about the API of this component but first I
want to talk more about the background of my idea. I had several
discussions with Alex Schatten and we came to the conclusion that,
generally spoken, there are two database usage
Le 19 avr. 04, à 10:50, Upayavira a écrit :
I would like to propose that we remove the Ant task from the
scratchpad.
This Ant task has been superceded by the new one that makes use of the
CocoonBean, sharing its configuration code.
+1
-Bertrand
Le 19 avr. 04, à 10:51, Antonio Gallardo a écrit :
...I will be glad to propose a
Groovy block that will use BSF more oriented to Groovy needs. Something
like precompiling support of classes, then if the source don't change
we
will be able to run the class as a generator (as XSP do now)
Of co
Le 19 avr. 04, à 10:17, Reinhard Poetz a écrit :
...The best way integrating database support in Flowscript is using an
*O/R-mapper*. If this is too complicated I would recommend a general
database component
I don't know much about the ModularDatabaseActions, but would a
ModularDatabaseCompo
Le 17 avr. 04, à 20:06, Carsten Ziegeler a écrit :
...So, I would suggest that we change our development plan a little
bit and consider adding those features to our 2.1.x code base
that are independent from blocks, like e.g. the virtual sitemap
components etc. Of course we should take care that th
Le 17 avr. 04, à 21:39, Tony Collen a écrit :
...My condition [a] on the item above was that we should try to
eliminate people from having to make these code changes in the first
place. We should be following the standard Java style, and most IDEs
can help enforce this...
I don't think an IDE-b
Le 17 avr. 04, à 17:42, Antonio Gallardo a écrit :
Joerg Heinicke dijo:
IMO it's only important to separate code changes clearly from style
changes. For an example see
http://thread.gmane.org/gmane.text.xml.cocoon.cvs/11901. A replacement
of hand-written code with commons lang code got completely
Lately there have been several hints that people are annoyed by commits
consisting only of style changes (rearranging imports, "cleaning up"
indents) etc.
Of course, there are always good intentions behind such changes, but
IMHO changes which make no difference to the actual code, are:
a) risk
Le 16 avr. 04, à 15:28, Marc Portier a écrit :
...I'm not currently not convinced there could be anything else then
careful consideration on each point in the code, sorry if this is bad
news
I tend to agree.
I don't have time currently to seriously follow the discussion, but a
quick random
Le 16 avr. 04, à 14:40, [EMAIL PROTECTED] a écrit :
...Ultimately you're right and the ToC should be generated, but for
now I want
to use it as an inventory for what's available, what's missing and in
short:
how much work is ahead. :-)
Fine, thanks for the clarification!
-Bertrand
Le 16 avr. 04, à 13:11, [EMAIL PROTECTED] a écrit :
...Yes I noticed on the wiki, my idea exactly to merge them, although
my plans
with the ToC are more "grand". As explained in another message, my
goal is
to get to an ebook kind of documentation
I dont' want to stop or slow down your most we
Hi Helma,
...AHA. That explains the "complete radio silence" when it comes to
updating
the documentation. :-) ...
Sorry about that. I guess some of us are in a more or less burnout
state about the docs (I am).
There have been many discussions about how to improve the docs, many
real good ideas
Le 16 avr. 04, à 03:41, Antonio Gallardo a écrit :
...Yes. I agreed, but there are still some issues to solve first in
this
parentesis oriented grammar. For example, try to write something like:
Hello, bold text
and you will see the true
You're right, the current state about mixed markup is
Le 16 avr. 04, à 00:02, Ugo Cei a écrit :
...In order to move forward, I propose to reparent the
org.apache.cocoon.ProcessingException to extend
org.apache.avalon.framework.CascadingRuntimeException instead of
CascadingException
+1
-Bertrand
Le 15 avr. 04, à 21:40, Antonio Gallardo a écrit :
...Aparently no O/R mapping suppport.
==
No researched enough Groovy to said that, but I will not go back to
plain
JDBC and SQL
I'm not seeing Groovy SQL support as a replacement for O/R mapping or
java-based b
Le 15 avr. 04, à 19:37, Leon Widdershoven a écrit :
You don't have access to a ServiceManager or ComponentManager
(provided by cocoon and holding the
configured pools)?
Sure - it just needs a little bridge to make the pools or Connections
available to the scripts.
-Bertrand
Le 15 avr. 04, à 18:20, [EMAIL PROTECTED] a écrit :
...You might as well just use DataSource then as this is pretty close
to all DataSource is. (Or at the least get ConnectionProvider to
implement DataSource)
There's an implementation in Jakarta Commons dbcp and various JDBC
drivers come with a
Le 15 avr. 04, à 18:01, [EMAIL PROTECTED] a écrit :
...BTW you could just create the Sql object with a DataSource which
is-a JDBC connection pool, then the Sql object takes care of all the
pooling for you. Is there support for DataSource in Cocoon or some
kinda adapter between DataSource and Co
1101 - 1200 of 1633 matches
Mail list logo
