Sylvain Wallez dijo: > The current situation is a bit different, but comes from my own > experience of using unreleased Cocoon on some projects. Sure, it's not > the usual case to deploy a non-official version, but being a committer > here, I often add new features to Cocoon because they are needed by the > projects I'm working on. And I can't wait for these changes to be > included in an official version to deliver the project to the customer. > This has the consequence that I must have an easy way to get back the > source in case of problems. And where is the best place to store the > code of opensource software? In the software itself! Hence the > -Dinclude.source-in-jars build flag and the idea to include source of > unreleased 3rd party jars in the jars themselves.
Hi Sylvain: I apreciate that you accepted that you sometimes release in your projects a unreleased cocoon. I think many other people do it and don't accept that. Anyway it is OT. I also understand that you are a more experience developer than me. My all programming experience after ending my studies is just 9 years and you already have 10 years in space industry + others now. But I hope I am not blind and believe that I understand the point of including sources on 3rd party jars or not. My concerns are not related to give the code away or not. My concerns are more related to: 1- Overall performance: unzipping a bigger jar is a more expensive task. 2-Bigger distribution. Already discussed. 3-Add complexity to the Cocoon build system. I thought the solution is OT for Cocoon. It is an application related problem. I am sure all you know this, but I will explain it: The old IDE environments defined 2 build targets for applications tagged as: "develoment" and "production" release. Where, 1-Development release means put inside debug info and other tasks. Here I can include the source code bundling inside the generated jar file. 2-Production releases" means compile with full performance switch and without debug info. Smaller zip files will be loaded faster, etc. We also found to samples: 1-The Stefano extreme sample. Already groovy well explained by Sylvain. As Sylvain explain, he already did this when some of us where playing baseball with folks in some park near home. ;-) In the Pier case, perhaps you will need a decompiler or try to find somewhere the right sources, ask on the right community, etc. I know the task is not easy.... My POV is that having avaliable sources from just few jars don't solve the problem. Imagine how helpful is to debug code just having 20-30% of the all sources (included in jars as was sugested). I agree it will help a little, it could you save some downloading time, but this is not the best solution. This is why I liked more the David solution to insert date to minuts precision. Not enough? For 2 or 3 more bytes on the jar name we get seconds precision. That is a good trade! Saying that, perhaps what we need is something like that old IDE target for development and production, and to do it, we need all the sources of all the jars and make a full rebuild of all jars at once. This is why gump comes first to my mind. This is why I wrote that Cocoon is not gump. I am really sorry if someone missinderstood the phrase. At the end, I need to said that I am not closed minded. As many here, I have a position based in my (perhaps narrowed) mind and experiences. so I please to someone to open this narrowed mind and explain why is a cocoon task to partially save the Best Regards, Antonio Gallardo
