on 2/15/01 4:17 PM, Craig R. McClanahan at [EMAIL PROTECTED]
wrote:
> 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 the
on 2/15/01 11:56 AM, Craig R. McClanahan at [EMAIL PROTECTED]
wrote:
> 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 proc
"Craig R. McClanahan" wrote:
>
> "Geir Magnusson Jr." wrote:
>
> > [EMAIL PROTECTED] wrote:
> >
> > > If someone chooses to duplicate a piece of code, maybe the problem is with
> > > the way the code is written and shared.
> >
> > I think in some cases, its bacause people aren't aware that the s
Hear hear! I think that Taglibs is an excellent model
for a library-oriented subproject. Here are some
features of Taglibs (some overlap with Craig's
comments) that I think would translate quite well:
* individual landing pages for each taglib
(essentially sub-subprojects)
* standardize
"Geir Magnusson Jr." wrote:
> [EMAIL PROTECTED] wrote:
>
> > If someone chooses to duplicate a piece of code, maybe the problem is with
> > the way the code is written and shared.
>
> I think in some cases, its bacause people aren't aware that the stuff
> exists. Go through the Jakarta project s
[EMAIL PROTECTED] wrote:
>
> > > If someone chooses to duplicate a piece of code, maybe the problem is with
> > > the way the code is written and shared.
> >
> > I think in some cases, its bacause people aren't aware that the stuff
> > exists. Go through the Jakarta project sites, and find the n
> > If someone chooses to duplicate a piece of code, maybe the problem is with
> > the way the code is written and shared.
>
> I think in some cases, its bacause people aren't aware that the stuff
> exists. Go through the Jakarta project sites, and find the number of
> places that offer a separa
> > The project should _host_ and maintain code that is shared by projects,
> > not _develop_ utils that may be needed ( like CPAN, or alexandria ).
>
> How can that work in the current "project & committer" model? I agree
> that it should be open to accept projects from the 'outside', but I
>
"Geir Magnusson Jr." wrote:
> Jakarta is rich in general-use tools. We just need to get them out into
> the light of day, documented, and supported directly, not incidentally
> as part of larger projects.
I believe you and I are on the same page, Geir. Costin wants to go a
different way with thi
[EMAIL PROTECTED] wrote:
> If someone chooses to duplicate a piece of code, maybe the problem is with
> the way the code is written and shared.
I think in some cases, its bacause people aren't aware that the stuff
exists. Go through the Jakarta project sites, and find the number of
places that
[EMAIL PROTECTED] wrote:
>
> The project should _host_ and maintain code that is shared by projects,
> not _develop_ utils that may be needed ( like CPAN, or alexandria ).
How can that work in the current "project & committer" model? I agree
that it should be open to accept projects from the
> My own hope is that each component be treated like a book, with it's own
> publication date, edition count, and set of authors and editors.
And again - we'll act as librarians and make sure the book is available,
not as censors or authors of competing books.
> For this branch, we probably ne
> >My hope is that the "library" project will be organized in a way that
> >allows multiple "books" in each collection.
>
> I agree, it's important to allow different ideas to flower rather than impose
> a "one true way" philosophy. But I also think it's important to keep strong
> quality contr
Sam Ruby wrote:
> 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.
The name is one of the things we would discuss on the l
[EMAIL PROTECTED] wrote:
> 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 t
Craig R. McClanahan typed the following on 02:19 PM 2/15/2001 -0800
>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) insi
[EMAIL PROTECTED] typed the following on 04:17 PM 2/15/2001 -0800
>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"
> 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
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.
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
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 c
> on 2/15/01 3:24 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
> wrote:
> > 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. entries
and the
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 co
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
Jon Stevens wrote:
>
> 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
but you do spell 'spaghetti' correctly, so
> TESTING SUITES
+1
> SUBPROJECT INFRASTRUCTURE
Specifically Tinderbox/Gump
+1
Scott Sanders
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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 existi
--- "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
"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
"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
Ted Husted wrote:
>
> Sam Ruby wrote:
> > Whilst this group seems to have difficulty agreeing on anything ,
> > 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 wrote:
> Whilst this group seems to have difficulty agreeing on anything ,
> 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
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 W
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*
"Craig R. McClanahan" wrote:
>
> 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 do
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 ,
perhaps a proposa
Craig escribio:
> management rules that include:
> protection from arbitrary API changes.
* Representative vote: 1 project 1 vote.
Please to start discussing a management for a shared repository, add
whatever rules you thin
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
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.
--
"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 ne
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 I
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 depe
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 Re
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:
>
> * XML Configuration
+1
> * JNDI / Naming
+1
> TESTING SUITES
>
> [Ant] test
Ted Husted wrote:
> TESTING SUITES
+1
> SUBPROJECT INFRASTRUCTURE
[*] - Subproject infrastructure: website, documentation, sample
applications, test suites, quality assurance.
+1
For a running tally, see < http://husted.com/about/jakarta/library.html
>.
--
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
+1
> * XML Configuration
+1
geir
--
Geir Magnuss
* XML Configuration
+1
>From: "Rodney Waldhoff" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: <[EMAIL PROTECTED]>
>Subject: Re: [POLL] Re: Code Sharing Concepts
>Date: Mon, 12 Feb 2001 07:01:54 -0600
>
>FW: [POLL] Re: Code Sharing Conc
> * DataSource/Database Pool
+1
> * XML Configuration
+1
> * Message Resources / i18n
+1
> * JNDI / Naming
> * Testing Suites
Saludos ,
Ignacio J. Ortega
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands
FW: [POLL] Re: Code Sharing Concepts> If you are * actually * interested in
working on a Jakarta library
> product, and a library implementation of one of these subproducts is an
> itch you are ready to scratch, please indicate your commitment with a
> +1.
> * DataSource/Da
>
> * DataSource/Database Pool
> * XML Configuration
+1
> * Message Resources / i18n
+1
> * JNDI / Naming
> * Testing Suites
+1
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PR
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
* Message Resources / i18n
* JNDI / Naming
* Testing Suites
If you a
51 matches
Mail list logo
