PMC chair nominations?

2003-03-17 Thread Morgan Delagrange
Sam said that we should obtain nominations for chair
from people in the (potentially expanded) PMC ranks by
the 16th, followed by [a]n election where every
member of the PMC has one vote...to be completed on
the 18th.

Whoops, we're late.

Are we obligated to choose a chair this month.  I
don't think we have enought time left for a proper
vote.

- Morgan

=
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog

__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

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



Re: Current roster of the Jakarta PMC

2003-03-03 Thread Morgan Delagrange
+1

- Morgan

--- Sam Ruby [EMAIL PROTECTED] wrote:
snip/
 The next board meeting is the 19th.  My suggestion
 is that current PMC 
 members nominate individuals that they believe
 should be on the PMC by 
 the 9th, then we hold a vote on these nominees to be
 complete on the 12th.
 
 This is to be followed this up with nominations for
 chair from people in 
 the (potentially expanded) PMC ranks by the 16th.  
 An election where 
 every member of the PMC has one vote, will then
 commence, to be 
 completed on the 18th.
 
 If there are concerns about not wishing one's votes
 to be known, I can 
 ask the board for an independent set of participants
 to tally the votes.
 
 In any case, I can inform the board of the results
 (potentially jointly 
 with my intended successor) on the 19th.
 
 How does this sound?
 
 - Sam Ruby
 


=
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog

__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

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



Re: PMC Nomination

2003-02-19 Thread Morgan Delagrange

--- Jeffrey Dever [EMAIL PROTECTED] wrote:
 
 
 
  I am not excited by the idea of only PMC members
 voting on releases 
  to the exclusion of active committers.  I'm the
 release prime for 
  Commons HttpClient where all committers vote on
 all issues all the 
  time, including releases.  HttpClient is somewhat
 unusual in commons 
  as it is rather a large project with a dedicated
 mailing list and a 
  rich family where many, such as myself, are
 primarily focused on just 
  one project, HttpClient.
 
 
  The goal is to make all active committers PMC
 members.
 
 
 Then what, exactly, is the difference between a
 committer and a PMC 
 member?  
 
 I thought the goal was to have the release primes be
 the PMC members. 
  It is the Project Management Committee after all.

If the implication is that release management =
project management, I don't agree.  Typically there
can only be one release manager, but it's takes lots
of people to keep a project going.  Certainly every
release manager should forward themselves as PMC
nominees, but the body of qualified candidates is much
larger.

- Morgan

=
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog

__
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

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




Re: Licensing again.

2003-02-10 Thread Morgan Delagrange
No there are plenty of works derived from Apache
projects.  Apache code may be freely modified or
redistributed, but as per the Apache license:

  The end-user documentation included with 
  [redistributions of Apache code], if any, 
  must include the following acknowlegement: 
  This product includes software developed by the
  Apache Software Foundation 
  (http://www.apache.org/).  Alternately, this 
  acknowlegement may appear in the software itself, 
  if and wherever such third-party acknowlegements 
  normally appear.

The fact that Apache code has an owner (the ASF
membership) and a copyright does not exclude it from
having an open-source license.  In fact, if the code
did not have an owner, the license would be
exceedingly difficult to defend.

- Morgan

--- Timothy Halloran [EMAIL PROTECTED]
wrote:
 Does this mean the ASF has taken away the ability
 for others to do
 derived works (including derived works that make the
 code commercial or
 GPL -- with a simple name change)?  That would mean
 the license is no
 longer open source (by OSD anyway)?
 
 This is a strange discussion thread.
 
 On Mon, 2003-02-10 at 12:36, Pier Fumagalli wrote:
  On 10/2/03 4:05 Lawrence E. Rosen
 [EMAIL PROTECTED] wrote:
  
   It should be noted that Apache Software
 Foundation members
   are the legal
   *owners* of the software that is available
 under the Apache
   Software License.  Indeed, that is one of the
 key benefits to
   becoming an ASF member, as opposed to just a
 committer on one
   or more projects.  It seems perfectly
 reasonable that
   decisions on the license under which that
 software is
   licensed should be made by the people that own
 it.
   
   I'm curious.  What is the legal basis for this
 claim of ownership?
  
  The fact that each contributor, prior access to
 our CVS repository, signs a
  paper saying that for whatever goes in CVS, he
 assigns copyright and
  ownership of the code to the ASF... No more no
 less than what any random
  employee of a software company does with his
 employer...
  
  Pier
  
  
 

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

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


=
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

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




Re: Logging strategy

2003-01-29 Thread Morgan Delagrange

--- Ceki Gülcü [EMAIL PROTECTED] wrote:
 At 11:21 29.01.2003 +0100, Dani Estermann wrote:
 Has jakarta got a strategy/guideline/regulation
 that recommends a certain 
 logging api to be used by jakarta projects? Are
 existing and future 
 jakarta projects allowed to choose between log4j,
 LogKit, commons-logging 
 or even JDK1.4-Logging?
 
 We are currently choosing a logging api and
 implementation to be used 
 in  our business projects. While I favor the power
 of the log4j 
 implementation, I ask myself if it would be wise to
 use a -- maybe more 
 future-proof -- thin bridge like commons-logging on
 top.
 
 I believe log4j is here to stay. Its user base is
 large and
 growing. As time passes, more people will gravitate
 to it as it keeps
 improving. We have enough cool features in pipe to
 keep us busy for
 the foreseeable future. Simile, the future is bright
 and open!

I agree with Ceki, Log4j has a bright future indeed. 
If it were my project, I'd pick Log4J first, then the
Merlin logging (even if I were using JDK 1.4).  I
don't known too much about LogKit, but it's probably
fine as well.

Don't use commons-logging unless you're absolutely
sure you need it.  If you are distributing your code
to other companies, then you might have an argument
for a logging facade in order to plug into their
logging framework.  However, if your code is intended
for internal use only, using a facade is more work
with no benefit.

- Morgan

 Daniel
 
 --
 Ceki
 
 
 

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


=
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

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




Re: [PMC VOTE] PMC Nominations

2003-01-17 Thread Morgan Delagrange
Are the current PMC members automatically re-upped? 
And it sounds like there won't have to be a massive
all-committer election like last year, which I'm sure
will be a relief to Dirk.  ;)  

Sounds like Jakarta PMC membership will become more
like Apache membership; once you're in, you can stay
in as long as you remain active.

- Morgan

--- Sam Ruby [EMAIL PROTECTED] wrote:
 Reorging the Jakarta PMC apparently has become an
 annual event.  This
 year will be no different.  I've had lengthy talks
 with the Apache
 Board, and this has caused me to revisit a number of
 assumptions.
 
 Looking at http://httpd.apache.org/contributors/, it
 is clear that the
 ASF concept of a Project Management Committee
 permits a significantly
 larger number of PMC members per project than I, at
 least, had ever
 presumed.
 
 Given the success that Jakarta has had to date, I
 don't want to propose
 any rapid, irreversable, or disruptive changes.  But
 the goal should be
 clear: the PMC should consist of *all* the people
 who are actively and
 consistently monitoring the code.
 
 So for the first step, I'd like to nominate the
 following individuals
 who have contributed multiple times to the Jakarta
 newsletter and/or 
 recently served as a release manager of a Jakarta
 subproject:
 
[  ]  Nicola Ken Barozzi
[  ]  Stephen Colebourne
[  ]  Martin Cooper
[  ]  Henri Gomez
[  ]  John Keyes
[  ]  Larry Isaacs
[  ]  Otis Gospodnetic
[  ]  Thomas Mahler
[  ]  Remy Maucherat
[  ]  Glenn Nielsen
[  ]  Andrew C Oliver
[  ]  Rob Oxspring
[  ]  Martin Poeschl
[  ]  Scott Sanders
[  ]  David Sean Taylor
[  ]  Mladen Turk
[  ]  James Turner
[  ]  Henri Yandell
 
 Future steps will include introduction of a concept
 of an emeritus PMC
 member, reinstating prior PMC members who are still
 active, and more
 nominations (particularly those that chose to
 contribute to the
 newsletter, and/or act as release manager, hint,
 hint).
 
 Longer term, the plan is to move the subprojects
 that chose to remain in
 Jakarta towards becoming a single community - in
 particular release
 votes will become a responsibility of the PMC.  That
 does not mean that
 all PMC members will vote on all releases, but that
 it will be from this
 pool of members that release votes will be cast. 
 Clearly there will
 need to be a number waves of additions like the one
 above to the PMC
 before we get to this point.
 
 Meanwhile, my plan is to see to it that those
 subprojects that desire to
 become ASF projects will get the full cooperation
 and support of this PMC.
 
 Now for some fine print:
 
 * nominees may chose to decline without giving any
 reason
 
 * only current PMC member's votes are binding
 
 * once the vote completes, PMC membership is not
 effective until 48
 hours after a board member acknowledges receipt of
 these votes.
 
 Let the voting begin!
 
 - Sam Ruby
 
 P.S.  My vote is +1 on all.
 
 
 
 --
 To unsubscribe, e-mail:  
 mailto:[EMAIL PROTECTED]
 For additional commands, e-mail:
 mailto:[EMAIL PROTECTED]
 


=
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

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




Re: Jakarta member seeking ASF membership

2002-10-24 Thread Morgan Delagrange
 is
