Re: [GUMP] Any James developers here?

2001-02-15 Thread Peter Donald

At 09:27  12/2/01 +, Charles Benett wrote:
 
http://jakarta.apache.org/builds/gump/2001-02-11/james.html

Strange, it wasn't a couple of days ago. And deprecating interfaces
shouldn't break a build.

I think it got too many deprecation messages and busted the compiler/ant.
Will have a look at it when I get the chance.

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: [GUMP] Any James developers here?

2001-02-15 Thread Peter Donald

At 04:08  13/2/01 +, Charles Benett wrote:
Hmm. Good idea, but I can't see it working for james, yet. There aren't
enough active james developers to keep up with daily changes in avalon.
James runs fine with the last release of Avalon, 3.1a1. 

If you like I could help keep them synched?
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: What is Struts? (was: Re: What is Avalon?)

2001-02-15 Thread Peter Donald

How very amusing.

At 11:06  10/2/01 -0800, Jim Driscoll wrote:
The internet, where everyone's an expert. 

yes - the biggest people of course are those who wear skippy badges and
loudly claim their excellence. Yes there are lots of experts.

Stop assuming things without checking facts.

right ... just like you - huh ?

 4. Implementing select() is not difficult considering it is part of POSIX
 and implemented on all platforms that I am aware of (except small ones
 which use a different platform - J2ME).

This is not entirely true.  If it was trivial, someone would have
cranked it out over a weekend.  Heck, you've got the source code (in
SCSL) - why don't YOU do it.

Well - do I look like an idiot? No one in their right mind would ever
contribute code under SCSL if it is the same one from a while back. Why do
you think that all the free JVM/class library projects will not accept code
from people who have looked at code under SCSL? I have heard people
complain about the GPL "taint" - well the SCSL taint is by far a more
sinister variety - it is a taint on IP of product. You effectively give up
the possibility of many of your ideas by signing that obstrocity.

Thankfully I have been hearing murmurings that there is to be a new GNU
jihad against ths SCSL soon ... not sure if it is true but it would follow
as since an incident with another free software java group (jBoss) I have
heard that the "gurus" are now having a closer look at java. We can only
hope it will get Sun to change to a less evil license or even a nice one ;)

 6. Without select it is impossible to write scalable server apps that deal
 with sparsly transmitted upon connections except in hardware that have fine
 grain locking + many CPUs

Not true.  With clever use of threads, it's been possible to write at
least one webserver which exceeded the performance of Apache using
standard benchmarks on SMP machines (both NT and Solaris, Linux threads
were crap back then, and the implementation wasn't up to it), as well as
a proxy server which was speed-competitive with Squid.

Yay - a Straw Man arguement. 

Question: What does a webserver have to do with "sparsly transmitted upon
connections"?
Answer: Nothing

Great reasoning you got there.

All of which sounds pretty competitive to me.  Where are you getting
*your* data?

I developed a prototype IM server similar to jabber in java. It wasn't
until later that I realized the theoretical limitations. Naturally we were
forced back to native code (namely c).

 8. Given the above - Sun obviously believes networking is important, server
 products are a forte of java and have little cost or risk implementing
 select().

Demonstrated false 

You are not very good at logic are you. "Demonstrated false" is a false
statement ;)

My conclusion is that it's more convenient for you to engage in
conspiracy theory than actually ask the engineers involved, or look at
the codebase, or think.

My conclusion is that you are too close to the subject material to think
rationally - and I guess that has been adequetely established, no?

But really, as I said, if you can write even a
halfway decent threadpool, it's not so necessary to have select.

When you make claims like this - how do you expect us to believe you are an
authority? Whats the saying - "It's better to stay silent and let people
think you are stupid than open your mouth and prove it".

It'd be far more yeild for high performance servers to have a bug-free
VM, better performance in multithreaded envirnments, security that
actually works, DNS lookups that do smart caching 

Add in keywords "service", "xml" and "distributed" and you will graduate
from the MS school of FUD.

Seriously if you think that Sun is whistle clean then feel free to say so.
However your reply was made up of
1. Personal insults
2. You displaying your ignorance
3. A strawman argument
4. FUD

If you want to convince us then try to make your argument cogent or at
least try to back it up with facts for without this you are just a
sophisticated troll. Recomended steps for anybody listening to you

After reading message
1. Take a deep breath
2. Re-read the message
3. think about message
4. reply

It is amazing how many people skip 1-3 ...



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: Test Infrastructure Project Proposal

2001-02-15 Thread Peter Donald

At 04:06  10/2/01 -0500, [EMAIL PROTECTED] wrote:
I propose a project for testing infrastructure, that covers the needs of
unit testing, stress testing, performance testing, negative testing (i.e.
testing of error conditions), integration testing, and error logging and
reporting.  

Stress and performance testing belong in a separate project and we already
have one (jmeter) which could easily be extended to performace/stress test
other things. negative testing is usually considered a subset of unit
testing and should be covered by the same framework. 

I am not sure what you mean by "integration testing" - I have heard
different meanings for it by different people. If you meaning integration
aka continuous integration then tinderbox/gump should do it for us. If you
mean "funcitonal testing" (ie test the integration of components and see if
they perform function) then this screams out for a customized set of ant
tasks/runtime or an amalgamation of things like gtest.

Could you expand what you mean by error logging/reporting - presumably of
tests? If so then I would log 
* success
* failure - expected possible error condition
* error - unexpected error
* non-completion ( ie test required other tests to pass before it could be
run).

These could be spit out to a listener that could construct the appropriate
report.

A small note - didn't the Avalon list seperate their testing code 

It was always separate. it was a unit testing framework I built for a
separate project. It only ended up in Avalon as I needed unit testing in
avalon. It is still currently in avalon under package org.apache.testlet.

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: Test Infrastructure Project Proposal

2001-02-15 Thread Peter Donald

At 11:52  11/2/01 -0800, Jon Stevens wrote:
So, your opinion on JUnit is based on a quote on their website and a quick
glance at it? Give me a break dude.

This is exactly the type of mindset that I despise.

