Re: Binaries in CVS

[Jon Stevens]

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 application, the installation becomes
> easier as the user does not need to fetch them herself.

At least with regards to installation of the application from CVS. This is
also applicable to development as well. The developer doesn't need to do
this either.

> - Only versions of the binaries known to work with the application are under
> CVS. This also eases installation.

Yup...and development.

> The disadvantages:
> 
> - CVS does not handle binaries very well.

This will eventually become a non-issue as tools like Subversion come into
play because it can do binary diff's.

Also, CVS handles binaries fine, the problem is that it takes up disk space,
which is a non-issue IMHO.

> - Increased checkout overhead as the binary files need to be retrieved from
> the network through the CVS  pserver.

They need to be downloaded anyway. The overhead is the duplication of
binaries.

> - The binary file under CVS control might interact with other binaries that
> the user has. For example, if the user has x.jar on her classpath and x.jar is
> also under CVS. 

That can be controlled with Ant build scripts that override the classpath.
Also, in practice this has been a non-issue now that all the XML xerces
people have their heads on straight.

> Any other advantages disadvantages? How bad is the overhead of manipulating
> binary files with CVS? Thanks for your comments, Ceki

Sam doesn't like it? :-)

The main advantage in my mind is simplicity which far outweighs any
disadvantages. Until there is a system (like my proposed CJAN) that is as
simple to use as checking files out of CVS, then I don't think that we have
any other alternative.

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[cmanolache]

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 binaries CVS.

Benefits over checking in binaries in all projects:
- only pristine sources in all projects ( except the binary tree )
- consistent behavior and location for the binaries for all projects using
the binary tree
- less duplication and space ( and download time )
- Sam may be happy ( as gump could create the binaries instead of checking
out, so it would be as easy to build with the "latest and greatest" )
( it would also be easy for developers to do both types of builds - if the
location of the "binary" tree is configurable )
- a simple way to get the latest stable release for all jars ( a cvs
update will also get only what's changed, instead of requiring to
download and install x different tar.gz files )

Problems:
- user has to checkout 2 trees
- all projects will be forced to use the latest stable release ( but this
can be a big benefit ! )
- you may get more binaries than you need for a project


Costin




On Thu, 12 Apr 2001, 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. 
> 
> The advantages are:
> 
> - By including required jar files for an application, the installation becomes 
>easier as the user does not need to fetch them herself.
> 
> - Only versions of the binaries known to work with the application are under CVS. 
>This also eases installation.
> 
> The disadvantages:
> 
> - CVS does not handle binaries very well. 
> 
> - Increased checkout overhead as the binary files need to be retrieved from the 
>network through the CVS  pserver.
>   
> - The binary file under CVS control might interact with other binaries that the user 
>has. For example, if the user has x.jar on her classpath and x.jar is also under CVS. 
> 
> 
> Any other advantages disadvantages? How bad is the overhead of manipulating binary 
>files with CVS? Thanks for your comments, Ceki
> 
> 
> --
> Ceki Gülcü Web: http://qos.ch 
> email: [EMAIL PROTECTED] or [EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Sam Ruby]

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 to override these defaults via
either a command line parameter or a property.

In contrast, excerpt from build-turbine.bat:

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

> The main advantage in my mind is simplicity which far outweighs any
> disadvantages. Until there is a system (like my proposed CJAN) that is as
> simple to use as checking files out of CVS, then I don't think that we
have
> any other alternative.

CJAN is the ultimate in vapor ware.  "Announced" in an attempt to trample
over an opposing side in an argument, without a single line of code ever
written to support it.  Sounds like tatics from a rather well known
corporation in the US NW if you ask me...

GUMP on the other hand can produce scripts tailored to order which will
download source and build it in the correct orderif anybody wants to
join in on the fun, please subscribe to [EMAIL PROTECTED]

- Sam Ruby

P.S.  In case people are wondering, the answer is "YES, DEFINATELY" to the
obvious question "is the above is only a thinly veiled attempt to goad,
coax, or otherwise encourage people to actually solve the underlying
problem instead of simply sweeping the problem under a rug by checking
binaries into CVS".

P.P.S.  ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Craig R. McClanahan]

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 [iso-8859-1] 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. 
> 
> The advantages are:
> 
> - By including required jar files for an application, the installation becomes 
>easier as the user does not need to fetch them herself.
> 
> - Only versions of the binaries known to work with the application are under CVS. 
>This also eases installation.
> 
> The disadvantages:
> 
> - CVS does not handle binaries very well. 
> 
> - Increased checkout overhead as the binary files need to be retrieved from the 
>network through the CVS  pserver.
>   
> - The binary file under CVS control might interact with other binaries that the user 
>has. For example, if the user has x.jar on her classpath and x.jar is also under CVS. 
> 
> 
> Any other advantages disadvantages? How bad is the overhead of manipulating binary 
>files with CVS? Thanks for your comments, Ceki
> 
> 
> --
> Ceki Gülcü Web: http://qos.ch 
> email: [EMAIL PROTECTED] or [EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Jon Stevens]

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 separate CVS only for binaries, with the
> latest "released" version of each product.

No. 

Say there is a new feature/bugfix in Ant that Turbine *has* to use. Why
limit Turbine development that way?

> Benefits over checking in binaries in all projects:
> - only pristine sources in all projects ( except the binary tree )
> - consistent behavior and location for the binaries for all projects using
> the binary tree
> - less duplication and space ( and download time )
> - Sam may be happy ( as gump could create the binaries instead of checking
> out, so it would be as easy to build with the "latest and greatest" )
> ( it would also be easy for developers to do both types of builds - if the
> location of the "binary" tree is configurable )
> - a simple way to get the latest stable release for all jars ( a cvs
> update will also get only what's changed, instead of requiring to
> download and install x different tar.gz files )
> 
> Problems:
> - user has to checkout 2 trees

I have about ~40 trees checked out. A non-issue for developers IMHO.

> - all projects will be forced to use the latest stable release ( but this
> can be a big benefit ! )

-1

> - you may get more binaries than you need for a project

-1. That isn't helping improve the situation.

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Glenn Nielsen]

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 process.
Even different versions of the same API. If we need to support this for non 
jakarta API's we might as well support it for common/shared jakarta API's.

Regards,

Glenn

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.
> 
> The advantages are:
> 
> - By including required jar files for an application, the installation becomes 
>easier as the user does not need to fetch them herself.
> 
> - Only versions of the binaries known to work with the application are under CVS. 
>This also eases installation.
> 
> The disadvantages:
> 
> - CVS does not handle binaries very well.
> 
> - Increased checkout overhead as the binary files need to be retrieved from the 
>network through the CVS  pserver.
> 
> - The binary file under CVS control might interact with other binaries that the user 
>has. For example, if the user has x.jar on her classpath and x.jar is also under CVS.
> 
> Any other advantages disadvantages? How bad is the overhead of manipulating binary 
>files with CVS? Thanks for your comments, Ceki
> 
> --
> Ceki Gülcü Web: http://qos.ch
> email: [EMAIL PROTECTED] or [EMAIL PROTECTED]
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-- 
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Jon Stevens]

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

No one has complained yet.

> CJAN is the ultimate in vapor ware.  "Announced"

"proposed"

