Re: Binaries in CVS

on 4/13/01 8:49 AM, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote: > I updated the bio information before the conference (DAT was my employer > prior to Sun). They must be using a VB app or something -- the update > never got committed :-). > > I'll try again. No, they probably use JSP. :-)

Re: Binaries in CVS

on 4/12/01 6:45 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote: > PHP 3.0 was essentially a rewrite with a high focus on > backwards compatbility. Not true. I was there during that time. The conversion was a mess. Also from php/fi (ie: 1.0) -> 2.0 was a mess to convert. So was 2.0->3.0. They are als

Re: Binaries in CVS

On Fri, 13 Apr 2001, Ceki [iso-8859-1] Gülcü wrote: > > > >* How are you measuring "activity"? I would guess from your statement > > that you are talking about developers doing commits -- but what about > > they users who just want to USE your project in their own work and could > > give a

Re: Binaries in CVS

On Fri, 13 Apr 2001, Geir Magnusson Jr. wrote: > Sam Ruby wrote: > > > > Peter Donald wrote: > > > > > > The fact of the matter is you would contribute to it even if you had to > > > pass the 12 heculean tests of power, jump tall buildings at lunch and > > beat > > > deep blue on your breaks .

Re: Binaries in CVS

Ceki Gülcü wrote: > > It is becoming increasingly clear to me that the inclusion > of binaries in a CVS is a minor or even a negligible point. > It begets heated debate but does not matter that much at > the end of the day. What matters is the quality of the code, > stability of the API and portab

Re: Binaries in CVS

At 18:44 12.04.2001 -0700, Craig R. McClanahan wrote: >On Fri, 13 Apr 2001, Peter Donald wrote: > >> At 08:16 12/4/01 -0400, Sam Ruby wrote: >> >If you accept that you are in a world where interfaces that you are >> >depending on change frequently, then the problem to solve is optimizing the >> >

Re: Binaries in CVS

Geir Magnusson Jr. wrote: > > > > why ? It's your job. > > > > For the record, it is Craig's job because he did all the things you said, > > not the other way around. > > > > http://conferences.oreilly.com/java/sessions/bios.html > > Hey - Craig's picture :) > > And they list him as doing bizdev f

RE: Binaries in CVS

Binaries in CVS isn't the problem, per se. Although they do tend to be large and CVS doesn't do binary diffs and patches. There are three flavours of binaries (jars) to worry about: External, Jakarta, and Project. External jars are things like jaxp, jmx, xerces and so on. They are outside Jakart

Re: Binaries in CVS

Sam Ruby wrote: > > Peter Donald wrote: > > > > The fact of the matter is you would contribute to it even if you had to > > pass the 12 heculean tests of power, jump tall buildings at lunch and > beat > > deep blue on your breaks ... why ? It's your job. > > For the record, it is Craig's job bec

Re: Binaries in CVS

