On May 14, 2007, at 5:49 PM, Rony G. Flatscher (Apache) wrote:
Hi Curt,
Seems like it may have already out-grown the labs phase. You
apparently have a functioning code base and maybe the start of a
community and applying to the incubator might be the appropriate
action. Completing a Podling Proposal would be helpful to identify
any issues.
Sorry, not being a native English speaker and not finding a
translation,
may I just ask you what a "Podling Proposal" would be?
A proposal for an incubator project (also known as a podling). A
guide to proposal creation is available at http://
incubator.apache.org/guides/proposal.html and an example is available
at http://maven.apache.org/proposals/incubator/nmaven.html. You
should also be familiar with the exit criteria for the incubator as
described in http://incubator.apache.org/incubation/
Incubation_Policy.html#Minimum+Exit+Requirements.
Seems like ooRexx has a established legal and development
framework in
which you are a significant participant. Is there a reason that
Apache would be a better home for log4r?
Well, seeing that commons is going TLP and possibly removing its
ties to
Java, I thought it might be a good idea to have comparable
implementations to the log4j architecture put untder the commons
umbrella. OTOH, it would be possible and feasible to submit the
current
implentation to the opensource ooRexx project's incubator.
If you think that it would be better for the project to submit it
to the
ooRexx projec (and maybe have a link or infos about an ooRexx
implementation of the log4j architecture), I would do so. (If done so,
would you think that the term "log4r" would be still confusing with
the
Ruby implementation?)
I think that you should avoid the name log4r regardless of the
ultimate home for the framework.
Logging Services would be most appropriate ultimate home for log4r
within Apache. I don't know ooRexx community at all, so I can't
judge your other options. Here are the pros and cons with hosting
the project at Apache:
Pros:
1. Established community and customs
2. Potential cross-pollination with log4j, log4cxx and log4net
3. Apache license
Cons:
1. Unable to formally release until graduation from incubator
2. Incubator exit criteria of 3 independent committers may be hard to
achieve and maintain
3. No established ooRexx community (as far as I know)
On a technical side, it appears that you were involved in the
development of an ooRexx/Java bridge as part of Apache BSF. Does the
use of log4r resemble the use of log4j over the bridge?
No, log4r as it stands now is a stand-alone, pure ooRexx
implementation.
It would be feasible in general, however, to take advantage of log4j
itself using the ooRexx bridge for Apache BSF (but that is a totally
different use-case making ooRexx dependent on Java, which nowadays -
practically every computer has a JRE installed - may not be a
hindering
stone anymore).
I was not suggesting implementing log4r in Java. The design goal in
all the log4X frameworks has been to minimize the cost of logging
when disabled to the absolute minimum, ideally as little as an
integer compare. Switching between languages is usually much more
expensive.
What I was suggesting is that you know what the syntax would be for
calling log4j over the ooRexx-Java bridge and consider that your
users might want to be able to migrate from log4r to log4j over the
bridge if they need a feature not in log4r or if they are running
within the context that is already using log4j.