> in an attempt to trample
> over an opposing side in an argument, without a single line of code ever
> written to support it.

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 cjan.xml
drwxrwxr-x   2 jon   jakarta   512 Nov 27 20:16 files

>  Sounds like tatics from a rather well known
> corporation in the US NW if you ask me...

Shit! You outted me! I use my @latchkey.com address because I don't work for
a well known OSS company (CollabNet), I really work for M$!

> P.S.  In case people are wondering, the answer is "YES, DEFINATELY" to the
> obvious question "is the above is only a thinly veiled attempt to goad,
> coax, or otherwise encourage people to actually solve the underlying
> problem instead of simply sweeping the problem under a rug by checking
> binaries into CVS".

All good things in time, right?

> P.P.S.  ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-)

LoL!

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Jon Stevens]

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.



:-)

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Kief Morris]

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 as the defaults, but
>also (2) make it not only possible but easy to override these defaults via
>either a command line parameter or a property.

+1, version specific binding is my main concern about binaries in CVS.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Jon Stevens]

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 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 to override these defaults via
>> either a command line parameter or a property.
> 
> +1, version specific binding is my main concern about binaries in CVS.

That is why we have Gump.

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Sam Ruby]

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 sources in all projects ( except the binary tree )
> - consistent behavior and location for the binaries for all projects
using
> the binary tree
> - less duplication and space ( and download time )
> - a simple way to get the latest stable release for all jars ( a cvs
> update will also get only what's changed, instead of requiring to
> download and install x different tar.gz files )

+1

Perhaps we could even get a change into ant.bat and ant.sh to "
-Djakarta.home=$JAKARTA_HOME".

> - Sam may be happy ( as gump could create the binaries instead of
checking
> out, so it would be as easy to build with the "latest and greatest" )
> ( it would also be easy for developers to do both types of builds - if
the
> location of the "binary" tree is configurable )

Sam already is happy - and those binaries should be built by the release
ownwers by whatever process they deem appropriate.

> Problems:
> - user has to checkout 2 trees

Oh, the humanity!  An extra command!  Whoa is me!  We can't expect our
*DEVELOPERS* to be able to handle this, can we?

;-)

> - all projects will be forced to use the latest stable release ( but this
> can be a big benefit ! )

That's actually a serious concern.  There are projects like Turbine and
Avalon that are in a continual state of flux.  At least now the Avalon
consumers are now marching in lock step, but in general one can not mix and
match just yet.  That's the real problem that we need to solve.

> - you may get more binaries than you need for a project

I'd actually get less.  ;-)

- Sam Ruby


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Sam Ruby]

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, check into this cvs instead.  Tag the sets of binaries
you want with some name starting with the name of your subproject, and
problem solved.

Those that want binaries from CVS can get it.  Those that don't, can build
their own.

- Sam Ruby


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Ceki Gülcü]

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 thinking on my 
part.

Nevertheless, it is quite natural to add binaries into CVS if they are part of the 
distribution. 

So if I understand you correctly, then having binaries (e.g. jar files) in the 
distribution is OK but it less so to put the same binaries into CVS. Do I understand 
you correctly?

Why do you think that it is wrong to have binaries in CVS? 

>I haven't heard anyone dispute the former -- only the latter.  Why are you
>linking the two issues?

Granted, they are separate but related issues. Ceki


--
Ceki Gülcü Web: http://qos.ch 
email: [EMAIL PROTECTED] or [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Sam Ruby]

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 cjan.xml
> drwxrwxr-x   2 jon   jakarta   512 Nov 27 20:16 files

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.  This is much more fun than REAL work.  ;-)  ;-)  ;-) ;-) ;-) ;-)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[cmanolache]

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 checked in almost all projects. If a
project depends on an un-released version of ant - that's fine, it can
check it in as before ( but at least this will raise the "awarness" about
dependencies on specific versions ).

For some projects that are tightly coupled to unreleased versions - this
is clearly not a solution. 

IMHO this should cover XX% of the jar problems with minimal pain. 

( and if we agree it's a good idea - maybe it doesn't even have to be a
CVS - maybe a jakarta-stable-binaries.tar.gz that you have to download and
get the latest ant/xalan/stableFoo will be enough ).

Costin





> > - all projects will be forced to use the latest stable release ( but this
> > can be a big benefit ! )
> 
> That's actually a serious concern.  There are projects like Turbine and
> Avalon that are in a continual state of flux.  At least now the Avalon
> consumers are now marching in lock step, but in general one can not mix and
> match just yet.  That's the real problem that we need to solve.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Jon Stevens]

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.  This is much more fun than REAL work.  ;-)  ;-)  ;-) ;-) ;-) ;-)

Hey, I tried (and failed) to get people interested in working on this.

Obviously checking in binaries into CVS is a good enough solution for
people.

Community rules.

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Binaries in CVS

[Nael Mohammad]

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 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.  This is much more fun than REAL work.  ;-)  ;-)  ;-) ;-) ;-) ;-)

Hey, I tried (and failed) to get people interested in working on this.

Obviously checking in binaries into CVS is a good enough solution for
people.

Community rules.

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Binaries in CVS

[Sam Ruby]

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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Sam Ruby]

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
> locally.  Or ignore the common repository and check
> everything in locally, if they're dead set against the
> idea.  To me, a common repository sounds like a lot
> less work for the individual subproject owners, but
> Jakarta members are nothing if not peculiar.

The way to build a community is to actually build something that people are
interested in contributing to(*).  With this in mind, it would be really
nice is such a repository could be seeded with as many of the following as
is legally permitted:

   ejb-1_1
   j2ee_connector-1_0-pfd2
   jaas1_0
   jaf-1.0.1
   javamail-1.2
   jaxp-1.1
   jdbc2_0
   jms1.0.2
   jmx-1_0
   jndi1_2_1
   jsse1.0.2
   jta-spec1_0_1
   jts1_0

IANAL, but ISTR that it is legal to distribute jaxp but not jsse.  I'm sure
that the rest will need to be looked at on a case by case basis.

> Of course, there are administrative details to
> consider.  I would be very wary of putting anything
> approaching a beta release in the common repository.
> We would need some ground rules to make sure that
> didn't happen.

How about the following rule: non released jars must go on a branch.

- Sam Ruby

(*)  :-P  :-P  :-P


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Craig R. McClanahan]

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.
> 
> True. There is an important distinction indeed. Call it conventional
> thinking on my part.
> 
> Nevertheless, it is quite natural to add binaries into CVS if they are
> part of the distribution.
> 

Quite natural to those who like it, quite unnatural to those who don't :-)

> So if I understand you correctly, then having binaries (e.g. jar
> files) in the distribution is OK but it less so to put the same
> binaries into CVS. Do I understand you correctly?
> 

