cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agssa.net>
Subject Re: Cocoon is not gump!
Date Wed, 30 Jun 2004 18:33:32 GMT
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

Mime
View raw message