approved.  Especially for projects like Commons, which
clearly tie to existing communities.  Jakarta Commons
is a very active community and our charter was created
very deliberately; I think we would have had a lot to
offer to the discussion.  And I don't think that j-c
has a monopoly here; projects like Commons are
relevant to all committers. 

 - Shane
 Disclaimers: ASF Member; xml-xalan, xml-commons
 committer; IBM
 Employee; Massachusetts, USA resident; lover of bad
 puns and cats.
 
 =
 - Shane
 
 eof .sig='When I use a word,' Humpty Dumpty said, 
 in a very scornful tone, 'it means just what I 
 choose it to mean - neither more nor less'
 Oohayu oyod?!=gis. /
 
 __
 Do you Yahoo!?
 Y! Web Hosting - Let the expert host your web site
 http://webhosting.yahoo.com/
 
 --
 To unsubscribe, e-mail:  
 mailto:general-unsubscribe;jakarta.apache.org
 For additional commands, e-mail:
 mailto:general-help;jakarta.apache.org
 


=
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog

__
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/

--
To unsubscribe, e-mail:   mailto:general-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:general-help;jakarta.apache.org




Jakarta member seeking ASF membership

2002-10-23 Thread Morgan Delagrange
Hi all,

[from a previous thread on a previous list]

 Morgan Delagrange wrote:
 
  I don't know if I've yet achieved the status of a
  long-term [committer] who have earned the right
 to
  set Apache-wide policies [...]

However, there's no time like the present to find out.
 Roy Fielding has suggested that not enough Jakarta
members seek membership in the ASF.  Until recently, I
was quite happy plugging along in my little Jakarta
world, developing software and trusting the Apache
world to continue onward as it has.  

However, recent events have shown me that my view may
be too narrow.  One specific example (sorry if you
subscribe to the reorg list, as this is repetition of
threads there): a top-level Apache project with the
same name and similar scope as a Jakarta subproject
can be proposed, discussed and approved (including a
PMC) without ever being mentioned on a list to which I
can subscribe.  This week, a mailing list was formed
to try to alleviate some of these communication
deficiencies, but in the words of a former U.S.
president, trust, yet verify.

So my specific goal in seeking ASF membership is to
look inside the black box.  I already know that
important decisions can be made that are hidden from
the view of most committers.  I'd like to know more
about the process, and hopefully help to make these
decisions more open and transparent to committers at
large; at present a very small percentage of Jakarta
members are actually ASF members.  Likewise, I
encourage other Jakarta committers to consider seeking
ASF membership if they are also concerned about
representation and the decision-making process.  The
Board seems very interested in increasing our numbers
in the ASF membership, and I think we should take them
up on this opportunity.

Specifically, I'd like to ask a member of our PMC or
any current ASF member to sponsor my membership.,
Unfortunately I will probably not be able to attend
the next Foundation meeting, and so I'd also ask that
my sponsor act as my proxy, if possible.

If I understand this process correctly, if I am
nominated, I fill out an application form and it's
discussed on the private [EMAIL PROTECTED] mailing
list until a decision spits out.  I guess I won't be
gaining any insight into the admission process at
first.  :)

- Morgan

=
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog

__
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/

--
To unsubscribe, e-mail:   mailto:general-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:general-help;jakarta.apache.org




Re: Jakarta member seeking ASF membership

2002-10-23 Thread Morgan Delagrange
As far as I can tell, that's up to the ASF to decide
on a case-by-case basis.  So I suggest that if you
think your experince would make a valuable
contribution to the ASF, ask our PMC for sponsorship. 
The worst they can do is say no.

--- Henri Yandell [EMAIL PROTECTED] wrote:
 
 If we're expected to nominate ourselves as such,
 it'd be nice to have some
 guidelines as to what we should be looking at in our
 day-to-day Apache
 goings on to know that the time has come. So we
 don't look like young
 punks :)
 
 Hen
 
 
 On Wed, 23 Oct 2002, Morgan Delagrange wrote:
 
  Hi all,
 
  [from a previous thread on a previous list]
 
   Morgan Delagrange wrote:
  
I don't know if I've yet achieved the status
 of a
long-term [committer] who have earned the
 right
   to
set Apache-wide policies [...]
 
  However, there's no time like the present to find
 out.
   Roy Fielding has suggested that not enough
 Jakarta
  members seek membership in the ASF.  Until
 recently, I
  was quite happy plugging along in my little
 Jakarta
  world, developing software and trusting the Apache
  world to continue onward as it has.
 
  However, recent events have shown me that my view
 may
  be too narrow.  One specific example (sorry if you
  subscribe to the reorg list, as this is repetition
 of
  threads there): a top-level Apache project with
 the
  same name and similar scope as a Jakarta
 subproject
  can be proposed, discussed and approved (including
 a
  PMC) without ever being mentioned on a list to
 which I
  can subscribe.  This week, a mailing list was
 formed
  to try to alleviate some of these communication
  deficiencies, but in the words of a former U.S.
  president, trust, yet verify.
 
  So my specific goal in seeking ASF membership is
 to
  look inside the black box.  I already know that
  important decisions can be made that are hidden
 from
  the view of most committers.  I'd like to know
 more
  about the process, and hopefully help to make
 these
  decisions more open and transparent to committers
 at
  large; at present a very small percentage of
 Jakarta
  members are actually ASF members.  Likewise, I
  encourage other Jakarta committers to consider
 seeking
  ASF membership if they are also concerned about
  representation and the decision-making process. 
 The
  Board seems very interested in increasing our
 numbers
  in the ASF membership, and I think we should take
 them
  up on this opportunity.
 
  Specifically, I'd like to ask a member of our PMC
 or
  any current ASF member to sponsor my membership.,
  Unfortunately I will probably not be able to
 attend
  the next Foundation meeting, and so I'd also ask
 that
  my sponsor act as my proxy, if possible.
 
  If I understand this process correctly, if I am
  nominated, I fill out an application form and it's
  discussed on the private [EMAIL PROTECTED]
 mailing
  list until a decision spits out.  I guess I won't
 be
  gaining any insight into the admission process at
  first.  :)
 
  - Morgan
 
  =
  Morgan Delagrange
  http://jakarta.apache.org/taglibs
  http://jakarta.apache.org/commons
  http://axion.tigris.org
  http://jakarta.apache.org/watchdog
 
  __
  Do you Yahoo!?
  Y! Web Hosting - Let the expert host your web site
  http://webhosting.yahoo.com/
 
  --
  To unsubscribe, e-mail:  
 mailto:general-unsubscribe;jakarta.apache.org
  For additional commands, e-mail:
 mailto:general-help;jakarta.apache.org
 
 
 
 
 --
 To unsubscribe, e-mail:  
 mailto:general-unsubscribe;jakarta.apache.org
 For additional commands, e-mail:
 mailto:general-help;jakarta.apache.org
 


=
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog

__
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/

--
To unsubscribe, e-mail:   mailto:general-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:general-help;jakarta.apache.org




Re: [Actual Action Taken] Re: Advertisement using Apache lists

2002-05-14 Thread Morgan Delagrange


--- Andrew C. Oliver [EMAIL PROTECTED] wrote:
 Please see:
 
 http://jakarta.apache.org/site/vendors.html
 
 If this is acceptable (this is the best I could do
 on my lunch break ;-)
 )

Doesn't there need to be some legalese?  Jakarta does
not endorse those vendors; that should probably be
noted.

 -- I'll go ahead and update the site and I'll
 supply a patch for
 mail.html that asks that folks don't post commercial
 ads to the mail
 lists rather supply a patch for the vendor page to
 be applied at
 jakarta-site2 committer discretion.  

So, if a committer is competing with another company,
he can veto that company's patches?  How is this
governed, while still maintaining our integrity as a
non-for-profit volunteer organization?

 If you have minor suggestions for this, please
 supply them in the form
 of commits or patches that correct any minor errors
 or improve things. 
 I'm not interested in creating the vendor
 superpage.
 
 Thanks,
 
 -Andy
 
 PS I realize www.superlinksoftware.com is down at
 the moment.  Its
 undergoing upgrades.  It'll be back up at the end of
 the week.
 
 
 On Mon, 2002-05-13 at 09:32, Henri Yandell wrote:
  +1 from me.
  
  While it's nice to see committers who are able to
 commercially work with
  the experience they gain/use here, it would be
 very demeaning to the list
  for every company who are using jsp/servlets/other
 to post their
  consultant services to the general list.
  
  Hen
  
  On 13 May 2002, Leo Simons wrote:
  
   +1 to all of that.
  
   - Leo
  
Sun Micro, has a page of here are Java
 companies  -- lets innovate
it and put up a similar Jakarta page -- Here
 are companies and folks who
support Apache Jakarta software.  I volunteer.
 Secondly, lets Make a
rule NOT to post advertising to the mail
 lists, that is NOT what they
are there for.
   
This does a few things:
   
1. Provides a good rationale to companies to
 use Apache Jakarta Software
(not a specific goal of the group but a
 personal goal of several people
here including myself as I like working with
 GOOD software)
   
2. Gives those companies a place to post thats
 relevant to Jakarta,
won't annoy people who might otherwise use
 them.
   
3. Give those companies a high visability web
 page to advertise on.
   
4. God I don't need more spam.  My spam filter
 entries will one day