Yep.  That is why Tomcat binary distributions have everything you need to
run Tomcat (except a JDK and the JSSE classes if you're using SSL).

> Why do you think that it is wrong to have binaries in CVS? 
> 

All the disadvantages you listed.

All the disadvantages Sam listed.

The irrationality (IMHO) of checking generated artifacts into a source
repository (same goes for HTML that's generated from XML in some projects,
but we won't go there right now ;-)

The fact that, once in a while, you have to do maintenance on a dialup
connection instead of a nice fast DSL line.  Case in point -- I had to
update jakarta-site2 while at O'Reilly Enterprise Java over a modem
connection, just after all the checked-in JAR files were updated to recent
versions.  It took 45 f*cking minutes to do the CVS update.  Suffice it to
say that the web site can go hang the next time I'm in that position.

> >I haven't heard anyone dispute the former -- only the latter.  Why are you
> >linking the two issues?
> 
> Granted, they are separate but related issues. Ceki
> 

Craig


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Ceki Gülcü]

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 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 in CVS. Gump 
works regardless of what people put in their CVS modules. Right?

>The irrationality (IMHO) of checking generated artifacts into a source
>repository (same goes for HTML that's generated from XML in some projects,
>but we won't go there right now ;-)

:-) That is a different issue.

>The fact that, once in a while, you have to do maintenance on a dialup
>connection instead of a nice fast DSL line.  Case in point -- I had to
>update jakarta-site2 while at O'Reilly Enterprise Java over a modem
>connection, just after all the checked-in JAR files were updated to recent
>versions.  It took 45 f*cking minutes to do the CVS update.  Suffice it to
>say that the web site can go hang the next time I'm in that position.

I certainly empathize with that. One question that needs to be asked is whether 
placing the updated binaries in CVS is the culprit.

I just compared downloading ant.jar (295'948 bytes) using CVS update, scp and http. 
The results were roughly the same. A 512Kbit/sec link was used to perform the tests. 
Results may vary depending on server load. 

Assuming performance scales up or down linearly with bandwidth, then the logical 
conclusion is that the problem lies with the automatic and recursive updating done by 
"cvs update" and not the cvs/ssh channel per se.

Probably, what you really wanted was to update the files under xdocs/ but not the jar 
files under lib/.

So the automatic update done by CVS eases the distribution of binaries but also 
increases the communication/networking overhead. The overhead is particularly 
irritating if the changes in the binary are minor. 

In other words, putting binary files under CVS decreases the need for developer to 
developer  communication but increases computer to computer communication. Cheers, 
Ceki 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Craig R. McClanahan]

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 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
> in CVS. Gump works regardless of what people put in their CVS modules.
> Right?
> 

Gump does that by overriding properties (same as a build.properties file
does in the proposed approach).  Given that you can make it work without
JARs in CVS, let's turn the question around - what does it buy you to have
them there?

Yes, it's nice to newbies to have the defaults set up to minimize the
effort of trying things.  But that can be accomplished in other ways,
without the disadvantages.

> >The irrationality (IMHO) of checking generated artifacts into a source
> >repository (same goes for HTML that's generated from XML in some projects,
> >but we won't go there right now ;-)
> 
> :-) That is a different issue.
> 
> >The fact that, once in a while, you have to do maintenance on a dialup
> >connection instead of a nice fast DSL line.  Case in point -- I had to
> >update jakarta-site2 while at O'Reilly Enterprise Java over a modem
> >connection, just after all the checked-in JAR files were updated to recent
> >versions.  It took 45 f*cking minutes to do the CVS update.  Suffice it to
> >say that the web site can go hang the next time I'm in that position.
> 
> I certainly empathize with that. One question that needs to be asked
> is whether placing the updated binaries in CVS is the culprit.
> 

The "jakarta-site2" repository has the following JARs checked in:
  Ant 1.3 (296k)
  Jdom "b6" (78k)
  Velocity 1.0 (370k)
  Xerces 1.3 (1605k)

All four had been updated.

> I just compared downloading ant.jar (295'948 bytes) using CVS update,
> scp and http. The results were roughly the same. A 512Kbit/sec link
> was used to perform the tests. Results may vary depending on server
> load.
> 
> Assuming performance scales up or down linearly with bandwidth, then
> the logical conclusion is that the problem lies with the automatic and
> recursive updating done by "cvs update" and not the cvs/ssh channel
> per se.
> 
> Probably, what you really wanted was to update the files under xdocs/
> but not the jar files under lib/.
> 

I could certainly do that, but what if someone updated a doc and needs one
of the new features?  Doing this (re)creates a version incompatibility,
which would defeat the whole point of having the JARs in CVS in the first
place.

> So the automatic update done by CVS eases the distribution of binaries
> but also increases the communication/networking overhead. The overhead
> is particularly irritating if the changes in the binary are minor.
> 
> In other words, putting binary files under CVS decreases the need for
> developer to developer communication but increases computer to
> computer communication. Cheers, Ceki
> 

Craig


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Ceki Gülcü]

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 you listed.
>> >
>> >All the disadvantages Sam listed.
>> 
>> 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
>> in CVS. Gump works regardless of what people put in their CVS modules.
>> Right?
>> 
>
>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.

> Given that you can make it work without
>JARs in CVS, let's turn the question around - what does it buy you to have
>them there?
>
>Yes, it's nice to newbies to have the defaults set up to minimize the
>effort of trying things.  But that can be accomplished in other ways,
>without the disadvantages.

You are suggesting that users download the necessary dependencies using a mechanism 
other than CVS. Right? While that is certainly reasonable it is not clear if any 
fundamental issues are solved by this  approach.   

>> >The irrationality (IMHO) of checking generated artifacts into a source
>> >repository (same goes for HTML that's generated from XML in some projects,
>> >but we won't go there right now ;-)
>> 
>> :-) That is a different issue.
>> 
>> >The fact that, once in a while, you have to do maintenance on a dialup
>> >connection instead of a nice fast DSL line.  Case in point -- I had to
>> >update jakarta-site2 while at O'Reilly Enterprise Java over a modem
>> >connection, just after all the checked-in JAR files were updated to recent
>> >versions.  It took 45 f*cking minutes to do the CVS update.  Suffice it to
>> >say that the web site can go hang the next time I'm in that position.
>> 
>> I certainly empathize with that. One question that needs to be asked
>> is whether placing the updated binaries in CVS is the culprit.
>> 
>
>The "jakarta-site2" repository has the following JARs checked in:
>  Ant 1.3 (296k)
>  Jdom "b6" (78k)
>  Velocity 1.0 (370k)
>  Xerces 1.3 (1605k)
>
>All four had been updated.
>
>> I just compared downloading ant.jar (295'948 bytes) using CVS update,
>> scp and http. The results were roughly the same. A 512Kbit/sec link
>> was used to perform the tests. Results may vary depending on server
>> load.
>> 
>> Assuming performance scales up or down linearly with bandwidth, then
>> the logical conclusion is that the problem lies with the automatic and
>> recursive updating done by "cvs update" and not the cvs/ssh channel
>> per se.
>> 
>> Probably, what you really wanted was to update the files under xdocs/
>> but not the jar files under lib/.
>> 
>
>I could certainly do that, but what if someone updated a doc and needs one
>of the new features?  Doing this (re)creates a version incompatibility,
>which would defeat the whole point of having the JARs in CVS in the first
>place.

Exactly. The problem is not with CVS or any other distribution mechanism. Or? The 
binaries changed and needed to be updated one way or another. CVS is one relatively 
convenient way to do that. Did you have a more efficient approach in mind? 

My current goal is to understand why some developers consider CVSed binaries as being 
evil personified. With all due respect, I have yet to see a convincing argument to the 
inherent evil in CVSed binaries. On the other hand, the advantages of CVSed binaries 
are not that decisive either. Live and let live, et cetera, etc.

This is beginning to feel like "un coup d'epée dans l'eau" or striking water with a 
sword. Regards, Ceki

 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Peter Donald]

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.properties to hold user specific, workspace specific and project
specific settings. In these settings you can locate position of specific jars.

>> Given that you can make it work without
>>JARs in CVS, let's turn the question around - what does it buy you to have
>>them there?
>>
>>Yes, it's nice to newbies to have the defaults set up to minimize the
>>effort of trying things.  But that can be accomplished in other ways,
>>without the disadvantages.
>
>You are suggesting that users download the necessary dependencies using a
mechanism other than CVS. Right? While that is certainly reasonable it is
not clear if any fundamental issues are solved by this  approach.   

The people who advocate binaries in CVS do so for ease of use. If CJAN were
in place now it would be just as easy to use that rather than binaries in
CVS. Hence no need for the binaries.


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]

