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 > LIBRARIES, AND THEREFORE MOSTLY BETWEEN COCOON RELEASES AS WE TRY AS > MUCH AS POSSIBLE TO USE RELEASED VERSIONS OF 3RD PARTY LIBRARIES FOR > OFFICIAL COCOON DISTRIBUTIONS. Yep, but keep in mind that we are not talking about rhino here. We are talking about more files: lib/core: 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 lib/endorsed: jakarta-bcel-20040329.jar -> 510 kB lib/optional 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. Sample: 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