reach the limit on the number of strings I can
 match on.
  
  
  
   --
   To unsubscribe, e-mail:  
 mailto:[EMAIL PROTECTED]
   For additional commands, e-mail:
 mailto:[EMAIL PROTECTED]
  
  
  
  
  --
  To unsubscribe, e-mail:  
 mailto:[EMAIL PROTECTED]
  For additional commands, e-mail:
 mailto:[EMAIL PROTECTED]
  
 -- 
 http://www.superlinksoftware.com - software
 solutions for business
 http://jakarta.apache.org/poi - Excel/Word/OLE 2
 Compound Document in
 Java
 http://krysalis.sourceforge.net/centipede - the best
 build/project
 structure
   a guy/gal could have! - Make Ant simple on
 complex Projects!
 The avalanche has already started. It is too late
 for the pebbles to
 vote.
 -Ambassador Kosh
 
 
 --
 To unsubscribe, e-mail:  
 mailto:[EMAIL PROTECTED]
 For additional commands, e-mail:
 mailto:[EMAIL PROTECTED]
 


=
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org

__
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

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




Re: [PROPOSAL] Centaven and Friends (was Re: You make the decision (was Re: Quick! convert all your projects to maven!))

2002-05-02 Thread Morgan Delagrange

http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAIN
TING

The language you use for transformation is, in the case of a
Maven/Centipete-type tool, largely internal to the project.  Gather some
developers, call a vote, and use what the majority decides.  Later on, if
you have an itch to switch, convert the files, put them in a staging area,
and call another vote.  Both will do the job.

Personally I like XSLT.  I find it feature rich and I don't find it
difficult to use.  But I'll use DVSL if that's what the project requires.  I
think the quantity of developers who are literally incapable of using one or
the other is negligable.  If they are ideologically incapable, that's their
problem.

Actually it may not even be necessary to pick one or the other exclusively.
For example Latka maintains its documentation in docbook, but Dion added a
transform to Anakia so it works with the site build.  Similarly you may be
able to provide DVSL and XSL alternatives.

This is not a slam on Oliver or anybody else.  This just happened to be the
most recent post on this topic.

- Morgan

- Original Message -
From: Andrew C. Oliver [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED]
Sent: Thursday, May 02, 2002 8:51 AM
Subject: Re: [PROPOSAL] Centaven and Friends (was Re: You make the decision
(was Re: Quick! convert all your projects to maven!))


 Guys,

 Bottom line (you could probably guess these but it needs to be said):

 1. I'll -1 the attempt to switch any project to maven that I have a vote
 on unless there is a concerted effort to collaborate on a combined
 effort with centipede.

 2. I'll -1 anything that REQUIRES me to use DVSL if I don't want to.

 So what decides (in the minds of the maven community) whether it is
 successful...  If its that a large set or all of the projects on
 jakarta/xml/etc use it well then collaboration is the easiest way (it
 removes my and several others objections).  If its to force us all to
 use your pet projects, well good luck.  Its certainly not turning out to
 be a springboard for collaboration.

 You want the hearts and minds, then we've outlined it.  Work towards
 collaboration.  Work towards standards support.  Then you'll reach a
 consensus.  If not, *shrug* then I'm sure some projects will use it, but
 it will imo kind of be a flop of the goals I assume it wants to achieve.

 -Andy



 Berin Loritsch wrote:

  Jon Scott Stevens wrote:
 
  on 5/2/02 2:54 AM, [EMAIL PROTECTED] [EMAIL PROTECTED]
  wrote:
 
 
  Centaven Reasoning: I don't see how we can easily do this. The
  approaches
  are wildly different at basic levels, e.g. dvsl vs xsl, entities vs
  external build files for ant, extending GUMPs descriptor vs
  generating one
  etc. Any 'coming together' is going to be a very difficult decision
  to get
  past the maven developer community, because they have a tool that
  works and
  is going in a consistent direction from a design perspective, and that
  coming together will result in much slowing of progress. I don't
think,
  IMHO, either tool is mature enough at this point to merge.
 
 
 
  I can agree with that. Hell, the dvsl vs. xsl is a showstopper for me.
 
  I can't stand XSL...
 
 
 
  And I can't be bothered with non-standard transformation languages...
 
  Centipede uses Cocoon, which allows you to use Velocity, or whatever you
  want to transform your documents.  You aren't locked into XSL if you
  don't want.  THat's the beauty of it.  WIth Maven, you are locked into
  DVSL, and there is no other way of doing things. :/
 
  But again, Reality Check: how often do you mess with the look and feel
  of a site?  If the theme exists--use it.  It's that simple.
 
 




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


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




Re: You guys are so funny.

2002-05-02 Thread Morgan Delagrange

I agree with pretty much everything said, although as
always Jon words it a tad more strongly than I ever
would.  :)

Let the community decide.  If 51% of the developers
want to use XSL, or DVSL, then that's what you should
use.  If you don't like it, prove that your
alternative is better.  But dropping a whole project
because of a detail is needless.

- Morgan

--- Jon Scott Stevens [EMAIL PROTECTED] wrote:
 on 5/2/02 8:44 AM, [EMAIL PROTECTED]
 [EMAIL PROTECTED] wrote:
 
  Same here, I'll -1 a switch to either maven or
 centipede on the projects I
  have a vote on until they find a way to work
 togheter.
  
  DVSL may be a nice language, but XSLT is the
 standard - regardless of how
  you play with the word. I'm fine with a tool that
 supports both.
  
  Costin
 
 You guys are so funny.
 
 Bike Sheds
 --
 
 At first, people -1'd the use of Anakia to generate
 the Jakarta website. But
 then when I took the effort to make it simple and
 easy to use and took away
 the bike shed argument, people adopted it and used
 it all over the world.
 
 On top of it, in *years*, no one has gone and
 replaced Jakarta-site2 with
 anything better. Sure, Craig did a XSLT stylesheet,
 but no one changed the
 main Jakarta site to use it and I still see new
 Anakia sites on
 Sourceforget.net all the time.
 
 The next thing to replace jakarta-site2 will be
 Maven. Just like with
 Anakia, I honestly don't care if you -1 it. You
 aren't doing the work and
 therefore your argument against it is simply a bike
 shed and is thus not
 valid in my opinion.
 
 Costin, just like with Tomcat 3 vs. Tomcat 4. We all
 learned that you can't
 force projects to work together. Nor can you vote -1
 on it. Given our
 history, I'm really surprised to hear you trying to
 argue for something like
 that. You hypocrite.
 
 Learning Technology
 ---
 
 The argument about learning minor technologies to
 make money is so silly it
 is funny. I have owned/started several companies now
 and have been
 responsible for hiring or directly approving the
 hiring of about 50-60
 people over the last 10 years. Not a huge amount,
 but not small either.
 
 Never once did I think to myself, hmmm...that person
 knows minor technology
 X better than minor technology Y. What I cared the
 most about was that the
 person had a general good skill set and the aptitude
 to learn something new.
 So, if learning DVSL vs. XSLT is beyond your
 aptitude, I probably would not
 have hired you anyway.
 
 On top of it, the mentality of having to fit into
 the box because everyone
 else is doing it would make me instantly not like
 your personality. I like
 people who are free thinkers and who can think
 outside of the box. Software
 is an art form, not something that you can just
 cookie cutter produce (and
 have it come out being any good). IMHO, it is the
 free thinkers that have
 the most creative and bug free code. Thinking
 outside of the box shows that
 you care about the code and systems you are
 creating.
 
 People
 --
 
 Needless to say, the attitudes here are becoming
 more and more familiar.
 Andrew reminds me of the early days of dealing with
 Peter Donald (credit to
 Peter for eventually coming to his senses...I think
 joining the PMC helped).
 Steven reminds me of Paulo. Deja vu!
 
 :-)
 
 -jon
 
 
 --
 To unsubscribe, e-mail:  
 mailto:[EMAIL PROTECTED]
 For additional commands, e-mail:
 mailto:[EMAIL PROTECTED]
 


=
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org

__
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

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




Re: You guys are so funny.

2002-05-02 Thread Morgan Delagrange


- Original Message -
From: Andrew C. Oliver [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED]
Sent: Thursday, May 02, 2002 3:37 PM
Subject: Re: You guys are so funny.


 You're still missing the point ... The main detail to me is I'd like to
 use a combined collaborated project...  I'd -1 solely on that.
  Centipede more completely fits MY needs and will make it easier for me
 to work with several projects that I need (not just tlaking about
 xsl)...  I'd -1 solely on that

Nope I'm not missing your point.  I'm just waiting for the salient points to
come out.  This DVSL vs. XSL thing is a complete red herring.  You've said:

[Andy]
  2. I'll -1 anything that REQUIRES me to use DVSL if I don't want to.

and Jon has said:

[Jon]
 I can agree with that. Hell, the dvsl vs. xsl is a showstopper for me.

 I can't stand XSL...

I'm pretty sure Jon was exaggerating, particularly considering that he
picked up my bike shed argument.  I suspect you are too.  If we want to
see if collaboration is possible, let's put the real issues on the table.
So far I haven't pinpointed any showstoppers, except for people too attached
to the color of their shed.  However it's hard to even judge what would make
a showstopper until there's a more concrete proposal.  If there are real
discrepencies, let's spell them out.

 BTW when did the Majority voting rule overrule the consenus based?   I
 regard this as a product change.