Re: Binaries in CVS

[Peter Donald]

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 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]

RE: Binaries in CVS

[Nael Mohammad]

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't implement CJAN - much more effective than
pissing in the wind. After that it will be bai bai binaries.
 
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]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Geir Magnusson Jr.]

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 installation becomes 
>easier as the user does not need to fetch them herself.
> 

Definitely.  It also becomes predicatble, as you can't be sure what jar
the user will find or have.

> - Only versions of the binaries known to work with the application are under CVS. 
>This also eases installation.

Yes.
 
> The disadvantages:
> 
> - CVS does not handle binaries very well.

Maybe not, but I think the real issue isn't the storage technology, but
the idea of including them.  For example, just including 'pointers' into
a central jakarta (or Jakarta Commons) managed repository of jars skirts
the technical debate about CVS and binaries and gets you what you want -
the question is how those 'pointers' would work.


> - Increased checkout overhead as the binary files need to be retrieved from the 
>network through the CVS  pserver.

Again, a separate repository would solve it, and an intelligent fetch
would also take care of it - for example, Ant would figure out if a jar
is needed, and go fetch and 'install' in the build for the user, to be
there forever after, until the 'pointer' for that resource is upgraded -
then Ant goes and fetches again.
 
> - The binary file under CVS control might interact with other binaries that the user 
>has. For example, if the user has x.jar on her classpath and x.jar is also under CVS.
> 

The classpath is evil - I think this can be managed through build
scripts or ant just controlling the classpath, right?

> Any other advantages disadvantages? How bad is the overhead of manipulating binary 
>files with CVS? Thanks for your comments, Ceki

I am really interested in this subject - it something we have been
talking a bit (ok, a lot) about for a while on the commons list.  It's
an interesting situation in commons, as it could be viewed as a
mini-jakarta : we have multiple components, all which need to build in
their own way, but will certainly share some commonality such as Ant and
JUnit, and possibly Velocity/Anakia for doc generation.

I think that it's an important thing for a newcomer to be able to just
grab a build or snapshot and be able to build the software, or at least
get something started via Ant - at least let the build tell you what you
need and where to get it.   Ease of use is important here.

I recognize the concerns that Sam and others have about version binding,
but I think that we can solve that, and Gump certainly acts as an
independant watchdog.

geir


-- 
Geir Magnusson Jr.   [EMAIL PROTECTED]
Developing for the web?  See http://jakarta.apache.org/velocity/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Binaries in CVS

[Peter Donald]

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
files) of products. 

Associated with each product has a list of jars each with a name (and
optionally a flavour) and a version. So you could have
turbine-debug-1.2.3.jar, avalon-4.5.6.jar, log4j-7.8.jar etc

When doing a build you can choose to update your local jars so that the
required versions are stored in a system wide, workspace wide or project
wide repository.

For instance in the Avalon projects I currently have a temporary hack till
CJAN arrives that installs the jars into a location specified by cjan.home.
So I set cjan.home in "${user.home}/.ant.properties". The binaries are
installed into systemwide /opt/apps/cjan in my case and other projects
directly reference it from there.

When full CJAN comes about the system will look something like this


  
  



This will first check your local repositories for appropriate jar. In my
case it would check the following locations

/opt/apps/cjan/xml/parser/xerces-1.2[.*].jar
/opt/Repositories/avalon/lib/xml/parser/xerces-1.2[.*].jar
/opt/Repositories/avalon/jakarta-avalon/lib/xml/parser/xerces-1.2[.*].jar

(or you could elide category directories - xml/parser - if it looked better).

It would detect that I don't have xerces around with correct version and
download the appropriate jar from CJAN repository

ie http://www.cjan.org/directory/xml/parser/xerces-1.2[.*].jar

It would then install it into a local system specific place dependening on
permissions and settings. I would choose for it to be installed at
workspace level - namely

/opt/Repositories/avalon/lib/xml/parser/xerces-1.2[.*].jar

It would then set the property xerces.jar to the location of the jar. 

A bit further on you go 


  
  ...


Subsequent runs would not need to download jar but instead could use this
one directly.

This would allow each project to depend on particular versions, be easy for
end user and remove need for binaries in CVS. 
Cheers,

Pete

*--*
| "Computers are useless. They can only give you   |
|answers." - Pablo Picasso |
*--*

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Sam Ruby]

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 in CVS. Gump works regardless of what people
> put in their CVS modules. Right?

See below.

> So the automatic update done by CVS eases the distribution
> of binaries but also increases the communication/networking
> overhead. The overhead is particularly irritating if the
> changes in the binary are minor.
>
> In other words, putting binary files under CVS decreases the
> need for developer to developer  communication but increases
> computer to computer communication. Cheers, Ceki

I think you are looking at the symptoms, not the root problem.

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 just fine against a
version of servlet.jar that was built two years ago.  I bet that 98% of
these servlets will compile just fine against the version of servlet.jar
that will be built two years from now.

The same can not be said for applications which depend on avalon or
turbine.  Not two years, not one year, not six months, not three months.
Heck, I doubt that 98% of the applications which depend on turbine would
compile against the version of turbine that WAS BUILT LAST NIGHT.

I have great sympathy for subprojects like jetspeed and cocoon who depend
on a long list of subprojects with little respect for their users.  Their
only defense it to check in jars.

When I first got involved with Tomcat, it only worked well with the latest
Sun 1.2 JDK, on Solaris, with encoding en_US.  It couldn't even compile
with Jikes.  Now it works on a wide range of JDKs from a number of vendors
on a number of platforms (and handles encoding properly too).  Why?
Thankfully both legal and technical problems prevented us from checking in
the JDK.

Gump doesn't solve these problems.  Peter Donald has outsmarted it.  Jason
van Zyl ignores it.

There are loud voices out there that say that version to version
compatibility isn't important.  You know better than your customers as to
what versions they really want.

They used to say that version to version compatibility wasn't much of an
issue, but they don't say that much any more, thanks to Gump.  In four
months, I have yet to have a clean run.  Even if one excludes xml-cocoon1
from the picture.

I have found that I can't talk over them all at once, so I have resigned
myself to convincing people one at a time that version to version
compatibility really matters.

