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
"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 stuff
exists.
[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"
[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 that
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
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 control on
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 need
[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
[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
"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 this.
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
think
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 separate,
[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
"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 sites,
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)
*
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 /
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
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
"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
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.
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 -
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
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*
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
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
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. ;-)
"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
"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
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
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,
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
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.
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
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
* 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,
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 Magnusson Jr.
36 matches
Mail list logo
