RE: Scarab (was RE: [ANN] in-house mail archive...)

[Waldhoff, Rodney]

> on 5/3/02 12:38 PM, "Waldhoff, Rodney" <[EMAIL PROTECTED]> wrote:
> > I don't have anything against Scarab (in fact I may even prefer it), and
> > I've no particular love for BugZilla (in fact I don't especially like
it),
> > but out of curiosity, how is this sort of thing decided?  I've seen no
> > mention of this switch up to this point.  Is there a list I should be on
to
> > see this sort of thing coming?
>
> In Scarab's case it is a trial for the Turbine projects and was decided on
> those lists.

OK, but that's not what it says:

"Scarab is an alternative Issue Tracking System and it will shortly replace
the current BugZilla installation."

That sounds both pretty broad and pretty final.

- Rod

> -jon

Scarab (was RE: [ANN] in-house mail archive...)

[Waldhoff, Rodney]

At http://nagoya.apache.org/ I now see:

> The BugZilla Bug Tracking System
>  BugZilla is the Bug Tracking System currently used by most Apache
projects. 
> The Scarab Issue Tracking System
>  Scarab is an alternative Issue Tracking System and it will shortly
replace the current BugZilla installation. 

I don't have anything against Scarab (in fact I may even prefer it), and
I've no particular love for BugZilla (in fact I don't especially like it),
but out of curiosity, how is this sort of thing decided?  I've seen no
mention of this switch up to this point.  Is there a list I should be on to
see this sort of thing coming?

By the way, there's a typo on that page:

"Those pages are prudly served by the Apache HTTP Server version 2.0 and
Apache Tomcat 4.0."
 ^^

RE: Database Subproject Discussion : creation of DBCommons ?

[Waldhoff, Rodney]

Henri Yandell wrote:

> +1 on Jakarta.OJB.
> -1 on Jakarta.DB-Commons unless otherwise convinced.
> -1 on db.apache.org, unless people start offering bribes.

I agree with all that.  Let's let something like jakarta-db[commons] or
db.apache.org evolve naturally.  Start small and let it grow.  

It seems like anything we might consider db-* appropriate would fit in
either as a top-level or as part of an existing sub-project right now.  

I think we'd be better off with more projects following Cactus's
trajectory--start as an in-scope part of some existing project and let it
*grow* into a top level project.  I'd rather have a couple of slightly
misplaced projects incubating (for example, Latka in Commons or Maven in
Turbine), then a bunch of grand plans later abandoned (I'll leave examples
of that up to the reader).

On a related note, I don't see a clear scope for db-commons right now. DB
related? What about Struts? Turbine (not just torque)? Avalon? Isn't db-tags
more about jsp/taglibs than databases (and more to the point, will share
more code with, and change at the same rate as other jsp/taglib projects?)
Do non-RDBMS systems count? Someone mentioned Axion. That's a fully fledged
database. Does it fit or should it be a project unto itself?

If we're wrong about db.apache or jakarta-db-commons, we're left with some
silly (and confusing) organizational artifacts.  If we're right, we'll be
just as right if we decide to pull together the "generic" db projects out of
various top-level and sub-top-level projects (whatever those might be) when
it becomes clear what that project's role would be. 

- Rod

RE: Database Subproject Discussion : creation of DBCommons ?

[Waldhoff, Rodney]

You mean this?

> [jakarta-commons] shall create and maintain packages written 
> in the Java language, intended for use in server-related 
> development, and designed to be used independently of any 
   
> larger product or framework. 
  ^^^

That seems like a pretty straightforward requirement.  It doesn't really
speak to the dependencies, but rather to use: I could have, for example, a
commons component that depends upon Struts or Turbine, it seems to me, as
long as the are usable outside of Struts or Turbine.  Otherwise it's pretty
silly to put it in commons.

For a concrete example, in theory one could create an implementation of
commons-pool that uses the avalon-excalibur pool implementation.  The
commons-pool interface, and generic implementations of it, remains usable
outside of avalon/excalibur. Only if I want to use that particular pool
implementation do I need to bundle avalaon-exaclibur with my client code.

 - Rod

-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 03, 2002 8:27 AM
To: Jakarta General List
Subject: Re: Database Subproject Discussion : creation of DBCommons ?


On 5/3/02 8:24 AM, "Waldhoff, Rodney" <[EMAIL PROTECTED]> wrote:

> Berin wrote:
> 
>> There are some things we have in Excalibur that we *can't*
>> donate to Commons because the charter does not allow it
>> (I think its something about the project can't rely on
>> non-commons projects or something).
> 
> What gives you that idea?  Many if not most commons projects rely upon
> non-commons projects (check out the gump descriptors).  There's no mention
> of anything like this in the commons charter
> (http://jakarta.apache.org/commons/charter.html).  I'm pretty confident
that
> no proposed commons component has been rejected because of its
dependencies
> on non-commons projects.

I think he was referring to the idea that the commons component should be
'mostly independent' ("He's mostly dead"), relying only upon common
platforms.

Having subproject specific bits (like Struts-only or Turbine-only) is
contrary to some of the non-binding guidelines we came up with in the
beginning.  The whole idea was to bring "productizable" things *out* of the
subprojects...

It also keeps things on an even keel, tribe-wise :)

-- 
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
[EMAIL PROTECTED]
+1-203-247-1713

RE: Database Subproject Discussion : creation of DBCommons ?

[Waldhoff, Rodney]

Berin wrote:

> There are some things we have in Excalibur that we *can't* 
> donate to Commons because the charter does not allow it 
> (I think its something about the project can't rely on 
> non-commons projects or something).

What gives you that idea?  Many if not most commons projects rely upon
non-commons projects (check out the gump descriptors).  There's no mention
of anything like this in the commons charter
(http://jakarta.apache.org/commons/charter.html).  I'm pretty confident that
no proposed commons component has been rejected because of its dependencies
on non-commons projects.

RE: Comments on the commons-logging API

[Waldhoff, Rodney]

I'm quoting Ceki's entire message here because I think he raises a number of
interesting and valid points.

But I think this misinterprets what (in my mind) is the main point of
commons-logging.

One can use commons-logging, as you state, as a implementation-independent
logging wrapper in hopes of reducing the cost of  switching between log4j
and JDK 1.4 (or logkit or whatever else comes along). But as you say, for
some changes the switching cost is already quite low.  (It's not clear to me
that the switching cost between, say, logkit and log4j is similarly low, but
maybe it is, I really don't know.)

But this isn't really the reason commons-logging was created.  Note that
most of the commons components are just that--tiny libraries meant to be
integrated/incorporated into larger frameworks and larger applications.
Some of these components need/want logging capabilities, or at least some
people need/want some components to have logging capabilities.  But it seems
a obtrusive for some tiny library to dictate the logging framework (if any)
that should be used by the larger application that contains it.  So the
component is stuck with a decision between not using logging at all, or
forcing some "standard" logging implementation upon the larger framework,
and the containing application is stuck with either converting everything to
this "standard" logging implementation (and hoping that each component
agrees on what that is) or having a heterogeneous set of logs and logging
implementations.  Search-and-replace code switching isn't really an option
for the commons components, or at least not a terribly good one.

Commons-Logging is meant to provide an alternative solution: create a
facade/adapter around an arbitrary logging API, use it at the common
component level, and allow the user (the containing application) to select
which specific logging implementation (if any) to use.  Then the same binary
works everywhere, and in many (most?) cases, the commons-logging will just
quietly do what you hope it would. (If you've got log4j, it uses it. If
you've got JDK 1.4, it uses that. If all else fails, it doesn't do
anything.)

An arbitrary application or system shouldn't feel compelled nor even
(necessarily) encouraged to use commons-logging. That's not what it's there
for.  It's there to allow the library components to delegate that decision
to the containing application.

 - Rod

-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 26, 2002 10:11 PM
To: [EMAIL PROTECTED]
Subject: Comments on the commons-logging API



Hello all,

Given that log4j is such a low-level library, most organizations are
suspicious to tie their code to log4j, especially considering the new
logging API in JDK 1.4.

Before going forward, it is appropriate to mention that these two APIs
are very similar.  The classical usage pattern for log4j is:

---

import org.apache.log4j.Logger;

public class MyClass {
   final static Logger logger = Logger.getLogger("some.name");

public void foo1() {
  logger.debug("Hello world.");
}

public void foo2() {
  logger.info("Another message.");
  logger.error("Stop that!", new Exception("The earth is getting 
warmer."));
}
}
---

As you are well aware by now, one of the important benefits of log4j
is that it can be configured at run time using configuration scripts.
You can have hundreds or thousands of log statement but only one or
two lines of code to configure log4j.

The usage pattern for the JDK 1.4 logging API is:

---
import java.util.logging.Logger;

public class MyClass {
final static Logger logger = Logger.getLogger("test");

public void foo1() {
  logger.debug("Hello world.");
}

public void foo2() {
  logger.info("Another message.");
  logger.error("Stop that!", new Exception("The earth is getting 
warmer."));
}
}
---

Do you notice anything similar? The JDK 1.4 logging API also admits
configuration scripts. Being part of the JDK, the common guess that
this API will supplant log4j some time in the future.

It is not so easy to write a complete logging API. Users
come to realize they need the features present in log4j but absent in
JDK 1.4 logging API.  Moreover, log4j runs with JDK 1.1 or later whereas
the JDK 1.4 logging API, requires, well, JDK 1.4.  Most users can't
afford to tie their code to JDK 1.4.

But they need logging and they need it now. A common strategy for
protecting against future changes and at the same time to benefit from
existing log4j features is to *wrap* log4j with a custom logging
API. Log4j actually has support to facilitate such wrappers.

It turns out that such wrappers are not that trivial to write. I frequently
receive email where a u

RE: Jakarta Overview

[Waldhoff, Rodney]

Well said Andrew.

Re. Chris's point, I think we'll be hard pressed to reach consensus on what
a project "maturity" means, let alone how to measure it.

If I were building this document (and if I remember correctly, I built this
document: http://jakarta.apache.org/commons/components.html, which is rather
similiar in some respects), I'd stick to factual information--brief
description, release dates/numbers, etc. and let the facts speak for
themselves.  

-Original Message-
From: Andrew C. Oliver
To: Jakarta General List
Sent: 3/20/2002 6:27 AM
Subject: RE: Jakarta Overview

Perhaps you could become a Jakarta developer by altering the provided
overview so that it is both useful to users and acceptable to the
developers of the projects it covers.  I should say a subjective
(mature/immature/good/bad) information might be useful, but probably is
more the area of a Jakarta "fan-site" ;-) then the Jakarta site itself. 
Furthermore, just a personal opinion, Documentation is an area I truly
want to help improve at Jakarta as a whole.  But, one thing I've noticed
is that it is much easier to contribute documentation at the project
level and work your way up then vice versa.  I like the overview myself,
its a clear and gives folks an easier way to find what they need.  I yet
understand the concerns about keeping it up to date and the likes.  


My suggestion is though is too fold.  General tends to give new
contributers who read the literature about community and the likes a
trial by incident, a series of "-1 no I don't like it!" and depend upon
the contributer to climb the mountain.  Rough for a first timer. 
Perhaps trying to be a bit more positive and saying "good but have you
considered" instead of the more traditional approach. ;-)  Secondly, to
the contributer of said documentation and future contributers.  While
end to end documentation is seriously lacking, I suggest contributing to
the in developing Jakarta Manual and furthermore the lower level project
documentation first.  Try not to include too much subjective information
(cause for debate) and don't take it personally ;-) or anything anywhere
at anytime too seriously.  (air raids and the likes excluded)

-Andy



On Wed, 2002-03-20 at 05:35, Chris Pheby wrote:
> I have to disagree! Speaking as a /user/ it is really hard to find
projects
> on Jakarta, and how the various projects relate to each other. I have
spent
> many weeks doing this and still haven't even scraped the iceberg.
Which I
> think is a shame. Some clear exposition would really help.
> 
> I have heard on this list that the Jakarta project is developer
centric, and
> the site is hard to penetrate if you are not a Jakarta developer. I am
sure
> this is not by design, but that is my perception as well. Any
suggestion
> that helps improve this situation such as Philipp's I would hope has
serious
> consideration - even if it presents new challenges that need to be
resolved.
> 
> As to deciding such things as how to assess the maturity of the
project, how
> about taking measures such as:
> 
> a) polls/votes of users
> b) number of downloads
> c) release number
> 
> I'm sure there are other possibilities...
> 
> 
> Chris.
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On
> Behalf Of Ceki Gulcu
> Sent: 20 March 2002 10:27
> To: Jakarta General List
> Subject: Re: Jakarta Overview
> 
> 
> 
> Isn't the "overview" document trying to substitute itself for the
> documentation that
> is already in subprojects (or should be)?  The cornerstone of the
Jakarta
> and
> Apache Software Foundation in general is that "management"  delegates
> responsibility for a given subproject to each subproject, intervening
> as little as possible.
> 
> Your introduction also raises further worries. Jakarta does not need
> more publicity. Everybody knows Jakarta. What is needed is improving
> the quality of each *subproject*. Marketing gimmicks are not helpful
and
> just
> waste precious time.
> 
> More importantly, who is to decide what project has what maturity? I
find
> the "overview" document a little too interventionist, perhaps less in
> content
> than in sprit. Until these concerns are addressed, here is my -1.
> 
> At 16:36 18.03.2002 -0800, you wrote:
> 

RE: Re: Jakarta Overview

[Waldhoff, Rodney]

I'm -1 until someone can clarify how/why this is different from the "Jakarta
Subprojects" section of the home page.

Why not just add status information to that listing, if that's where the
value-add is?  How many places do we expect developers to update/document
the status of their projects?

-Original Message-
From: acoliver [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 19, 2002 11:16 AM
To: [EMAIL PROTECTED]
Subject: Re: Re: Jakarta Overview


+1 - I'd like to see the detractors patch it as they see fit.

>On Tue, 19 Mar 2002 08:56:31 -0800 Daniel Rall <[EMAIL PROTECTED]>
wrote.
>Ted Husted <[EMAIL PROTECTED]> writes:
>
>> http://jakarta.apache.org/site/news.html#0319
>>
>> Thank you for your contribution. 
>
>I would be in favor of having the overview linked off of the "About
>Jakarta" section of the left nav.
>
>Index: project.xml
>===
>RCS file: /home/cvs/jakarta-site2/xdocs/stylesheets/project.xml,v
>retrieving revision 1.28
>diff -u -u -r1.28 project.xml
>--- project.xml17 Mar 2002 11:20:42 -  1.28
>project.xml19 Mar 2002 16:55:55 -
>@@ -17,6  17,7 @@
> 
> 
> 
> 
> 
> 
> 
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Jakarta Overview

[Waldhoff, Rodney]

The concept of this document is perhaps a good one, but can you clarify how
its role is distinct from the "Jakarta Subprojects" section of the homepage?

Also, I take a bit of exception to the "Documentation: None" classification
on commons-pool and commons-dbcp.  The documentation is minimal, no doubt,
and likely insufficient, but "none" suggests there's no need to keep looking
for it, while if you do, you'll find fairly extensive JavaDocs:

*
http://nagoya.apache.org/gump/javadoc/jakarta-commons/pool/dist/docs/api/ind
ex.html
*
http://nagoya.apache.org/gump/javadoc/jakarta-commons/dbcp/dist/docs/api/ind
ex.html

as well as some additional documentation for each:

* http://cvs.apache.org/viewcvs/jakarta-commons/dbcp/doc/
* http://cvs.apache.org/viewcvs/jakarta-commons/pool/xdocs/


And I'll reiterate dion's comment: 

> Documentation: Overview, Javadoc, and XML syntax reference, 

That seems pretty exhaustive for what Latka does.

RE: Jakarta Overview

[Waldhoff, Rodney]

In order to avoid duplicate edits, can we just point the "Commons" section
of this document to: 
  http://jakarta.apache.org/commons/components.html

-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 19, 2002 4:49 AM
To: Jakarta General List
Subject: Re: Jakarta Overview



http://jakarta.apache.org/site/news.html#0319

Thank you for your contribution. 

-Ted.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Base64 anywhere ?

[Waldhoff, Rodney]

> There is also one in Batik, JXTA, Catalina, Apache SOAP, 
> Apache Xerces, Axis, Commons, Talon and Freenet.

Also Slide, Commons-HttpClient, etc.  Moreover many of them have some direct
cut-and-paste relationship.

For what it's worth, the commons-codec package
(http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/codec/) is intended
avoid having so many flavors or having to "grab" a Base64 implementation
from an otherwise unrelated framework or application.

PMC Nomination - Morgan Delagrange

[Waldhoff, Rodney]

I would like to nominate Morgan Delagrange for the PMC.  He's a founding
member of and an active participant in jakarta-commons, is the author of
some popular jakarta-taglibs tags, and has contributed a substantial amount
of code, documentation and organizational support to both projects.

RE: [OT] FW: Sun Headquarter Briefings: Developing Web Services

[Waldhoff, Rodney]

> I'm guessing it [web services] is fancy marketing foo about 
> SOAP/XML-RPC 

Correct. "Web Services" generally means SOAP/XML-RPC etc.

It's an important part of optimizing your value Chain when dealing with
everything from SMEs to large scale enterprises. ;)

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

Gump

[Waldhoff, Rodney]

Where can I find out more about Gump? Where can I get it?

I know I've seen these questions asked on more than one jakarta list, but I
don't remember seeing a satisfactory answer. (Maybe I just missed it.)

Short of http://jakarta.apache.org/gump/bench.png, I can't find anything on
the jakarta.apache.org or xml.apache.org sites, or in cvs on Gump.
(Actually, I vaguely remember something buried in Alexandria about it, but I
can't find it now.)

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