Ceki - you are one of the people I have convinced.  Now look at the
dependencies of jakarta-log4j.  You are one of the lucky ones - outside of
Ant, you depend on stable standards.  And Ant has grown up to the point
where they are responsible.  So, do you really care whether users use
whichever XML parser they happen to have on their local machine, or do you
really want to require them to download yet another XML parser?  If they
happen to have jakarta-ant checked out, they already have three.  I'll bet
any one of them will serve your needs.

I still think a single repository of stable jars is an excellent idea.
Whether that repository is implemented as a tar, in cvs, or named CJAN, I
care not.  But IMHO, such a system only works if mix and match is made
possible first.

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 marketing machine.
Not because it it technically better.  But because I for one don't like
rewriting my applications every few months.

- Sam Ruby


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Ceki Gülcü]

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 to solve is optimizing the
>communication paths.
>
>I don't accept that reality.
>
>I bet that 98% of the servlets out there would compile just fine against a
>version of servlet.jar that was built two years ago.  I bet that 98% of
>these servlets will compile just fine against the version of servlet.jar
>that will be built two years from now.
>
>The same can not be said for applications which depend on avalon or
>turbine.  Not two years, not one year, not six months, not three months.
>Heck, I doubt that 98% of the applications which depend on turbine would
>compile against the version of turbine that WAS BUILT LAST NIGHT.
>
>I have great sympathy for subprojects like jetspeed and cocoon who depend
>on a long list of subprojects with little respect for their users.  Their
>only defense it to check in jars.

OK. This is a new working assumption. If you think about CVSing jar files as a defense 
against code changes, then your remark about symptoms versus root problem makes sense. 

>When I first got involved with Tomcat, it only worked well with the latest
>Sun 1.2 JDK, on Solaris, with encoding en_US.  It couldn't even compile
>with Jikes.  Now it works on a wide range of JDKs from a number of vendors
>on a number of platforms (and handles encoding properly too).  Why?
>Thankfully both legal and technical problems prevented us from checking in
>the JDK.
>
>Gump doesn't solve these problems.  Peter Donald has outsmarted it.  Jason
>van Zyl ignores it.
>
>There are loud voices out there that say that version to version
>compatibility isn't important.  You know better than your customers as to
>what versions they really want.

It's actually the aspect that matters the most, for widely used projects that is. It 
is perfectly OK to be adventurous until the API is actually relied upon by many 
people. Backward compatibility is not exactly fun. There are different degrees of 
backward compatibility. I am not sure if all code written for Tomcat 3.x will compile 
or work under 4.0. 

>They used to say that version to version compatibility wasn't much of an
>issue, but they don't say that much any more, thanks to Gump.  In four
>months, I have yet to have a clean run.  Even if one excludes xml-cocoon1
>from the picture.
>
>I have found that I can't talk over them all at once, so I have resigned
>myself to convincing people one at a time that version to version
>compatibility really matters.
>
>Ceki - you are one of the people I have convinced.  Now look at the
>dependencies of jakarta-log4j.  You are one of the lucky ones - outside of
>Ant, you depend on stable standards.  And Ant has grown up to the point
>where they are responsible.  So, do you really care whether users use
>whichever XML parser they happen to have on their local machine, or do you
>really want to require them to download yet another XML parser?  If they
>happen to have jakarta-ant checked out, they already have three.  I'll bet
>any one of them will serve your needs.

I am very grateful to you for hammering on the backward compatibility issue. The 
current goal is to make log4j v1.1 to be 100% compatible with log4j v1.0.x in every 
aspect. Our users should appreciate... 

Now, regarding ant.jar checked in the log4j module, I don't see what the problem is. 
The user can use whatever ant version she decides to use; log4j does not care. The 
same goes for the xml parser. Hey, you can even use JDK 1.1.x. If the user does not 
have ant.jar then there is a default one provided by the log4j CVS module (as well as 
by the log4j distribution.) So as far as I see, there are no issues with log4j 
including binaries in its CVS module. It's just a convenience feature with few or 
negligible side effects.   

The versioning issue that you raise is much more fundamental and somewhat orthogonal 
to CVSed binaries (IMHO).

>I still think a single repository of stable jars is an excellent idea.
>Whether that repository is implemented as a tar, in cvs, or named CJAN, I
>care not.  But IMHO, such a system only works if mix and match is made
>possible first.
>
>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 marketing machine.
>Not because it it technically better.  But because I for one don't like
>rewriting my applications every few months.

I'll let Jason and Jon comment, wouldn't want to touch this one with a 12 yard stick. 
Cheers, Ceki 


-
To unsubscribe, e-mail: [EMAIL PROTECTED

Re: Binaries in CVS

[Peter Donald]

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 just fine against a
>version of servlet.jar that was built two years ago.  I bet that 98% of
>these servlets will compile just fine against the version of servlet.jar
>that will be built two years from now.
>
>The same can not be said for applications which depend on avalon or
>turbine.  Not two years, not one year, not six months, not three months.
>Heck, I doubt that 98% of the applications which depend on turbine would
>compile against the version of turbine that WAS BUILT LAST NIGHT.

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 you want
static versions go buy something from a major vendor. Even those generally
do complete changes every major version (see MS and their DX1-8 or MFC
versions).

>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 cost of entry.

Have a look at all the projects under apache umbrella. Now rate the
activity of each project excluding people who get paid to directly work on
products. Now correlate this with cost of entry (of which jars in CVS is a
factor). Excluding ant for the moment what do you see? ... Which ones have
more community behind them? Which ones store binaries in CVS? Coincidence?? ;)

The exception of course is Ant - it only stores the absolute minimum jars
in CVS. It is still popular to developers though partially out of necessity
and partially because the excluded jars are non-essentials.

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]

Re: Binaries in CVS

[Scott Sanders]

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 snapshots (ie .jar/.war/.ear
> files) of products. 

Cool.  Let's do it!


> 
> Associated with each product has a list of jars each with a name (and
> optionally a flavour) and a version. So you could have
> turbine-debug-1.2.3.jar, avalon-4.5.6.jar, log4j-7.8.jar etc
> 

OK


> When doing a build you can choose to update your local jars so that the
> required versions are stored in a system wide, workspace wide or project
> wide repository.

OK


> 
> For instance in the Avalon projects I currently have a temporary hack till
> CJAN arrives that installs the jars into a location specified by cjan.home.
> So I set cjan.home in "${user.home}/.ant.properties". The binaries are
> installed into systemwide /opt/apps/cjan in my case and other projects
> directly reference it from there.
> 
> When full CJAN comes about the system will look something like this
> 
> 
>   
>   
> 
> 

Cool.


> 
> This will first check your local repositories for appropriate jar. In my
> case it would check the following locations
> 
> /opt/apps/cjan/xml/parser/xerces-1.2[.*].jar
> /opt/Repositories/avalon/lib/xml/parser/xerces-1.2[.*].jar
> /opt/Repositories/avalon/jakarta-avalon/lib/xml/parser/xerces-1.2[.*].jar
> 
> (or you could elide category directories - xml/parser - if it looked better).
> 
> It would detect that I don't have xerces around with correct version and
> download the appropriate jar from CJAN repository
> 
> ie http://www.cjan.org/directory/xml/parser/xerces-1.2[.*].jar
> 
> It would then install it into a local system specific place dependening on
> permissions and settings. I would choose for it to be installed at
> workspace level - namely
> 
> /opt/Repositories/avalon/lib/xml/parser/xerces-1.2[.*].jar
> 
> It would then set the property xerces.jar to the location of the jar. 
> 
> A bit further on you go 
> 
> 
>   
>   ...
> 
> 
> Subsequent runs would not need to download jar but instead could use this
> one directly.
> 

