At the last PMC meeting we scheduled the next PMC meeting for Monday, 16
April 2001 at 1900 GMT. Now that daylight savings time has swapped
hemispheres, it might make sense to revisit this.
The two somewhat workable times are 1200 GMT and 2000 GMT. I'd like to
hear opinions on the following
on 4/12/01 8:42 AM, "Sam Ruby" [EMAIL PROTECTED] wrote:
B:
4PM California
7PM NY
2000GMT
2200Zurich
0600Melbourne (Tuesday)
I vote for B. :-)
-jon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
At 11:42 12.04.2001 -0400, Sam Ruby wrote:
At the last PMC meeting we scheduled the next PMC meeting for Monday, 16
April 2001 at 1900 GMT. Now that daylight savings time has swapped
hemispheres, it might make sense to revisit this.
The two somewhat workable times are 1200 GMT and 2000 GMT.
I vote for A:
8AM California
11AMNY
1200GMT
1400Zurich
2200Melbourne
- Sam Ruby
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
Sam Ruby wrote:
At the last PMC meeting we scheduled the next PMC meeting for Monday, 16
April 2001 at 1900 GMT. Now that daylight savings time has swapped
hemispheres, it might make sense to revisit this.
The two somewhat workable times are 1200 GMT and 2000 GMT. I'd like to
hear
on 4/12/01 10:37 AM, "Ceki Glc" [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
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
On Thu, 12 Apr 2001, Ceki [iso-8859-1] Gülcü wrote:
At 11:42 12.04.2001 -0400, Sam Ruby wrote:
At the last PMC meeting we scheduled the next PMC meeting for Monday, 16
April 2001 at 1900 GMT. Now that daylight savings time has swapped
hemispheres, it might make sense to revisit this.
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
At 15:04 12.04.2001 -0700, Craig R. McClanahan wrote:
On Thu, 12 Apr 2001, Ceki [iso-8859-1] Glc 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
At 12:57 13/4/01 +0200, Ceki Glc 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
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
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
Ceki Glc 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.
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
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
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
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.
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
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
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,
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
Hi,
I'd like to get an account on the Jakarta FAQ.
I read what is there :
http://jakarta.apache.org:8080/jyve-faq/Turbine/screen/DisplayProjects
I talked with Alex, but apparently the account activation failed, and I
couldn't get in touch with him since.
Could one of the roots help me out ?
My
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
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
--- 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
42 matches
Mail list logo