People need to start to learn to work together instead of constantly
re-inventing each others work. If JUnit doesn't do what you need, then work
together with the JUnit people to add the functionality that you need. Don't
just start a whole new project.

depends on the purpose. If adding the functionality to junit would
fundamentally change junit and break backwards compatability or something
similar then it is easier to rewrite it from scratch. Rewriting from
scratch while learning from mistakes of another framework makes it much
easier to develope a better product. Any revolution (say C1-c2,
tc3.x-4.0, Ant1.x-Ant2.0) is largely a rewrite. However outside apache
and one other freesoftware group I have never seen internal forks been
applied and thus it doesn't apply as it is not part of their culture. If
you said - I think I can do better than blah, rewrote blah and showed it to
original blah creators then it is unlikely they would be happy. Even if you
tried to work with them.





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: [POLL] Re: Code Sharing Concepts

2001-02-15 Thread Peter Donald

At 07:26  12/2/01 -0500, Ted Husted wrote:
On 2/9/2001 at 8:12 AM Sam Ruby wrote:
I would suggest that you start with a proposed code base.

Going back over the posts, there seem to be at least five clear areas of
overlap:

* DataSource/Database Pool
* XML Configuration

+1

* Message Resources / i18n

+1

* JNDI / Naming

+1

* Testing Suites

+1 if that means suites for products I indicated above, +1 also if it means
integrating all the test frameworks into one.

I would also like to hear from the struts bean utils. I haven't looked at
them but I presume they would be general enough (or could be made so) so
Ant2.x could use it (ie remove converter/introspector elemenets from Ant2.0
codebase).

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: FW: Suppose our department wants to contribute to Apache projects... ?

2001-02-15 Thread Ted Husted

Jon Stevens wrote:
 I don't even have an idea on how to start to answer him. Someone else wanna
 try?

How about something like this?

 Many things needed to create sites like this are actively developed
 under the wings of Apache projects, most notably the Jakarta and XML
 projects. But: there are overlaps between the various projects, and
 subprojects. Some similar things appear in different places (like: a
 webserver's built into Tomcat; there's webdav in Apache 2.0, Tomcat
 4.0, Slide shares goals with Jetspeed).

The current Apache projects are product-orientated. Each is meant to be
something a user can download and start to use. Since the feature-set of
products will naturally overlap, so do some of the technologies. This is
not unlike the situation where a spreadsheet product may also have a
database component, or a where word processing product may also have
templates for business presentations. 

Since may of the products are now relatively mature, we are now
discussing a common library of components that can be shared among
Apache subprojects, and other products. Of course, before we can 
have a component library, we need codebases for the components, so 
this is a natural evolution.  

 I know the Java, Jakarta projects are in the process of being merged,
 but I sure would like to know what gets merged with what! Suppose, to
 be more specific, I'd like to use Apache, Tomcat, Cocoon, Jetspeed to
 have a flexible XML-based portal set-up.

What's happening is that these products are being transferred to the
Jakarta site. No other changes to the Java Apache products are
contemplated as part of the transfer. For all intents and purposes, they
are all "Jakarta" products now, we just have to update the Web sites to
reflect what has already been done.

 Suppose, to
 be more specific, I'd like to use Apache, Tomcat, Cocoon, Jetspeed to
 have a flexible XML-based portal set-up.

That sounds like a very good way to go! The general idea is that you
should be able to assemble the products to build your own platform. Not
unlike the way you might put HTTP, FTP, SMTP, and POP servers from
different vendors together to assemble your preferred "Web site"
platform.

I think you will find that many of these products share developers, and
you would have many quick answers to any deployment questions. 

 The main question is: what could we contribute ? Personalization ?
 Workflow ? Management features ? Or are these things being worked on
 somewhere where I haven't seen it ? 

This is an open source community, and anything anyone is really working
on is all out in the open. So, if you don't see it, it's probably not
being done. A good place to double check is on the Jakarta General
mailing list, where we now discuss cross-product and Jakarta-wide
issues.

The best thing to contribute is what you * want * to contribute. The
usual approach is that when you find something that you need is missing,
create it and then contribute it back to the community for others to
use. Of course, the "creating it" part often involves working with
others within the community.

If you were able to deploy a super-portal based on Apache, Tomcat,
Cocoon, Jetspeed, [and JAMES], and turn that into a framework others
could use, that would be quite a contribution right there. 

Off-hand, I might suggest that you focus on working with the Jetspeed
team first, and think of your setup as building on what that product has
already started. The essence of open-source is finding a shoulder to 
stand on ;0)

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/about/struts/

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




Re: [POLL] Re: Code Sharing Concepts

2001-02-15 Thread Craig R. McClanahan

Peter Donald wrote:


 I would also like to hear from the struts bean utils. I haven't looked at
 them but I presume they would be general enough (or could be made so) so
 Ant2.x could use it (ie remove converter/introspector elemenets from Ant2.0
 codebase).


They are -- and they have dependencies only on JDK classes for the following
org.apache.struts.util classes:  BeanUtils, ConvertUtils, and PropertyUtils.
Javadocs are online at

http://jakarta.apache.org/struts/api/index.html

I haven't voted yet in this thread because I haven't seen anyone else say
"let's figure out the process issues first."  I guess it's not as interesting
as writing code :-), but it is very much as important to a shared resource like
this.

I will coordinate contributing any or all of the code listed at the bottom of
my "Code Sharing Concepts" message, but I'm definitely not interested in making
any project I'm a part of dependent on an ad hoc collection of code with no
rules about who can change what.  I've been bitten way too many times in that
scenario.


 Cheers,

 Pete


Craig



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




[ANNOUNCEMENT] Tomcat 3.3 Milestone 1

2001-02-15 Thread Larry Isaacs

The first milestone release of the next version of Tomcat 3.x is available
for download and testing.  As a Tomcat 3.x release, it remains an
implementation of the Servlet 2.2 and JSP 1.1 specifications.