Great.


> This would allow each project to depend on particular versions, be easy for
> end user and remove need for binaries in CVS. 

Since I understand the commons sandbox to be just the sort of thing for 
this, and I also understand that every jakarta committer has access to 
the sandbox, I am going to start the code part of CJAN.  I see it as an 
optional ant task with some repository configuration information.

See you all in the sandbox.

Scott Sanders


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Sam Ruby]

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 to CVSed binaries (IMHO).

More fundamental, certainly, but not orthogonal.

There is an inverse correlation between home sales and interest rates.
Home sales do continue when interest rates are high, but interest rates put
a damper on them.

Looking at Jakarta projects, IMHO there is an inverse correlation between
interface stability and CVSed binaries.

I'd wager that if these binaries were placed in a separate CVS module - as
has been suggested a number of times here - that all the benefits of CVSed
binaries will be present with few if any of the drawbacks.

I'd even go so far as to suggest that the name of this CVS module be
jakarta-jpan.

- Sam Ruby


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Craig R. McClanahan]

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.
> >
> >I bet that 98% of the servlets out there would compile just fine against a
> >version of servlet.jar that was built two years ago.  I bet that 98% of
> >these servlets will compile just fine against the version of servlet.jar
> >that will be built two years from now.
> >
> >The same can not be said for applications which depend on avalon or
> >turbine.  Not two years, not one year, not six months, not three months.
> >Heck, I doubt that 98% of the applications which depend on turbine would
> >compile against the version of turbine that WAS BUILT LAST NIGHT.
> 
> 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 you want
> static versions go buy something from a major vendor. Even those generally
> do complete changes every major version (see MS and their DX1-8 or MFC
> versions).
> 

In a backhanded way, I agree with this sentiment -- open source is
demonstrably good at creating great implementations, and not so good at
creating specifications.  I suspect this is partly/mostly because many
open source developers rebel against the very disciplines that a
"standard" implies.  (If you want a fight, let's talk about where the
curly braces should go on an "if" statement :-).

But this also raises an issue of who are the "users" we are trying to make
life easier for.  More on this below.

> >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 cost of entry.
> 
> Have a look at all the projects under apache umbrella. Now rate the
> activity of each project excluding people who get paid to directly work on
> products. Now correlate this with cost of entry (of which jars in CVS is a
> factor). Excluding ant for the moment what do you see? ... Which ones have
> more community behind them? Which ones store binaries in CVS? Coincidence?? ;)
> 

This paragraph begs for multiple responses, from different viewpoints (not
necessarily building on each other):

* 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 rip about how the thing is built.  By that measure, I would submit
  that Tomcat is far and away the most active Jakarta project, followed by
  Ant, followed by Struts, followed by everything else.  (Check download
  counts and -USER list subscriptions and activity for corroborating
  evidence).  Tomcat 3.x and Struts contains no checked in JARs, Tomcat 4
  only has patched versions of the stupid JAXP sealed jars until the next
  version of JAXP fixes that for us.

* The number of binary distro downloads of most Jakarta projects is orders
  of magnitude more than the number of people who download source distros
  or update via CVS.  Note that the popular packages for USERS include
  convenient "all in one" binary distributions, despite the fact that they
  don't use CVS to store JAR files.  (Ant is sorta an exception - they
  offer two downloads (Ant and optional.jar) but you have to go grab
  everything else yourself).

* There seems to be a theory that only people who build from source can
  contribute patches and enhancements.  That is not borne out by
  experience on the projects I'm involved in, because the source code is
  there for examination anyway -- very large percentages of patches come
  from people who are just looking at the "src" directory included with
  the binary distributions.

* Your exclusion of "people who get paid to directly work on products"
  in measuring activity doesn't sit well with me.  Is my contribution to
  Tomcat *illegitimate* because I'm paid to do it?  I guess we'd also need
  to throw out the contributions of lots of other people whose companies use
  Tomcat and who contribute to it on company time, but it's not their full
  time job.  This kind of attitude denigrates the substantial contributions
  of lots of people; you might want to rethink it.

* Finally, to show that I can be just as elitist :-), I'd say that being
  able to build something like Tomcat from sources (by following the
  directions included in the README) is a pretty good first level filter
  for people worthy of being committers in the future :-).

> The exception of course is Ant - it only stores the absolute minimum jars
> in CVS. It is

Re: Binaries in CVS

[Sam Ruby]

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 you want
> static versions go buy something from a major vendor.
>
> Have a look at all the projects under apache umbrella. Now rate the
> activity of each project excluding people who get paid to directly work
on
> products. Now correlate this with cost of entry (of which jars in CVS is
a
> factor). Excluding ant for the moment what do you see? ... Which ones
have
> more community behind them? Which ones store binaries in CVS?
Coincidence?? ;)

Best community, by far, IMHO is http://www.php.net/.  The number of active
developers there is larger than the total number of developers across all
Jakarta and XML projects combined.  No .jar, .exe, .so in CVS at all.

PHP 4.0 was essentially a rewrite, with a high focus on backwards
compatibility.  PHP 3.0 was essentially a rewrite with a high focus on
backwards compatbility.

Not because a standards body dictated it.  Not because a major vendor paid
for it.  But because it was the right thing to do.

CPAN wouldn't be possible if Perl were as unstable as most Jakarta
projects.  While outside of the Apache umbrella, Perl is another example.

- Sam Ruby


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Jason van Zyl]

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. There are fundamental aspects of
Turbine
that have been reimplemented in Jetspeed because the Jetspeed group has
felt that some essential functionality is missing. This is true, but I
am trying to work with Raphael from the group to find a solution.
We are both busy, but steps in the right direction have been made. One
of the problems was the amalgamation of the ExtendedProperties classes.
This is on it's way into the commons and I am trying to integrate some
of
Raphaels additional changes back into the new Configuration class. The
second problem is the template service in turbine. I have revamped the
template service and additional changes are being made my Ilkka Priha
to try and address some limitations in an attempt to make the use
of the Turbine template service more applealing then reimplementing
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), and a temporary patch to silence GUMP wouldn't
really do much to solve anything tangible. I value the output of GUMP
and I do what I can, I don't think it's fair to say that I'm igorning
the problem or ignoring GUMP.

I work on a project which relies on Turbine, and am often annoyed at
myself when trying to upgrade a turbine.jar. I have yet to learn to
balance my eagerness to improve turbine with the saneness of stability.
I intend for this habit to die quickly when turbine is released at
javaone.

[snip]
 
> 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 marketing machine.
> Not because it it technically better.  But because I for one don't like
> rewriting my applications every few months.

How much do you want to bet :-) I do like those US dollars :-)

This is a problem with Turbine, a big one. I think that the
release at javaone will be a big step in the right direction
and will go a long way toward providing a stable incarnation
of Turbine that is far less annoying to work with.

