cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject Re: Cocoon is not gump! ( was RE: [VOTE] preservation policy for third-party snapshot sources)
Date Tue, 29 Jun 2004 10:11:31 GMT
Sylvain Wallez dijo:
> Antonio Gallardo wrote:
>>As a Cocoon user I really don't care if the problem is at x line inside a
>>3rd party lib. To me is enough to know that the fuunction f() in the 3rd
>>party lib is not making the right work. How the function f() works it is
>>up to the 3rd party jar developers.

> C'mon Antonio! As a software developper, your goal is to build an
> application that works. And if you depend on that f() function and need
> to release to the customer, you will certainly get your hands dirty in
> the 3rd party code. That's one of the biggest advantages of opensource:
> you can fix it yourself.

Yep. I understand the point. In my own case, what I do is to contact the
right community and tell them where is the problem. I know that this is
more complicated and time consuming, but I think it is the right think to
do if me (as developers) don't want to fix it over and over on every new
release of the 3rd party jar.

As samples, I can mention the jcs.jar and Maven (I know maven is not used
in Cocoon, but it is used in jcs and Cocoon use jcs. So I went a little
more far and made and filled a report patch to add a library in maven).

>>If people really care, we will had fixed all the problems in xalan,
>> xerces
>>and so on. And AFAIK, they have a big bug list now. They use Cocoon (or
>>Xalan, Xerces and expect that the right community fix it). I understand
>>this POV, because there is people with more experience than "this" user
>>that can fix the bug without breaking other parts of the system.
>>Now, the more experienced users (and developers?):
>>They already have a lot of related project in the hard disk. They have
>> the
>>sources on the disk. They care to go into the f() function and discover
>>why it does not work as expected. This kind of users are very few. I can
>>include myself here. I have lot of sources of 3rd party jars in the PC.
>> If
>>I choose to follow the 3rd party jar, I prefer to follow it in the right
>>community and tell them if there is a problem and perhaps how to fix it.
> Who said the contrary? Nobody ever talked about forking 3rd party
> libraries!

I don't talked about forking. My POV is, why to see the code? It is not
enough to know that a 3rd party lib is broken. Contact the right community
and check if there is already a patch for the problem? IMHO it is easier
than debug it yourself. The chances a fix is there is very high.

I often prefer to google for a bug before starting to wet my hands. Maybe
I am very lazy! ;-)

>>Also is important to note that, Cocoon often is ranted because our
>>distribution is bigger than the any J2SDK! And adding java files to 3rd
>>party libs will dramatically increase the size of the distrbution. This
>>will be a really bloat to us.
> Again and again and again: THIS IS ONLY ABOUT SNAPSHOTS OF 3RD PARTY

Yep, but keep in mind that we are not talking about rhino here. We are
talking about more files:

commons-jexl-1.0-beta-1-20040113.jar   -> currently 116 kB
commons-jxpath-20030909.jar            -> 266 kB
jcs-1.0-dev-20040516.jar               -> 318 kB
rhino1.5r4-continuations-20040627.jar  -> before was 500 kB

jakarta-bcel-20040329.jar              -> 510 kB

xreporter-expression-20030725.jar      -> 87kB

html block
jtidy-04aug2000r7-dev.jar              -> 158 kB

chaperon block
chaperon-20040205.jar                  -> 169 kB

Slide block
geronimo-spec-jta-DEV-20040202.jar     -> 10 kB

stx block
joost-20040330.jar                     -> 260 kB

scratchpad block
apache-garbage-0.0.jar                 -> 1 MB (perhaps sources included)
commons-betwixt-20030910.jar           -> 128 kB

JMS block
geronimo-spec-jms-DEV-20031120.jar     -> 26 kB

Portal block
portlet-api-20040310.jar               -> 123 kB
pluto-20040607.jar                     -> 16 kB

And there are other files that I am not sure if they are released or not.

xmldb block:
xmldb-api-20030701.jar                -> 8.8 kB
xmldb-common-20030701.jar             -> 11 kB
xmldb-xupdate-20040205.jar            -> 33 kB

IMHO the list is long and the mantainenment of that have potential problems.
Plus add to our current 41 MB distro the sum(above_jars_size) kB (a fast
eyes looking, it is cca 3. MB).

> So yes, the *cvs update* size may be bigger. But not the official distro.
> Sylvain, getting bored.

Me too.

Best Regards,

Antonio Gallardo

View raw message