DVSL is a product change for Centipede.  XSL is a product change for Maven.
If the projects merge, different approaches will have to be reconciled by
the majority; essentially you would have a new product; there would be no
existing product to change.  Clearly most people don't known what, if
anything, they want to gain from this discussion.  Two compatible projects?
One merged project?  Let's work out some more detailed proposals before
chasing at shadows.



 Morgan Delagrange wrote:

 I agree with pretty much everything said, although as
 always Jon words it a tad more strongly than I ever
 would.  :)
 
 Let the community decide.  If 51% of the developers
 want to use XSL, or DVSL, then that's what you should
 use.  If you don't like it, prove that your
 alternative is better.  But dropping a whole project
 because of a detail is needless.
 
 - Morgan
 
 --- Jon Scott Stevens [EMAIL PROTECTED] wrote:
 
 on 5/2/02 8:44 AM, [EMAIL PROTECTED]
 [EMAIL PROTECTED] wrote:
 
 Same here, I'll -1 a switch to either maven or
 
 centipede on the projects I
 
 have a vote on until they find a way to work
 
 togheter.
 
 DVSL may be a nice language, but XSLT is the
 
 standard - regardless of how
 
 you play with the word. I'm fine with a tool that
 
 supports both.
 
 Costin
 
 You guys are so funny.
 
 Bike Sheds
 --
 
 At first, people -1'd the use of Anakia to generate
 the Jakarta website. But
 then when I took the effort to make it simple and
 easy to use and took away
 the bike shed argument, people adopted it and used
 it all over the world.
 
 On top of it, in *years*, no one has gone and
 replaced Jakarta-site2 with
 anything better. Sure, Craig did a XSLT stylesheet,
 but no one changed the
 main Jakarta site to use it and I still see new
 Anakia sites on
 Sourceforget.net all the time.
 
 The next thing to replace jakarta-site2 will be
 Maven. Just like with
 Anakia, I honestly don't care if you -1 it. You
 aren't doing the work and
 therefore your argument against it is simply a bike
 shed and is thus not
 valid in my opinion.
 
 Costin, just like with Tomcat 3 vs. Tomcat 4. We all
 learned that you can't
 force projects to work together. Nor can you vote -1
 on it. Given our
 history, I'm really surprised to hear you trying to
 argue for something like
 that. You hypocrite.
 
 Learning Technology
 ---
 
 The argument about learning minor technologies to
 make money is so silly it
 is funny. I have owned/started several companies now
 and have been
 responsible for hiring or directly approving the
 hiring of about 50-60
 people over the last 10 years. Not a huge amount,
 but not small either.
 
 Never once did I think to myself, hmmm...that person
 knows minor technology
 X better than minor technology Y. What I cared the
 most about was that the
 person had a general good skill set and the aptitude
 to learn something new.
 So, if learning DVSL vs. XSLT is beyond your
 aptitude, I probably would not
 have hired you anyway.
 
 On top of it, the mentality of having to fit into
 the box because everyone
 else is doing it would make me instantly not like
 your personality. I like
 people who are free thinkers and who can think
 outside of the box. Software
 is an art form, not something that you can just
 cookie cutter produce (and
 have it come out being any good). IMHO, it is the
 free thinkers that have
 the most creative and bug free code. Thinking
 outside of the box shows that
 you care about the code and systems you are
 creating.
 
 People
 --
 
 Needless

Re: News Page Problems

2002-04-07 Thread Morgan Delagrange

Thats probably my fault.  I'll fix it.

--- Daniel F. Savarese [EMAIL PROTECTED] wrote:
 
 In message

[EMAIL PROTECTED],
 Kur
 t Schrader writes:
 It seems that whomever updated
 http://jakarta.apache.org/site/news.html
 last somehow managed to generate it in such a way
 so that it has two
 menus, instead of just one.  The jakarta-site2
 build from CVS appears to
 work correctly though, so someone with karma
 probably just needs to
 rebuild and update the site.
 
 When I tried to update news.html I got a conflict,
 so I moved it to
 news.html.conflict and did an update for the sake of
 having the Web
 site look right.  I'll leave it to someone else who
 knows what was
 intended to resolve the conflict.
 
 daniel
 
 
 
 --
 To unsubscribe, e-mail:  
 mailto:[EMAIL PROTECTED]
 For additional commands, e-mail:
 mailto:[EMAIL PROTECTED]
 


=
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org

__
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

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




[ANNOUNCE] Jakarta Commons Collections 2.0 Released

2002-04-05 Thread Morgan Delagrange

Come and get the Commons Collections 2.0 release!

http://jakarta.apache.org/commons/components.html

Commons-Collections provides a suite of classes that extend or augment the
Java Collections Framework.  Collections 2.0 includes 11 new collections and
3 new comparators, as well as several enhancements and bug fixes.  Enjoy!

- The Commons Dev Team


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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




Re: Comments on the commons-logging API

2002-03-28 Thread Morgan Delagrange


- Original Message -
From: Jeff Schnitzer [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED]
Sent: Thursday, March 28, 2002 2:12 PM
Subject: RE: Comments on the commons-logging API


  From: Morgan Delagrange [mailto:[EMAIL PROTECTED]]
 
  Yes, the defining advantage to the commons-logging API that I see is
that
  it
  allows users to adopt a single logging implementation, which confers
real

 What needs to be appended to that statement is ...if everyone codes to
 the commons-logging API.

Every component that uses the Commons Logging proxy will play well with
every other component using the proxy, _plus_ all code using a single logger
implementation of your choice.

Saying that everyone must code to the commons-logging API is an
oversimplification.  More accurately, coding to commons-logging facilitates
integration with a single arbitrary logging implementation.  Any environment
that uses a combination of the logging facade and a single logging
implementation will work well.  Any environment that uses more than one
logging implementation will not work as well.

 The exact same statement can be reconstructed
 using Log4J API and it is equally true.

If you can guarantee that:

  1) All Jakarta developers will use Log4J in their code,
 eschewing even LogKit, another logging implementation
 under the Jakarta umbrella.

and

  2) All Jakarta _users_ will use Log4J in their code.

then there is no need for a proxy logger.

 If everyone uses commons-logging, then only one logger must be
 configured.  If everyone uses Log4J, then only one logger must be
 configured.

Where is this world where everyone uses Log4J?

 If third-party software is using different loggers, then
 you have to configure multiple loggers no matter what API your code
 uses.

Unless that third-party is Jakarta, and that software is utilizing a proxy
logger like commons-logging.  That's the whole point, we can't (and
shouldn't) dictate what implementations others may choose to use.  We can,
however, facilitate integration with their implementation.  Or we can leave
them to the wolves.

 It seems to me that the commons-logging API just adds Yet Another
 Logging API... especially when someone gets the bright idea to make a
 native implementation of the API for performance reasons.

 At least with Turbine, Struts, (Maverick :-), etc, there are some
 fundamentally different approaches to the problem of how to publish a
 web application.  Logging doesn't seem that complicated.  The massive
 duplication of this basic feature in the Jakarta codebase is silly, and
 trying to build an abstraction layer on top of it seems even sillier.

I'm not sure what massive duplication you're referring to, but you seem to
believe that an abstraction layer is unimportant because you think everyone
should use Log4J.  I think the LogKit folks would disagree.  I do too; for
simple logging in a JDK 1.4 environment, using the built-in logger should be
perfectly acceptable.  Because I made that choice, does that mean I should
not get any output from Jakarta components in my log?

- Morgan

 Jeff Schnitzer
 [EMAIL PROTECTED]

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


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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




Re: Comments on the commons-logging API

2002-03-28 Thread Morgan Delagrange


- Original Message -
From: Ceki Gülcü [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED]
Sent: Thursday, March 28, 2002 3:18 PM
Subject: Re: Comments on the commons-logging API


 At 15:10 28.03.2002 -0600, Morgan Delagrange wrote:
 Where is this world where everyone uses Log4J?

 That world = (world - jakarta)


I am pro-Log4J.  I wish I lived in that Log4J-only world (until/unless
something better came along).  Generally, commons-logging neither encourages
nor discourages use of Log4J.  However, I would argue that it _does_
encourage Log4J a bit by not forcing a logging implementation war.

The fact is, JDK 1.4 logging in particular is going to become more and more
common over time, and unless someone can summon forth a magic recantation of
that JSR, then a component-level interface with popular loggers is
necessary.  Otherwise you have to pick, which only services us at the
expense of those who use other logger implementations.



_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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




Re: Comments on the commons-logging API

2002-03-28 Thread Morgan Delagrange


- Original Message -
From: Ceki Gülcü [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED]
Sent: Thursday, March 28, 2002 4:14 PM
Subject: Re: Comments on the commons-logging API


 At 15:30 28.03.2002 -0600, Morgan Delagrange wrote:

 I am pro-Log4J.  I wish I lived in that Log4J-only world (until/unless
 something better came along).  Generally, commons-logging neither
encourages
 nor discourages use of Log4J.  However, I would argue that it _does_
 encourage Log4J a bit by not forcing a logging implementation war.

 True. It does encourage it, but only initially. On the long run,
 however, people will run into problems with their logging (as is
 happening now). They will say this commons-logging+log4j stuff is too
 complicated, we'll switch to JDK 1.4 logging, at least that does not
 have any CLASSPATH problems.

I'm not convinced.  These sound like minor, temporary issues, not
showstoppers.  Classpaths do get a little complicated, but it's only one
additional JAR.

 The fact is, JDK 1.4 logging in particular is going to become more and
more
 common over time, and unless someone can summon forth a magic recantation
of
 that JSR, then a component-level interface with popular loggers is
 necessary.  Otherwise you have to pick, which only services us at the
 expense of those who use other logger implementations.

 Possible but I would not be that sure.  We will have very strong new
 features in log4j 1.3 (the release after 1.2) which will leave JDK 1.4
 logging even further behind.  Just as importantly, log4j documentation
 is going to get a massive boost with the upcoming log4j book.

I hope you're right.  Log4J is a great tool.  Still, you cannot dictate
preference.

 Sun's me-too strategy is bound to fail. The question is whether the
 bigger jakarta community is going to help us defeat JSR47 or stand in
 the way.

That's a bit harsh, isn't it?

- Morgan

 --
 Ceki




_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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




Re: Comments on the commons-logging API

2002-03-27 Thread Morgan Delagrange


- Original Message -
From: Ceki Gülcü [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED]
Sent: Wednesday, March 27, 2002 2:43 PM
Subject: RE: Comments on the commons-logging API


 At 11:49 27.03.2002 -0600,  Rodney Waldhoff wrote:

 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.

 If your library chooses to use logging API XYZ, this does not impose
 XYZ to the clients of your library. Your clients can use the logging
 library they prefer (if they are using logging API) and your library
 can use XYZ. One choice does not necessarily influence the other. For
 example, the fact that JBoss uses log4j does not impose a logging
 library to the bean developer. Similarly, Tomcat's logging library
 does not prevent web-app developers from using log4j.

But it doesn't facilitate it either.

Here's the problem, as I see it.

Suppose Commons component A decides to adopt Log4J, Commons component B
decides to adopt LogKit, and Commons component C adopts JDK1.4 logging.
They will all minimally function with the right jars in the classpath.
However you (the end-user) are left with maintaining configuration for 3
different logging APIs, which is tedious at best.  When you take into
account cool features like variable log levels, Log4J appenders and the
like, you're pretty much guaranteed to swallow up useful configuration
options because sophisticated configurations are too difficult to maintain
over mutiple logging implementations.

Contrarily, if all three Commons components use a logging facade, you can
focus all your configuration efforts on one logging implementation.  Sure,
there is a trade-off; you don't have access to all the features, and the
interface between the facade and the implementation must be maintained.  But
the benefits are not just political; they potentially make the end-users
configuration much easier.

Even if all Commons components used the same logging implementation (Log4J
for example), other projects in Jakarta-land may choose otherwise.  If you
add enough Jakarta projects to your environment, you eventually end up with
the scenario described above.  It's a worthwhile effort to attempt a logging
solution that plays well with the Jakarta community at large.  I think in
many cases the Commons Logging component can fill that role.

To take your analogy of trading a nickel's worth of functionality for a
penny payoff later (only because I'm dying to play off of it, FEEL FREE TO
IGNORE THIS PARAGRAPH :), yes each logger implementation delivers that
nickel.  However Log4J is delivering a US nickel, LogKit a Canadian nickel,
and JDK 1.4 a wooden nickel.  Each end-user becomes a bank that must
constantly monitor the exchange rate between those nickels, including those
wooden nickels which aren't worth a damn.  Some banks would prefer the
guarantee of a good penny than deal with the hassle of all those nickels.
:)

 In other words, the argument about (jakarta-commons) components
 dictating a logging API to the containing application is widely
 accepted although very dubious in my opinion.


