>From: Stefano Mazzocchi <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: [EMAIL PROTECTED] >CC: Apache Cocoon <[EMAIL PROTECTED]> >Subject: Re: URGENT: 3rd Party jar's in apache CVS need immediate action. >Date: Wed, 30 Jan 2002 11:13:12 +0100 >MIME-Version: 1.0 >Received: from [64.125.133.20] by hotmail.com (3.2) with ESMTP id >MHotMailBE21129B005F40043789407D85140C760; Wed, 30 Jan 2002 02:14:51 -0800 >Received: (qmail 35044 invoked by uid 500); 30 Jan 2002 10:14:33 -0000 >Received: (qmail 35032 invoked from network); 30 Jan 2002 10:14:32 -0000 >From cocoon-dev-return-21878-marc_johnson27591 Wed, 30 Jan 2002 02:16:09 >-0800 >Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm >Precedence: bulk >list-help: <mailto:[EMAIL PROTECTED]> >list-unsubscribe: <mailto:[EMAIL PROTECTED]> >list-post: <mailto:[EMAIL PROTECTED]> >Delivered-To: mailing list [EMAIL PROTECTED] >Message-ID: <[EMAIL PROTECTED]> >X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) >X-Accept-Language: en >References: ><[EMAIL PROTECTED]> >X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > >Dirk-Willem van Gulik wrote: > > > > On Tue, 29 Jan 2002, Guillaume Rousse wrote: > > > > So we now have three proposed ways forward: > > > > > > Option 1.1 > > > > Each project put's their jar's back in - but > > > > according to the guidelines below. > > > > > > > > Option 2.2 > > > > We create a 'xml-third-party' repository for > > > > all the third party jar's. Following the > > > > guide lines below. > > > > > > > > So we keep all 3rd party and alien code in > > > > one place. > > > > > > Option 2.3: > > > Don't import any jar back into the cvs, but fills a > > complete and exact dependency list -) > > > > Opinions ? > >Don't want to appear negative, but I keep remaining -1 until I see a way >to make it easy for developers to download CVS and be ready to go. A >dependency list is a good start, but it's not enough. > >Don't get me wrong, I'm not against this. But the above are words, I >need something that works and jars in CVS (with the license and >description of where they were from attached) work best for me. > >My ideal solution? > >cvs checkout xml-cocoon2 >./prepare.sh >./build.sh dist > >I personally don't care what "prepare.sh" does and I'd be ok in >requiring Ant to be installed on the machine in order for this to work. > >Also, I'd be ok in centralizing the JAR repository and have to pass >*thru* the PMC in order to have jars placed in that repository (could be >a CVS module or anything else, I don't care, as long as prepare.sh can >get to it) > >Ok, let's see, here is how prepare.sh could work: > > 1) post a request with the project name and version number, obtains a >list of jars and their location (depending on IP address, it could even >get a mirrored location) > 2) depending on user parameters (./prepare.sh --get-core-libraries-only >--get-all-libraries etc...) it goes on the net and downloads the >libraries (checking into the repository if they are uptodate) > >[note: the same machinery could power both developers and users... users >will need a better tool though] > >Think apt-get and you get the idea. > >I'm -1 on the centralized repository until we have something similar to >the above and no, I'm not bugged enough but jars in CVS in order to >implement this (even if Forrest+Gump should give us enough >web-publishing capabilitiy to do this very easily) > >Comments? > >Dirk, > >please look into > > xml-cocoon2/legal/ > >where we were placing all the legal information of the entire package (I >urged the same action on the cocoon project a couple of weeks ago and >progress has been slow). > >Would that be a good solution even for the other projects?
I think that would be a good solution for ours (jakarta-poi); we're very likely to need javacc support in our project soon, and their policy on redistribution is, to put it bluntly, a royal pain ... if we had such a script, it would address the need to have that particular tool in hand without going through the hassle of obtaining permission to redistribute the jar. Also, this might alleviate some of the bloating in our distribution (and others). We bundle up all the jars (of course) into our distributions, and it boggles my mind that our files are so big, thanks in no small measure to all the jar files we feel obliged to provide. Making our cvs repositories and our distributions smaller would be of benefit. > >-- >Stefano Mazzocchi One must still have chaos in oneself to be > able to give birth to a dancing star. ><[EMAIL PROTECTED]> Friedrich Nietzsche >-------------------------------------------------------------------- > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] > A stroke of the brush does not guarantee art from the bristles. - Kosh Naranek _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
