Ralph Goers wrote:
Is the cocoon build really trying to rely on transitive dependency
verions? Very bad idea. Versions of every dependency cocoon uses
directly or indirectly should be specified in the managedDependencies.
The problem is that the groupId of the Avalon framework changed and that
Joerg Heinicke wrote:
But how to trace it back when the dependency report does not even
mention it. I wonder if I'm actually the only one with this problem?
It's probably not critical since it seems to occur only with the Eclipse
plugin and fixing the build path is easy. But it might point to a
Joerg Heinicke wrote:
On 25.11.2007 10:32 Uhr, Grzegorz Kossakowski wrote:
I'm quite reluctant to accept this patch because I believe that one
should never rely on block's
directory location
Why? It might be necessary when communicating with other systems. There
is no difference than with WA
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Since I've been running successfully two of my custom Cocoon 2.2 apps
with Spring 2.5-rc2
(http://opensource.atlassian.com/projects/spring/browse/SPR-4081), I
upgraded trunk to use Spring 2.5. Since it is aimed to be a drop-in
replacement for 2.0.x,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joerg Heinicke wrote:
> On 23.11.2007 9:58 Uhr, Giacomo Pati wrote:
>
>>> How can this be null after all? From what I see value can only be null
>>> if value was null in the first place, i.e. before replace(..). This
>>> means that null must already
Is the cocoon build really trying to rely on transitive dependency
verions? Very bad idea. Versions of every dependency cocoon uses
directly or indirectly should be specified in the managedDependencies.
Joerg Heinicke wrote:
Found this thread on the user list which has the same symptoms:
http
On 25.11.2007 23:47 Uhr, Joerg Heinicke wrote:
PS: There is also an error somewhere with the dependencies I think. XSP
block includes Avalon Framework 4.1.3 instead of 4.3.1 which causes
bunch of problems in Eclipse. How to trace the dependencies? Grek sent
once a mail with "mvn project-info-rep
On 22.11.2007 6:04 Uhr, Andreas Hartmann wrote:
I used an action to pass the current source resolver to the
SourceProtocolHandler, but this resulted in an NPE because the URI of
the TranscoderInput object was null. After I applied a little patch to
the SourceProtocolHandler which enabled the f
[
https://issues.apache.org/jira/browse/COCOON-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545326
]
Jörg Heinicke commented on COCOON-2150:
---
Reinhard mentioned the suspicion about the error handler:
http://mar
Error on resetting response
---
Key: COCOON-2150
URL: https://issues.apache.org/jira/browse/COCOON-2150
Project: Cocoon
Issue Type: Bug
Components: - Servlet service framework
Affects Versions: 2.2-dev (
On 25.11.2007 10:32 Uhr, Grzegorz Kossakowski wrote:
I added an issue with a new input module which returns the full file
path location of the base dir/resource of a block.
https://issues.apache.org/jira/browse/COCOON-2145
Can I apply the patch?
Sorry but I've no idea - I'm not clear yet on b
On 23.11.2007 9:58 Uhr, Giacomo Pati wrote:
How can this be null after all? From what I see value can only be null
if value was null in the first place, i.e. before replace(..). This
means that null must already have been in the Properties object which is
kind of impossible since Properties.put(
On 25.11.2007 10:45 Uhr, Grzegorz Kossakowski wrote:
PS: There is also an error somewhere with the dependencies I think. XSP
block includes Avalon Framework 4.1.3 instead of 4.3.1 which causes
bunch of problems in Eclipse. How to trace the dependencies? Grek sent
once a mail with "mvn project-in
[
https://issues.apache.org/jira/browse/COCOON-2148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545272
]
Grzegorz Kossakowski commented on COCOON-2148:
--
Thanks for providing this patch Andreas.
Even though,
Joerg Heinicke pisze:
> PS: There is also an error somewhere with the dependencies I think. XSP
> block includes Avalon Framework 4.1.3 instead of 4.3.1 which causes
> bunch of problems in Eclipse. How to trace the dependencies? Grek sent
> once a mail with "mvn project-info-reports:dependencies" [
Vadim Gritsenko pisze:
> Thorsten Scherler wrote:
>> Hi all,
>>
>> I added an issue with a new input module which returns the full file
>> path location of the base dir/resource of a block.
>>
>> https://issues.apache.org/jira/browse/COCOON-2145
>>
>> Can I apply the patch?
>
> Sorry but I've no i
Joerg Heinicke pisze:
> Just an explanation: A namespace declaration is not an attribute (even
> if it looks so) and that's why it should not end as such. The DOM
> produced by Cocoon is absolutely correct, the one by parsing expected
> document in the test case is not since it has both the namespa
[
https://issues.apache.org/jira/browse/COCOON-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545261
]
Grzegorz Kossakowski commented on COCOON-2149:
--
Ellis, thanks for contributing this patch. I'm waiting
[
https://issues.apache.org/jira/browse/COCOON-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Kossakowski reassigned COCOON-2149:
Assignee: Grzegorz Kossakowski
> Patch to IncludeTransformer to add root-e
Carsten Ziegeler pisze:
> Reinhard Poetz wrote:
> I really like Daniels stuff but why merging it now? Can't we just wait
> after the final release?
+1
Since we want to release 2.2 before Christmas I think it's too late for such
big changes.
--
Grzegorz Kossakowski
Committer and PMC Member of Ap
20 matches
Mail list logo