I don't know if the word dictate quite captures it.


 Anyway, I think we have been through all this already. I do not expect
 to be able to convince anyone altough I suspect uncertainty and the
 bug reports will, slowly but surely.

It may be difficult to maintain.  The most we can do to mitigate it is
frequent releases and careful version management.

 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.)

 I don't think hoping quitely and computers get along very 

Re: Comments on the commons-logging API

2002-03-27 Thread Morgan Delagrange


- Original Message -
From: Ceki Gülcü [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED]
Sent: Wednesday, March 27, 2002 4:20 PM
Subject: Re: Comments on the commons-logging API


 At 15:18 27.03.2002 -0600, Morgan Delagrange wrote:
 Here's the problem, as I see it.
 
 Suppose Commons component A decides to adopt Log4J, Commons component B
 decides to adopt LogKit, and Commons component C adopts JDK1.4 logging.
 They will all minimally function with the right jars in the classpath.
 However you (the end-user) are left with maintaining configuration for 3
 different logging APIs, which is tedious at best.  When you take into
 account cool features like variable log levels, Log4J appenders and the
 like, you're pretty much guaranteed to swallow up useful configuration
 options because sophisticated configurations are too difficult to
maintain
 over mutiple logging implementations.
 
 Contrarily, if all three Commons components use a logging facade, you can
 focus all your configuration efforts on one logging implementation.
Sure,
 there is a trade-off; you don't have access to all the features, and the
 interface between the facade and the implementation must be maintained.
But
 the benefits are not just political; they potentially make the end-users
 configuration much easier.

 So, if I understand correctly the reason for adopting commons-logging
 API is for convenience rather than non-intrusiveness as a library
 (with respect to logging).

Yes, the defining advantage to the commons-logging API that I see is that it
allows users to adopt a single logging implementation, which confers real
benefits particularly with regard to configuration.  Easy transitions from
one logging implementation to another are not particularly important; the
tangible benefit is to let disparate components have the _option_ to use the
same log without complicated bridges between logging implementations.

 With commons-logging, the end user will only have to configure the
 logging API that common-logging selects (or detects) but the selection
 mechanism is dynamic such that there are many ways and reasons for
 which the selected API will be the wrong one. This is the uncertainty
 factor I am talking about.  Uncertainty breeds confusion and confusion
 breeds despair.


I believe the order of precedence is well documented.  I think the logging
component would benefit from warning messages when a default implementation
is selected (like Log4J warns you when there is no log4j.properties file
available), but this doesn't require any fundamental change to the API.

If you want to take about confusion and despair, look at the environment
that's running three logging implementations simultaneously.

- Morgan


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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




Re: Jakarta Overview

2002-03-22 Thread Morgan Delagrange

I'm not Ted, but let me take a stab.  :)

- Original Message -
From: Danny Angus [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED]
Sent: Friday, March 22, 2002 7:09 AM
Subject: RE: Jakarta Overview


 Ted,
 I don't want to have an argument, and I'm not criticising Philipp for
 offering, nor for the effort he obviously put in.
 I do have some reservations with this particular page, which I'm not going
 to raise again, if anyones interested they've already read them.

 I would like to take you up on a couple of points you make though,

  The overview has been donated to the ASF, and is under Jakarta rules
  now.

 Does this mean that anything donated is accepted on behalf of the
project,
 by anyone with karma, without discussion and can therefore only be openly
 opposed once it has already been accepted?

Yes, that is the Commit Then Review philosophy.  You cannot prevent anyone
from initially committing anything, but one it has been committed you can
vote it down.

  If anyone wants to make it more objective, have at it. If not,
  leave it alone and it will wither away.

 What if (and I don't, I'm just asking) modification and inaction are not
 enough for me, I want to veto it?
 I don't have enough Karma for Jakarta-site2, but if I did would I be
within
 my rights to arbitrarily remove it? I think, and hope, not.
 Therefore it seems that it is a bigger hurdle for a donation of this kind
to
 be vetoed than accepted.

You cannot arbitrarily remove it, but you can veto it.  Under the current,
slightly strange, default voting rules for Jakarta, Ted would have to talk
you out of your objection; if he could not, he might have to back out his
change (or you could do it for him).  Any changes to a product require
consensus approval.  Does the website fit under the definition of a Jakarta
product?  A good question, which does not come up very often.  Usually
committers are more permissive of website changes then code changes.

  Regardless of the content, it's important to recognize that the initial
  author Did The Right Thing. The overview was prepared in XML and
  required no afterwork to commit. This makes him a Contributor in my
  book. If more of our users went to the trouble this person went to, we'd
  have more and better documentation throughout Jakarta.

 You're absolutely right, I agree utterly with that statement, and I hope
my
 miserable grumping doesn't put him off.


  Apache stands for patching ...

 But we don't want to have to patch any old thing that comes swinging by,
do
 we?

 Surely there could be a slightly better, and simple, way of accepting
 website proposals that makes it obvious that they are undergoing peer
 review?

Well you can always exercise your veto.  Then the committer backs it out,
discusses changes on the list, makes some modifications, and resubmits for
another vote.

 And in the interests of providing construtive criticism I'll propose --
 A proposals section of the site, into which anyone with karma can commit
 any submissions and from which documents can be promoted by lazy concensus
 of all jakarta commiters. Its stylesheet will include a footer explaining
 the status of proposal documents(if thats possible). -- for instance?

 d.

We have that section.  It's called CVS.  :)  It operates exactly the way you
describe.

- Morgan


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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




Re: Re: Get together / SunOne / JakartaOne / The One that binds them

2002-03-04 Thread Morgan Delagrange


- Original Message -
From: acoliver [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, March 04, 2002 12:59 PM
Subject: Re: Re: Get together / SunOne / JakartaOne / The One that binds
them


 On Mon, 04 Mar 2002 19:01:31   Pier Fumagalli [EMAIL PROTECTED]
 wrote.
 [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 
  Including whiteboards, etternet-hubs, wireless, telcon/phone, coffee,
  thee, softdrinks c for one day (take your pick; tentative suggestion:
  that Tuesday).
 
 Plane tickets? :)
 

 oooh h me too me too!  Throw in hotels and registration fees and I'm
 there dude!


I don't even need registration fees.  I'd much rather go to JakartaOne.  :)

- Morgan


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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




Re: Boycott JavaOne? was Re: Re: StudioZ (was: Re: JakartaOne?)

2002-03-04 Thread Morgan Delagrange

We could save travel money if we slept under the bar.