Jason van Zyl wrote: > > > Gump doesn't solve these problems. Peter Donald has outsmarted it. Jason > > van Zyl ignores it. > > The Jetspeeders don't care about developing against the HEAD of > Turbine because we do change so much (I know we change a lot and I > know it's a big problem), +1 Ad

Re: Binaries in CVS

Sam Ruby wrote: > A final note. At http://jakarta.apache.org/velocity/ymtd/ymtd.html you > will find a comparison between Turbine/Velocity and Struts/JSP. I pretty > much agree with everything said there. But I'll place my bets on > Struts/JSP. Not because of some presumedly massive Sun marke

Re: Binaries in CVS

Peter Donald wrote: > > The fact of the matter is you would contribute to it even if you had to > pass the 12 heculean tests of power, jump tall buildings at lunch and beat > deep blue on your breaks ... why ? It's your job. For the record, it is Craig's job because he did all the things you said

Re: Binaries in CVS

At 09:45 12/4/01 -0400, Sam Ruby wrote: >Peter Donald wrote: >> >> Welcome to opensource! Standards are not done here - we can implement >them >> but we don't build them - for those please go elsewhere >> (IETF/W3C/JCP/Other). One of the advantages of opensource is people are >> free to adapt the

Re: Binaries in CVS

At 06:44 12/4/01 -0700, Craig R. McClanahan wrote: >> >Gump doesn't solve these problems. Peter Donald has outsmarted it. >> >> I haven't outsmarted it. I solved the problem that was presented. You have >> failed to pose any other problem that would make me adjust my position - I >> want low

Re: Binaries in CVS

Sam Ruby wrote: > Jon Stevens wrote: > >> Define "code". >> >> [daedalus] 11:33am ~ > cd /www/jakarta.apache.org/cjan/ >> [daedalus] 11:33am cjan > dir >> total 5 >> drwxrwxr-x 3 jon jakarta 512 Nov 27 20:16 . >> drwxrwxr-x 35 root jakarta 1024 Apr 2 21:20 .. >> -rw-rw-r-- 1 jon j

Re: Binaries in CVS

Sam Ruby wrote: [snip] > Gump doesn't solve these problems. Peter Donald has outsmarted it. Jason > van Zyl ignores it. I have not made the message go away, that is true. But I'm not simply going to apply a patch just to make GUMP stop complaining, that's not going to solve the real problem.

Re: Binaries in CVS

Peter Donald wrote: > > Welcome to opensource! Standards are not done here - we can implement them > but we don't build them - for those please go elsewhere > (IETF/W3C/JCP/Other). One of the advantages of opensource is people are > free to adapt them to their own environments. Hence they do. If y

Re: Binaries in CVS

On Fri, 13 Apr 2001, Peter Donald wrote: > At 08:16 12/4/01 -0400, Sam Ruby wrote: > >If you accept that you are in a world where interfaces that you are > >depending on change frequently, then the problem to solve is optimizing the > >communication paths. > > > >I don't accept that reality. > >

Re: Binaries in CVS

Ceki Gülcü wrote: > > I am not sure if all code written for Tomcat 3.x will compile or > work under 4.0. All is a mightly high target. But I'd wager that you would be pleasantly surprised by the percentage. > The versioning issue that you raise is much more fundamental and > somewhat orthogonal

Re: Binaries in CVS

Peter Donald wrote: > At 04:35 12/4/01 -0700, Nael Mohammad wrote: > >> Can you elaborate on CJAN? > > > It was an idea originally brought up by Jon to implement a system similar > to CPAN but for java not perl. So you would basically have a global > repository where you could download binary

Re: Binaries in CVS

At 08:16 12/4/01 -0400, Sam Ruby wrote: >If you accept that you are in a world where interfaces that you are >depending on change frequently, then the problem to solve is optimizing the >communication paths. > >I don't accept that reality. > >I bet that 98% of the servlets out there would compile

Re: Binaries in CVS

At 20:16 12.04.2001 -0400, Sam Ruby wrote: >I think you are looking at the symptoms, not the root problem. We are thinking about the same issue from different angles. See below. >If you accept that you are in a world where interfaces that you are >depending on change frequently, then the problem

Re: Binaries in CVS

Ceki Gülcü wrote: > > Sam objects to early binding. In other words to packages > assuming a certain version of a dependency project where > different versions of the dependency package behave > differently. Is that correct? > > I fail to see how this is *directly* related to putting > binary files

RE: Binaries in CVS

Hi, At 04:35 12/4/01 -0700, Nael Mohammad wrote: >Can you elaborate on CJAN? It was an idea originally brought up by Jon to implement a system similar to CPAN but for java not perl. So you would basically have a global repository where you could download binary snapshots (ie .jar/.war/.ear file

Re: Binaries in CVS

Ceki Gülcü wrote: > > Hello, > > I suppose this horse was thoroughly beaten to death but I still would like to hear >about the pros and cons of including binary files in CVS. I love this horse... > > The advantages are: > > - By including required jar files for an application, the installat

RE: Binaries in CVS

Can you elaborate on CJAN? -Original Message- From: Peter Donald [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 12, 2001 4:21 PM To: [EMAIL PROTECTED] Subject: Re: Binaries in CVS Binaries in CVS suck, not having binaries in CVS sucks more. Instead of complaining about them why don&#

Re: Binaries in CVS

Binaries in CVS suck, not having binaries in CVS sucks more. Instead of complaining about them why don't implement CJAN - much more effective than pissing in the wind. After that it will be bai bai binaries. Cheers, Pete *-* | "Faced with the

Re: Binaries in CVS

At 12:57 13/4/01 +0200, Ceki Gülcü wrote: >>Gump does that by overriding properties (same as a build.properties file >>does in the proposed approach). > >Build.properties in the proposed approach? Doesn't compute. the library project uses build.properties where the rest of the world uses .ant.p

Re: Binaries in CVS

At 15:04 12.04.2001 -0700, Craig R. McClanahan wrote: >On Thu, 12 Apr 2001, Ceki [iso-8859-1] Gülcü wrote: > >> At 12:55 12.04.2001 -0700, Craig R. McClanahan wrote: >> >> [removed text] >> >> >> Why do you think that it is wrong to have binaries in CVS? >> >> >> > >> >All the disadvantages yo

Re: Binaries in CVS

On Thu, 12 Apr 2001, Ceki [iso-8859-1] Gülcü wrote: > At 12:55 12.04.2001 -0700, Craig R. McClanahan wrote: > > [removed text] > > >> Why do you think that it is wrong to have binaries in CVS? > >> > > > >All the disadvantages you listed. > > > >All the disadvantages Sam listed. > > Sam obje

Re: Binaries in CVS

At 12:55 12.04.2001 -0700, Craig R. McClanahan wrote: [removed text] >> Why do you think that it is wrong to have binaries in CVS? >> > >All the disadvantages you listed. > >All the disadvantages Sam listed. Sam objects to early binding. In other words to packages assuming a certain version o

Re: Binaries in CVS

--- Sam Ruby <[EMAIL PROTECTED]> wrote: > Costin Manolache wrote: > > > > One compromise may be to use a separate CVS only > for binaries, with the > > latest "released" version of each product. > > > > Users will have to check out the project cvs and > the common binaries CVS. > > > > Benefits o

Re: Binaries in CVS

On Thu, 12 Apr 2001, Ceki [iso-8859-1] Gülcü wrote: > > Hi Craig, > > At 11:25 12.04.2001 -0700, Craig R. McClanahan wrote: > >Whether or not there is a nice, easy, "all in one" download with > >everything you need has absolutely nothing to do with whether binaries are > >checked into CVS. >

Re: Binaries in CVS

Morgan Delagrange wrote: > > A common binary repository sounds like the way to go. > There's no strict need for everbody to buy into it > though. If, for some reason, a new release of a JAR > breaks a particular subproject, that subproject can > always check in the required version of a binary >

RE: Binaries in CVS

Nael Mohammad wrote: > > Community is king I guess my definition of community isn't "every subproject out for itself". Hmmm. What was a fun conversation stands a definite possibility of turning unfun. Perhaps I should go back to work. - Sam Ruby -

RE: Binaries in CVS

Community is king -Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 12, 2001 12:16 PM To: [EMAIL PROTECTED] Subject: Re: Binaries in CVS on 4/12/01 12:00 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote: > I stand corrected. A 1.5K fi

Re: Binaries in CVS

on 4/12/01 12:00 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote: > I stand corrected. A 1.5K file that is not even well-formed XML and an > empty directory. Created and abandoned last year. > > My appologies. At this rate, perhaps my grandkids will be able to use > CJAN. > > - Sam Ruby > > P.S.

Re: Binaries in CVS

On Thu, 12 Apr 2001, Sam Ruby wrote: > Costin Manolache wrote: > > > > One compromise may be to use a separate CVS only for binaries, with the > > latest "released" version of each product. This is not a solution for all versioning or cvs/binaries problems. Xerces, Xalan, Ant are used and check

Re: Binaries in CVS

Jon Stevens wrote: > > Define "code". > > [daedalus] 11:33am ~ > cd /www/jakarta.apache.org/cjan/ > [daedalus] 11:33am cjan > dir > total 5 > drwxrwxr-x 3 jon jakarta 512 Nov 27 20:16 . > drwxrwxr-x 35 root jakarta 1024 Apr 2 21:20 .. > -rw-rw-r-- 1 jon jakarta 1562 Nov 27 20:16 cja

Re: Binaries in CVS

Hi Craig, At 11:25 12.04.2001 -0700, Craig R. McClanahan wrote: >Whether or not there is a nice, easy, "all in one" download with >everything you need has absolutely nothing to do with whether binaries are >checked into CVS. True. There is an important distinction indeed. Call it conventional t

Re: Binaries in CVS

Jon Stevens wrote: > >> - all projects will be forced to use the latest stable release ( but this >> can be a big benefit ! ) > > -1 By use of CVS tags, we could have a number of different profiles defined. In other words, any jar file that you might want to check into your subproject's cvs, che

Re: Binaries in CVS

Costin Manolache wrote: > > One compromise may be to use a separate CVS only for binaries, with the > latest "released" version of each product. > > Users will have to check out the project cvs and the common binaries CVS. > > Benefits over checking in binaries in all projects: > - only pristine s

Re: Binaries in CVS

on 4/12/01 11:37 AM, "Kief Morris" <[EMAIL PROTECTED]> wrote: > Sam Ruby typed the following on 02:21 PM 4/12/2001 -0400 >> Jon Stevens wrote: >>> >>> Sam doesn't like it? :-) >> >> What Sam doesn't like early binding to specific versions. >> >> The various Avalon projects are excellent exampl

Re: Binaries in CVS

Sam Ruby typed the following on 02:21 PM 4/12/2001 -0400 >Jon Stevens wrote: >> >> Sam doesn't like it? :-) > >What Sam doesn't like early binding to specific versions. > >The various Avalon projects are excellent examples of ones that both (1) >check in cvs binaries and utilize them automatically

Re: Binaries in CVS

on 4/12/01 11:31 AM, "Glenn Nielsen" <[EMAIL PROTECTED]> wrote: > A method will still be needed for using jar's for API's in the build process > which can not be made available via CVS due to licensing issues. Such as > all the Sun API's. I have a picture for that.

Re: Binaries in CVS

on 4/12/01 11:21 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote: > set CLASSPATH=%CLASSPATH%;.\ant-1.2.jar;.\ant-1.2-optional.jar > set CLASSPATH=%CLASSPATH%;..\lib\xerces-1.3.0.jar > set CLASSPATH=%CLASSPATH%;..\lib\velocity-1.0b2-dev.jar > set CLASSPATH=%CLASSPATH%;..\..\jakarta-site2\lib\jdom-b6.jar

Re: Binaries in CVS

A method will still be needed for using jar's for API's in the build process which can not be made available via CVS due to licensing issues. Such as all the Sun API's. We will still need a global lib directory outside of CVS where these can be installed and made available for the build proces

Re: Binaries in CVS

on 4/12/01 10:25 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > One issue may be that each project will include ant, xerces, xalan, etc, > with the same or slightly different version. That doesn't really matter and is the projects decision, right? > One compromise may be to use a separ

Re: Binaries in CVS

Whether or not there is a nice, easy, "all in one" download with everything you need has absolutely nothing to do with whether binaries are checked into CVS. I haven't heard anyone dispute the former -- only the latter. Why are you linking the two issues? Craig On Thu, 12 Apr 2001, Ceki [is

Re: Binaries in CVS

Jon Stevens wrote: > > Sam doesn't like it? :-) What Sam doesn't like early binding to specific versions. The various Avalon projects are excellent examples of ones that both (1) check in cvs binaries and utilize them automatically as the defaults, but also (2) make it not only possible but easy

Re: Binaries in CVS

One issue may be that each project will include ant, xerces, xalan, etc, with the same or slightly different version. One compromise may be to use a separate CVS only for binaries, with the latest "released" version of each product. Users will have to check out the project cvs and the common b

Re: Binaries in CVS

on 4/12/01 10:37 AM, "Ceki Gülcü" <[EMAIL PROTECTED]> wrote: > > Hello, > > I suppose this horse was thoroughly beaten to death but I still would like to > hear about the pros and cons of including binary files in CVS. > > The advantages are: > > - By including required jar files for an appli