In addition to bug fixes, a large amount of refactoring has gone into
Tomcat 3.3m1 since Tomcat 3.2. Much of the code is still there, but cleaned
up and likely in a new location. It is hoped with the changes that have
occurred, you will find Tomcat 3.3 more flexible and easier to configure.
You should also find improved performance over Tomcat 3.2.

In this milestone release, documentation hasn't caught up with some of the more
recent changes to Tomcat 3.3m1.  For this reason, be sure to read the "README"
file found in Tomcat's "doc" directory.  It contains documentation that covers
some of the more important of these recent changes to Tomcat 3.3.

In addition to the "README" file, the following notes provide some additional
information you will need to make full use of this release:

1) The binary distribution has source for the connectors, but not for the
   Tomcat container.  The source for the full jakarta-tomcat CVS tree is
   available separately in the "v3.3-m1/src" directory.

2) The internal directory structure contained in the binary and source archives
   differs from Tomcat 3.2.  The binary expands to a directory called "tomcat"
   and the source expands to "jakarta-tomcat".  This matches what you would get
   if you checked out CVS source and built Tomcat from that source.

3) The new class loader scheme in this release ignores your CLASSPATH setting.
   Instead, you are expected to add needed jars to Tomcat's "lib", "lib/common",
   and "lib/shared" directories. See the "README" file in Tomcat's "doc"
   directory for details.

4) The "sanity-test" is not part of the binary distribution like it was with
   Tomcat 3.2.  However, it is available in "War" form, along with the
   Watchdog JSP and servlet tests.  These are found in the "v3.3-m1/apps"
   directory.  Place these War files in Tomcat's "webapps" directory before
   starting Tomcat. To simplify testing, these tests can be run from the Admin
   web application. See the "README" file in Tomcat's "doc" directory for details.

5) On Windows 9x, there have been instances where the watchdog-jsp.jsp test
   failed to run when the jsp was first compiled.  If this happens, try
   refreshing the page to get the test to run.  Note: There is one expected
   failure, "positiveScriptlet.jsp", when the watchdog-jsp.jsp test is run again
   without restarting Tomcat 3.3.

6) For the watchdog-servlet.jsp test file to run, you must copy
   jakarta-tools' "moo.jar" and jakarta-watchdog's "client.jar" to Tomcat's
   "webapps/admin/WEB-INF/lib" directory before starting Tomcat.  Both of these
   jars are found in the "v3.3-m1/bin" directory.  These will be included in
   the admin.war in the next release.

7) The Admin web application's index.html file has an error in the commands
   it displays to set it to "trusted".  "run" should appear before "-enableAdmin"
   when using the ".sh" and ".bat" files.  This is documented correctly in
   the "README" in the "doc" directory.

Please download this release and give it a try in your environment.  The source,
rpms, and binaries may be found at:

http://jakarta.apache.org/builds/tomcat/release/v3.3-m1

To log problems or bugs, as well as submit patches, please refer to:

http://jakarta.apache.org/site/bugs.html

When logging bugs to Bugzilla, please specify the Program as "Tomcat 3"  and
the Version as "Nightly Build".

I would like to thank all those who have volunteered their time and efforts to
bring Tomcat 3.3m1 to this point. I look forward to continuing the effort to
bring Tomcat 3.3 to a final release.

Thanks,
Larry Isaacs

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




Re: [POLL] Re: Code Sharing Concepts

2001-02-15 Thread David Weinrich

Ok, sorry I was a bit late on the draw here, while I doubt my
programming skills are up to snuff, I would love to help out
with the following in any way I can:


 DATASOURCE/DATABASE POOL

+1 I can test the heck out of these and perhaps help with a bit of the
documentation...


 SUBPROJECT INFRASTRUCTURE

 [*] - Subproject infrastructure: website, documentation, sample
 applications, test suites, quality assurance.

 [Tinderbox] ?
 [GUMP] ?

+1 Just let me know what needs to be done...


 -- Ted Husted, Husted dot Com, Fairport NY USA.
 -- Custom Software ~ Technical Services.
 -- Tel 716 425-0252; Fax 716 223-2506.
 -- http://www.husted.com/about/struts/

 -
 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: [POLL] Re: Code Sharing Concepts

2001-02-15 Thread Ted Husted

"Craig R. McClanahan" wrote:
 I haven't voted yet in this thread because I haven't seen anyone else say
 "let's figure out the process issues first."  I guess it's not as interesting
 as writing code :-), but it is very much as important to a shared resource like
 this.
 
My thinking on the next step would be to draft a formal proposal for
consideration by the proposed committers, for comments, discussions,
revisions, and eventually a vote in the usual way. Also in the usual
way, these discussions could take place on an interim list (off Jakarta)
to which the proposed committers, and other interested parties, can
subscribe. Of course, when it comes to a vote, only those of the
proposed committers would be binding, again in the usual way.

There are many packages which would make good candidates for the
library. To find a starting set, I simply looked for packages where
there was already overlap. But, if no one disagrees, let's hereby amend
the POLL to include 

--

[Struts] Bean Introspection support - BeanUtils, PropertyUtils, and
ConvertUtils classes have generic support for managing JavaBean property
setting and getting through the use of the Java Reflection APIs,
including support for nested and indexed property expressions.

--

If you or Pete or anyone else would like to commit to this proposed
codebase, please reply with your +1.

I think this subproject has tremendous potential, but like all Apache
subprojects, the decision-making has to be pushed down to the people who
are willing to do the work. So before we can make any decisions, we need
to find out who will do the work, and let them decide. I know you are
one of those people, Craig, and I think you know I won't let the process
issues slide. 

-Ted.

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




Re: [POLL] Re: Code Sharing Concepts

2001-02-15 Thread Ted Husted

David Weinrich wrote:
 Ok, sorry I was a bit late on the draw here

Glad to have you aboard, David, especially since as near as I can
figure, you're the one that started this thread!

 http://www.mail-archive.com/general@jakarta.apache.org/msg00018.html 

(This time, at least ;-)

-Ted.

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




Re: [POLL] Re: Code Sharing Concepts

2001-02-15 Thread Craig R. McClanahan

