You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Antonio Gallardo <ag...@agssa.net> on 2004/06/29 12:11:31 UTC
Re: Cocoon is not gump! ( was RE: [VOTE] preservation policy for
third-party snapshot sources)
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
Re: Cocoon is not gump! ( was RE: [VOTE] preservation policy for
third-party snapshot sources)
Posted by Ralph Goers <Ra...@dslextreme.com>.
Wow. This just goes on and on.
Actually, I'd be happy if the jar file had a "findme.txt" file that had
the exact location of the CVS/subversion repository and the cvs parameters
that will result in the exact same checkout, whether it is a tag or
timestamp or whatever. And since I can't use CVS through my corporate
firewall I'd need viewcvs to work as well.
Is that too much to expect?
Ralph
Re: Cocoon is not gump! ( was RE: [VOTE] preservation policy for
third-party snapshot sources)
Posted by Sylvain Wallez <sy...@apache.org>.
Antonio Gallardo wrote:
>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.
>
This absolutely not the point of this discussion. The point is to know
how to find the sources for a CVS snapshot. We do not care where the bug
fixes it contains come from. Personally, if I find a bug that is
blocking for my project, I'll try to track it and solve it and send the
relevant community a patch instead of just informing them of the bug.
>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.
>
>
I never, never, never, never talked about forking a 3rd party library,
and this would be the worst thing to do. Find the bug, fix it and send
the patch, and people will thank you and eventually make you a committer.
This is my last reply to this thread.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Cocoon is not gump!
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:
>
>> Sylvain Wallez wrote:
>
>
>
> <snip/>
>
>>> Now it seem not everybody agrees with or understand these concerns.
>>> Those who do will use -Dinclude.source-in-jars when building their
>>> unofficial distros, and will fetch 3rd party sources using the
>>> timestamp included in the library name (can even be automated using a
>>> script).
>>
>>
>>
>> This is a good point: even if we cannot reach consensus on having the
>> code inside the jars, it should be *completely automatic* to have the
>> build process do so and for every library that you choose your
>> application to depend on.
>>
>> In this regard, I would *strongly* suggest *NOT* to put that
>> information in the library name, but in the gump.xml descriptor, so
>> that even gump can use that information in the future (for example,
>> acting as a nightly build system instead of a continous integration one).
>
>
>
> Well, do you deliver gump.xml with your project? No. If we don't include
> the source in jars, we must at least be able to reach them unambiguously
> just from that single jar file. Either through additional manifest files
> stored in it, or - and this is the most simple way - through the
> filename (provided of course that it's kept unchanged).
My point is: in order to allow those who want to generate their cocoon
with all the sources included in the libraries, you need a timestamp/tag
and a CVS repository description for every library.
instead of placing the CVS timestamp in the library name and the CVS
location alongside, place it in the gump descriptor which is a much more
natural place for that metadata to be and much more useful.
> Furthermore, I'm not sure putting this information in gump.xml is
> necessary to perform nightly builds, as each project's build.xml should
> theroretically be able to do that build, either using dependencies
> included in the project itself or by fetching them from a remote
> repository. Reproduceability of the build is also a key aspect of
> software maintainance, and the OSS community has for long understood
> this because of its wide geographical distribution and its lazyness to
> answer FAQs ;-)
gump builds against the very last checkout, it has no (yet) the notion
of a regression to a required tag/timestamp and it's work that is in my
todo list because it will be able to identify blame in broken
dependencies with a lot more precision.
--
Stefano.
Re: Cocoon is not gump!
Posted by Stefano Mazzocchi <st...@apache.org>.
Vadim Gritsenko wrote:
> Ralph Goers wrote:
>
>> Frankly, this is where maven would really help as all these jars would
>> not be included with the Cocoon distribution but be coming from a
>> central repository. It would then be just as easy to put a jar of the
>> source in the repository as the binary jar. This would make the
>> problem just disappear.
>
> Just wondering - who will put sources into the maven repository and who
> will maintain it for 30 years?
Exactly.
Look, there is only one approach to digital preservation: make tons of
copies and put enough metadata and unique identifiers to know what you
have in your hands and what is the copy of what else.
Of course, it does not work after a world-wide nuclear holocaust or the
end of oil resources that creates permanent world-wide blackouts, but at
that point, I think maintaining you cocoon application will not be your
biggest concern anyway.
--
Stefano.
Re: Cocoon is not maven! (was Cocoon is not gump)
Posted by Stefano Mazzocchi <st...@apache.org>.
Ralph Goers wrote:
> I took a look at maven's mailing list. Their approach to this is to have a
> POM (Project Object Model) for each jar. From this a maven goal could be
> used to get the source from the correct CVS directly into your own
> repository. This would, in fact, solve the problem where it should be
> solved. Unfortunately, I can't find any POMs that seem to have the
> information needed to actually make this work.
>
> Interestingly enough, www.ibiblio.org/maven/cocoon only has builds for
> 2.1.3 and 2.1.4 but not 2.1.5 and doesn't have POMs. Anyone know who
> builds this stuff?
>
> As for what is in ibiblio or a Cocoon repository, it only has to contain
> stuff that is currently supported. If I "formally" built something I will
> have a copy of the source in the global repository at my site.
I do agree with one thing, though: it is naive to expect that all
projects will care for proper long-term source availability of all the
artifacts they depend on.
Even if Cocoon does, this is something that we should address at the
foundation level, since it's a much bigger concern.
Hmmm.
--
Stefano.
Cocoon is not maven! (was Cocoon is not gump)
Posted by Ralph Goers <Ra...@dslextreme.com>.
I took a look at maven's mailing list. Their approach to this is to have a
POM (Project Object Model) for each jar. From this a maven goal could be
used to get the source from the correct CVS directly into your own
repository. This would, in fact, solve the problem where it should be
solved. Unfortunately, I can't find any POMs that seem to have the
information needed to actually make this work.
Interestingly enough, www.ibiblio.org/maven/cocoon only has builds for
2.1.3 and 2.1.4 but not 2.1.5 and doesn't have POMs. Anyone know who
builds this stuff?
As for what is in ibiblio or a Cocoon repository, it only has to contain
stuff that is currently supported. If I "formally" built something I will
have a copy of the source in the global repository at my site.
Ralph
Vadim Gritsenko said:
> Ralph Goers wrote:
>
>> What do you mean by maintain?
>
>
> Just compare content of the http://www.ibiblio.org/maven/tomcat/jars/
> with http://archive.apache.org/dist/jakarta/tomcat-4/archive/. Maven has
> single 4.0 release, and single 4.1 release even now. What will it have
> several years from now? Nothing?
>
>
>> As for who will put the source in, it would be whoever puts the binary
>> jar in - they should come in and go out together.
>
>
> So your answer is "nobody" :-)
> If somebody steps forward (like you, for example) and creates a
> repository of software cocoon release depends on, there is at least some
> guarantee that this repository will happen and will be complete. And if
> you just sit and wait when source code will be put in by corresponding
> team, there is no much chance this will happen at all - simply because
> other teams do not have reasons or motivation to do so.
>
> Vadim
Re: Cocoon is not gump!
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Ralph Goers wrote:
> What do you mean by maintain?
Just compare content of the http://www.ibiblio.org/maven/tomcat/jars/
with http://archive.apache.org/dist/jakarta/tomcat-4/archive/. Maven has
single 4.0 release, and single 4.1 release even now. What will it have
several years from now? Nothing?
> As for who will put the source in, it would be whoever puts the binary
> jar in - they should come in and go out together.
So your answer is "nobody" :-)
If somebody steps forward (like you, for example) and creates a
repository of software cocoon release depends on, there is at least some
guarantee that this repository will happen and will be complete. And if
you just sit and wait when source code will be put in by corresponding
team, there is no much chance this will happen at all - simply because
other teams do not have reasons or motivation to do so.
Vadim
> At 7/1/2004 03:59 AM, you wrote:
>
>> Ralph Goers wrote:
>>
>>> Frankly, this is where maven would really help as all these jars
>>> would not be included with the Cocoon distribution but be coming
>>> from a central repository. It would then be just as easy to put a
>>> jar of the source in the repository as the binary jar. This would
>>> make the problem just disappear.
>>
>>
>>
>> Just wondering - who will put sources into the maven repository and
>> who will maintain it for 30 years?
>>
>> Vadim
>
Re: Cocoon is not gump!
Posted by Ralph Goers <Ra...@dslextreme.com>.
What do you mean by maintain?
As for who will put the source in, it would be whoever puts the binary jar
in - they should come in and go out together.
At 7/1/2004 03:59 AM, you wrote:
>Ralph Goers wrote:
>
>>Frankly, this is where maven would really help as all these jars would
>>not be included with the Cocoon distribution but be coming from a central
>>repository. It would then be just as easy to put a jar of the source in
>>the repository as the binary jar. This would make the problem just disappear.
>
>
>Just wondering - who will put sources into the maven repository and who
>will maintain it for 30 years?
>
>Vadim
>
Re: Cocoon is not gump!
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Ralph Goers wrote:
> Frankly, this is where maven would really help as all these jars would
> not be included with the Cocoon distribution but be coming from a
> central repository. It would then be just as easy to put a jar of the
> source in the repository as the binary jar. This would make the
> problem just disappear.
Just wondering - who will put sources into the maven repository and who
will maintain it for 30 years?
Vadim
Re: Cocoon is not gump!
Posted by Ralph Goers <Ra...@dslextreme.com>.
At 6/29/2004 11:11 PM, you wrote:
>Stefano Mazzocchi wrote:
>
>>In this regard, I would *strongly* suggest *NOT* to put that information
>>in the library name, but in the gump.xml descriptor, so that even gump
>>can use that information in the future (for example, acting as a nightly
>>build system instead of a continous integration one).
>
>
>Well, do you deliver gump.xml with your project? No. If we don't include
>the source in jars, we must at least be able to reach them unambiguously
>just from that single jar file. Either through additional manifest files
>stored in it, or - and this is the most simple way - through the filename
>(provided of course that it's kept unchanged).
>
>Furthermore, I'm not sure putting this information in gump.xml is
>necessary to perform nightly builds, as each project's build.xml should
>theroretically be able to do that build, either using dependencies
>included in the project itself or by fetching them from a remote
>repository. Reproduceability of the build is also a key aspect of software
>maintainance, and the OSS community has for long understood this because
>of its wide geographical distribution and its lazyness to answer FAQs ;-)
I haven't looked at what is in gump.xml, but I'm reticent with just going
with a naming standard. While jars.xml does point you to a project's
website, it doesn't point you to the cvs repository. Second, blocks don't
seem to have the equivalent of jars.xml so one is left guessing as to where
to find the project that owns the jar.
Frankly, this is where maven would really help as all these jars would not
be included with the Cocoon distribution but be coming from a central
repository. It would then be just as easy to put a jar of the source in
the repository as the binary jar. This would make the problem just
disappear. Each block's project.xml would just reference the jar and
version. And, of course, this would make Cocoon's distribution much
smaller. I understand the resistance to using maven, but if it is not used
I would suggest that Cocoon needs to reinvent at least this part of it.
Ralph
Re: Cocoon is not gump!
Posted by Sylvain Wallez <sy...@apache.org>.
Stefano Mazzocchi wrote:
> Sylvain Wallez wrote:
<snip/>
>> Now it seem not everybody agrees with or understand these concerns.
>> Those who do will use -Dinclude.source-in-jars when building their
>> unofficial distros, and will fetch 3rd party sources using the
>> timestamp included in the library name (can even be automated using a
>> script).
>
>
> This is a good point: even if we cannot reach consensus on having the
> code inside the jars, it should be *completely automatic* to have the
> build process do so and for every library that you choose your
> application to depend on.
>
> In this regard, I would *strongly* suggest *NOT* to put that
> information in the library name, but in the gump.xml descriptor, so
> that even gump can use that information in the future (for example,
> acting as a nightly build system instead of a continous integration one).
Well, do you deliver gump.xml with your project? No. If we don't include
the source in jars, we must at least be able to reach them unambiguously
just from that single jar file. Either through additional manifest files
stored in it, or - and this is the most simple way - through the
filename (provided of course that it's kept unchanged).
Furthermore, I'm not sure putting this information in gump.xml is
necessary to perform nightly builds, as each project's build.xml should
theroretically be able to do that build, either using dependencies
included in the project itself or by fetching them from a remote
repository. Reproduceability of the build is also a key aspect of
software maintainance, and the OSS community has for long understood
this because of its wide geographical distribution and its lazyness to
answer FAQs ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Cocoon is not gump!
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:
>
>> Antonio Gallardo wrote:
>>
>>> 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! ;-)
>>
>>
>>
>> hmmm, consider this scenario: you are asked to build a system, say,
>> for the government, that has to support the pension system or the IRS.
>>
>> This cocoon application was built out of an official release,
>> everything documented, legally certified, all text written and such.
>>
>> This application runs for 15 years, then, one day, a change in the
>> underlying dependencies (java or whatever) affects it in such a way
>> that it can no longer work.
>>
>> You are hired again to fix it.
>>
>> You find out that this "jurassic" cocoon version depends on
>> technologies that are no longer available, their communities folded,
>> the CVS archived or lost in a disk crash or in OSDN bankrupcy.
>>
>> What do you do?
>
>
>
> I spent 10 years in the space industry, and worked some satellite
> control systems that require maintainance to be possible for 15 years!
> And I actually had to work in 1999 on a software I wrote in 1991 to fix
> some Y2K bugs.
>
> In this kind of situation, there is a very heavy process set up to
> ensure that *all* source code is available, as long as *all* tools and
> operating systems required to build and run the software. Plus a huge
> amount of design and test documents to allow people to dive in years
> after the original development team has disappeared.
>
> 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.
>
> Now it seem not everybody agrees with or understand these concerns.
> Those who do will use -Dinclude.source-in-jars when building their
> unofficial distros, and will fetch 3rd party sources using the timestamp
> included in the library name (can even be automated using a script).
This is a good point: even if we cannot reach consensus on having the
code inside the jars, it should be *completely automatic* to have the
build process do so and for every library that you choose your
application to depend on.
In this regard, I would *strongly* suggest *NOT* to put that information
in the library name, but in the gump.xml descriptor, so that even gump
can use that information in the future (for example, acting as a nightly
build system instead of a continous integration one).
--
Stefano.
Re: Cocoon is not gump!
Posted by Ralph Goers <Ra...@dslextreme.com>.
Steven Noels said:
> On 30 Jun 2004, at 08:47, Sylvain Wallez wrote:
>
>
> CVS sandbox size shouldn't be a concern IMHO - distribution size might
> be for some, and would hopefully get solved once we split Cocoon into a
> kernel project and a federation of Cocoon modules|blocks subprojects.
> Until we are there, we might add an ûber-src-jar build target to the
> build system collecting source dumps of those libraries and wrapping
> those into a cocoon-unreleased-dependent-libs.jar we ship along the
> real distribution.
>
> Since Ralph is very keen on this, maybe he can help to come up with
> some Ant tasks. ;-)
>
> </Steven>
<sigh> We need to move to a different planet with more hours in the day.
Actually, if I was to work on this I'm not sure you'd like what I'd come
up with. It would probably be based on Maven since that is what we use for
our project.
Re: Cocoon is not gump!
Posted by David Crossley <cr...@apache.org>.
Steven Noels wrote:
> Sylvain Wallez wrote:
>
> >> For third-party, unreleased or patched libs, a coherent naming scheme
> >> and archive.apache.org offloading procedure should suffice.
> >
> > A coherent naming scheme is needed, but is archiving in a central
> > location necessary (not talking of the infrastructure problems)? When
> > you decide to deliver a project using a snapshot, that snapshot is
> > generally a recent one (otherwise its changes are likely to be part of
> > an official release) and the CVS repository is therefore still
> > available.
>
> For "snapshot releases" of dependency libraries, I think adding and
> versioning separate src jars of these specific libraries to CVS should
> be enough - and could possibly boil down to a simple jar-up and commit
> of said library's source code by the committer doing the library
> upgrade.
>
> CVS sandbox size shouldn't be a concern IMHO.
Our CVS is already huge. This might frighten away of a lot of
would-be developers. I am lucky because i recently upgraded
from dial-up modem to ADSL. If holding sources in CVS is the
only solution, then so be it.
> - distribution size might
> be for some, and would hopefully get solved once we split Cocoon into a
> kernel project and a federation of Cocoon modules|blocks subprojects.
> Until we are there, we might add an ûber-src-jar build target to the
> build system collecting source dumps of those libraries and wrapping
> those into a cocoon-unreleased-dependent-libs.jar we ship along the
> real distribution.
That is a great idea.
> Since Ralph is very keen on this, maybe he can help to come up with
> some Ant tasks. ;-)
>
> </Steven>
Re: Cocoon is not gump!
Posted by Steven Noels <st...@outerthought.org>.
On 30 Jun 2004, at 08:47, Sylvain Wallez wrote:
>> For third-party, unreleased or patched libs, a coherent naming scheme
>> and archive.apache.org offloading procedure should suffice.
>
>
> A coherent naming scheme is needed, but is archiving in a central
> location necessary (not talking of the infrastructure problems)? When
> you decide to deliver a project using a snapshot, that snapshot is
> generally a recent one (otherwise its changes are likely to be part of
> an official release) and the CVS repository is therefore still
> available.
For "snapshot releases" of dependency libraries, I think adding and
versioning separate src jars of these specific libraries to CVS should
be enough - and could possibly boil down to a simple jar-up and commit
of said library's source code by the committer doing the library
upgrade.
CVS sandbox size shouldn't be a concern IMHO - distribution size might
be for some, and would hopefully get solved once we split Cocoon into a
kernel project and a federation of Cocoon modules|blocks subprojects.
Until we are there, we might add an ûber-src-jar build target to the
build system collecting source dumps of those libraries and wrapping
those into a cocoon-unreleased-dependent-libs.jar we ship along the
real distribution.
Since Ralph is very keen on this, maybe he can help to come up with
some Ant tasks. ;-)
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Cocoon is not gump!
Posted by Sylvain Wallez <sy...@apache.org>.
Steven Noels wrote:
> On 29 Jun 2004, at 23:53, Sylvain Wallez wrote:
>
>> In this kind of situation, there is a very heavy process set up to
>> ensure that *all* source code is available, as long as *all* tools
>> and operating systems required to build and run the software. Plus a
>> huge amount of design and test documents to allow people to dive in
>> years after the original development team has disappeared.
>
>
> One might wonder whether this isn't something where
> consultants/integrators get their money from. If preservation and/or
> fall-back is what your customer expects, would that be something he's
> going to pay for? I'm talking about the preservation aspect here: if
> we provided sources, how long could the Cocoon community be expected
> to keep them? At what cost?
It all depends on the project. For the space software I was talking
about, the customer paid (a lot) for this, including employing people
that keep the knowledge and regularily replay the build procedures. But
this is a very exceptional case as they have to operate the satellite
over our heads during 15 years. I don't think any of the customers of
Cocoon-related projects would ever want to reach that level of
maintainability nor pay for it. So all this is more about protecting our
own asses if some problem ever arises. And we all know that often
problems do arise, even if the application was well tested at first:
unexpected load increase, hardware/OS changes, unusual usage scenarios, etc.
> I tend to understand Ralph's point, but OTOH I think providing the
> build targets to create source jars should be sufficient, and that the
> actual assembly work should be at the third party's deliberation.
+1
> For third-party, unreleased or patched libs, a coherent naming scheme
> and archive.apache.org offloading procedure should suffice.
A coherent naming scheme is needed, but is archiving in a central
location necessary (not talking of the infrastructure problems)? When
you decide to deliver a project using a snapshot, that snapshot is
generally a recent one (otherwise its changes are likely to be part of
an official release) and the CVS repository is therefore still available.
Of course the problem is different if the sources weren't fetched and
archived with the other project sources when it was delivered.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Cocoon is not gump!
Posted by Steven Noels <st...@outerthought.org>.
On 29 Jun 2004, at 23:53, Sylvain Wallez wrote:
> In this kind of situation, there is a very heavy process set up to
> ensure that *all* source code is available, as long as *all* tools and
> operating systems required to build and run the software. Plus a huge
> amount of design and test documents to allow people to dive in years
> after the original development team has disappeared.
One might wonder whether this isn't something where
consultants/integrators get their money from. If preservation and/or
fall-back is what your customer expects, would that be something he's
going to pay for? I'm talking about the preservation aspect here: if we
provided sources, how long could the Cocoon community be expected to
keep them? At what cost?
I tend to understand Ralph's point, but OTOH I think providing the
build targets to create source jars should be sufficient, and that the
actual assembly work should be at the third party's deliberation. For
third-party, unreleased or patched libs, a coherent naming scheme and
archive.apache.org offloading procedure should suffice.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Cocoon is not gump!
Posted by Antonio Gallardo <ag...@agssa.net>.
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
Re: Cocoon is not gump!
Posted by Sylvain Wallez <sy...@apache.org>.
Stefano Mazzocchi wrote:
> Antonio Gallardo wrote:
>
>> 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! ;-)
>
>
> hmmm, consider this scenario: you are asked to build a system, say,
> for the government, that has to support the pension system or the IRS.
>
> This cocoon application was built out of an official release,
> everything documented, legally certified, all text written and such.
>
> This application runs for 15 years, then, one day, a change in the
> underlying dependencies (java or whatever) affects it in such a way
> that it can no longer work.
>
> You are hired again to fix it.
>
> You find out that this "jurassic" cocoon version depends on
> technologies that are no longer available, their communities folded,
> the CVS archived or lost in a disk crash or in OSDN bankrupcy.
>
> What do you do?
I spent 10 years in the space industry, and worked some satellite
control systems that require maintainance to be possible for 15 years!
And I actually had to work in 1999 on a software I wrote in 1991 to fix
some Y2K bugs.
In this kind of situation, there is a very heavy process set up to
ensure that *all* source code is available, as long as *all* tools and
operating systems required to build and run the software. Plus a huge
amount of design and test documents to allow people to dive in years
after the original development team has disappeared.
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.
Now it seem not everybody agrees with or understand these concerns.
Those who do will use -Dinclude.source-in-jars when building their
unofficial distros, and will fetch 3rd party sources using the timestamp
included in the library name (can even be automated using a script).
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Cocoon is not gump!
Posted by Ralph Goers <Ra...@dslextreme.com>.
Thanks, you said this much better and clearer than I could.
Ralph
Stefano Mazzocchi said:
>
> My point is: do *not* make the assumption that the CVS will be there
> when you need it. It won't be. Solid working software has the tendency
> to work for decades before requiring fixes. And people have a tendency
> to change jobs, ideas and interests much faster than working software
> requires fixes.
>
> And information has a notoriously bad habit of getting corrupted, or
> lost and people (including myslelf!) have a notoriously bad habit of
> still considering digital storage capacity as a scarce resource and are
> maniacs of cleaning up and very bad at forecasting the need for
> information that today appears useless.
>
> I guess that working in a library does change your perspectives on those
> things a little bit ;-)
>
> Especially when your boss sings the digital preservation anthem every
> other day ;-) [and for a good reason, I must say!]
>
> --
> Stefano.
>
>
Re: Cocoon is not gump!
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 29 Jun 2004, at 19:46, Stefano Mazzocchi wrote:
>
> A decompiler will be your best friend, not google. Google might give
> you the solution, but without the code how to you change it?
> re-assemblying the bytecode by hand?
>
> Or you might want to kiss Sylvain if the source code was distributed
> along with the binary code ;-)
I found myself in this exact situation last year: the guy who developed
the pre-Cocoon version of VNUNET.COM built the site with a CVS snapshot
of Lucene (of course using features not available in the
previously-released version, and with API changes incompatible with the
next), whatever.
A couple of weeks before he left his PC (where he kept the Lucene
snapshot) died, and I found myself in the position of having to run on
a decompiled version of a JAR to see what he did for MONTHS before I
actually found how to rewrite the whole shabang using a release
version.
Now, this is (of course) my fault (I should have checked before he
left), but having been in the situation of "where the heck are the
sources" already, with a system which runs your live server, well, I'm
telling you it ain't pretty at all...
Pier
Re: Cocoon is not gump!
Posted by Stefano Mazzocchi <st...@apache.org>.
Antonio Gallardo wrote:
> 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! ;-)
hmmm, consider this scenario: you are asked to build a system, say, for
the government, that has to support the pension system or the IRS.
This cocoon application was built out of an official release, everything
documented, legally certified, all text written and such.
This application runs for 15 years, then, one day, a change in the
underlying dependencies (java or whatever) affects it in such a way that
it can no longer work.
You are hired again to fix it.
You find out that this "jurassic" cocoon version depends on technologies
that are no longer available, their communities folded, the CVS archived
or lost in a disk crash or in OSDN bankrupcy.
What do you do?
A decompiler will be your best friend, not google. Google might give you
the solution, but without the code how to you change it? re-assemblying
the bytecode by hand?
Or you might want to kiss Sylvain if the source code was distributed
along with the binary code ;-)
When I say "along" it doesn't mean "inside", even if I completely agree
with Sylvain that having the code inside with the bytecode in the jar
makes the most natural sense.
Carsten is afraid of having to deploy a few more Mb of stuff, I think
the first time he is hit by the above scenario he'll change his mind
rather quickly and a few Mb will not be such a big deal of a price to
pay to sleep well at night.
My point is: do *not* make the assumption that the CVS will be there
when you need it. It won't be. Solid working software has the tendency
to work for decades before requiring fixes. And people have a tendency
to change jobs, ideas and interests much faster than working software
requires fixes.
And information has a notoriously bad habit of getting corrupted, or
lost and people (including myslelf!) have a notoriously bad habit of
still considering digital storage capacity as a scarce resource and are
maniacs of cleaning up and very bad at forecasting the need for
information that today appears useless.
I guess that working in a library does change your perspectives on those
things a little bit ;-)
Especially when your boss sings the digital preservation anthem every
other day ;-) [and for a good reason, I must say!]
--
Stefano.
Re: Cocoon is not gump! ( was RE: [VOTE] preservation policy for
third-party snapshot sources)
Posted by Antonio Gallardo <ag...@agssa.net>.
Nicola Ken Barozzi dijo:
> Antonio Gallardo wrote:
> ...
>> 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
> ...etc
>
> I did not think it was about *these* snapshots too. I thought it was
> about snapshots of stuff that we had modified somehow and the code of
> which was hard to find or build. (see for example excalibur stuff when
> there was confusion about it's future).
Yep. It was:
<quoting>
Some time ago, we discussed the need to keep sources somewhere in Cocoon
for third-party jars produced from CVS snapshots....
</quoting>
Source: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108841157302296&w=2
AFAIK, the term "3rd party" refers to anything outside cocoon. That
includes other Apache projects. The posted list is valid.
Best Regards,
Antonio Gallardo
> If what Antonio has written is the case, consider my vote a -1, as we
> should not be distributing sources of things that can and should be
> easily gotten elsewhere, *especially* is 'elsewhere' is still in Apache.
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
Re: Cocoon is not gump! ( was RE: [VOTE] preservation policy for
third-party snapshot sources)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Antonio Gallardo wrote:
...
> 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
...etc
I did not think it was about *these* snapshots too. I thought it was
about snapshots of stuff that we had modified somehow and the code of
which was hard to find or build. (see for example excalibur stuff when
there was confusion about it's future)
If what Antonio has written is the case, consider my vote a -1, as we
should not be distributing sources of things that can and should be
easily gotten elsewhere, *especially* is 'elsewhere' is still in Apache.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------