On Wed, 14 Mar 2001, GOMEZ Henri wrote:
Still no response for this sub-project proposal.
A big +1
This will also reduce the pressure on making changes in the "stable" code.
If a bug is found in the connector - we can just make a new release of the
connector ( both sides ), without a need to
on 3/9/01 1:15 PM, "David Duddleston" [EMAIL PROTECTED] wrote:
Just another rant Even after a few years, it still bugs me that license
and copyright mark on each piece of Apache code is so darn long. Even a dog
knows it only takes a few drops to marks its territory.
-david
Tell that
At 12:40 10/3/01 -0500, Geir Magnusson Jr. wrote:
I have to side a little with Peter Donald on this, if you are serious about
achieving this goal, then it is better to work with an existing project
that
is attempting to achieve some of the same goals.
I would agree 100%, because of the
That could be - my problem when I went looking for things is that I
surmised that Avalon was some sort of framework, rather than a
collection of independent utilities. I got that idea because that is
what the avalon site says... Peter and others are aware that this is
often the
David Duddleston wrote:
Over the several years I have been lurking these forums, the topic of a
shared library of common classes has been discussed several times and a few
different attempts have been made to realize this goal, but all have either
failed or fallen sort. Avalon is probably
Hi Steve!
Steve Downey wrote:
Please, let us not start the great brace and indentation holy war here.
Nope sir, not my intention at all.
Also, if you want to reformat code, take a look at astyle, (sorry don't have
a URL handy) a syntax directed indent engine that converts between the
On Fri, 9 Mar 2001, Nael Mohammad wrote:
I for one would like to see mod_webapp
Same for me - the automatic configuration is great for most users.
Having this "common" project would be great because it'll allow the
development of a connector that combines the best features of mod_jk and
Ted Husted wrote:
Since I'm the lone wolf on this point:
snip
(3.1) mailing list(s)
jakarta-commons-general
jakarta-commons-DBCP (database connection pool)
jakarta-commons-sandbox (unreleased packages)
/snip
insert
(3.1) mailing list(s)
jakarta-commons
/insert
I think that I do
Hola a todos, Ted:
Since I'm the lone wolf on this point:
snip
(3.1) mailing list(s)
jakarta-commons-general
jakarta-commons-DBCP (database connection pool)
jakarta-commons-sandbox (unreleased packages)
/snip
insert
(3.1) mailing list(s)
jakarta-commons
/insert
+1
and how
From: "Ted Husted" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, March 08, 2001 10:57 PM
Subject: Re: [PROPOSAL] The Commons
+1 to all your changes
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
From: "Geir Magnusson Jr." [EMAIL PROTECTED]
I support the notion of standardization, but some of the Sun conventions
are just awful, particularly the bit about ending the method declaration
with a '{'
+1, but I fear it is too widely used in the Java world now :-(
Getting rid of the tabs
Geir Magnusson Jr. wrote:
Futher, I like starting blocks with a { a la
if( foo )
{
block
}
Blech. I guess it takes all kinds. ;-)
- Sam Ruby
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
Jon Wrote:
Additional: the issues surrounding logging and pluggable logging
implementations are not covered here. I think they have the same importance
as configuration. My vote is that we standardize on simply using Log4J and
its interfaces for *everything*.
+1
Two logging mechanisms is
1) There are religious battles over the hanging brace..
let's not start one here please. We can either follow the standard
or not, period... But the code should all look the same...
- on a side note, many people in my company have gone full circle
first fighting for the hanging
on 3/8/01 8:57 AM, "Ceki Glc" [EMAIL PROTECTED] wrote:
To summarize, I think that as an organization we should consider APIs on the
basis of their merit and their respective advantages/disadvantages. Saying
that we should adopt API XYZ just because it is Sun sponsored is not the
wisest way
Gunnar R|nning wrote:
"Geir Magnusson Jr." [EMAIL PROTECTED] writes:
The thing that started this, about the coding guidelines, was in
response to the addition of the Sun coding guidelines (rules...) - I was
just indicating my preference.
Of course, but it is important to be able
Ted Husted [EMAIL PROTECTED] wrote:
Conor MacNeill wrote:
I think it would be better to start with one mailing list so ensure
there is enough "mass" in discussions.
I feel strongly that there should be a combined user/dev list for
each package, and I personally stand by the statement in
Message -
From: "Ted Husted" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, March 07, 2001 11:57 PM
Subject: Re: [PROPOSAL] The Commons
Conor MacNeill wrote:
Ted,
Sounds good to me. I think it would be better to start with one mailing
list
so ensure there is en
At 09:21 7/3/01 -0500, Ted Husted wrote:
Peter Donald wrote:
I will say it again - though no one really seems to listen.
No one's asking you to do anything you don't want to do, Peter. If you
are not comfortable working on a Commons package, then you should not
work on a Commons package.
I
Say I'd propose to move the org.apache.tools.tar and
org.apache.tools.mail packages from Ant to the commons repository -
which I'll probably do - these are very small thingies that don't
really need separate mailing lists at all.
+1 !!
And maybe parts of ProjectHelper ( turned into a
on 3/7/01 5:08 AM, "Sam Ruby" [EMAIL PROTECTED] wrote:
Jon Stevens wrote:
7: Should provide an interface or implement a Sun defined interface.
s/Sun defined/standard/
- Sam Ruby
define standard.
http://jakarta.apache.org/velocity/ymtd/ymtd-implementation.html
-jon
--
If you come
on 3/7/01 5:21 AM, "Ted Husted" [EMAIL PROTECTED] wrote:
How about:
7. In general, packages should provide an interface and one or more
implementations of that interface, or implement another standard
interface (e.g. one defined by Sun).
-1
I don't like the implication that something
on 3/7/01 4:57 AM, "Ted Husted" [EMAIL PROTECTED] wrote:
I feel strongly that there should be a combined user/dev list for each
package, and I personally stand by the statement in the FAQ.
This will fail for new projects.
Reason: community building.
To create a community, you need a single
Peter,
On Thu, 8 Mar 2001, Peter Donald wrote:
I already work on commons packages - after all I work on Avalon ;)
Avalon is not a commons package, it is a "common framework for server
applications". Why does the framework need to contain code to accomplish
specific tasks?
What Ted
At 02:53 7/3/01 -0600, Tim O'Brien wrote:
Avalon is not a commons package, it is a "common framework for server
applications". Why does the framework need to contain code to accomplish
specific tasks?
The perception that it is solely a framework is wrong. Frameworks by
themselves are useless
Ted,
Sounds good to me. I think it would be better to start with one mailing list
so ensure there is enough "mass" in discussions. Also, I am a bit dubious
about the name "commons" (Don't know if there has been much discussion about
that). The concept of a Commons is often used as an example of
Nice initiative.
Sharing code is allways great and there are in jakarta
projects some fine pieces of code which could be used outside
their 'original' project.
A suggestion will be to ask all of you to do your best to
organize this subproject in many smaller sub-subprojects just
to avoid
The archive for the interim "library-dev" mailing list is at
mail-archive.com
There is also a page linking the working documents at
http://husted.com/about/jakarta/library.html .
My own preference is that it be called something simple and generic. (I
was good with library.)
Conor MacNeill
on 3/6/01 2:03 PM, "Ted Husted" [EMAIL PROTECTED] wrote:
Proposal for "The Commons" - A Jakarta Subproject
version 1.0 - 5 Mar 2001
(0) rationale
Apache-Java and Jakarta originally hosted product-based subprojects,
consisting of one major deliverable. The Java language however is
29 matches
Mail list logo