Ted Husted wrote:

 There are many packages which would make good candidates for the
 library. To find a starting set, I simply looked for packages where
 there was already overlap. But, if no one disagrees, let's hereby amend
 the POLL to include

 --

 [Struts] Bean Introspection support - BeanUtils, PropertyUtils, and
 ConvertUtils classes have generic support for managing JavaBean property
 setting and getting through the use of the Java Reflection APIs,
 including support for nested and indexed property expressions.

 --

 If you or Pete or anyone else would like to commit to this proposed
 codebase, please reply with your +1.


As I stated in words rather than votes, and on this code base or any of the others in
the polll that came from my original list:

Before process management issues are worked out:  -0

After process management issues are worked out:  +1

I don't have any time to waste on anarchy-based shared code repositories.  I have
lots of time to spend, and useful code to contribute, to a shared repository that I
know I can confidently use in my projects, based on process management rules that
include protection from arbitrary API changes.


 -Ted.


Craig



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




Re: Nightly builds

2001-02-15 Thread cmanolache

Hi Sam,

I (think ) I got gump to work, it's not updating/building. There are few 
issues/sugestions. I tried to find the alexandria list ( I assume the
discussion on gump happens on alexandria ), I'm sure it is somewhere and
I'll keep searching :-)

Anyway - it would be possible to switch tomcat3.x nightly builds to use
gump, with few small changes in the project definition. 

The main issue is that (IMHO) you should relax a bit the
dependencies: a number of projects had  releases, and I think other
projects should depend on the (stable) release of those projects.

For example, tomcat, servletapi, etc should depend on released-ant-1.2,
not jakarta-ant, etc. 


Whenever a project has a major release - we should of course update the
scripts to make all projects depend on the latest "stable" and fix all
projects that are in development mode to match the latest "stable".

Given that each project has independent release cycle, I don't think it's
normal for a stable release of a project to depend on a development
release of another project ( for example, tomcat 3.3 shouldn't depend on
the dev. release of ant - but on the latest "stable" ant. If ant1.3 will 
be released before 3.3 is "frozen", then tomcat3.3 should be fixed to
make sure it works with ant 1.3 - if not, it should stay dependent on
the released ant 1.2 ).

This can be resolved by adding "project/released-ant-12.xml", etc.

Another issue - wouldn't be better to generate build.xml instead of
build.sh and build.bat ? Most of the code inside build.sh can be done
easily in a "super" build.xml that calls ant. It is even possible to
use java tags to start different VMs. 

I think this would be easier to maintain and enhance.

Another think - one planned feature for tc3.x build was a mechanism to
triger a build from a web page ( so if someone does a change, he doesn't
have to wait until the next night to find out if it brakes something ). 
My plan was to use the ant taglib ( that is also used to run the tests
from a web page ) and write a simple build.war that will allow runs of 
the build from the web. 
That would also allow a lot of simplification ( since wars are
self contained and have a stable environment/structure ). It would also
modularize a bit the build ( a page to update a repository, a page to
build, no more "echo \foo\", etc )

Finally: it would be nice if the build scripts would get the sources using
http-get instead of cvs. 


Costin


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




Re: [POLL] Re: Code Sharing Concepts

2001-02-15 Thread Sam Ruby

Ted Husted wrote:

 Also in the usual way, these discussions could take place on
 an interim list (off Jakarta) to which the proposed committers,
 and other interested parties, can subscribe.

Why off Jakarta?

Whilst this group seems to have difficulty agreeing on anything grin,
perhaps a proposal to create a new list could get enough support?  Heck, it
might even get some +1's from people that DON'T want to be subjected to
this discussion any more.  ;-)

- Sam Ruby


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




Re: [POLL] Re: Code Sharing Concepts

2001-02-15 Thread Sam Ruby

Geir Magnusson Jr. wrote:

 Call it 'Rupert'.

Be careful, that name might stick. ;-)

 I mean, with Tomcat 4, nothing really guarantees that you
 won't abandon Servlet 2.3 for the Wiggly Green Spec from
 Planet Mongo, but I trust that you will stick to your
 'mission'... :)

The are *SOME* things that the PMC are ready, willing, and able to enforce
immediately.  You just happened to pick one of them.

Not to mention the fact that the likehood of a majority of Tomcat
developers would be predisposed to consider such a thing is basically nil.

- Sam Ruby


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




Re: Nightly builds

2001-02-15 Thread Sam Ruby

Copying alexandria-dev.

Others can run builds with stable dependencies.  They are permitted, and
even encouraged to do so using Gump.  The runs I have been making are to
determine the impact of changes - something that I think that has not
received enough attention, and so that's why I have been and will continue
to focus the runs that I make on that.

Since you gave the specific example of ant, I do not like the idea of
ant-1.3 being released without some assessment of the impact of changes on
other projects.  There was a change that would have gone into 1.3 that
would have caused xerces and xalan packaging builds to fail, this was
changed to a way that would still cause it to fail, but in order to change
it to make is succeed would have required developers to step up to 1.3, and
finally, a change was made that did not require any changes.

Given the number of projects we have here, each project binding too closely
to exactly one version of each of their prereqs means that someone who
desires to compose a system out of these components is likely to run into
problems.  So, in fact, I would be greatly pleased if there were multiple
nightly builds going on out there with different combinations.  And
alexandria can certainly house the various project definitions required,
and

Making ant build.xml files as a target of gump would be a valuable
addition.  It has been often discussed, but never contributed.

Getting using http as an alternative to cvs would also make a great
addition.

- Sam Ruby

P.S.  What does it mean to have gump "working", but not
"updating/building"?

-- Forwarded by Sam Ruby/Raleigh/IBM on 02/15/2001
03:18 PM ---

[EMAIL PROTECTED] on 02/15/2001 03:07:04 PM

