CPAN was mentioned a number of times in this thread. I would like to relate my very
recent experience with CPAN. See http://www.cpan.org/modules/index.html and in
particular http://www.cpan.org/modules/00modlist.long.html.
I wanted to install a Perl-based tool called dtdnsclient on my linux box. This tool
required the package Term::ReadKey. I had no idea where to get this package from. (I
have not programmed anything substantial in Perl in many years.) So I went to my good
old RH 6.2 CD and tried to find the package there. I did not find it on the CD tough
it must be said I did not look very hard.
Then CPAN came to my mind since I had heard of it here. I typed www.cpan.org browsed
the site for about 22.4 seconds and landed on the modlist page. I just clicked on
Term::ReadKey and a few moments later TermReadKey-2.14.tgz was on my disk. After
reading the INSTALL, I did:
To install, unpack somewhere, type "perl Makefile.PL", and then "make test".
If the compilation and the tests are successful, then change to root and run
"make install".
I tried to run dtdnsclient but now LWP:UserAgent was missing. I repeated downloaded
LWP:UserAgent but it required the URI, MIME-Base64, HTML-Tagset packages. I downloaded
these and did "perl Makefile.PL", and then "make test." I realized that additional
packages were missing, I installed these, and tried to run my script and still some
other package was missing. I installed that, typed "perl Makefile.PL", and then "make
test".
And behold, it worked! After about 15 minutes, decent dose of panic, a completely
clueless and impatient user could install all these packages. I was and still am
deeply impressed.
Let me also add that I could have probably written a limited version of dtdnsclient
myself in less than a day without using any additional tools other then Perl. But I
had better things to do...
To sum it up, a Java version of CPAN would be awesome but it will involve *massive*
amounts of work and it will probably not look like anything useful before at least
year. Just my 2 centimes, Ceki
ps: If CPAN is not a temple glorifying reuse I don't know what is.
At 01:09 09.02.2001 +1100, you wrote:
>At 11:48 8/2/01 +1100, Conor MacNeill wrote:
>>I think this last point is particularly strong in open source projects
>>where a lot of people want to implement things themselves.
>
>I think this is a more significant issue than any other. People like
>hacking at code and unless the candidate code is significantly better or
>there is someother incentive to work with it then it aint going to happen.
>When the code is part of another largish framework then it is almost
>invariably unwise to adopt it unless there is collaborators on both sides
>who want it to happen.
>
>>Anyway, what all this says to me is that if we want strong reuse across
>>Jakarta projects, we need to make reuse easier. We need a way to find code
>>that can be reused. If we are to have a utility project, then it must
>>produce not only the code, but a code catalog which facilitates reuse. I
>>think such a group could range over all the Jakarta projects, looking for
>>code that can be packaged for reuse. I would prefer to see modules with
>>little coupling rather than a framework approach. Building such components
>>can be hard. If we don't want a centralized project to own the code,
>>another idea could be to have a central catalog maintained across the
>>Jakarta projects. The Turbine folks, Struts folks, etc could "advertise"
>>all the modules they provide. There would be implications for how projects
>>package their software.
>
>There is a problem with this view point I suspect. There has already been
>one project with such an aim. The charter of the Avalon project was to
>provide support for things of exactly this nature.
>
>http://java.apache.org/framework/need-for-avalon.html
>http://java.apache.org/framework/call-to-vote.html
>
>While it has accumulated some code - there was only support from 2 other
>projects (namely JAMES and cocoon) - it hasn't become anywhere near what it
>was originally envisioned to be. Instead what you have is rapid duplication
>throughout all the projects ;)
>
>Even worse - if you are watching commits you will have noticed that turbine
>just increased it's charter to include general purpose server utilities (ie
>it now encompases Avalons charter). Ironic that Jons complaining about the
>way Struts aren't sticking to their charter, no ? ;) I don't see this as a
>bad thing - just natural tendency. People want to see their work used by
>greatest audience generally but want the "other" to adopt their framework
>aswell.
>
>Creating a new project to act as a repository for util code could work.
>However things like DB pools that work best when integrated into a
>framework will unlikely to see a lot of reuse (except the copy-paste kind)
>if the framework is not adopted.
>
>The only way to "fix" this is to make each component self-contianed (and
>very bean-esque). This will of course entail a lot of work and will
>actually also increase duplicity. Each bean will duplicate functionality
>present in frameworks because it can not rely on the framework. Hence you
>have not stopped duplication - you just changed it from per-framework to
>per-component.
>
>>The bigger
>>issue is to improve our communications, cataloging, etc so reuse is easier,
>>going forward.
>
>I think there needs to be more infrastructure in place. Sams tinderbox
>stuff with automatic notification and a constant integration build would
>solve this. Combine this with the ability to build finer grain .jars and
>distribute them ala CJAN and it may work but I have my doubts ;)
>
>>This seems to me to be exactly the sort of cross-project issue the PMC is
>>designed to handle. Perhaps the PMC should consider whether to adopt a
>>policy of reuse across Jakarta projects, what that policy might be, whether
>>the policy should be promoted through a library subproject, etc.
>
>It's up to individual projects IMHO. However if a project spurns reuse due
>to the NIH syndrome then they probably shouldn't have been accepted into
>apache in the first place ...
>
>Cheers,
>
>Pete
>
>*-----------------------------------------------------*
>| "Faced with the choice between changing one's mind, |
>| and proving that there is no need to do so - almost |
>| everyone gets busy on the proof." |
>| - John Kenneth Galbraith |
>*-----------------------------------------------------*
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
----
Ceki Gülcü e-mail: [EMAIL PROTECTED] (preferred)
av. de Rumine 5 [EMAIL PROTECTED]
CH-1005 Lausanne
Switzerland Tel: ++41 21 351 23 15
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