- Original Message -
From: acoliver [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, March 04, 2002 1:56 PM
Subject: Boycott JavaOne? was Re: Re: StudioZ (was: Re: JakartaOne?)


 If a group were zealously opensource, a group Could publically boycott the
 JavaOne, hold a countersession called JakartaOne at a bar or club and
a
 certain club owner might make a killing in selling inebriation to geeks
and
 make a very public spit in a certain corporations eye.

 Hypothetically of course.  It would certainly make for interesting press..

 Moot for me because of my limited wealth.

 -Andy

 On Mon, 04 Mar 2002 19:20:48   Pier Fumagalli [EMAIL PROTECTED]
 wrote.
 Jon Scott Stevens [EMAIL PROTECTED] wrote:
 
  I would love to host JakartaOne at Studio Z. I think it would be a lot
of
  fun.
 
For free. *
 
  However, I do need to know the day/time/length of the event as well as
 what
  other things will be needed (chairs/tables/whatever). Unless some
people
  here volunteers, I can look into getting some great local
  techno/house/trance/ambient DJ's to spin music.
 
  We do have a DSL line into the space as well as ethernet drops
literally
  every five feet (the space was a .bomb before we moved in) and I will
 have
  an open 802.11b network available in the next week or so (as soon as
the
  Linksys is delivered). Bring your laptops. :-)
 
  Studio Z is not walking distance from Moscone, however, it is only
about
 a 5
  minute, $4-5 taxi ride. Not a big deal.
 
 
  * The only requirement is that the date/times not conflict with any
other
  events that we are putting on there.
 
 
  The Covalent deal also sounds cool, but I doubt they have a large dance
  floor and a big sound system. :-)
 
 And I can vouch for him... The space is _fantastic_... Been there, seen
 that, wanna get back! :) Go JON! :)
 
 Pier (for free? Where's that nice scottish spirit of yours! :)
 
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 


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


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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




Re: Jakarta PMC 2002: Results of the Ballot.

2002-02-25 Thread Morgan Delagrange

Congratulations to the new PMC members!  We couldn't ask for a more
qualified group.  :)

- Morgan


- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Monday, February 25, 2002 12:02 PM
Subject: Jakarta PMC 2002: Results of the Ballot.


 -BEGIN PGP SIGNED MESSAGE-


 Thanks for voting.

 We received 75 valid ballot forms (from 219 committers). There where 462
 votes casted on nominees and 63 abstaining votes (i.e. with a total of
 7x75=525 votes).

 None of the received ballot forms where rejected. No issues where found
 during the verification of the email sender/messages.

 The 7 people with the largest number of votes (in alphabetical order):

   Stefan Bodewig
   Craig McClanahan
   Diane Holt
   Conor MacNeill
   Geir Magnusson Jr.
   Costin Monolache
   Sam Ruby

 The above people thus compose the Jakarta PMC effective immediately
 and will be confirmed as the Jakarta PMC for 2002 at the next ASF
 board meeting.

 Should you have issue with those elections or its procedure then please
 contact [EMAIL PROTECTED] or [EMAIL PROTECTED]

 Your vote counters: Ben, Jim and Dirk-Willem.

 Thanks,

 Dw.

 -BEGIN PGP SIGNATURE-
 Version: PGPfreeware 5.0i for non-commercial use
 Comment: Made with pgp4pine 1.76
 Charset: noconv

 iQCVAwUBPHp8QjGmPZbsFAuBAQHXnAP+Jlfa5oCvFumrlYC07P27FZUL7SkJzML6
 OlvkCShXJBnsvN5glDkKhzPPLVDZMSuPEXRusT7B08hxoqyzLWhe9AXV2QPx3gUI
 nju20ZfQhn8a9OiLKbUEa8i4kP7bd8jXmRHmyTyYrC22ZE7ejvyQni4uvm98S5W1
 e1m8VWWhOds=
 =f3Ef
 -END PGP SIGNATURE-



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


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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




jakarta-site2 karma please

2002-02-12 Thread Morgan Delagrange

Could someone grant me karma to jakarta-site2?

I'd like to post a copy of the versioning guidelines from Taglibs
(http://cvs.apache.org/viewcvs/jakarta-taglibs/HOWTO-RELEASE?rev=1.8content
-type=text/vnd.viewcvs-markup) and Commons
(http://cvs.apache.org/viewcvs/jakarta-commons/xdocs/versioning.xml?rev=1.1;
content-type=text/vnd.viewcvs-markup) to the site, so that they can be
shared by those projects and any others that wish it.

- Morgan


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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




Are 3 votes necessary for the PMC nomination? [was: Re: To jvote or not to jvote]

2002-02-05 Thread Morgan Delagrange

So, what was the answer to the question below?  If we really do need two +1s
for a nomination, then I have some campaigning to do!  (Unless someone else
wants to go ahead and +1 me, if only to shut me up.  ;)