Please respond to [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:
Subject:  Re: Nightly builds



Hi Sam,

I (think ) I got gump to work, it's not updating/building. There are few
issues/sugestions. I tried to find the alexandria list ( I assume the
discussion on gump happens on alexandria ), I'm sure it is somewhere and
I'll keep searching :-)

Anyway - it would be possible to switch tomcat3.x nightly builds to use
gump, with few small changes in the project definition.

The main issue is that (IMHO) you should relax a bit the
dependencies: a number of projects had  releases, and I think other
projects should depend on the (stable) release of those projects.

For example, tomcat, servletapi, etc should depend on released-ant-1.2,
not jakarta-ant, etc.


Whenever a project has a major release - we should of course update the
scripts to make all projects depend on the latest "stable" and fix all
projects that are in development mode to match the latest "stable".

Given that each project has independent release cycle, I don't think it's
normal for a stable release of a project to depend on a development
release of another project ( for example, tomcat 3.3 shouldn't depend on
the dev. release of ant - but on the latest "stable" ant. If ant1.3 will
be released before 3.3 is "frozen", then tomcat3.3 should be fixed to
make sure it works with ant 1.3 - if not, it should stay dependent on
the released ant 1.2 ).

This can be resolved by adding "project/released-ant-12.xml", etc.

Another issue - wouldn't be better to generate build.xml instead of
build.sh and build.bat ? Most of the code inside build.sh can be done
easily in a "super" build.xml that calls ant. It is even possible to
use java tags to start different VMs.

I think this would be easier to maintain and enhance.

Another think - one planned feature for tc3.x build was a mechanism to
triger a build from a web page ( so if someone does a change, he doesn't
have to wait until the next night to find out if it brakes something ).
My plan was to use the ant taglib ( that is also used to run the tests
from a web page ) and write a simple build.war that will allow runs of
the build from the web.
That would also allow a lot of simplification ( since wars are
self contained and have a stable environment/structure ). It would also
modularize a bit the build ( a page to update a repository, a page to
build, no more "echo \foo\", etc )

Finally: it would be nice if the build scripts would get the sources using
http-get instead of cvs.


Costin


-
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: [POLL] Re: Code Sharing Concepts

2001-02-15 Thread Geir Magnusson Jr.

Sam Ruby wrote:
 
 Geir Magnusson Jr. wrote:
 
  Call it 'Rupert'.
 
 Be careful, that name might stick. ;-)

That would be fine - forward progress!  I guess the logo would be
next...  :)

  I mean, with Tomcat 4, nothing really guarantees that you
  won't abandon Servlet 2.3 for the Wiggly Green Spec from
  Planet Mongo, but I trust that you will stick to your
  'mission'... :)
 
 The are *SOME* things that the PMC are ready, willing, and able to enforce
 immediately.  You just happened to pick one of them.

Really?  How's that?  If all the developers decided to switch to the
WGSfromPM, what could the PMC do?  I am not trying to be argumentative -
I just thought that the PMC was well described as 'general oversight'
with project-specific issues pushed down to the project participants. 

If the tomcat developers, arguably some of the top-tier servlet
infrastructure developers in the world, decided that the WGSfromPM was
superior to Servlet 2.3 ?  Granted, Craig would be looking for a new
employer, I think... :)
 
 Not to mention the fact that the likehood of a majority of Tomcat
 developers would be predisposed to consider such a thing is basically nil.

And back to the issue, that is kinda my point : if you have a group of
developers committed to producing a top quality db connection pool for
general use, it's not clear that there is much one could do to enforce
API stability in an external way that makes sense.  At some point, you
have to trust someone involved with the project...

geir

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

-- 
Geir Magnusson Jr.   [EMAIL PROTECTED]
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity

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




Re: [POLL] Re: Code Sharing Concepts

2001-02-15 Thread Ted Husted

Sam Ruby wrote:
 Whilst this group seems to have difficulty agreeing on anything grin,
 perhaps a proposal to create a new list could get enough support?  Heck, it
 might even get some +1's from people that DON'T want to be subjected to
 this discussion any more.  ;-)

Ok, based on the response to the poll tallied at 

 http://husted.com/about/jakarta/library.html 

may we please have a interim Jakarta "libary" mailing list for the
purpose of formaling the details of a proposal for this subproject. 

If convenient, these individuals may be subscribed to list when it is
installed, being the group of people who have agreed to committ to the
proposed codebases.

Costin  [EMAIL PROTECTED] 
Rodney Waldhoff   [EMAIL PROTECTED] 
Ignacio J. Ortega  [EMAIL PROTECTED] 
Bhamidi Krishna  [EMAIL PROTECTED] 
Geir Magnusson Jr.  [EMAIL PROTECTED] 
Ted Husted  [EMAIL PROTECTED] 
Federico Barbieri  [EMAIL PROTECTED] 
Peter Donald  [EMAIL PROTECTED] 
David Weinrich  [EMAIL PROTECTED] 

If an area of the Website were also available, we'd be happy to have
that as well ;-)

Of course, in the event the proposal were rejected or died in committee,
we would expect the interim list and Web space to be cancelled.

-Ted.

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




Re: [POLL] Re: Code Sharing Concepts

2001-02-15 Thread Geir Magnusson Jr.

Ted Husted wrote:
 
 Sam Ruby wrote:
  Whilst this group seems to have difficulty agreeing on anything grin,
  perhaps a proposal to create a new list could get enough support?  Heck, it
  might even get some +1's from people that DON'T want to be subjected to
  this discussion any more.  ;-)
 
 Ok, based on the response to the poll tallied at
 
  http://husted.com/about/jakarta/library.html 

Man, you are *damn* organized :)

geir
 

-- 
Geir Magnusson Jr.   [EMAIL PROTECTED]
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity

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




Re: [POLL] Re: Code Sharing Concepts

2001-02-15 Thread Ted Husted

"Geir Magnusson Jr." wrote:

 You might think then that each partition could manage it's own issues,
 like the projects do.  

So given 

 http://www.mail-archive.com/general@jakarta.apache.org/msg00154.html 

are we on the same page, Geir?

Basically, I just want to nest everything we do for Jakarta subprojects
into Library subproducts. (But then I may have spent too many years
wired to a Pascal compiler ;-)

 I don't know what kind of process management
 rules one could have to ensure API stability other than responsibility
 to the users.  I mean, with Tomcat 4, nothing really guarantees that you
 won't abandon Servlet 2.3 for the Wiggly Green Spec from Planet Mongo,
 but I trust that you will stick to your 'mission'... :)

