cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@dslextreme.com>
Subject Re: JXPathHelper
Date Tue, 25 Dec 2007 01:52:43 GMT
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 many committers didn't 
even remember we had passed this.
2. Personally I think 2.2 should be 3.0, but that is just me. Because of 
that I have no real problem breaking binary compatibility with it and so 
I definitely don't have a problem with what you are proposing there.
3. Welcome to the club. We've all been depressed at one time or another 
over how infrequently we do releases. But the list of issues shouldn't 
end there. For one, your original fix shouldn't have been able to go in 
without causing the build to test. The number of unit tests we have is 
abysmal. We can drastically improve this in 2.2 since maven makes it so 
easy to build and run them, but I don't think it is that hard in 2.1 either.

I kind of find it amusing that you checked in this change 3 months ago 
and no one has noticed until now that the JXPath modules are all broken 
- at least on getting the values of elements anyway. Attributes still work.

In the end I'm probably just going to let this slide unless someone else 
responds and says it will be a problem for them, partly for the reasons 
you cite with regards to JXPathHelper, partly because the existing 
method is a bit odd and partly for other reasons.

I'll add the new method and fix the other classes as part of checking in 
XPathXMLFileModule (ironically, I made a new class because this version 
is not quite compatible with XMLFileModule).

Ralph

Grzegorz Kossakowski wrote:
> 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. JXPathHelper, even if not marked explicitly, should be considered as rather internal
class. It
> has absolutely no Javadocs and does not look as a standard API.
> 2. Current behavior of getAttribute() method does not fulfill any API's needs as there
are no
> documentation on how it is supposed to work. What's more current behavior is completely
different
> from what one could expect taking javax.servlet.http.HttpServletRequest.getAttribute()
as an example
> of similar functionality.
> 3. We are really bad on releasing and desperately bad on making minor releases. It was
clearly shown
> by Antonio: http://article.gmane.org/gmane.text.xml.cocoon.devel/76241
>
> I'm not sure if it's just me not being in good condition overall but when I read this
list compiled
> by Antonio and realize how long it takes to make a patch release I become really depressed.
Don't
> you think that waiting about three to four years to remove (first deprecate) some old
code is too long?
>
> [1] http://marc.info/?l=xml-cocoon-dev&m=108266407019215&w=2
>
>   

Mime
View raw message