- Original Message -
From: Morgan Delagrange [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Monday, February 04, 2002 2:51 PM
Subject: Re: To jvote or not to jvote


 ARE two +1 votes necessary?  That was not mentioned in the original email
 Announcement: JakartaPMC elections for 2002.  (Just to stave off any
 potential debate here, the ASF-appointed administrator gets to decide how
 elections are run.  It's not our call.)

 - Original Message -
 From: Paulo Gaspar [EMAIL PROTECTED]
 To: Jakarta General List [EMAIL PROTECTED]
 Sent: Monday, February 04, 2002 2:52 PM
 Subject: RE: To jvote or not to jvote


  Thanks Dirk.
 
 
  But then, from what I can see in the general list, only
  Geir has both the nomination and the 2 necessary additional
  +1s all sent to jvote.
 
  How should this be fixed?
 
 
  This is what I see in general:
  (I am skipping those that refused the nomination.)
 
   - Ted Husted
   The 3rd +1 did not get to jvote.
 
   - Stefan Bodewig
   - Conor MacNeill
   Nothing went to jvote.
   (I think that both are still missing votes.)
 
   - Scott Sanders
   Only the nomination went to jvote.
 
   - Sam Ruby
   Nothing went to jvote.
 
   - Peter Donald
   Nothing went to jvote.
 
   - Paulo Gaspar
   Nothing went to jvote.
 
   - Morgan Delagranje
   Only his acceptance went to jvote.
 
   - Geir Magnusson
   Enough votes went to jvote.
 
   - Diane Holt
   Only the nomination went to jvote.
 
   - Craig McClanahan
   Only the nomination and one vote went to jvote.
 
   - Costin Manolache
   Only the nomination and one vote went to jvote.
 
  Have fun,
  Paulo Gaspar
 
 
   -Original Message-
   From: Dirk-Willem van Gulik [mailto:[EMAIL PROTECTED]]
   Sent: Monday, February 04, 2002 8:36 PM
   To: Jakarta General List; [EMAIL PROTECTED]
   Cc: [EMAIL PROTECTED]
   Subject: Re: To jvote or not to jvote
  
  
  
  
   On Mon, 4 Feb 2002, Paulo Gaspar wrote:
  
From the PMC nomination postings, some are going to
[EMAIL PROTECTED] and some not.
  
Why? What are the rules?
  
   See below. We'll debug the message for the next election to make sure
it
   is clearer.
  
   What we will be checking on the 7th is what we have received on the
   [EMAIL PROTECTED] mailing list - and in particular those messages
   from the nominee himself or herself that he or she is willing to
   be run in the election.
  
   Dw.
  
  
   T+7 Nominations for PMC needs to be in by 0:00 GMT 7th of
   February 2001. You can either nominate yourself - or
   nominate someone else. What counts is the confirmation
   from the nominee being received.
  
   -  Posting a message to [EMAIL PROTECTED] and
   Cc: [EMAIL PROTECTED] with your candidature, a short
   description about who you are, what you want to
   accomplish.
  
   -  Or if you are volunteered by someone else - a similar
   message confirming that you are accepting the
   nomination - with again - some details about yourself.
  
   -  PMC seats are open to anyone. Regardless as to
   wether you are a committer, lurker or coder. And
   you can even nominate a complete outsider (assuming
   he or she would consent of course.)
  
   -  The board volunteers handling the vote cannot
   be nominated.
  
   -  The nomination must include the email address of
   the nominee. And it really should be a valid one :-)
  
  
  
   --
   To unsubscribe, e-mail:
 mailto:[EMAIL PROTECTED]
   For additional commands, e-mail:
 mailto:[EMAIL PROTECTED]
  
 
  --
  To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
  For additional commands, e-mail: mailto:[EMAIL PROTECTED]



_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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




Re: PMC Nomination - Morgan Delagrange

2002-02-04 Thread Morgan Delagrange

I accept this nomination, which was originally sent to the
[EMAIL PROTECTED] mailing list.  Thanks Rod!

- Original Message -
From: Waldhoff, Rodney [EMAIL PROTECTED]
To: 'Jakarta General List' [EMAIL PROTECTED]
Sent: Friday, February 01, 2002 11:15 AM
Subject: PMC Nomination - Morgan Delagrange


 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.



_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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




Re: To jvote or not to jvote

2002-02-04 Thread Morgan Delagrange

ARE two +1 votes necessary?  That was not mentioned in the original email
Announcement: JakartaPMC elections for 2002.  (Just to stave off any
potential debate here, the ASF-appointed administrator gets to decide how
elections are run.  It's not our call.)

- Original Message -
From: Paulo Gaspar [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED]
Sent: Monday, February 04, 2002 2:52 PM
Subject: RE: To jvote or not to jvote


 Thanks Dirk.


 But then, from what I can see in the general list, only
 Geir has both the nomination and the 2 necessary additional
 +1s all sent to jvote.

 How should this be fixed?


 This is what I see in general:
 (I am skipping those that refused the nomination.)

  - Ted Husted
  The 3rd +1 did not get to jvote.

  - Stefan Bodewig
  - Conor MacNeill
  Nothing went to jvote.
  (I think that both are still missing votes.)

  - Scott Sanders
  Only the nomination went to jvote.

  - Sam Ruby
  Nothing went to jvote.

  - Peter Donald
  Nothing went to jvote.

  - Paulo Gaspar
  Nothing went to jvote.

  - Morgan Delagranje
  Only his acceptance went to jvote.

  - Geir Magnusson
  Enough votes went to jvote.

  - Diane Holt
  Only the nomination went to jvote.

  - Craig McClanahan
  Only the nomination and one vote went to jvote.

  - Costin Manolache
  Only the nomination and one vote went to jvote.

 Have fun,
 Paulo Gaspar


  -Original Message-
  From: Dirk-Willem van Gulik [mailto:[EMAIL PROTECTED]]
  Sent: Monday, February 04, 2002 8:36 PM
  To: Jakarta General List; [EMAIL PROTECTED]
  Cc: [EMAIL PROTECTED]
  Subject: Re: To jvote or not to jvote
 
 
 
 
  On Mon, 4 Feb 2002, Paulo Gaspar wrote:
 
   From the PMC nomination postings, some are going to
   [EMAIL PROTECTED] and some not.
 
   Why? What are the rules?
 
  See below. We'll debug the message for the next election to make sure it
  is clearer.
 
  What we will be checking on the 7th is what we have received on the
  [EMAIL PROTECTED] mailing list - and in particular those messages
  from the nominee himself or herself that he or she is willing to
  be run in the election.
 
  Dw.
 
 
  T+7 Nominations for PMC needs to be in by 0:00 GMT 7th of
  February 2001. You can either nominate yourself - or
  nominate someone else. What counts is the confirmation
  from the nominee being received.
 
  -  Posting a message to [EMAIL PROTECTED] and
  Cc: [EMAIL PROTECTED] with your candidature, a short
  description about who you are, what you want to
  accomplish.
 
  -  Or if you are volunteered by someone else - a similar
  message confirming that you are accepting the
  nomination - with again - some details about yourself.
 
  -  PMC seats are open to anyone. Regardless as to
  wether you are a committer, lurker or coder. And
  you can even nominate a complete outsider (assuming
  he or she would consent of course.)
 
  -  The board volunteers handling the vote cannot
  be nominated.
 
  -  The nomination must include the email address of
  the nominee. And it really should be a valid one :-)
 
 
 
  --
  To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
  For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
 

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


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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




PMC Nomination - Craig McClanahan

2002-02-01 Thread Morgan Delagrange

I would like to nominate Craig McClanahan for re-election to the PMC.

Craig works on a lot more projects than I do (than _most_ people do), so I
cannot give a complete rundown of his accomplishments.  I can say, however,
that his excellent and informed contributions to Commons, to Taglibs, and to
numerous mailing lists prove his value to the community.

- Morgan Delagrange


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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




PMC Nomination - Ted Husted

2002-01-31 Thread Morgan Delagrange

I would like to nominate Ted Husted for re-election to the PMC.

Ted has a strong (and active) committment to documentation, probably the
most often neglected component of any project.  He also was a driving force
in the Commons project; it's unlikely that the Commons would have been so
successful in its first year if it weren't for Ted's influence.  Finally, he
may have the most level head in Jakarta.  That's a big plus.

- Morgan Delagrange



_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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




Re: problem with Apache email?

2001-07-19 Thread Morgan Delagrange

on 7/19/01 6:51 PM, Morgan Delagrange [EMAIL PROTECTED] wrote:

 They are icarus and daedelus right?  I just tried icarus and it was no
 better.  But you're probably on to something, maybe something got goofed
 up in the transition to the new CVS server.  (I didn't actually get this
 email in my Apache account, by the way.  Had to paste it from
Outlook.  :(
 )  I know a few other folks use the SMTP server; is everyone
experiencing
 this?
 
 - Morgan

The smart  thing to do is to setup a .forward file and keep the resource
usage on apache.org down. Oh wait, I just posted about that like 2 days
ago...sigh...

-jon

I probably didn't get the email.  :)  That's a good idea, I'll probably do
that, although it's a moot point at the moment...no email to forward.

I started using my Apache account, because at work we have to use
Outlook 98, which is incapable (yes, incapable) of sending emails without
reformatting them as HTML.  Some committers are very adamant about text
emails, eh Jon?  

- Morgan



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




Re: Binaries in CVS

2001-04-12 Thread Morgan Delagrange


--- Sam Ruby [EMAIL PROTECTED] wrote:
 Costin Manolache wrote:
 
  One compromise may be to use a separate CVS only
 for binaries, with the
  latest released version of each product.
 
  Users will have to check out the project cvs and
 the common binaries CVS.
 
  Benefits over checking in binaries in all
 projects:
  - only pristine sources in all projects ( except
 the binary tree )
  - consistent behavior and location for the
 binaries for all projects
 using
  the binary tree
  - less duplication and space ( and download time )
  - a simple way to get the latest stable release
 for all jars ( a cvs
  update will also get only what's changed, instead
 of requiring to
  download and install x different tar.gz files )
 
 +1
 
 Perhaps we could even get a change into ant.bat and
 ant.sh to 
 -Djakarta.home=$JAKARTA_HOME.

 [big ol' snip]

A common binary repository sounds like the way to go. 
There's no strict need for everbody to buy into it
though.  If, for some reason, a new release of a JAR
breaks a particular subproject, that subproject can
always check in the required version of a binary
locally.  Or ignore the common repository and check
everything in locally, if they're dead set against the
idea.  To me, a common repository sounds like a lot
less work for the individual subproject owners, but
Jakarta members are nothing if not peculiar.

Of course, there are administrative details to
consider.  I would be very wary of putting anything
approaching a beta release in the common repository. 
We would need some ground rules to make sure that
didn't happen.

- Morgan


=
Morgan Delagrange
Britannica.com

__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

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




Re: Jakarta PMC election results

2001-03-08 Thread Morgan Delagrange

Hi all,

I have no objection to the elections, but for the
benefit of the Jakarta members, could a current PMC
member please list the PMC members (current and
proposed) and which projects they are qualified to
represent?  I at least would like to know who's
speaking for what project.

- Morgan


--- Jon Stevens [EMAIL PROTECTED] wrote:
 on 3/7/01 8:04 AM, "Sam Ruby" [EMAIL PROTECTED]
 wrote:
 
  Peter Donald:  five +1's, one +0, one -1. 
   Passes.
  Diane Holt:   six +1's.Passes.
 Beyond challenge.
  Ted Husted:   five +1's, one +0.  Passes.
  Ceki Gülcü:   seven +1's.  Passes.
 Beyond challange.
  Geir Magnusson Jr.:four +1's, two +0's.
 Passes.
  Daniel F. Savarese:four +1's, two +0's.
 Passes.
  Jason van Zyl: four +1's, two +0's.
 Passes.
 
 +1
 
 -jon
 
 -- 
 If you come from a Perl or PHP background, JSP is a
 way to take
 your pain to new levels. --Anonymous
 http://jakarta.apache.org/velocity/ymtd/ymtd.html
 
 

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


=====
Morgan Delagrange
Britannica.com

__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

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




Re: Jakarta PMC election results

2001-03-08 Thread Morgan Delagrange

Ah, so according to the site the proposed PMC
represents:

  Peter Donald:
Avalon, Ant
  Diane Holt: 
No listing on Site, don't know her 
work
  Ted Husted: 
Site doesn't list Karma, but I know
he at least works on Struts
  Ceki Gülcü:
Log4J
  Geir Magnusson Jr.:
Velocity
  Daniel F. Savarese:
Site doesn't list Karma, probably ORO
  Hans Bergsten:
Site doesn't list Karma, don't know his
work, probably Tomcat?
  James Duncan Davidson:
Tomcat, Ant
  Pierpaolo Fumagalli:
Jserv, probably Tomcat?
  Craig McClanahan:
Jserv, Struts, probably Tomcat?
  Sam Ruby:
Site doesn't list Karma, don't know his work
(other that his Chairmanship, that is :)
  Jon S. Stevens:
JServ, ECS, Turbine
  Anil Vijendran:
Tomcat

So if you cross-reference this list against Jakarta
subprojects, you get the following subproject
representation:
 
  Ant 2
  Avalon 1
  ECS 1
  James 0
  Jetspeed 0
  JMeter 0
  Log4J 1
  ORO 1
  Regexp 0
  Slide 0
  Struts 2
  Taglibs 0
  Tomcat 5
  Turbine 1
  Velocity 1
  Watchdog 1

An improvement, I guess, but still not perfect.  The
Apache board's compliant still seems legitimate, since
we don't really know who's representing what.  

Maybe Sam could comment on the roles of the nominees,
since I'm sure he knows what project they work on, and
the site is not specific enough.

--- Jon Stevens [EMAIL PROTECTED] wrote:
 on 3/8/01 11:44 AM, "Morgan Delagrange"
 [EMAIL PROTECTED] wrote:
 
  Hi all,
  
  I have no objection to the elections, but for the
  benefit of the Jakarta members, could a current
 PMC
  member please list the PMC members (current and
  proposed) and which projects they are qualified to
  represent?  I at least would like to know who's
  speaking for what project.
  
  - Morgan
 
 http://jakarta.apache.org/site/whoweare.html
 
 -jon
 
 

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


=====
Morgan Delagrange
Britannica.com

__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

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




Re: Jakarta PMC election results

2001-03-08 Thread Morgan Delagrange

That list is perfect, Jon.  Thanks!

Perhaps the PMC might go as far as to designate point
person(s) for each subproject?  E.g. if nobody from
the PMC is monitoring the dev mailing list for a
particular project, they're not really in the know
despite their karma.  I know that those karma lists
are considerably longer than the people I hear from in
a typical week, which makes me fear that some are not
active participants.

--- Jon Stevens [EMAIL PROTECTED] wrote:
 on 3/8/01 2:39 PM, "Morgan Delagrange"
 [EMAIL PROTECTED] wrote:
 
  So if you cross-reference this list against
 Jakarta
  subprojects, you get the following subproject
  representation:
  
 
 Ah, I see what you are trying to do.
 
 Actually, it is better to just look at the avail
 file and get your data that
 way. That is about as specific as possible because
 it shows who has CVS
 write access to what.
 

http://www.apache.org/websrc/viewcvs.cgi/CVSROOT/avail
 
 From that POV, you can see that there are ASF
 members and or PMC members
 involved with *every* Jakarta Project currently
 available.
 
 In reality, we should simply create another page on
 the website that lists
 things out in exact specifics. It would be something
 similar to what I
 started here:
 

http://www.apache.org/foundation/members-projects.html
 
 As you can see, I'm involved with quite a few
 projects. :-) It would be nice
 if others picked up the balls as well. I'm getting
 tired.
 
 -jon
 
 

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


=====
Morgan Delagrange
Britannica.com

__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

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




Re: [POLL] Re: Code Sharing Concepts

2001-02-16 Thread Morgan Delagrange

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)
  * standardized documentation formats in most
taglibs
  * clearly defined divisions between tag 
libraries in the CVS repository
  * "courteous" interaction between taglib 
developers (i.e., I don't muck about with
your taglib without asking)
  * lots of user interaction on the dev list
esp. concerning release candidates (which
neutrilizes maverick developer
syndrome and reduces the necessary number
of committers)
  * reasonable scope boundaries (e.g. the JDBC
taglib doesn't do database pooling, that's
what utility libraries are for!)
  * it's fun to work on!

Although I'm not interested in being a committer on
any of the other proposed library sub-subprojects at
this time, I'd be happy to help out with the "Library
Infrastructure" sub-subproject, if the goal is a
Taglibs-like organization for the project and the
site.

- Morgan


--- "Craig R. McClanahan"
[EMAIL PROTECTED] 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.  Go through the Jakarta project sites, and
 find the number of
  places that offer a separate, clean FOO tool
 that supports BAR.
  (Choose your tool and it's expected
 functionality).
 
 
 One small proto-model of "shared code" code
 components already exists within the
 Jakarta community, and might serve as a starting
 point for discussions -- the
 Jakarta Taglibs project, which is focused on
 creating reuseable JSP custom tag
 libraries.  The encouraged sharing is in this case
 at the end developer's
 application level, rather than within the Jakarta
 community itself, but some
 practices we created there might be useful models to
 look at.
 
 Basically, developers on Taglibs agree to the
 following conventions and
 policies:
 
 * No particular concern about overlaps of
 functionality -
   different applications care about different
 features and
   might appreciate alternative approaches.
 
 * Committers essentially take ownership of the
 pieces
   they care about, and agree to offer at least some
 level
   of ongoing support.
 
 * Organize their tag library directories according
 to standard
   conventions (source, example app, documentation)
 and
   package naming hierarchies that quickly become
 familiar
   to library users.
 
 * Construct semi-autonomous releases of individual
 tag libraries,
   plus a convenient way to go grab them all.  Formal
 versioning
   hasn't been an issue yet because the whole thing
 is pretty new,
   but that will need to be addressed.
 
 * Make information (essentially, the documenation
 associated
   with each tag library) available online and
 accessible.  Having
   one or more FOO modules in a shared library
 doesn't help
   any more than the current situation, if I don't
 know about them
   or cannot find anything out about them.
 
 It would seem reasonable to adopt some set of
 conventions like this for the
 sorts of code modules we're discussing here.  That
 way, people whose itch is
 creating shareable modules have a place to showcase
 their wares, and people who
 would rather reuse than write have a place to
 "shop".
 
 As long as you avoid a rule that there will be only
 one kind of FOO in the
 library, that should avoid most of the potential
 conflict issues.
 
 In order to make this work, someone(s) needs to step
 up and organize the basic
 infrastructure, but after that it can be fairly
 self-sustaining.  (And maybe Sam
 can extend Gump to see which individual modules are
 being used in which projects
 -- having your shared code selected by some other
 project is a pretty good vote
 on it's quality, plus an indication of who you
 should talk to before changing
 APIs ;-).
 
 
 
  geir
 
 
 Craig
 
 
 

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


=
Morgan Delagrange
Britannica.com

__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

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




Re: [POLL] Re: Code Sharing Concepts

2001-02-15 Thread Morgan Delagrange


--- "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 one
 could do to enforce
  API stability in an external way that makes sense.
  At some point, you
  have to trust someone involved with the project...
 
 
 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) inside those APIs.
 When changes ultimately do occur, they should be
 designed to minimize the pain
 of adapting (through techniques like providing
 convenience base classes that
 most alternative implementations would have started
 from).
 
 For a connection pool in particular, the relavant
 API (for my needs, at least)
 is javax.sql.DataSource -- I want to be able to plug
 in *any* connection pool
 that conforms to that interface and use it. 
 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 existing Turbine apps that use
 it, which would not be a
 Good Thing.
 
 But in the mean time, without a wrapper around it 
 -- I'm about 75% done with
 this, but unfortunately the wrapper will have to be
 bigger than the entire code
 for the Struts connection pool :-( -- the Turbine
 connection pool is not useful
 to me.  Whether it is in a shared repository or not
 makes no difference.

Supporting DataSources seems like a prerequisite of a
current database-pooling mechanism, but it would be
very useful to also support a pooling pseudo-driver. 
Otherwise, DriverManager-based clients to the database
pool (which may even include non-Jakarta projects)
will be required to reach into their code to use the
pool.  Pseudo-drivers are a very elegant way to
prevent that.

=====
Morgan Delagrange
Britannica.com

__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

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




RE: What is Jakarta?

2001-02-06 Thread Morgan Delagrange


--- Ted Husted [EMAIL PROTECTED] wrote:
 On 2/6/2001 at 11:26 AM Delagrange, Morgan wrote:
 Right, but the Jakarta PMC chairman objects to that
 definition.  
 
 I'm not sure if Sam Ruby has actually "objected" or
 not. It is evident
 that Roy Fielding has objected to the scope of the
 Jakarta Project. As
 it stands, the current mission given on the Web site
 is technically
 incorrect. If we want a broader scope, it's obvious
 that the ASF will
 require a board resolution to put things right. 

From Sam's comments, it seems pretty clear that he'd
rather expand the scope than start pruning
subprojects.

 If you make the definition of Jakarta this
 restrictive
 
 Jakarta's charter is * already * that restricted.
 The contract between
 the ASF and the Jakarta PMC reads that Jakarta is
 "charged with the
 creation and maintenance of open-source Java
 Servlet-related software
 for distribution at no charge to the public." 

Agreed, many Jakarta projects are currently out of
scope according to the current charter.

 As you pointed out,  the Jakarta PMC has exceed its
 original charter.
 The ASF board chairman has raised an exception, and
 presented two
 alternatives: (1) A broader charter or (2) More
 PMCs. 
 
 Some people seem to like the idea of a broader
 charter. Other people
 have said they don't. I'm just suggesting that as a
 followup to Roy's
 suggestion (2) that we consider whether chartering
 Java-Apache for the
 out-of-scope projects makes any sense. 

Thanks to Jon for clarifying the deprecation of the
java.apache.org domain.  The current Jakarta site
states:

  The older Java Apache Project will have its 
  projects merged into the Jakarta Project 
  in the near future (no set date). For more 
  information please see the announcement on that
  website. 

If this is still the case, fine.  If not, we need a
new plan of action, since clearly java.apache.org
needs to go away.

 Really, if you limit the scope of the Jakarta
 project to Servlet-based
 technologies, the list of in-scope projects is very
 short:
 
 But, is that a bad thing?

It's too specific.  See next comment.

 projects like Slide and Struts, which only deal
 with servlets in part
 
 I can't vouch for Slide, but Struts is definately
 Java Servlet-related
 software.

I didn't say there weren't servlet-related components
in Struts, I'm saying there's a lot more in Struts
than servlet stuff; hence you can easily argue that
Struts is not entirely in-scope.  Much of Struts deals
with servlets, but Struts also provides frameworks for
XML parsing and database pooling, correct?  Since
these are not specifically servlet-related, they would
have to be removed from the project.

I'm not arguing for Jakarta becoming the one giant
Java project, I'm just saying that a Servlet-oriented
charter is too inflexible.  I'd rather see a charter
that focuses on Java servers and related tools (and I
think Ant in particular may not fit, but that's
another argument).

- Morgan


=====
Morgan Delagrange
Britannica.com

__
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/

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