The idea is that when a subproject is proposed, it will also define it's
scope, or charter. The scope of the Tomcat subproject is to provide a
reference implementation for the Sun Servlet and JSP specifications. If
the committers did go insane and adopt another API, the subproject could
be cancelled. 

And the ASF Chairman has alluded to doing just that with Ant. But that's
another problem. 

I would imagine that we would do the same with our library subproducts.
If the datasource team started building JDBC drivers, we'd have to ask
if they were still within scope, or whether we needed another subproduct
for that codebase.

-Ted.

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




Re: [POLL] Re: Code Sharing Concepts

2001-02-15 Thread Craig R. McClanahan

"Geir Magnusson Jr." wrote:

 Sam Ruby wrote:
 
  Geir Magnusson Jr. wrote:
  
   Call it 'Rupert'.
 
  Be careful, that name might stick. ;-)

 That would be fine - forward progress!  I guess the logo would be
 next...  :)

   I mean, with Tomcat 4, nothing really guarantees that you
   won't abandon Servlet 2.3 for the Wiggly Green Spec from
   Planet Mongo, but I trust that you will stick to your
   'mission'... :)
 
  The are *SOME* things that the PMC are ready, willing, and able to enforce
  immediately.  You just happened to pick one of them.

 Really?  How's that?  If all the developers decided to switch to the
 WGSfromPM, what could the PMC do?  I am not trying to be argumentative -
 I just thought that the PMC was well described as 'general oversight'
 with project-specific issues pushed down to the project participants.


IMHO, the PMC would certainly behave as Sam indicated, but they probably
wouldn't have to -- the ASF Board would undoubtedly say such a thing would be so
far out of scope that it wouldn't be "Tomcat" any more.


 If the tomcat developers, arguably some of the top-tier servlet
 infrastructure developers in the world, decided that the WGSfromPM was
 superior to Servlet 2.3 ?  Granted, Craig would be looking for a new
 employer, I think... :)


Yah, especially if WGSfromPM == .NET's APIs or something like that :-)


  Not to mention the fact that the likehood of a majority of Tomcat
  developers would be predisposed to consider such a thing is basically nil.

 And back to the issue, that is kinda my point : if you have a group of
 developers committed to producing a top quality db connection pool for
 general use, it's not clear that there is much one could do to enforce
 API stability in an external way that makes sense.  At some point, you
 have to trust someone involved with the project...


My personal preferences in this regard are fairly simple -- publish APIs (or use
existing ones where there are reasonable standards) that you promise reasonably
stable contracts for, and innovate on the implementation(s) inside those APIs.
When changes ultimately do occur, they should be designed to minimize the pain
of adapting (through techniques like providing convenience base classes that
most alternative implementations would have started from).

For a connection pool in particular, the relavant API (for my needs, at least)
is javax.sql.DataSource -- I want to be able to plug in *any* connection pool
that conforms to that interface and use it.  Turbine's pool (still) does not do
this -- and that makes perfect sense, because it existed before the DataSource
API was standardized.  Changing Turbine's pool to conform to this would break
the contracts for all existing Turbine apps that use it, which would not be a
Good Thing.

