Grzegorz Kossakowski wrote:
1. If you want other projects to use your stuff you need to prepare an
official release. :-)
First we have to discuss, which project does the release? Do we want to pull it
into Cocoon? TBH, I'd rather get rid of Excalibur dependencies that creating
another one.
Grzegorz Kossakowski wrote:
Carsten, I've taken a look at your code and it looks very nice. I have
2. All we need to do in SSF is:
a) implement our own SourceFactoriesManager (by extending your
abstrac class)
No :) Just use SourceFactoriesManager.pushFactories when the request
starts and
Reinhard Poetz wrote:
Grzegorz Kossakowski wrote:
1. If you want other projects to use your stuff you need to prepare an
official release. :-)
First we have to discuss, which project does the release? Do we want to
pull it into Cocoon? TBH, I'd rather get rid of Excalibur dependencies
that
I think I'm wrong, we could also change the dep from jnet to
sourceresolve to use the avalon version as a start.
Carsten
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Grzegorz Kossakowski wrote:
1. If you want other projects to use your stuff you need to prepare
an official release. :-)
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Grzegorz Kossakowski wrote:
1. If you want other projects to use your stuff you need to prepare
an official release. :-)
First we have to discuss, which project does the release? Do we want
to pull it into Cocoon? TBH, I'd rather get rid of
Carsten Ziegeler wrote:
The problematic part is the time frame. I would suggest to just copy the
jnet classes to SSF to be able to release SSF in a short time frame.
Shouldn't we rather create another subproject jnet?
We can then sort out the details after Easter.
Just to be clear: Do you
When I was testing one of my projects with the latest version of trunk, I run
across some obscure behaviour, when I use the exception generator: The problem
is that it only works every second request.
When it fails, following exception is thrown:
Caused by:
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
The problematic part is the time frame. I would suggest to just copy
the jnet classes to SSF to be able to release SSF in a short time frame.
Shouldn't we rather create another subproject jnet?
Yes, in the long run. But to get out SSF asap I would
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Grzegorz Kossakowski wrote:
1. If you want other projects to use your stuff you need to prepare
an official release. :-)
First we have to discuss, which project does the release? Do we want
to pull it into Cocoon? TBH, I'd
Carsten Ziegeler wrote:
Yes, in the long run. But to get out SSF asap I would just copy the
classes. This is internal stuff, so this shouldn't cause problems if
the packages, classes or methods change after the SSF release.
+1
I propose to release 1.0.0 with a copy of jnet inside SSF; after
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
The problematic part is the time frame. I would suggest to just copy
the jnet classes to SSF to be able to release SSF in a short time frame.
Shouldn't we rather create another subproject jnet?
Yes, in the long run. But to
Carsten Ziegeler wrote:
No :) Just use SourceFactoriesManager.pushFactories when the request
starts and popFactories at the end of the request. This can then also
be used for different factories depending on the block that is
currently executed.
So it's like switching the block context.
Yep,
Reinhard Poetz wrote:
When I was testing one of my projects with the latest version of
trunk, I run across some obscure behaviour, when I use the exception
generator: The problem is that it only works every second request.
When it fails, following exception is thrown:
Caused by:
Grzegorz Kossakowski wrote:
Carsten Ziegeler wrote:
Yes, in the long run. But to get out SSF asap I would just copy the
classes. This is internal stuff, so this shouldn't cause problems if
the packages, classes or methods change after the SSF release.
+1
I propose to release 1.0.0 with a copy
Exception generator doesn't work properly
-
Key: COCOON-2179
URL: https://issues.apache.org/jira/browse/COCOON-2179
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects
Grzegorz Kossakowski wrote:
Reinhard Poetz wrote:
When I was testing one of my projects with the latest version of
trunk, I run across some obscure behaviour, when I use the exception
generator: The problem is that it only works every second request.
When it fails, following exception is
Carsten Ziegeler wrote:
Grzegorz Kossakowski wrote:
Therefore I propose:
1. Make a 1.0.0 of SSF as it's now so Cocoon users can consume it and we
will be able to release other artifacts in final version. (Remember: we
can't release Cocoon Core 2.2 final if we don't have final release of
SSF)
Automated build for cocoon-docs FAILED
Log attached.
--
Forrestbot run ended at 19 March 12:38 PM
Using Forrest 0.9-dev
Forrestbot administrator: ForrestBot
--
[echo]
... Forrest render START 2008-03-19 12:12:14
... Rendering docs in
On 18 Mar 2008, at 05:40, Joerg Heinicke wrote:
On 13.03.2008 16:20, Luca Morandini wrote:
This means that Forms must depend on Ajax (Dojo to be more
precise) despite the fact you use Ajax or not.
As Joerg said, we are currently re-working the client-side aspect of
CForms to use Dojo
On Mar 19, 2008, at 5:39 AM, [EMAIL PROTECTED] wrote:
Author: reinhard
Date: Wed Mar 19 02:39:07 2008
New Revision: 638759
URL: http://svn.apache.org/viewvc?rev=638759view=rev
Log:
fix a rather obscure problem with per-pipeline error handlers:
If there is a per-pipeline handler in the last!
[
https://issues.apache.org/jira/browse/COCOON-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580376#action_12580376
]
Vadim Gritsenko commented on COCOON-2178:
-
Harald, this should help you get
On Mar 18, 2008, at 4:11 AM, Thorsten Scherler wrote:
I am not sure whether you are aware of
http://svn.apache.org/viewvc/labs/droids/trunk/
You probably missed it, it was mentioned just few emails up this same
thread -
http://markmail.org/message/53mbfx56ubpx5and
Vadim
[
https://issues.apache.org/jira/browse/COCOON-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Harald Entner updated COCOON-2178:
--
Attachment: Tree.diff
Unique Diff of the Tree class.
It's not packaged, as it is only one
On Mar 18, 2008, at 2:29 PM, Reinhard Poetz wrote:
I've created another series of non-Maven release artifacts. See
http://people.apache.org/~reinhard/cocoon-staging/cocoon-servlet-service/
Jar file name to source/documentation directory name mapping is
inconsistent:
Vadim Gritsenko wrote:
On Mar 18, 2008, at 2:29 PM, Reinhard Poetz wrote:
I've created another series of non-Maven release artifacts. See
http://people.apache.org/~reinhard/cocoon-staging/cocoon-servlet-service/
Jar file name to source/documentation directory name mapping is
inconsistent:
Vadim Gritsenko wrote:
On Mar 19, 2008, at 5:39 AM, [EMAIL PROTECTED] wrote:
Author: reinhard
Date: Wed Mar 19 02:39:07 2008
New Revision: 638759
URL: http://svn.apache.org/viewvc?rev=638759view=rev
Log:
fix a rather obscure problem with per-pipeline error handlers:
If there is a
Issue Subscription
Filter: COCOON-open-with-patch (106 issues)
Subscriber: cocoon
Key Summary
COCOON-2178 Array-based constructors of TreeSelectionEvent used.
https://issues.apache.org/jira/browse/COCOON-2178
COCOON-2177 ImageOp with requested height width both zero should
As a user of sourceresolve independent of Cocoon I would be -1 on moving
it into Cocoon. If it goes anywhere I'd prefer commons.
Carsten Ziegeler wrote:
Now, I think that this will be over time the best solution *if* we can
keep the excalibur package names - but I think that should be
Ralph Goers pisze:
As a user of sourceresolve independent of Cocoon I would be -1 on moving
it into Cocoon. If it goes anywhere I'd prefer commons.
Ralph, I'm not sure if you have followed the whole thread. We don't want to tie JNet code with
Cocoon but only to establish a subproject of
I'm not sure what JNet actually is, but the part I was referring to was
where Carsten was talking about Excalibur being dead and pulling out the
few pieces we use.
Grzegorz Kossakowski wrote:
Ralph Goers pisze:
As a user of sourceresolve independent of Cocoon I would be -1 on
moving it into
Ralph Goers pisze:
I'm not sure what JNet actually is, but the part I was referring to was
where Carsten was talking about Excalibur being dead and pulling out the
few pieces we use.
Maybe it's better that Carsten explains what he meant. Anyway, my understanding is to bring JNet
which is
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Do we really have to include each license into single LICENSE.txt file?
I think I missed this development...
There were so many discussions on several Apache lists that I can't point
you to the thread :-/
Anyway, I was following the
Automated build for cocoon-docs FAILED
Log attached.
--
Forrestbot run ended at 20 March 12:40 AM
Using Forrest 0.9-dev
Forrestbot administrator: ForrestBot
--
[echo]
... Forrest render START 2008-03-20 12:12:14
... Rendering docs in
33 matches
Mail list logo
