Le 11 oct. 05, à 12:43, Pier Fumagalli a écrit :
Ok, there we go, here's the vote...
[ ] +1 Yes please, let's move all our bugs to Jira...
+1 BUT - I'm going to start a vote about
http://wiki.apache.org/cocoon/BugzillaIssuesCleanup, to do a big
cleanup in the next two weeks, so it would
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon has an issue affecting its community integration.
This issue affects 55
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon has an issue affecting its community integration.
This issue affects 55
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36907.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Jorg Heymans wrote:
Leszek Gawron wrote:
want it - got it.
check the trunk - if it's ok - I'll port it back to 2.1.
I don't have time to check myself, but are these new properties
respected by the eclipse-customized-project target ?
They should but ... to tell you the truth I do not know.
Jorg Heymans wrote:
Leszek Gawron wrote:
want it - got it.
check the trunk - if it's ok - I'll port it back to 2.1.
I don't have time to check myself, but are these new properties
respected by the eclipse-customized-project target ?
Unfortunately it does not - I'll look into that.
--
Jorg Heymans wrote:
Leszek Gawron wrote:
want it - got it.
check the trunk - if it's ok - I'll port it back to 2.1.
I don't have time to check myself, but are these new properties
respected by the eclipse-customized-project target ?
want it - got it (I will (tm) this ! :))
--
Leszek
Leszek Gawron wrote:
Jorg Heymans wrote:
Leszek Gawron wrote:
want it - got it.
check the trunk - if it's ok - I'll port it back to 2.1.
I don't have time to check myself, but are these new properties
respected by the eclipse-customized-project target ?
They should but ... to tell you
Carsten Ziegeler wrote:
But unfortunately the portal is still not working; it seems to me that
lazy loading really has some problems. The first time I invoke the
portal I get an obscure NPE, if I reload the page everything works
perfectly. So it seems that something is not initialized properly.
Ok, there we go, here's the vote...
[X] +1 Yes please, let's move all our bugs to Jira and set it up
to work in the following way:
+1
Arjé
Leszek Gawron wrote:
want it - got it (I will (tm) this ! :))
mighty cool, thanks Leszek !
So what about those 300 outstanding bugzilla issues :P
On 13 Oct 2005, at 07:14, Bertrand Delacretaz wrote:
Le 11 oct. 05, à 12:43, Pier Fumagalli a écrit :
Ok, there we go, here's the vote...
[ ] +1 Yes please, let's move all our bugs to Jira...
+1 BUT - I'm going to start a vote about http://wiki.apache.org/
Le 13 oct. 05, à 10:42, Pier Fumagalli a écrit :
...In the meantime, I'm going to set-up Jira with statuses and
workflows. And after the cleanup is done, we can move all outstanding
issues over...
Cool, thanks.
-Bertrand
David Crossley wrote:
Ross Gardler wrote:
Now that I am a Cocoon committer, can someone with the necessary karma
please create an account for me on the Cocoon Zone. I would like to set
up the ForrestBot to publish a staged site from Daisy every X hours.
I know that enthousiasm is bubbling
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36907.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Leszek Gawron wrote:
Leszek Gawron wrote:
Jorg Heymans wrote:
Leszek Gawron wrote:
want it - got it.
check the trunk - if it's ok - I'll port it back to 2.1.
I don't have time to check myself, but are these new properties
respected by the eclipse-customized-project target ?
They
Sylvain Wallez wrote:
Fixed. The problem was caused by the GroupBasedProfileManager which was
not preloaded and thus wasn't listening for events. This led the portal
temporary attribute (don't know what that is) named
org.apache.cocoon.portal.profile.impl.AbstractProfileManager/User not
Jorg Heymans wrote:
Leszek Gawron wrote:
want it - got it (I will (tm) this ! :))
mighty cool, thanks Leszek !
So what about those 300 outstanding bugzilla issues :P
Hmmm you know ... I do impossible things in no time. Still you'll have
to wait a little bit for miracles.
--
Leszek
Leszek Gawron wrote:
I will remove the standard eclipse-project (It also seems outdated
comparing to eclipse-customized-project). eclipse-customized-project has
all the functionality of the former one so this should be no problem for
as the standard eclipse-project is more known, why not
Leszek Gawron wrote:
I will remove the standard eclipse-project (It also seems outdated
comparing to eclipse-customized-project). eclipse-customized-project has
all the functionality of the former one so this should be no problem for
anyone.
Please don't - I'm using the project to
Upayavira wrote:
Leszek Gawron wrote:
Leszek Gawron wrote:
Jorg Heymans wrote:
Leszek Gawron wrote:
want it - got it.
check the trunk - if it's ok - I'll port it back to 2.1.
I don't have time to check myself, but are these new properties
respected by the eclipse-customized-project
Carsten Ziegeler wrote:
Leszek Gawron wrote:
I will remove the standard eclipse-project (It also seems outdated
comparing to eclipse-customized-project). eclipse-customized-project has
all the functionality of the former one so this should be no problem for
anyone.
Please don't - I'm
Leszek Gawron wrote:
The thing is eclipse-project and eclipse-customized-project were out of
sync (doing different things regardles of being inclusion/exclusion aware)
how about:
build -Dinclude.all.blocks=true eclipse-project
I assume that include has precedence over exclude, right?
Carsten Ziegeler wrote:
Leszek Gawron wrote:
The thing is eclipse-project and eclipse-customized-project were out of
sync (doing different things regardles of being inclusion/exclusion aware)
how about:
build -Dinclude.all.blocks=true eclipse-project
I assume that include has precedence
Leszek Gawron wrote:
Carsten Ziegeler wrote:
Leszek Gawron wrote:
The thing is eclipse-project and eclipse-customized-project were out
of sync (doing different things regardles of being
inclusion/exclusion aware)
how about:
build -Dinclude.all.blocks=true eclipse-project
I assume that
Upayavira wrote:
So, I have created a wiki page:
http://wiki.apache.org/cocoon/PublicAPIClasses
Please go there and mark classes public/private as necessary. As it
says at the top of that page, if you disagree with someone, change it
to dispute or D for short. Then it becomes an opportunity
David Crossley wrote:
hepabolu wrote:
And Windows? At work I use Windows and handle all SVN actions using
subclipse.
Erk. Well then one of the other committers can set
the properties for those files.
Well, I went through the entire subclipse menu and found some entries to
set properties
Leszek Gawron wrote:
Leszek Gawron wrote:
Carsten Ziegeler wrote:
Leszek Gawron wrote:
The thing is eclipse-project and eclipse-customized-project were out
of sync (doing different things regardles of being
inclusion/exclusion aware)
how about:
build -Dinclude.all.blocks=true
Stefano Mazzocchi wrote:
Ross Gardler wrote:
Vadim Gritsenko wrote:
...
Another problem I noticed - all URLs are number.daisy.html - we can't
publish these to official website...
Which part(s) are you objecting to?
The number is because daisy uses numbers rather than names to identify
--- Daniel Fagerstrom [EMAIL PROTECTED] schrieb:
Upayavira wrote:
So, I have created a wiki page:
http://wiki.apache.org/cocoon/PublicAPIClasses
Please go there and mark classes public/private as
necessary. As it
says at the top of that page, if you disagree with
someone,
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
As described in the comment above, classes in [block]/COB-INF/classes are added
to the classpath. The information, which blocks are added, is read out from
wiring.xml.
While doing this, I've (hopefully) cleaned up our classloading abit as I've
--- Leszek Gawron [EMAIL PROTECTED] schrieb:
Does it mean I will be forced to have xalan/xerces
in cocoon's
web-inf/lib directory? Right now the only place is
jetty/lib/endorsed.
No, but if you put it into web-inf/lib they will be
used, independently what the system classloader or the
* Jorg Heymans:
Jean-Baptiste Quenot wrote:
Bug 36907 Missing dependency on commons-beanutils
http://issues.apache.org/bugzilla/show_bug.cgi?id=36907
isn't this fixed by r314825 from yesterday by Bruno ?
Yes, thank you.
--
Jean-Baptiste Quenot
Systèmes d'Information
ANYWARE
* Ugo Cei:
* Bruno Dumon ha scritto:
The problem is that (at least for me) this requires updating
some javascript here and there which makes use of the IDs, and
more annoying, that it makes it hard to support both 2.1.7 and
2.1.8 at the same time for the same application.
I agree. I
Bruno Dumon wrote:
Hi,
I've noticed that in 2.1-head all widgets have in their HTML rendering
the text -input added to their widget id (and are contained in a span
which has the original widget id).
I assume this is to support the new ajax stuff, but is there a reason
why this couldn't have
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon has an issue affecting its community integration.
This issue affects 55
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon has an issue affecting its community integration.
This issue affects 55
Ross Gardler wrote:
David Crossley wrote:
Ross Gardler wrote:
Now that I am a Cocoon committer, can someone with the necessary karma
please create an account for me on the Cocoon Zone. I would like to set
up the ForrestBot to publish a staged site from Daisy every X hours.
I know that
Ross Gardler wrote:
However, as Vadim said (in another mail in this thread) we have to be
careful not to break current links and search engine indexing. This can
be done by forcing the rewriting of links to mirror the existing
structure, but that assumes the existing structure is good. I
Ugo Cei wrote:
Il giorno 12/ott/05, alle ore 16:48, Vadim Gritsenko ha scritto:
Check your ~/.subversion/config, it should have [auto-props] section
set up. For files already added to the svn, use this shell script:
Would you be so nice as to share with us the contents of your [auto-
Ugo Cei wrote:
Il giorno 12/ott/05, alle ore 11:35, Bruno Dumon ha scritto:
I've noticed that in 2.1-head all widgets have in their HTML rendering
the text -input added to their widget id (and are contained in a span
which has the original widget id).
I assume this is to support the new
[EMAIL PROTECTED] wrote:
Our barrier to be able to extend the SQLTransformer is the Inner Class
Query is either package access in the 2.1.7 version or now refactored
to private access in the latest code base.
Could Query be a interface with a default implementation , a non Inner
Public Class, a
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=6200.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Bertrand Delacretaz wrote:
Le 13 oct. 05, à 10:42, Pier Fumagalli a écrit :
...In the meantime, I'm going to set-up Jira with statuses and
workflows. And after the cleanup is done, we can move all outstanding
issues over...
Shouldn't we move *all* issues to Jira - so that fixed/closed
[EMAIL PROTECTED] wrote:
I'm a bit disappointed by the lack of interest in Bugzilla issues. Do
committers read bugzilla notifications on cocoon-dev? I wonder.
punNo, they filter them out! But once we move over to Jira, all filters will
broke and they will read them for a week or so.../pun
Vadim Gritsenko wrote:
Same here. I think we should treat those XSLT files more like our
public API with forms users and keep an eye on backward compatibility.
I agree. But the problem is that the switch to Ajax required more ids in
the page to identify updatable units which are bound to
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Same here. I think we should treat those XSLT files more like our
public API with forms users and keep an eye on backward compatibility.
I agree. But the problem is that the switch to Ajax required more ids in
the page to identify updatable
Le 13 oct. 05, à 16:51, Vadim Gritsenko a écrit :
Bertrand Delacretaz wrote:
Le 13 oct. 05, à 10:42, Pier Fumagalli a écrit :
...In the meantime, I'm going to set-up Jira with statuses and
workflows. And after the cleanup is done, we can move all
outstanding issues over...
Shouldn't we
Reinhard Poetz wrote:
--- Daniel Fagerstrom [EMAIL PROTECTED] schrieb:
IMO we need to find two set of interfaces/classes:
the API of Cocoon,
and the set of classes (components) that an
application programmer need
JavaDoc for.
If it ain't public API you ain't need Javadoc for it, period.
hepabolu wrote:
My proposal is: keep the current docs, aka legacydocs in Daisy, as much
backward compatible as possible. This will be all the Cocoon 2.1.X
documentation we have.
Once we start releasing Cocoon 2.2 the 2.1 docs will be frozen, i.e.
the current state of cocoon.apache.org is
Upayavira wrote:
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Same here. I think we should treat those XSLT files more like our
public API with forms users and keep an eye on backward compatibility.
I agree. But the problem is that the switch to Ajax required more ids in
the page to
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37079.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
I'd like to:
1. make ApplesProcessor.instantiateController protected
2. introduce SpringAwareApplesProcessor that would not create an apples
controller like the current one:
private AppleController instantiateController(String className)
throws Exception {
Class clazz =
Hi all,
I just found a very annoying feature of the Prototype library on which
the nice Scriptaculous Ajax stuff is buit. It adds a number of methods
to the Array class to bring more features such as filtering, mapping,
iterating, etc.
Sounds nice at first, but this has the effect of
On 13 Oct 2005, at 17:13, Vadim Gritsenko wrote:
Either way - I think this change should be mentioned both in
changes.xml and Updating Cocoon, Chapter 2.1.7 - 2.1.8 document.
+100
Ajax might be cool and sexy and all that, but now we are forced to
support either 2.1.8 or 2.1.7 in Daisy, and
Leszek Gawron wrote:
I'd like to:
1. make ApplesProcessor.instantiateController protected
I never used Apples, but it looks like some people (and not only their
original creators) are using it.
If it's to become one of the official flow implementation, what about
changing its name?
On Oct 13, 2005, at 8:42 AM, Sylvain Wallez wrote:
I never used Apples, but it looks like some people (and not only their
original creators) are using it.
I never really did get Apples. Can somebody just sort of give a
quick summary of what it's all about, and why I would want to use it?
Sylvain Wallez wrote:
Leszek Gawron wrote:
I'd like to:
1. make ApplesProcessor.instantiateController protected
I never used Apples, but it looks like some people (and not only their
original creators) are using it.
If it's to become one of the official flow implementation, what about
On 13.10.2005, at 17:45, Mark Lundquist wrote:
On Oct 13, 2005, at 8:42 AM, Sylvain Wallez wrote:
I never used Apples, but it looks like some people (and not only
their original creators) are using it.
I never really did get Apples. Can somebody just sort of give a
quick summary of
Vadim Gritsenko wrote:
Upayavira wrote:
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Same here. I think we should treat those XSLT files more like our
public API with forms users and keep an eye on backward compatibility.
I agree. But the problem is that the switch to Ajax required
Mark Lundquist wrote:
On Oct 13, 2005, at 8:42 AM, Sylvain Wallez wrote:
I never used Apples, but it looks like some people (and not only
their original creators) are using it.
I never really did get Apples. Can somebody just sort of give a
quick summary of what it's all about, and why
Mark Lundquist wrote:
On Oct 13, 2005, at 8:42 AM, Sylvain Wallez wrote:
I never used Apples, but it looks like some people (and not only their
original creators) are using it.
I never really did get Apples. Can somebody just sort of give a quick
summary of what it's all about, and why I
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
and Updating Cocoon, Chapter 2.1.7 - 2.1.8 document.
Uh, /me feeling dumb: where is that doc?
It used to be here:
http://cocoon.apache.org/2.1/installing/updating.html
In Daisy, it is
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
--- Daniel Fagerstrom [EMAIL PROTECTED] schrieb:
IMO we need to find two set of interfaces/classes:
the API of Cocoon, and the set of classes (components) that an
application programmer need JavaDoc for.
If it ain't public API you ain't need
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
and Updating Cocoon, Chapter 2.1.7 - 2.1.8 document.
Uh, /me feeling dumb: where is that doc?
It used to be here:
http://cocoon.apache.org/2.1/installing/updating.html
In Daisy, it is
Leszek Gawron wrote:
First time the apple is invoked it is created from scratch. Later on if
continuation is being called the apple object is retrieved from
continuation and apple.process( req, res ) is called again on the same
object. You have to maintain view flow yourself. You do not have
Ralph Goers wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
--- Daniel Fagerstrom [EMAIL PROTECTED] schrieb:
IMO we need to find two set of interfaces/classes:
the API of Cocoon, and the set of classes (components) that an
application programmer need JavaDoc for.
If it ain't public
Leszek Gawron wrote:
I'd like to:
1. make ApplesProcessor.instantiateController protected
2. introduce SpringAwareApplesProcessor that would not create an apples
controller like the current one:
private AppleController instantiateController(String className)
throws Exception {
Class
Torsten Curdt wrote:
The API itself is not very likely to change much - if at all.
What about Invoker? If this class is part of API... It declares two exceptions
which are not thrown in the method:
public Invoker(Method method) throws IllegalAccessException,
InstantiationException {
Vadim Gritsenko wrote:
Ralph Goers wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
--- Daniel Fagerstrom [EMAIL PROTECTED] schrieb:
IMO we need to find two set of interfaces/classes:
the API of Cocoon, and the set of classes (components) that an
application programmer need JavaDoc
Vadim Gritsenko wrote:
Torsten Curdt wrote:
We only need a few more people using it to find the corner cases.
Stable API != Stable Implementation. If API is stable, you should
start vote on marking javaflow stable.
Vadim
I second that. We really need to find a better term than
Gump wrote:
compile-core:
[mkdir] Created dir:
/x1/gump/public/workspace/cocoon/build/cocoon-12102005/classes
[copy] Copying 21 files to
/x1/gump/public/workspace/cocoon/build/cocoon-12102005/classes
[copy] Copied 75 empty directories to 43 empty directories under
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
--- Daniel Fagerstrom [EMAIL PROTECTED] schrieb:
IMO we need to find two set of interfaces/classes:
the API of Cocoon, and the set of classes (components) that an
application programmer need JavaDoc for.
If it ain't public API you ain't need
Daniel Fagerstrom wrote:
Upayavira wrote:
So, I have created a wiki page:
http://wiki.apache.org/cocoon/PublicAPIClasses
Please go there and mark classes public/private as necessary. As it
says at the top of that page, if you disagree with someone, change it
to dispute or D for short. Then
hepabolu wrote:
Ross Gardler wrote:
However, as Vadim said (in another mail in this thread) we have to be
careful not to break current links and search engine indexing. This
can be done by forcing the rewriting of links to mirror the existing
structure, but that assumes the existing
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
--- Daniel Fagerstrom [EMAIL PROTECTED] schrieb:
IMO we need to find two set of interfaces/classes:
the API of Cocoon, and the set of classes (components) that an
application programmer need JavaDoc for.
If it ain't public API you ain't need
Ralph Goers wrote:
Vadim Gritsenko wrote:
Torsten Curdt wrote:
We only need a few more people using it to find the corner cases.
Stable API != Stable Implementation. If API is stable, you should
start vote on marking javaflow stable.
Vadim
I second that. We really need to find a
Reinhard Poetz wrote:
Leszek Gawron wrote:
WDYT? If you don't like it I will do 2). only in my codebase.
I like it. I'm one of the Apples users Sylvain mentioned in his mail.
I've also prototyped nearly the same code as you did :-)
Do you use the spring block or does getSpringContext()
Torsten Curdt wrote:
- it looks like javaflow is still quite unstable
Hey, hey, hey! ;) ...that sounds much worse than it is!
It is still marked unstable - that's true. And compared
to Apples it has a bigger complexity implementation-wise
so of course the risk it might break in certain
Stefano Mazzocchi wrote:
Ralph Goers wrote:
Vadim Gritsenko wrote:
Torsten Curdt wrote:
We only need a few more people using it to find the corner cases.
Stable API != Stable Implementation. If API is stable, you should
start vote on marking javaflow stable.
Vadim
I second
Sylvain Wallez wrote:
Leszek Gawron wrote:
I'd like to:
1. make ApplesProcessor.instantiateController protected
I never used Apples, but it looks like some people (and not only their
original creators) are using it.
If it's to become one of the official flow implementation, what about
Stefano Mazzocchi wrote:
Gump wrote:
[cocoon.javac]
/x1/gump/public/workspace/cocoon/src/java/org/apache/cocoon/components/ChainedConfiguration.java:277:
cannot resolve symbol
[cocoon.javac] symbol : method getValueAsDouble (double)
[cocoon.javac] location: interface
On Thursday 13 October 2005 11:37 am, Sylvain Wallez wrote:
Other possible candidates you are aware of ?
I'm using MochiKit[1], which doesn't do most of nifty little effects that
Scriptaculous but does make JS programing a good bit more sane. Mochi is very
well documented and haven't had any
The API itself is not very likely to change much - if at all.
What about Invoker? If this class is part of API... It declares two
exceptions which are not thrown in the method:
public Invoker(Method method) throws IllegalAccessException,
InstantiationException {
No external API.
(NB I hope that I can soon drop Apples in favor of JavaFlow as
using a state machine is a PITA. The missing part is serialization
support for Javaflow. It is itself already serializeable as
Torsten showed me in Amsterdam, but needs some integration work in
Cocoon to make use of it.)
To
Mozilla uses 'frozen'.
I've always used that term to mean that there can't be any more
code changes - such as just before a release.
Well, there definitely going to be code changes to improve the
JavaInterpreter (stupid name - RT!)
But as a user you won't have to change anything in your
On Thursday 13 October 2005 11:37 am, Sylvain Wallez wrote:
Other possible candidates you are aware of ?
I'm using MochiKit[1], which doesn't do most of nifty little effects that
Scriptaculous but does make JS programing a good bit more sane. Mochi is very
well documented and haven't had any
Vadim Gritsenko wrote:
Stefano Mazzocchi wrote:
Gump wrote:
[cocoon.javac]
/x1/gump/public/workspace/cocoon/src/java/org/apache/cocoon/components/ChainedConfiguration.java:277:
cannot resolve symbol
[cocoon.javac] symbol : method getValueAsDouble (double)
[cocoon.javac] location:
Stefano Mazzocchi wrote:
hepabolu wrote:
Ross Gardler wrote:
However, as Vadim said (in another mail in this thread) we have to be
careful not to break current links and search engine indexing. This
can be done by forcing the rewriting of links to mirror the existing
structure, but that
Stefano Mazzocchi wrote:
Is there a way to have non-numerical URL in daisy?
I've added the original filename to the navigation entry of a document
in the legacydocs navigation. This results in a name as URL, rather than
a number. Daisy still uses the number to retrieve the document from
Vadim Gritsenko wrote:
hepabolu wrote:
My proposal is: keep the current docs, aka legacydocs in Daisy, as
much backward compatible as possible. This will be all the Cocoon
2.1.X documentation we have.
Once we start releasing Cocoon 2.2 the 2.1 docs will be frozen, i.e.
the current state of
Ralph Goers wrote:
Vadim Gritsenko wrote:
Torsten Curdt wrote:
We only need a few more people using it to find the corner cases.
Stable API != Stable Implementation. If API is stable, you should
start vote on marking javaflow stable.
Vadim
I second that. We really need to find a
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37082.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36999.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37082.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37083.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36999.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37083.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37079.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=30104.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
1 - 100 of 131 matches
Mail list logo