But in the mean time, without a wrapper around it  -- I'm about 75% done with
this, but unfortunately the wrapper will have to be bigger than the entire code
for the Struts connection pool :-( -- the Turbine connection pool is not useful
to me.  Whether it is in a shared repository or not makes no difference.


 geir

 
  - Sam Ruby
 


Craig



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




Re: Nightly builds

2001-02-15 Thread cmanolache

 Others can run builds with stable dependencies.  They are permitted, and
 even encouraged to do so using Gump.  The runs I have been making are to
 determine the impact of changes - something that I think that has not
 received enough attention, and so that's why I have been and will continue
 to focus the runs that I make on that.

That's a valid configuration, I'm not saying to drop it - I just want to
be sure that both "styles" are supported. My interest is in using gump for
tomcat3.x builds - maintaining the scripts for testing is enough effort,
if I can use gump for building I'll save time.

The tomcat nightly should include the latest tomcat and the stable
dependencies - whenever it'll be released, it can't depend on the
"latest" ant but on the "latest release".

 Since you gave the specific example of ant, I do not like the idea of
 ant-1.3 being released without some assessment of the impact of changes on
 other projects.  There was a change that would have gone into 1.3 that

True - I will probably start using/testing ant-1.3, since it'll probably
be released before tc3.3.

 Given the number of projects we have here, each project binding too closely
 to exactly one version of each of their prereqs means that someone who
 desires to compose a system out of these components is likely to run into

Assuming an change happens in ant-1.3 ( or ant-1.4 or 2.0 ), should
tomcat/xalan/etc  be updated to use the latest ant  or the stable ant ?

Yes, in theory all API/DTD changes should be backward compatible - but in
reality we are talking about projects that are in development mode, not
about "standard" APIs. And if a project has a dependency on another
project, it is expected to track the changes ( and we did changed the
build.xml several times already ), but with certain granularity.
 
IMHO relaxing the requirement to "latest released version" is a very good
idea. Maybe when a project enters "feature freeze" or "beta" we can update
the builds and make sure all other projects work with the freezed
APIs/DTDs, and roll back/fix what is broken. 


 problems.  So, in fact, I would be greatly pleased if there were multiple
 nightly builds going on out there with different combinations.  And

A tomcat3.x nightly build will happen soon.


 Making ant build.xml files as a target of gump would be a valuable
 addition.  It has been often discussed, but never contributed.
 
 Getting using http as an alternative to cvs would also make a great
 addition.

My time is as limited as anyone else, but I'll try to do at least (1).
( if you remember the nightly builds of tomcat used to be ant-based 
and used to use get, so most of the code is there, it just need to be
geenralized to gump )

 P.S.  What does it mean to have gump "working", but not
 "updating/building"?

It means: spell error, I meant "is no_w_ updating" (instead of "not").

Costin




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




Re: [POLL] Re: Code Sharing Concepts

2001-02-15 Thread Morgan Delagrange


--- "Craig R. McClanahan"
[EMAIL PROTECTED] wrote:
 "Geir Magnusson Jr." wrote:

[snip]

  And back to the issue, that is kinda my point : if
 you have a group of
  developers committed to producing a top quality db
 connection pool for
  general use, it's not clear that there is much one
 could do to enforce
  API stability in an external way that makes sense.
  At some point, you
  have to trust someone involved with the project...
 
 
 My personal preferences in this regard are fairly
 simple -- publish APIs (or use
 existing ones where there are reasonable standards)
 that you promise reasonably
 stable contracts for, and innovate on the
 implementation(s) inside those APIs.
 When changes ultimately do occur, they should be
 designed to minimize the pain
 of adapting (through techniques like providing
 convenience base classes that
 most alternative implementations would have started
 from).
 
 For a connection pool in particular, the relavant
 API (for my needs, at least)
 is javax.sql.DataSource -- I want to be able to plug
 in *any* connection pool
 that conforms to that interface and use it. 
 Turbine's pool (still) does not do
 this -- and that makes perfect sense, because it
 existed before the DataSource
 API was standardized.  Changing Turbine's pool to
 conform to this would break
 the contracts for all existing Turbine apps that use
 it, which would not be a
 Good Thing.
 
 But in the mean time, without a wrapper around it 
 -- I'm about 75% done with
 this, but unfortunately the wrapper will have to be
 bigger than the entire code
 for the Struts connection pool :-( -- the Turbine
 connection pool is not useful
 to me.  Whether it is in a shared repository or not
 makes no difference.

Supporting DataSources seems like a prerequisite of a
current database-pooling mechanism, but it would be
very useful to also support a pooling pseudo-driver. 
Otherwise, DriverManager-based clients to the database
pool (which may even include non-Jakarta projects)
will be required to reach into their code to use the
pool.  Pseudo-drivers are a very elegant way to
prevent that.

=
Morgan Delagrange
Britannica.com

__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

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




CVS repository problems

2001-02-15 Thread Tim O'Brien

Has anyone noticed any problems accessing the CVS repository?  

It has been taking 1+ hours to update "jakarta-ant".  ( Choosing ant as an
example ).

Tim



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




Re: [POLL] Re: Code Sharing Concepts

2001-02-15 Thread Craig R. McClanahan

Jon Stevens wrote:

 on 2/15/01 2:19 PM, "Craig R. McClanahan" [EMAIL PROTECTED]
 wrote:

  Turbine's pool (still) does not do
  this -- and that makes perfect sense, because it existed before the DataSource
  API was standardized.  Changing Turbine's pool to conform to this would break
  the contracts for all existing Turbine apps that use it, which would not be a
  Good Thing.

 I'm not sure that statement is true because...I have implemented all of the
 JDBC 2.0 API for Turbine except that single one. It didn't break any
 existing code to do so (except in one case where you now need to deal with a
 SQLException that is now being thrown in the API and wasn't before...not a
 big deal).


The one you haven't gotten to yet is the critical one that makes application code
portable.  You will find that it is quite a bit more significant a change to
existing APIs than the ones you did.

The typical application usage pattern of a DataSource goes like this:

// Acquire a reference to the pool (typically from a JNDI
// context provided by the app server, or a servlet context
// attribute)
javax.sql.DataSource ds = ... acquire a reference ...

// Acquire a connection from the pool
javax.sql.Connection conn = ds.getConnection();

// Do your thing with the returned connection
Statement stmt = conn.createStatement("...");
stmt.execute();

// Return the connection to the pool
conn.close();

Note this last -- as far as the application is concerned, they are closing a JDBC
connection, but since the "Connection" was really provided by the pool, the
underlying real connection is *not* closed; it is simply returned to the pool.

Making org.apache.turbine.util.db.pool work like this (i.e. implement
java.sql.Connection) is certainly possible, but breaks the existing contract for
what DBConnection.close() does, among others.  If that is OK, you're pretty much
reingineering the whole thing.  If not, wrappers are the way to go.


 I didn't realize that I also needed to implement the DataSource interface,
 now that I do, I will go make it happen.

 At that point, will you use it Craig?


I will certainly document it as an available option -- assuming that the changes
were complete, using this connection pool in a Struts app would be as simple as the
following in the app config file:

struts-config
...
data-sources
data-source type="org.apache.turbine.util.db.pool.ConnectionPool"
loginTimeout="30"
driver="org.postgresql.Driver"
maxCount="4"
url="jdbc:postgresql://localhost/mydatabase"
username="myusername"
password="mypassword"
/
/data-sources
...
/struts-config

(assuming a few more property setters on ConnectionPool to set the rest of the
configuration properties).

However, I would not recommend it ... the turbine-pool.jar file drags along ~40
classes of Turbine infrastructure that aren't useful unless you are running inside
Turbine.

Of course, no third part connection pool at all is needed if your app server
provides one for you.  And, as long as the server obeys the conventions described in
the servlet and J2EE specs w.r.t. resource-ref entries and the corresponding JNDI
context provided by the server (which is in the near-term plans for Tomcat 4 as
well, with plug-in of any conforming data source), the app doesn't care.  It's
portable, instead of locked in to a particular implementation.


 I doubt it because you are so head strong in re-inventing everything that
 Turbine has done.

 I guess my main point here is that I really think it is messed up to simply
 say that you won't use something because it doesn't implement some Sun
 interface.

 The fact of the matter here is that in this case, you NEED an implementation
 of a database pool regardless of what interface that it implements. By
 saying that you would like to plug other pools into the back end is a
 separate issue entirely.

 On top of it, it took me all of 30 minutes to implement the majority of the
 interfaces in Turbine's pool. You are a better engineer than I (remember,
 according to some people, I only write crappy spaghetti code)...so I bet you
 could have done it in 15 minutes.


It's actually been quite a few more hours than that writing the wrappers for you so
far.  But, if you're going to do it, I won't bother to finish.


 p.s. I spent some time reviewing Struts recently and it is absolutely
 hilarious how much of it clearly has been "borrowed" from Turbine...all the
 way down to the idea of "Actions" for the C portion of MVC. Struts is
 clearly Craig's refusal to work with the Turbine project which is clearly
 contrary to what he had originally stated when he proposed the project.


Turbine is a fine project, with a good group of developers and a solid base of
functionality.  That's not my problem.

I just don't want to work with you (and the 

Re: [POLL] Re: Code Sharing Concepts

2001-02-15 Thread Jon Stevens

on 2/15/01 3:24 PM, "Craig R. McClanahan" [EMAIL PROTECTED]
wrote:

 However, I would not recommend it ... the turbine-pool.jar file drags along
 ~40 classes of Turbine infrastructure that aren't useful unless you are
 running inside Turbine.

What *exactly* is the problem with that?

 Of course, no third part connection pool at all is needed if your app server
 provides one for you.  And, as long as the server obeys the conventions
 described in the servlet and J2EE specs w.r.t. resource-ref entries and the
 corresponding JNDI context provided by the server (which is in the near-term
 plans for Tomcat 4 as well, with plug-in of any conforming data source), the
 app doesn't care.  It's portable, instead of locked in to a particular
 implementation.

Point being...where is Tomcat going to get its implementation of a
connection pool from? Are you going to re-implement Struts pool again? :-)

