My numbering has nothing to do with yours...
1. The versioning manifest described in [1] used to be at
http://cocoon.apache.org/versioning.html. Somewhere along the line that
page was apparently removed. Probably because it wasn't being followed.
There was a followup thread a while later where
Ralph Goers pisze:
> So you have no problem breaking API contracts with end users on minor
> point releases?
To be honest I was thinking about 2.2 mainly. Anyway, I agree with everything
that has been said in
the thread[1] mentioned by you but at the same time I see some subtle details:
1. JXPath
)
Affects version (Component): Parent values: Cocoon Core(10151).
Fix version (Component): Parent values: Cocoon Core(10227).
Added 's'.
Committed 20071224 revision 606745 for 2.1.11.
> CocoonServlet error message names wrong parameter: c
[
https://issues.apache.org/jira/browse/COCOON-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
solprovider closed COCOON-2074.
---
Resolution: Fixed
Fix Version/s: 2.1.11-dev (Current SVN)
Affe
http://marc.info/?l=xml-cocoon-dev&m=108266407019215&w=2
Ralph Goers wrote:
So you have no problem breaking API contracts with end users on minor
point releases?
Grzegorz Kossakowski wrote:
Ralph Goers pisze:
I have verified that the code below gets my new XPathXMLFileModule
working again
So you have no problem breaking API contracts with end users on minor
point releases?
Grzegorz Kossakowski wrote:
Ralph Goers pisze:
I have verified that the code below gets my new XPathXMLFileModule
working again. However, I'm still not sure that is the correct thing to
do as the change es
On Dec 24, 2007, at 9:50 AM, Grzegorz Kossakowski wrote:
Ralph Goers pisze:
I have verified that the code below gets my new XPathXMLFileModule
working again. However, I'm still not sure that is the correct
thing to
do as the change essentially broke the contract. So although I could
make the
Vadim Gritsenko pisze:
> On Dec 23, 2007, at 8:15 PM, Grzegorz Kossakowski wrote:
>
>> So I'm fine with this proposal and I would take one step further. What
>> about deprecating whole
>> org.apache.cocoon.components.notification package? It is used only by
>> NotifyingGenerator.
>
> Not quite :)
Ralph Goers pisze:
> I have verified that the code below gets my new XPathXMLFileModule
> working again. However, I'm still not sure that is the correct thing to
> do as the change essentially broke the contract. So although I could
> make the same change in all the affected Cocoon classes any cust
I have verified that the code below gets my new XPathXMLFileModule
working again. However, I'm still not sure that is the correct thing to
do as the change essentially broke the contract. So although I could
make the same change in all the affected Cocoon classes any customer who
happened to us
As far as I know the old implement wasn't buggy,it just always returned
text. It looks like it could have returned null and the code might not
handle that properly, but that isn't a problem in JXPathHelper. The
proper way to have done this would have been to either have created a
new method -
Ralph Goers pisze:
> I am going to have to revert the change below to JXPathHelper as it has
> broken XMLFileModule. The sample site no longer works correctly.
Hi Ralph.
Are you sure that simple revert is a solution? AFAIR previous behavior of
JXPathHelper.getAttribute() method was buggy too.
--
[
https://issues.apache.org/jira/browse/COCOON-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers reopened COCOON-2108:
-
This patch causes XMLFileModule and anything based on AbstractJXPathModule or
JXPathMetaModule to f
I am going to have to revert the change below to JXPathHelper as it has
broken XMLFileModule. The sample site no longer works correctly.
Subject: svn commit: r575808 -
/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/modules/input/JXPathHelper.java
Date: Fri, 14 Sep 2007 22:40
14 matches
Mail list logo