-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
http://tambora.zenplex.org

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Scott Sanders]

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   jakarta  1562 Nov 27 20:16 cjan.xml
>> drwxrwxr-x   2 jon   jakarta   512 Nov 27 20:16 files
> 
> 
> 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.  This is much more fun than REAL work.  ;-)  ;-)  ;-) ;-) ;-) ;-)
> 

I must say that you two are the most comedic couple I've read on a 
mailing list in a LONG time.  Keep it up, and we might get somewhere.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Peter Donald]

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 cost of entry.
>> 
>> Have a look at all the projects under apache umbrella. Now rate the
>> activity of each project excluding people who get paid to directly work on
>> products. Now correlate this with cost of entry (of which jars in CVS is a
>> factor). Excluding ant for the moment what do you see? ... Which ones have
>> more community behind them? Which ones store binaries in CVS?
Coincidence?? ;)
>> 
>
>This paragraph begs for multiple responses, from different viewpoints (not
>necessarily building on each other):
>
>* How are you measuring "activity"?  

developers rather than users. Community is sustained/defined by developers
rather than users.

> I would guess from your statement
>  that you are talking about developers doing commits 

not just commits, any communication - code, questions, patches whatever.

> By that measure, I would submit
>  that Tomcat is far and away the most active Jakarta project, followed by
>  Ant, followed by Struts, followed by everything else.  (Check download
>  counts and -USER list subscriptions and activity for corroborating
>  evidence).  

Thats interesting - I would have assumed ant is downloaded more frequently.
Is there an apache page that lists hits by category/month - or do I resort
to grep/sort/wc ;)

>* There seems to be a theory that only people who build from source can
>  contribute patches and enhancements.  That is not borne out by
>  experience on the projects I'm involved in, because the source code is
>  there for examination anyway -- very large percentages of patches come
>  from people who are just looking at the "src" directory included with
>  the binary distributions.

I haven't seen evidence of this in any of the projects I am involved in -
not sure.

>* Your exclusion of "people who get paid to directly work on products"
>  in measuring activity doesn't sit well with me.  Is my contribution to
>  Tomcat *illegitimate* because I'm paid to do it? 

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. Most of the rest of the
community does not have that privlidge. Putting obstacles in their way is
one way of reducing the possibility of a community ever developing outside
those paid to do work.

>* Finally, to show that I can be just as elitist :-), I'd say that being
>  able to build something like Tomcat from sources (by following the
>  directions included in the README) is a pretty good first level filter
>  for people worthy of being committers in the future :-).

It's not about understanding directions - it is about work.

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]

Re: Binaries in CVS

[Peter Donald]

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 them to their own environments. Hence they do. If you want
>> static versions go buy something from a major vendor.
>>
>> Have a look at all the projects under apache umbrella. Now rate the
>> activity of each project excluding people who get paid to directly work
>on
>> products. Now correlate this with cost of entry (of which jars in CVS is
>a
>> factor). Excluding ant for the moment what do you see? ... Which ones
>have
>> more community behind them? Which ones store binaries in CVS?
>Coincidence?? ;)
>
>Best community, by far, IMHO is http://www.php.net/.  The number of active
>developers there is larger than the total number of developers across all
>Jakarta and XML projects combined.  No .jar, .exe, .so in CVS at all.

right - and I assume very few similar projects also include exes/dlls.
There is a number of reasons for this 
* c/whatever is infinitely more mature than java as a development environment.
* sos/dlls/exes wouldn't work as I assume php is built on multiple
OSes/architectures/environments

Notice however that most of jakarta is based on java and it's immature
environment and java is cross-platform so these steps are viable ;)

>PHP 4.0 was essentially a rewrite, with a high focus on backwards
>compatibility.  PHP 3.0 was essentially a rewrite with a high focus on
>backwards compatbility.

I am not sure what this has to do with above - but ... the question arise: so?

As products become mature they stabilize - that is natural. PHP reached
that plateau, ant sorta did with 1.3 and really will with 2.0. Many of the
other projects are a work in progress with no real reason to maintain
eternal compatability. In most cases (ie turbine/avalon/cocoon2 are the
ones I am aware of) it is less cost to move to a better system than it is
to stay with a sucky system.

When/if any of these projects gain thousands of followers this tide will
turn but until then ... 

>Not because a standards body dictated it.  Not because a major vendor paid
>for it.  But because it was the right thing to do.

you mean PHP matured?

>CPAN wouldn't be possible if Perl were as unstable as most Jakarta
>projects.  While outside of the Apache umbrella, Perl is another example.

So how long has perl been around? What about the apache projects? Where the
early years of perl bump free?
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]

Re: Binaries in CVS

[Sam Ruby]

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,
not the other way around.

http://conferences.oreilly.com/java/sessions/bios.html

- Sam Ruby


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Geir Magnusson Jr.]

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 marketing machine.
> Not because it it technically better.  But because I for one don't like
> rewriting my applications every few months.

The comparison was really about JSP vs. Velocity.

What if you could use Struts/Velocity?   :-)

geir

-- 
Geir Magnusson Jr.   [EMAIL PROTECTED]
Developing for the web?  See http://jakarta.apache.org/velocity/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Sam Ruby]

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

Admitting that you have a problem is the first step!

;-)

> I don't think it's fair to say that I'm igorning the problem
> or ignoring GUMP.

It is fair to say that you are ignoring Gump at this point.  It is also
fair to say that this is the right thing to do at this time.  (It doesn't
mean I have to like it, but it is true nevertheless).

> I intend for this habit to die quickly when turbine is released at
> javaone.

A big +1.

Personally, I'd love to see JetSpeed check in a turbine.jar at JavaOne and
still have the *SAME* jar file be the one at the CVS head at the *NEXT*
JavaOne - *AND* still build successfully each night with Gump.

- Sam Ruby


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Geir Magnusson Jr.]

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 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 for 'DAT Services'  Hmmm.


-- 
Geir Magnusson Jr.   [EMAIL PROTECTED]
Developing for the web?  See http://jakarta.apache.org/velocity/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Binaries in CVS

[Steve Downey]

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
Jakarta control. If a project depends on them, it probably depends on
specific versions. In order to have repeatable builds from different
developers, having those under project configuration management is critical.
Otherwise you rely on the outside world to maintain the version you need.

Project jars are the ones that are produced by the project. For ant, to take
a random example, to include ant.jar in their repository would be
pathological. At best it represents a bootstrap problem (which ant does
have, and surmounts), at worst you never have the current target in cvs
because it is always out of date. Products of a build should not be
versioned. Sources should be.

The middle ground is where the 'fun' is. Should Cactus treat jakarta-servlet
as a foreign project, or should it treat it as a co-equal project. Answer
one way and you end up with A depending on a downlevel version of B, while B
depends on a downlevel version of A. A production deployment nightmare.
Answer the other and you run the risk that your release is contingent on
project C's, and they're behind schedule.

Gump is tending to show that the latter risk is minimal. Simply having it is
keeping people more honest about published interfaces. 

My preference is to CVS external binaries, and rely on dist builds for
propagating Jakarta jars. Or a build from a unified tree, the way Tomcat
used to be.

-SMD
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Sam Ruby]

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 for 'DAT Services'  Hmmm.

Yup.  Craig was not a Sun employee at the time he wrote the following:

http://jakarta.apache.org/tomcat/jakarta-tomcat-4.0/catalina/docs/dev/proposal.html

Note the pronoun used in the first sentence:

"In June 1999, Sun announced that they..."

- Sam Ruby


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Ceki Gülcü]

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
>> >communication paths.
>> >
>> >I don't accept that reality.
>> >
>> >I bet that 98% of the servlets out there would compile just fine against a
>> >version of servlet.jar that was built two years ago.  I bet that 98% of
>> >these servlets will compile just fine against the version of servlet.jar
>> >that will be built two years from now.
>> >
>> >The same can not be said for applications which depend on avalon or
>> >turbine.  Not two years, not one year, not six months, not three months.
>> >Heck, I doubt that 98% of the applications which depend on turbine would
>> >compile against the version of turbine that WAS BUILT LAST NIGHT.
>> 
>> 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 you want
>> static versions go buy something from a major vendor. Even those generally
>> do complete changes every major version (see MS and their DX1-8 or MFC
>> versions).
>> 
>
>In a backhanded way, I agree with this sentiment -- open source is
>demonstrably good at creating great implementations, and not so good at
>creating specifications.  I suspect this is partly/mostly because many
>open source developers rebel against the very disciplines that a
>"standard" implies.  (If you want a fight, let's talk about where the
>curly braces should go on an "if" statement :-).
>
>But this also raises an issue of who are the "users" we are trying to make
>life easier for.  More on this below.
>
>> >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 cost of entry.
>> 
>> Have a look at all the projects under apache umbrella. Now rate the
>> activity of each project excluding people who get paid to directly work on
>> products. Now correlate this with cost of entry (of which jars in CVS is a
>> factor). Excluding ant for the moment what do you see? ... Which ones have
>> more community behind them? Which ones store binaries in CVS? Coincidence?? ;)
>> 
>
>This paragraph begs for multiple responses, from different viewpoints (not
>necessarily building on each other):
>
>* 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 rip about how the thing is built.  By that measure, I would submit
>  that Tomcat is far and away the most active Jakarta project, followed by
>  Ant, followed by Struts, followed by everything else.  (Check download
>  counts and -USER list subscriptions and activity for corroborating
>  evidence).  Tomcat 3.x and Struts contains no checked in JARs, Tomcat 4
>  only has patched versions of the stupid JAXP sealed jars until the next
>  version of JAXP fixes that for us.

Are the stats available? If so, I would appreciate a pointer.

Coming back to the number comparisons, I think that most jakarta projects are very 
popular compared to the thousands of open source projects out there. Log4j which is 
not as nearly as popular as tomcat, gets over 10'000 hits/day, a 2000-4000 
visitors/day, and about 500 downloads each day, that's more than most open source 
projects get in a whole year. Although log4j is totally dwarfed by Tomcat which is 
probably the most popular Java application in the world today. The point to remember 
is that even if Tomcat included binaries in its CVS module, Tomcat would still be very 
popular, not more, not less.  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 portability.  


>* The number of binary distro downloads of most Jakarta projects is orders
>  of magnitude more than the number of people who download source distros
>  or update via CVS.  Note that the popular packages for USERS include
>  convenient "all in one" binary distributions, despite the fact that they
>  don't use CVS to store JAR files.  (Ant is sorta an exception - they
>  offer two downloads (Ant and optional.jar) but you have to go grab
>  everything else yourself).
>
>* There seems to be a theory that only people who build from source can
>  contribute patches and enhancements.  That is not borne out by
>  experience on th

Re: Binaries in CVS

[Sam Ruby]

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 portability.

LOL!

If you think this was a heated debate, then you really haven't been around
here long!  ;-)

Apache in general, and Jakarta in specific tolerates a significant amount
of diversity of opinions.  Within a subproject, what matters most is the
opinions of a majority of committers to that subproject.

There are people who believe that Ant would have a more active development
community if only it were to check in an ant.jar.  There are people who
believe that releases of JetSpeed and Turbine would not be so tied at the
hip if turbine.jar weren't checked into jetspeed's cvs.  The majority of
committers on both projects understand the points that are being made, but
have come to different conclusions.  And life goes on.

- Sam Ruby


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Craig R. McClanahan]

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 ... 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 for 'DAT Services'  Hmmm.
> 

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.

> 
> -- 
> Geir Magnusson Jr.   [EMAIL PROTECTED]
> Developing for the web?  See http://jakarta.apache.org/velocity/
> 

Craig


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Craig R. McClanahan]

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 rip about how the thing is built.  By that measure, I would submit
> >  that Tomcat is far and away the most active Jakarta project, followed by
> >  Ant, followed by Struts, followed by everything else.  (Check download
> >  counts and -USER list subscriptions and activity for corroborating
> >  evidence).  Tomcat 3.x and Struts contains no checked in JARs, Tomcat 4
> >  only has patched versions of the stupid JAXP sealed jars until the next
> >  version of JAXP fixes that for us.
> 
> Are the stats available? If so, I would appreciate a pointer.
> 

For download counts, you have to go analyze the log files (and, of course,
we're only counting downloads from daedalus -- not from mirrors).  Tomcat
runs in the 50k-100k downloads per month range -- having up to date stats
would be quite nice.

For mailing lists, the following are subscription counts as of this
morning to the Jakarta-based mailing lists:

alexandria -dev   65-user   57
announcements 4183
ant-dev  517-user  860
avalon -dev  104-user   22
ecs-dev   53-user   96
general   1165
jakarta-commons   72
james  -dev  102-user  128
jetspeed   -dev  153-user  202
jmeter -dev   45-user   71
log4j  -dev  157-user  335
oro-dev   74-user  135
regexp -dev   97-user  156
slide  -dev  193-user  283
struts -dev  610-user 1189
taglibs-dev  348-user  510
tomcat -dev 1082-user 2176
turbine-dev  190-user  304
velocity   -dev  152-user  304

Craig


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Jon Stevens]

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 also a much older project with a much higher number of users. PHP
gets a lot of Perl people who wake up and realize that Perl sucks for CGI's.
We don't get that crowd nearly as much.

Comparing PHP to Jakarta is like comparing apple's to oranges.

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Jon Stevens]

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.

:-)

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binaries in CVS

[Morgan Delagrange]

--- 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 over checking in binaries in all
> projects:
> > - only pristine sources in all projects ( except
> the binary tree )
> > - consistent behavior and location for the
> binaries for all projects
> using
> > the binary tree
> > - less duplication and space ( and download time )
> > - a simple way to get the latest stable release
> for all jars ( a cvs
> > update will also get only what's changed, instead
> of requiring to
> > download and install x different tar.gz files )
> 
> +1
> 
> Perhaps we could even get a change into ant.bat and
> ant.sh to "
> -Djakarta.home=$JAKARTA_HOME".
>
> [big ol' snip]

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
locally.  Or ignore the common repository and check
everything in locally, if they're dead set against the
idea.  To me, a common repository sounds like a lot
less work for the individual subproject owners, but
Jakarta members are nothing if not peculiar.

Of course, there are administrative details to
consider.  I would be very wary of putting anything
approaching a beta release in the common repository. 
We would need some ground rules to make sure that
didn't happen.

- Morgan


=
Morgan Delagrange
Britannica.com

__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]