-jon

-- 
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
http://jakarta.apache.org/velocity/  http://java.apache.org/turbine/


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




Re: [POLL] Re: Code Sharing Concepts

2001-02-15 Thread Sam Ruby

Craig R. McClanahan wrote:

 I just don't want to work with you (and the attitudes you carry)
 on Turbine.

Hmmm.

As release manager of Tomcat 4.0, you appear quite willing to ship code
that he (and the attitudes that he carries) has committed to that cvs tree.

But code that the same person commits to a different cvs tree is somehow
not something you want to work with?

What will your reaction be if Ted and others are successful in creating a
library subproject, and seed it with code of mixed heritage from various
subprojects?

- Sam Ruby


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




Re: [POLL] Re: Code Sharing Concepts

2001-02-15 Thread Sam Ruby

Ted Husted wrote:

 may we please have a interim Jakarta "libary" mailing
 list for the purpose of formaling the details of a
 proposal for this subproject.

Are you sure that you want to call it that.  ;-)

Beyond the typo...the name of the mailing list should match the name of the
subproject.  I'm willing to create the mailing list in anticipation of the
project being created, but it like to be sure that the name is what
everybody wants.

Once that is settled, I'd gladly create a mailing list in anticipation of a
subproject being formed, and add any initial subscribers you provide.

 If an area of the Website were also available, we'd be
 happy to have that as well ;-)

... looking down the road, you'd put this in the same cvs tree as your
source.  Meanwhile, you (personally) already have update access to
jakarta-site, so I'm not really sure what you are asking for here.

- Sam Ruby


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




Re: [POLL] Re: Code Sharing Concepts

2001-02-15 Thread Craig R. McClanahan

Sam Ruby wrote:

 Craig R. McClanahan wrote:
 
  I just don't want to work with you (and the attitudes you carry)
  on Turbine.

 Hmmm.

 As release manager of Tomcat 4.0, you appear quite willing to ship code
 that he (and the attitudes that he carries) has committed to that cvs tree.


You might want to count the "jakarta-tomcat-4.0" commits from Jon (they fit on
one hand :-), but that is not your point.


 But code that the same person commits to a different cvs tree is somehow
 not something you want to work with?


Primary difference is that Turbine is a project growing out of Jon's dreams and
drives.  The success he's had building that is a testament to the fact that
he's pretty good at community building.

But that is not a community that I care to participate in.  The stated goals
(and, somewhat more importantly, the clear "non-goals") don't scratch my itch
for an application framework that plays nice with J2EE APIs.

Turbine preceeded the vast majority of these APIs coming into existence, so its
no surprise that conforming to them hasn't been a big concern.


 What will your reaction be if Ted and others are successful in creating a
 library subproject, and seed it with code of mixed heritage from various
 subprojects?


Not a problem, per my previous vote (assuming the process issues are dealt with
on how decisions about code contributions and backwards compatibility are
addressed).

I don't even care what connection pool implementation(s) are made part of it,
as long as it implements interfaces I care about.  But that is not the same
thing as trying to go tell another project they should change all their APIs to
meet *my* needs.  To say nothing of the "my way or the highway" attitude that
is so prevalent (what happened to competing codebases and "may the best
implementation win"?).

Personally, I get my satisfaction from open source participation in writing
code that people find useful, rather than the somewhat more "political" aspects
of community building. I don't have any time for personal diatribes, attacks on
my motives, complaints about my employer, or any of the rest of it.

You'll have to excuse me now ... I need to go back to work on getting around
the *()*() package sealing violations that are affecting any apps that try to
use Xerces under WEB-INF/lib in Tomcat 4.0 (including Turbine and Cocoon) ...


 - Sam Ruby


Craig



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




Re: [POLL] Re: Code Sharing Concepts

2001-02-15 Thread cmanolache

 Ted Husted wrote:
 
  may we please have a interim Jakarta "libary" mailing
  list for the purpose of formaling the details of a
  proposal for this subproject.
 
 Are you sure that you want to call it that.  ;-)
 
 Beyond the typo...the name of the mailing list should match the name of the
 subproject.  I'm willing to create the mailing list in anticipation of the
 project being created, but it like to be sure that the name is what
 everybody wants.

Well, if it's a library - why not calling it "alexandria" - it would be a 
nice name for that :-) 

Ops, the name is taken - but maybe we can re-use it - after all alexandria
is already a project that is shared by all other projects ( since it
contains tools that put togheter everything, etc).

Seriously speaking - I am very concerned with the content of the library -
I have a feeling that some people would like one book for each subject. I
think that would be a very big step backwards.

My hope is that the "library" project will be organized in a way that
allows multiple "books" in each collection.  

Costin



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