Re: [VOTE] HiveMind as a Jakarta sub-project

2004-03-08 Thread Craig R. McClanahan
 
 [X] +1  I support this proposal
 [ ] -1  I don't support this proposal
 [ ]  0  I abstain from voting for or against this proposal
 

Craig


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



Re: questions license for site documents

2004-03-03 Thread Craig R. McClanahan
Quoting Christopher Lenz [EMAIL PROTECTED]:

 
 You're not saying that the boilerplate text should appear as comment in 
 every generated HTML document, are you?
 

Yes, I am.  For the same reason that it's in every Java file.


 Cheers,
 Chris

Craig


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



Re: boilerplate LICENSE text in different formats

2004-03-03 Thread Craig R. McClanahan
Quoting Tetsuya Kitahata [EMAIL PROTECTED]:

 On Tue, 2 Mar 2004 13:37:48 -0500
 Shapira, Yoav wrote:
 
  I have started a wiki page  at
  http://wiki.apache.org/incubator/LicenseFormats  for boilerplate text
  in
  different formats.
  Cool and useful -- thanks ;)
 
 Ditto. :-)
 
 I'll try it out.

Looks good.  I just added a tweak that the XML format also works for HTML as
well.

 
 -- Tetsuya. ([EMAIL PROTECTED])
 

Craig


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



Re: questions license for site documents

2004-03-01 Thread Craig R. McClanahan
Quoting Tetsuya Kitahata [EMAIL PROTECTED]:

 On Mon, 1 Mar 2004 22:24:02 +
 robert burrell donkin wrote:
 
  i've had a quick google and i'm not sure that there's a consensus out 
  there on this. i like the idea of modifying the .vsl file and i'd be 
  inclined to add both formulations. maybe this would be a good question 
  to raise on community...
 
 Go ahead. I suspect it that we should modify site.vsl
 in either case. :-)
 
 If we decide to modify all the xml files in /xdocs/,
 appending link rel=license href=http://jakarta.apache.org/LICENSE/
 line would be more practical ... under /document/properties/ element.
 (generated htmls should have meta tag, link tag or something equivalent)
 

The instructions at the very end of
http://www.apache.org/licenses/LICENSE-2.0.html
describe *exactly* what to do to documentation files, and adding a link in the
manner you described is the wrong answer.

Instead, you should enclose the same boilerplate text at the top of each such
document that is included at the top of Java sources, enclosed in the
appropriate comment characters for your format (i.e. for XML, surround by
!--. and --, for properties files, prefix by #, and so on).

 -- Tetsuya. ([EMAIL PROTECTED])


Craig McClanahan



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



Re: jakarta-site karma?

2004-02-02 Thread Craig R. McClanahan
Quoting Erik Hatcher [EMAIL PROTECTED]:

 In order to finally make an official mirrored release of Lucene 1.3, I 
 need jakarta-site karma so that I can update binindex and sourceindex.
 
 Would the powers that be please grant me this?
 
 Thanks,
   Erik
 

Done.

Craig


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



Re: Differences

2004-01-22 Thread Craig R. McClanahan
Quoting Vadim Gritsenko [EMAIL PROTECTED]:

 Ted Husted wrote:
 
 Perhaps once most of the Committers are on the PMC list, we can move the
 administrative nonsense there again, and let the General list be the General
 list again :) 
   
 
 
 Looking forward to it. Do not remember when good flame worth reading 
 last happened on this list.
 

The last really good (by some people's definition, I guess) flame war happened
a couple of years ago ... and caused the subscription count on this list to
drop from 4000 to 1500 in less than a month.

It is currently 718.

 Vadim
 

Craig McClanahan


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



Re: [License] for jars in CVS

2004-01-02 Thread Craig R. McClanahan
Quoting Danny Angus [EMAIL PROTECTED]:

 
 
 
 
  I see what you are saying, but why is this an issue only with OGNL? Is it
 because of license
  incompatibilities? 'Cause there are other jars in CVS both Apache and
 non-Apache.
 Harish,
 
 It isn't only an issue with OGNL, it is a general issue which has been
 bubbling away for months.
 In principle it is not good to have Jars in CVS. In practice it makes life
 much easier for many people.

It also makes it more difficult for many other people -- especially those that
need to integrate lots of open source projects (with overlapping dependencies)
together.  The goal here is to ensure that all the modules you want to create
are built with (and tested with) the *same* versions of the common
dependencies, not the ones whose jars happen to be checked in to CVS for that
particular module.

You still need mechanisms to allow the developer to override the default
decisions checked in to the build scripts.  For nearly all of the I've checked
in jars for the convenience of developers packages I've evaluated for use fail
to allow such overrides, and hard code their build classpaths to point at the
checked in JARs only.

 There are moves afoot to produce some kind of
 jar download site which would provide the convenience of automated
 downloads with Ant or Maven, and comply with licence issues, and not
 require jars to be in CVS, cvs is not great at handling binaries.
 
 d.
 

Craig McClanahan


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



Re: [VOTE] ORO 2.0.8 maintenance release

2003-12-24 Thread Craig R. McClanahan
Quoting Daniel F. Savarese [EMAIL PROTECTED]:

 
 I know now may not be the best time to have a vote, but I would ask
 the PMC to vote on approving the release of jakarta-oro 2.0.8.
 The current code base contains important bug fixes and has gone too
 long without a public release.
 
 [X] +1  I approve the release of jakarta-oro version 2.0.8.
 [ ] -1  I do not approve the release of jakarta-oro version 2.0.8.
 

Craig McClanahan (as Jakarta PMC member)


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



RE: [VOTE] ORO 2.0.8 maintenance release

2003-12-24 Thread Craig R. McClanahan
Quoting Gary Gregory [EMAIL PROTECTED]:

  -Original Message-
  From: Daniel F. Savarese [mailto:[EMAIL PROTECTED]
  Sent: Tuesday, December 23, 2003 17:40
  To: [EMAIL PROTECTED]
  Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
  Subject: [VOTE] ORO 2.0.8 maintenance release
  
  [X] +1  I approve the release of jakarta-oro version 2.0.8.
  [ ] -1  I do not approve the release of jakarta-oro version 2.0.8.
 
 Gary Gregory
 (in a pending state, awaiting adding to the committee file)
 


Do you mean you're awaiting commit karma on the jakarta-oro repository?  If so,
cnan you (or anyone) point me to a vote thread electing Gary as a committer? 
With that I can add you immediately.

Craig McClanahan


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



Re: Jakarta: Confederation or Single Project?

2003-12-19 Thread Craig R. McClanahan
Quoting Harish Krishnaswamy [EMAIL PROTECTED]:

 Thanks Craig, this is elaborate, informative and puts the issue in my
 perspective. May be this 
 should be put on the website too somewhere.
 
 Here are my inferences so far...
 
 inferences
 ASF is a group of projects administered by the Apache board members. The
 board delegates certain 
 responsibilities over to the PMCs of the individual projects while still
 maintaining the authority 
 and management responsibilities. The PMC is responsible for a wholesome code
 and community of the 
 project it oversees but does not have the authority to recognize new
 projects.
 
 Jakarta started out as a single project for a web container and has grown
 into a foundation of 
 projects in itself without sufficient administration/organization.
 /inferences
 

Waiting for the bureacracy to be created first is kind of antithetical to the
way most open source developers think :-).

 Here are my thoughts distilled from a lot others'...
 
 * I think the projects at ASF should be classified in some way (preferably by
 technology like we 
 have now for xml, db etc.) into umbrella projects. All projects piled
 together at the top level 
 would not convey very well. This is where Jakarta would need redefinition.
 Seems like the inital 
 motivation, server side web development, is a good fit. And that would mean
 some reshuffling.

The problem with graph shaped (single inheritance) hierarchies is that
sometimes a single project fits more than one place.  For example, where do you
put Cocoon?  It's clearly a thing that fits into an XML Technologies sort of
place.  It's also a thing that clearly fits into a server site technologies
sort of place.  The answer that Cocoon chose (the right one, IMHO) was to be a
separate TLP that is *linked* to both of those technology's web sites.

But, the more fundamental principle is that the legal organization of the ASF
need not have anything at all to do with how websites are organized and how
projects are made visible.

 * I think each umbrella project or each project within could have a PMC and
 each project should 
 maintain a PMC membership of atleast 51% of its committers to sustain.

That's pretty much the way that Jakarta works now (we've focused on expanding
the PMC membership over the last year to ensure coverage from all the
subprojects).  But, as a Jakarta PMC member, it's still a daunting thought to
be held responsible for oversight of all the code, and all the releases, across
all of Jakarta.  It's hard enough for me, for example, just to stay current on
the three projects I watch and try to participate in (Commons, Struts, Tomcat).
 I'm pretty clueless about what the Tapestry folks are doing, yet *I* need to
approve releases?

Having Tapestry committers on the PMC helps, but isn't sufficient.

 * I think the website should match the organizational structure to avoid
 confusion.

I don't agree.  The website(s) should be focused around making it easy for users
to  find out what Apache projects might have products that are relevant to
their needs.  The internal project organization is an implementation detail.

 * I think the board should classify the newly adopted projects. Projects that
 churn out of existing 
 projects should be brought back to the board for classification at the time
 of creating new CVS 
 repositories.
 * Each umbrella could have a commons and a sandbox to share and play.
 * There could be a top level commons to house cross-umbrella components.
 
 It seems like what we now have is pretty much in good shape and only means
 that the following 
 actions take place...
 
 * Reorganize Jakarta (and may be others??)

The interesting question is what Jakarta becomes after the subprojects that want
to become TLPs do so.  I suspect that keeping it as a brand is likely to be
helpful, but the brand has been pretty muddled too (is it Apache Struts or
Jakarta Struts?  Depends on which book title you read :-), and the earlier
perceptions that Jakarta had for high quality server side Java code is starting
to slip.

 * Enforce project level PMC membership
 

IMHO, it's just not good enough to satisfy the oversight requirements delegated
to the PMCs by the ASF Board.

 Just my thoughts.
 
 Regards,
 Harish
 

Craig


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



Re: Confused with PMCs, TLPs, ASF and Power?

2003-12-18 Thread Craig R. McClanahan
Quoting Stephen Colebourne [EMAIL PROTECTED]:

 Then try this:
 
 http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCPropsedChanges
 
 It aims to be a starter course on why discssions about PMCs, TLPs, Jakarta
 and the ASF appear, and possibly how they affect you. Be aware of the
 disclaimer at the top, however trying to distill any controversial topic to
 one page always ends up annoying someone.
 
 Stephen
 

Stephen,

Thanks for taking the time to attempt condensing an incredible amount of email
(on an incredible number of mailing lists) down to a single page that
highlights the key issues.

I wanted to let you know that I just committed a small patch to the Wiki page --
where you said Note also that Struts committers have no rights to vote I
added the parenthetical statement (unless they are also members of the Jakarta
PMC) which is true for several of us.  Indeed, the Jakarta PMC has been
growing lately in a deliberate attempt to encompass committer representation
from more Jakarta subprojects.

Craig


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



Re: Jakarta: Confederation or Single Project?

2003-12-18 Thread Craig R. McClanahan
Quoting Harish Krishnaswamy [EMAIL PROTECTED]:

 Could someone please explain the motivation behind the creation of Jakarta
 and how it got to where 
 it is today? May be that would help answer some of the questions we have?
 
 -Harish
 

These comments are going to be (like anyone's would be) colored by my own
personal experiences during the development of Jakarta -- including my
ignorance of a lot of the details in subprojects that I'm not an active
participant.  But it should give you a little feel for the history of the
place.

The gist of the creation of Jakarta was around three facts:

* Apache wasn't an incorporated entity (this is about
  four years ago now), but wanted to be -- and was
  formally becoming the Apache Software Foundation.

* Apache had a project to build a servlet container
  (Apache JServ) at a website called java.apache.org
  which created a trademark-use issue around java.
  (I was a committer on Apache JServ, which is how I
  originally got involved in open source software.)

* Sun wanted to contribute, and Apache wanted to accept,
  the source code for the servlet and JSP implementation
  called the Java Servlet Development Kit, and later
  published by Apache as Tomcat 3.0.

Just as an item of slight historical interest, Jakarta was the name of the
conference room at Sun where a lot of the early discussions took place.

An organizational framework to focus on developing open source server side Java
stuff was created to host these initiatives, and other related subprojects got
proposed and added to the mix.  As the number of Jakarta committers scaled from
the original 10 or so to where we are today (hundreds), the original charter
has
become, umm, somewhat stretched.

Ironically, it didn't take long at all for the scope of that original charter to
get exceeded, because one of the little nuggets of code that was included in
the
original Tomcat contribution was a pure-Java build tool (to replace make)
called Ant ...

As more and more subprojects were added, there were some inevitable cases of
overlapping scope, and overlapping implementations of the same ideas.  One of
the best things we've done (IMHO) was purposely creating a subproject
(jakarta-commons) focused on making small, focused, reusable packages, and
encouraging the larger projects to use them.  Not only has this been successful
within Jakarta -- there's been quite a lot of cross-fertilization among the web
app frameworks, for example -- it's also created a fairly rich library of
funcational packages that are widely used elsewhere.  But one could really
argue whether something like Commons Digester (originally designed as an
easy-to-use tool to parse XML configuration files) really fit the Jakarta
charter.

Over time, there have been more than a few, err, voluminous discussions about
how to scale up Jakarta from an organizational perspective, and whether the
fundamental organizing principle was still the correct one.  Does a focus on
server side stuff exclude what could be some really interesting open source
projects?  Does a focus on Java make sense when just across the website there
are things like xml.apache.org that are focused on a technology, not on an
implementation language?  Does it make sense to have community type projects
that host individual software package projects at all?

Coupled with these increasing concerns (at the ASF board level) about the
ability of any oversight group (a responsibility delegated to PMCs in the ASF
organizational structure), several original Jakarta subprojects (or even
sub-sub-projects in some cases) like Ant, Maven, and James decided to become
top level projects (TLPs) of their own -- this takes making a formal proposal
to the ASF Board that gets accepted, and the formation of a PMC for that
project.  Those sorts of discussions continue to this day.

Somewhat separately, but overlapping in time, it became clear that there needed
to be a way to incorporate new developer communities (and in some cases
existing codebases that were being contributed) into Apache.  The developers
(if they weren't Apache committers already) needed to learn the Apache way to
do things.  The code (if any) needed to be vetted for appropriate contributor
agreements to protect both the ASF and those that rely on our code.  Thus, the
incubator project was created as a place for these things to happen.  It is
also actively evolving.

personal-view
To a large extent, the stresses that are felt as the ASF grows are actually a
result of our success, and should not be looked at as signs of failure.  I
remember a statement from a consultant that one of my employers brought in
along the way to deal with some important decisions when we had no consensus at
all:

  The absence of stress is death.

So, here's to having some more stress!  :-)
/personal-view

Craig


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

RE: Why you *want* to be on the PMC

2003-12-18 Thread Craig R. McClanahan
Quoting Noel J. Bergman [EMAIL PROTECTED]:

 Henri Yandell wrote:
 
  If all the PMC's share the same website, who is responsible
  for the website as a global concept. For example, the need
  to do mirrors.
 
  If a Jakarta-Site PMC exists, all other PMCs [jakarta sub-project based]
  are accepting the Jakarta Site PMC's oversight over their websites.
 
 How do you think the Jakarta site works already?  The site2 module is just
 the core Jakarta site.  All of the projects already have their own sites
 in their own CVS, which are then checked out under the
 /www/jakarta.apache.org/$project.

And all of those $project sites are under oversight of the Jakarta PMC.  There
is no such thing as a jakarta sub-project based PMC.

 Nothing would have to change, unless a
 project *wanted* a new domain, from what I can see.  Am I missing your
 point?  I'm just not seeing the problem.
 

Although I'm  sympathetic to the idea that Jakarta sub-projects who then become
TLPs might want to maintain their jakarta.apache.org/$project web site for
brand identification purposes, I'm concerned about the potential for external
confusion over who's in charge here.  The reality would be that the Jakarta
PMC would (correctly) *not* think they had management over that subdirectory of
the site, but the legal distinction would be very likely missed by anyone who
is visiting.

If/when Struts becomes a TLP, I'm going to recommend that we do exactly what
Ant, James, and Maven (for example) did:

* Maintain a link on the Jakarta home page under Related

* Install a webserver redirect from http://jakarta.apache.org/struts
  to http://struts.apache.org.

   --- Noel

Craig


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



Re: [Proposal] HiveMind Service Framework

2003-11-11 Thread Craig R. McClanahan
Quoting [EMAIL PROTECTED]:

 Part of the proposal indicates the jakarta-commons is not the right home for
 HiveMind, as it does not fit in with the charter of the commons (too many
 dependencies, etc.).
 

Even if it were proposed that Hivemind stay in jakarta-commons, I do not share
Martin's concern.  There have been several cases where a number of
new-to-Jakarta committers have joined, and (because of the technical
limitations of our permissions infrastructure) have been granted
jakarta-commons karma to work on the package they are interested in.

In practice, this has not caused any problems.  If we are still concerned that
it might, we've got a jakarta-commons infrastructure issue to deal with, not a
concern about any particular package and its associated committers.

 --
 [EMAIL PROTECTED]

Craig


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



Re: Changes to the jakarta-site

2003-09-04 Thread Craig R. McClanahan
On Thu, 4 Sep 2003, Henning Schmiedehausen wrote:

 Date: 04 Sep 2003 10:49:50 +0200
 From: Henning Schmiedehausen [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: Jakarta General Mailinglist [EMAIL PROTECTED]
 Subject: Changes to the jakarta-site

 Hi,

 I'd like to put some update about the Turbine project and also yours
 truly into the jakarta-site. Unfortunately, I lack the necessary karma.
 What can I do / whom must I contact to change this?


I've granted karma on the jakarta-site repositories for you.

 I've attached two patches that I'd like to see applied. :-)

   Regards
   Henning


Craig


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



Re: Issues with XMLBeans proposal

2003-07-03 Thread Craig R. McClanahan

Snipping to an issue I have with one particular comment.

On Thu, 3 Jul 2003, Andrew C. Oliver wrote:


 In summary the most serious issues to this proposal are:

 1. diversity of committership.  I'd personally like to see 51% of the
 ACTIVE committership from a different company.  So long as a decision in one
 company can MAKE the vote, you don't have an Apache project, you have a
 corporate subproject at Apache.


Andy, I agree with you that diversity is important, but your proposed
standard (more than half the committers from elsewhere) has some
distrubing implications that are worth exploring.

* There is an implied assumption that the proposed committers
  will behave the way that their employer wants, not the way
  that they want.  Although it is too simplistic to say that
  this never happens (our individual actions are public record,
  so of course you take into consideration what your employer
  might think), developers that are solely corporate mouthpiece
  players should never have been elected as committers
  in the first place.

* There is an implied assumption that all the committers from
  the same company will vote the same way.  I can tell you from
  lots of experience over the last few years (some of it pretty
  painful and personal) that this is not likely to be a problem.
  If it is, then we screwed up on accepting the original committers
  in the first place.

* There is an implied assumption that a person's employer (and therefore
  their corporate email address) should have anything to do with
  whether or not that person is individually a good choice for being
  an Apache committer.  THAT should be the overriding concern -- after
  all, they will be able to stay a committer even if they move to a
  different job (within the same company or elsewhere).

* What happens to your diversity statistics if a committer that was
  originally outside the originating company is then hired by that
  company to continue working on the project?  One of the company's
  goals might well be to support open source by allowing that person
  to work on the project on company time; yet your proposed standard
  would view the change of employment as a negative and not a positive.

Apache is about individuals, not about companies.  Apache is about
attracting high quality software projects, not about conspiracy theories
(go back in the archives a couple years before you joined, and you'll see
LOTS of discussion along these lines :-).

Diversity is important -- a proposal that ONLY has committers from one
company needs to be analyzied.  But a proposal that includes a software
contribution from a company, but WITHOUT any committers from that company
willing to continue working on the software (the throw it over the wall
scenario) would also be problematic.

Simplistic standards like  51% of the ACTIVE committership from a
different company might work for making simplistic decisions.  They are
not appropriate for a decision to accept a new project into Apache, which
should be based on the quality of the proposed code and the proposed
initial committers, not on the email addresses of the proposed initial
committers.

Craig McClanahan

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



Re: Proposal: Jakarta should protect community email addresses

2003-06-27 Thread Craig R. McClanahan


On Fri, 27 Jun 2003, Andrew C. Oliver wrote:

 Date: Fri, 27 Jun 2003 11:26:04 -0400
 From: Andrew C. Oliver [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: Jakarta General List [EMAIL PROTECTED]
 Subject: Re: Proposal: Jakarta should protect community email addresses

 I'd be all of this if it would make a difference, unfortunately you're
 barking up the wrong tree.  I'm getting that virus/attachment to every email
 address I have just about.  I think it looks locally (user address book,
 etc).

That is exactly what happens with this particular worm.  If your address
is in the address book of someone who gets infected, not only do *you*
start to receive the messages, messages with forged from headers with
your name on them also go out.  Then, the volume of messages is made worse
by all of those helpful spam filters that catch the fact that the virus
is included, and return a notification to the (forged) sender.

Obscuring email addresses in the archives would have zero impact on this
particular problem.

Craig (just cleaned out about 300 of these from this morning's mail)


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



Re: Adminitrivia: Assigning new bugs to the list

2003-04-04 Thread Craig R. McClanahan


On Fri, 4 Apr 2003, Howard M. Lewis Ship wrote:

 Date: Fri, 4 Apr 2003 10:44:26 -0500
 From: Howard M. Lewis Ship [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: Jakarta General List [EMAIL PROTECTED]
 Subject: Adminitrivia: Assigning new bugs to the list

 Currently, new Tapestry bugs are all assigned to me, personally.

 I would prefer that new bugs be assigned to the Tapestry developer list.

 Is there a way to do this cleanly in BugZilla, or do I create a fake user
 ([EMAIL PROTECTED])?


The latter is how we've done it for several other projects, and seems to
work fine.  You'll probably want to disable the fake user's login after
it's created, so that nobody accidentally uses that account.

Craig

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



Re: [PATCH] promoted sub-projects

2003-03-19 Thread Craig R. McClanahan


On Wed, 19 Mar 2003, Danny Angus wrote:

 Date: Wed, 19 Mar 2003 10:11:17 -
 From: Danny Angus [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: Jakarta General List [EMAIL PROTECTED]
 Subject: [PATCH] promoted sub-projects

 Although I've got karma I thought I should get some kind of opinion..

 This patch moves ANT, AVALON and JAMES links from the sub-projects into a new menu 
 section promoted.

 Should I apply this, or just remove James and Avalon (ant is already gone), or do 
 nothing, or do something different?


Personally, I'd vote for Promoted -- even though my head knows better,
my fingers still go to jakarta.apache.org first for Ant updates :-).

 d.


Craig

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



Re: Jakarta: too many similar projects?

2003-03-11 Thread Craig R. McClanahan


On Tue, 11 Mar 2003, Andrew C. Oliver wrote:

 Date: Tue, 11 Mar 2003 22:09:14 -0500
 From: Andrew C. Oliver [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: Jakarta General List [EMAIL PROTECTED]
 Subject: Re: Jakarta: too many similar projects?

 Thanks Pier.  Thats a great perpective.  Lets have some more.

 Anyone have a remarkably positive Gee the JCP listens to everyone and I
 can disclose everything to my fellow committers and its been great for
 our community?

Andy seems to believe that *implementing* a specification (as opposed to
creating one) is not a valid itch to be scratched if he doesn't like the
mechanism by which the specification is created.  It's perfectly
reasonable for Andy to decide that for the projects he gets personally
involved in, but it seems awfully arrogant to argue that no one at Apache
should involve themselves in such an implementation project on that basis.

As it turns out, there is substantial room for innovation and debate in
the implementation of API specs like servlet and JSP (see the history of
Tomcat development, and the recent innovation going on there for an
example), just like there is lots of room to be creative in implementing
something like HTTP, which has been done, and continues to be done, in
a very large number of implementations in a very large number of
languages -- despite the fact that the W3C standards process, like many
others, includes periods of time when only the privileged few are
allowed to be involved.

 -Andy

Craig McClanahan


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



RE: Karma request jakarta-site2

2003-02-27 Thread Craig R. McClanahan


On Thu, 27 Feb 2003, Howard M. Lewis Ship wrote:

 Date: Thu, 27 Feb 2003 14:33:13 -0500
 From: Howard M. Lewis Ship [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: 'Jakarta General List' [EMAIL PROTECTED]
 Subject: RE: Karma request jakarta-site2

 I'd like to join the bandwagon.  I would like karma and permission to
 advertise major Tapestry releases on the Jakarta main page.


Also done.

Howard, the procedures to update the Jakarta web site are documented at:

  http://jakarta.apache.org/site/site2.html

which is (recursively :-) generated from file
xdocs/site/jakarta-site2.xml in the jakarta-site2 repository.  You
won't be able to do the Modifications of the Website step, which
actually updates the web server's HTML pages, without a login account on
daedalus -- contact [EMAIL PROTECTED] for that -- but any changes you make
and check in to jakarta-site2 will be reflected when the next person who
can performs that last step.

Craig

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



Re: Karma request jakarta-site2

2003-02-26 Thread Craig R. McClanahan


On Wed, 26 Feb 2003, O'brien, Tim wrote:

 Date: Wed, 26 Feb 2003 19:12:51 -0600
 From: O'brien, Tim [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: 'Jakarta General List' [EMAIL PROTECTED]
 Subject: Karma request jakarta-site2

 Was trying to add my name to the whoweare.xml list.  Could I get some karma?


Done.


 
 Tim O'Brien


Craig

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



Re: Licensing again.

2003-02-10 Thread Craig R. McClanahan


On Mon, 10 Feb 2003, Timothy Halloran wrote:

 Date: 10 Feb 2003 13:43:24 -0500
 From: Timothy Halloran [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: Jakarta General List [EMAIL PROTECTED]
 Subject: Re: Licensing again.

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


People who *use* Apache code are free to use it in any way they want
(subject, of course, to the Apache license requirements).  That means that
they can incorporate GPL/LGPL code on their own -- no problems.  The user
of Apache software can even redistribute Apache+GPL code in a package if
they want -- nothing has changed there.

The issue at hand for Apache is what are the license terms that cover the
code that Apache *itself* distributes?  Users of Apache code, quite
naturally, will assume that the Apache Software License covers *all* the
code in that distribution.  That assumption is violated when a GPL/LGPL
package is included, and this matters a *lot* to organizations that, for
whatever policy reasons, choose not to utilize GPL/LGPL code.

Craig McClanahan

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




Re: Licensing again.

2003-02-09 Thread Craig R. McClanahan


On Sun, 9 Feb 2003, Ellis Teer wrote:

 Date: Sun, 09 Feb 2003 18:41:54 -0800
 From: Ellis Teer [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: Jakarta General List [EMAIL PROTECTED]
 Subject: Re: Licensing again.

 Ditto plus some,

 Seeing the license issues discussed is also of interest to end users who
 are under that license.  And for list members are faced with similar
 issues in other projects.


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.

Craig McClanahan

PS:  Yes, I am an ASF member, and therefore one of those owners.

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




Re: [Fwd: Maven as a top-level apache project]

2003-02-06 Thread Craig R. McClanahan

On Fri, 7 Feb 2003, Dan Diephouse wrote:


 4.  Can ASF Projects use Sun BCL licensed products?

 Yes, but ASF can't distribute them.


Each product you download from Sun's java.sun.com web site has a license
that you have to agree to in order to download that JAR.  In the case of
several commonly useful packages (including, for example, JavaMail, JAF,
and the JDBC 2.0 optional package (jdbc20ext.jar)), the license terms
allow you to redistribute the JAR under a set of conditions that you need
to agree to by accepting the license agreement -- the fundamental issue
that affects this discussion is that you cannot distribute it
*separately*.  (See the individual licenses for other requirements.)

Including such JARs in a product, like Tomcat or James (for example) do,
is fine.  Checking them in to an Apache CVS repository is not fine
(because it is then available individually to anyone with CVS access;
given that Apache repositories offer anonymous CVS access to anyone who
follows the instructions, that is clearly a problem).

Note that it is perfectly acceptable for *you* (as someone who wants to
build a package that includes the Sun JARs whose license allows
redistribution) to download your own copy of these packages (after
agreeing to the license terms), and include them in the distributions of
your own package.  If you are using an automated build tool, you should
configure it to utilize repositories where you are satisfied that *your*
compliance with license requirements is appropriately dealt with.

If you have any questions on the terms of the Sun BCL license for a
particular package, and how they apply to you, go to the appropriate
download page, such as:

  http://java.sun.com/products/javamail/

and click the download link.  Then *read* the terms and conditions of the
license agreement that is displayed, rather than just blindly accepting
it, or believing what anyone else says about it.  We are all responsible
for our own behavior, and ignorance of the requirements is not a legally
defensible excuse.

 Dan Diephouse

Craig McClanahan


PS:  You should note that Apache Software Foundation downloads are subject
to a license, just like downloads from most software providers.  In the
case of Apache-originated packages, the license is the Apache Software
License, Version 1.1 -- a copy of which can be found at:

  http://www.apache.org/LICENSE

Just because the terms of this license give you lots of latitude in how
you use the software you download does *not* absolve you from meeting the
requirements that are outlined there.


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




Re: No reply from root

2003-01-24 Thread Craig R. McClanahan


On Fri, 24 Jan 2003, Jeffrey Dever wrote:

 Date: Fri, 24 Jan 2003 12:22:01 -0500
 From: Jeffrey Dever [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: Jakarta General List [EMAIL PROTECTED]
 Subject: No reply from root

 I am the release prime for the commons-httpclient component.  I have
 made several attempts to have a user added as a committer, but there is
 no response from multiple requests to [EMAIL PROTECTED]

[EMAIL PROTECTED] is several people, all of whom are pretty busy, and
supporting the Apache infrastructure is done at the expense of their sleep
hours :-).  Sometimes it takes a couple of days.

I will forward the new account request again to make sure it doesn't fall
through the cracks, and then set up the CVS commit karma correctly when
the account is set up.

Craig


 Can someone please:
 1) determine if someone is actually reading the mail sent to root.
 2) create a committer account for this very deserving contributor.

 New committer: Oleg Kalnichevski [EMAIL PROTECTED]
 Project: Jakarta Commons HttpClient
 Userid: oleg
 Voting results:
 +1 Jeff Dever [EMAIL PROTECTED]
 +1 Dion Gillard [EMAIL PROTECTED]
 +1 Ortwin Gluck [EMAIL PROTECTED]

 Thanks,
 -jsd


 --
 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: Forum Software.

2003-01-22 Thread Craig R. McClanahan


On Wed, 22 Jan 2003, Robert Simmons wrote:

 Date: Wed, 22 Jan 2003 18:52:12 +0100
 From: Robert Simmons [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: Jakarta General List [EMAIL PROTECTED]
 Subject: Re: Forum Software.

 Then how do you answer the following issues:

 1) The vast majority of Jakarta users will not want to be inundated with
 email on a daily basis. They either wont bother to read it or will
 unsubscribe. This will ultimately cost us hundreds of potential developers
 that might have wanted to work on a part of a project but didn't know about
 the issue.


If users can't be bothered to figure out how to use folders and filter
rules, they are perfectly free to use the various mail archive sites to
search through the messages for previously posted information.

An alternative to folders+filters for folks who have crippled mail readers
is to subscribe in digest mode instead - that way you only get one message
per day per list.

A third alternative, as others have pointed out, is to use sites that
mirror the mailing lists as newsgroups.

 2) The emails are intrusive and disruptive. Its as bad as getting
 advertising. You care for a while but then after a couple days of deleting
 conversations not relevant to you. Subsequently you stop answering questions
 and then you just unsubscribe. This means other users don't have the benefit
 of your expertise.


Forums are totally useless to me, becuase it forces me to go *ask* to
participate.  Mailing lists get fed to my machine (nicely filtered into a
folder for each list, with the default sort sequence set to threading) in
the background, and I can go scan a few messages from interesting lists
whenever I feel like it.  No mailing list message is *ever* sitting in my
INBOX, so they don't bother my normal flow.

To say nothing of the fact that, since I operate quite often from a
laptop, I can read and answer mailing list messages when I'm offline and
then send them later when I reconnect.

 3) The lack of a complex search engine makes looking for information a hit
 and miss gesture at best. The archive search engines just aren't sufficient.


Search engines for forums can't do any better when the keywords you are
looking for are not present in the underlying messages.

 4) Mailing lists exclude non-developer casual users of the software from
 being able t ask questions. If they do subscribe to one, especially for a
 popular product, they get blasted with hundreds of emails they don't care
 about. After they get their specific question answered, than they
 unsubscribe to the list. This robs the list of other qualified people to
 answer questions. Say, for example, I was an advanced Ant user and
 subscribed t the list to ask a question about writing my own tasks. Once I'm
 answered, if ever, I unsubscribe to the list. Now all the knowledge in my
 head that I could have given to another user asking a question is out of the
 community. On the other hand, if there was a forum, I could pick and choose
 what to reply and not be intrusively bothered with questions that I don't
 care about.


I've been a heavy participant in STRUTS-USER (2616 subscribers) and
TOMCAT-USER (2410 subscribers), the two largest user lists at Jakarta, for
many years, and have not had your experience.  Proper configuration of
your mail reader can give you the organization and sorting capabilities
that you like about forum based software, without eliminating the
advantages for people like me.

 All of this boils down to the best communication strategy for an online
 project. That would be Bugzilla + forum software.


Well, the mailing list volume would certainly go down by the number of
questions *I* would not be answering any more if the user lists switched
to forums.

 -- Robert


Craig McClanahan



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




Re: New Jakarta proposal: Pluto

2003-01-21 Thread Craig R. McClanahan


On Tue, 21 Jan 2003, Costin Manolache wrote:

 Date: Tue, 21 Jan 2003 11:31:32 -0800
 From: Costin Manolache [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Re: New Jakarta proposal: Pluto

 Alex McLintock wrote:

  At 17:41 21/01/03, you wrote:
 One more question: why not doing this as a subproject of JetSpeed ?
 It is an existing jakarta project, the scope matches - why
 creating a separate jakarta community instead of joining the
 existing one ?
 
 
  I assume that it would be a tool which could be used by the Cocoon portal
  system, and a Struts portal system as well as Jetspeed which is
  essentially a Turbine portal system. People may want to use this component
  without using Jetspeed. Of course I haven't read the JSR yet.

 My understanding was that Jetspeed goal is to implement a portal - with Java
 and XML.

 I would rather see all portal systems sharing a single community and
 implementing similar behavior/standards - rather than have one portal for
 each technology ( struts, cocoon, turbine, tapestry, plain JSP, plain
 servlet, whatever else toolset ).


One thing to remember is that JSR-168 is only standardizing the interface
between a portal server and the portlets it calls (just as the servlet
spec only defines the interface between a servlet container and the
servlets).  The architecture of the portal server itself (or the servlet
container itself) is not being mandated.

Therefore, it's entirely reasonable to have a single portal server
implementation (created with whatever server-side technologies the
developers of the portal server choose).  But it's also reasonable to have
different portal servers with different feature sets, aimed at different
markets, if that is what folks want to do.  But, as Costin says, that
should *not* be driven by the technology used to implement the portal
server itself.

Where the frameworks need to get on board, IMHO, is making it easy to
create standard *portlets* using that framework's technology -- that way,
someone who wants to deploy a portal is not constrained to only using web
components implemented on a single particular framework.  And
portlet-based Struts applications (for example) could be plugged into
anybody's portal server as long as it supports the standard portlet API.

 Costin

Craig


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




Re: [discussion] jakarta-gump as community property

2002-12-19 Thread Craig R. McClanahan


On Thu, 19 Dec 2002, Sam Ruby wrote:

 Date: Thu, 19 Dec 2002 12:21:03 -0500
 From: Sam Ruby [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: [discussion] jakarta-gump as community property

 Gump is now two years old.  It has had contributions from over a dozen
 people, about a half-dozen this month alone.  There seems to be a
 renewed interest in gump (some in response to a little nudging grin).

 Considering all of this, what I would like to propose is that the
 contents of jakarta-alexandria/proposal/gump get moved to jakarta-gump,
 all committers to any jakarta code base be given karma and voting rights
 on the full contents (descriptors, code, and stylesheets alike) and that
 a single [EMAIL PROTECTED] mailing be created (we are all devs
 here, right?)

 Thoughts?


I like the idea of Gump becoming community property, but should it really
be only for Jakarta committers?  I'm thinking in particular about groups
like Ant and Avalon (recently graduated into full fledged Apache
projects), as well as the XML packages that Gump also watches over.

 - Sam Ruby

Craig McClanahan



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




RE: Short Apache licence for source files

2002-12-04 Thread Craig R. McClanahan


On Thu, 5 Dec 2002, Tim Vernum wrote:

 Date: Thu, 5 Dec 2002 10:12:37 +1100
 From: Tim Vernum [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: 'Jakarta General List' [EMAIL PROTECTED]
 Subject: RE: Short Apache licence for source files


 From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]

  OK, I think I understand slightly better but our license refers to
  this software not to any specific file.

 IANAL, IAN-Roy, IAN-ASF, but...

 The license does not give any indication of what this software is.
 i.e. It doesn't define the scope of the piece of work to which it applies.

 Thus when Roy said:
 'The problem with the 1.1 license is that it lacked a way to define the
scope of what was covered beyond this file.'

 It means just that - the 1.1 license doesn't define what it applies to.
 It refers vaguely to THIS SOFTWARE, but that's all.

 The concern is that if it is not directly included within the source files
 then the scope of THIS SOFTWARE is unclear.
 Does it include all the source?
 What about the included jars?
 What if those jars are not under the ASF license?

 This not the case in the GPL (http://www.gnu.org/licenses/gpl.txt) because
 Term 0 of the GPL defines (ot attempts to define) the scope of the work.

 My understanding is that License 2.0 will include a similar item (but I'm
 basing that on guesswork).


Current drafts of the 2.0 license include a solution to this issue, plus a
whole bunch of other niceties.  Discussions of the new license are
happening on a mailing list dedicated to that purpose.

In the mean time, I believe all Apache projects should treat the Board
member comments quoted above and elsewhere in this thread (and taken out
of much larger discussions) as authoritative direction to ASF committers
that we should use the long form of the ASF 1.1 license in every source
file checked in to Apache CV repositories.

It doesn't matter whether it's legally required (to get around the this
software interpretation) or not.  It matters that the ASF Board
(representing the foudnation, which is the owner of all this code) told us
to do it that way.  That's all the reason any of us should need.

 While it should be clear to normal people what this software means,
 lawyers have a nasty habit of not seeing the obvious :)


Craig McClanahan


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




Re: [xdocs] Bug report (fwd)

2002-11-25 Thread Craig R. McClanahan


On Mon, 25 Nov 2002, Henri Yandell wrote:

 Date: Mon, 25 Nov 2002 18:17:09 -0500 (EST)
 From: Henri Yandell [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: Jakarta General List [EMAIL PROTECTED]
 Subject: [xdocs] Bug report (fwd)


 I originally mentioned this on the Commons list, but as xdocs are used
 pretty heavily across Jakarta, I thought I'd try here too.

 I have a bug with the site generation. Either that or user-stupidity.

 I want a url in the xdoc file which has 's in.


What's worked for me is to just use the XML entity (amp;) instead of the
ampersand in cases like this.  Give it a try.

 If I just do it the html way, xdocs aren't handled as the parser complains
 about them and doesn't do an output file.
 If I do them the xml way and make them amp;, then the generator doesn't
 properly turn them into 's again for the html.

 Is there a solution? The url in question is the evil:

 
http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=RESOLVEDbug_status=VERIFIEDbug_status=CLOSEDemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Commonscomponent=Langshort_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitnewqueryname=order=Reuse+same+sort+as+last+time

 Hen

Craig


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




Re: karma for jakarta-site2

2002-10-04 Thread Craig R. McClanahan



On Fri, 4 Oct 2002, mohammad nabil wrote:

 Date: Fri, 04 Oct 2002 14:39:51 +0200
 From: mohammad nabil [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Re: karma for jakarta-site2


 hi,
 hope somehuman read any of my mails to jakarta community.
 i would like to help in any thing, but it seems that only
 mail machines read my email :s

 i hope to hear from any one alife at there :D


Mohammed,

The best way to get involved at Jakarta is to find one or more projects
you are really interested in, sign up for the developer mailing lists, and
start submitting patches and enhancements.  The general procedures are
outlined on the Jakarta web site, starting at:

  http://jakarta.apache.org/site/getinvolved.html

Welcome!

Craig


 -Mohammad Nabil

 From: Jeff Dever [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: karma for jakarta-site2
 Date: Thu, 03 Oct 2002 20:28:04 -0400
 
 I would like to add some info to the jakarta-site2 module.  Could somone
 hit me with the karma?
 
 Jeff Dever
 HttpClient 2.0 release manager
 
 
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]




 _
 Send and receive Hotmail on your mobile device: http://mobile.msn.com


 --
 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: [Poll result] Committers, who are we?

2002-10-04 Thread Craig R. McClanahan



On Sat, 5 Oct 2002, Pier Fumagalli wrote:

 Date: Sat, 05 Oct 2002 02:44:19 +0100
 From: Pier Fumagalli [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: Jakarta General List [EMAIL PROTECTED]
 Subject: Re: [Poll result] Committers, who are we?

 On 4/10/02 14:49, Andrew C. Oliver [EMAIL PROTECTED] wrote:

  I'd be more interested to hear statistics on how many people are
  California-based versus non-California based.  (It would help me with my
  research into Apache cultures and cliches ;-) for a paper I'm writing )

 More than being in CA, I would say, how many of us have been there and
 did the Silicon Valley thing... I'm saying that because I spent 2 years in
 CA, and feel strongly related to that environment... Only thing is now I
 live in London (UK)...


I appreciate the willingness of Pier (and others) to work there.  All I
can say is that *not* moving to the Bay Area was a condition of me
accepting my job at Sun ... :-)

 Pier


Craig McClanahan (happily working from Portland, Oregon)


--
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 Craig R. McClanahan



On Thu, 2 May 2002 [EMAIL PROTECTED] wrote:

 Date: Thu, 02 May 2002 14:24:58 -0700
 From: [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: Jakarta General List [EMAIL PROTECTED]
 Subject: Re: You guys are so funny.


 Berin Loritsch says:
  There are other dirty underhanded things that M$ did to get where it
  is today.  Don't try to compare us to M$.  We're not M$.


 Whenever someone tells me how much MSFT has done for technology, I
 can't help but think of how far we might have gotten if MSFT hadn't
 been so in the way all these years!

For all the nasty things Microsoft has done over the years, they have also
been pretty good at one particular thing -- asking their customers (and
potential customers) what they want, and listening to the answer.

It seems to me that authors of a build environment that they want
everyone to use would think about going and asking the potential users
(i.e. committers on various other projects) what their requirements are,
before any attempt (by those authors, or by anyone else as was the case
that started this particular flamefest) to shove it down everyone's
throats.

This is a characteristic of pretty much every company that gains long
term and/or mainstream acceptance for their products.  Too bad some open
source developers haven't learned that the same principles can apply here.

 Jeff Sexton

Craig McClanahan


--
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 Craig R. McClanahan



On Fri, 3 May 2002 [EMAIL PROTECTED] wrote:

  I think I've been saying this long enough. .  MERGE MERGE MERGE!

smiling
I can't help sitting here thinking about how the committers on projects
being told to MERGE MERGE MERGE must feel like two young adults whose
parents want them to get married (and have kids), but they don't even know
if they like each other yet ...
/smiling

Craig


--
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 Craig R. McClanahan



On Fri, 3 May 2002 [EMAIL PROTECTED] wrote:

 [snip]
 As for people shoving Maven down other people's throats, I'd like to know
 where the Maven developers have been doing that. From what I can see the
 Maven developers have been fairly balanced.


As I tried to point out in my parenthetical remark -- it wasn't the Maven
committers who started this whole thing ... it was our favorite iconoclast
himself (Jon), who seems to believe that anything that makes him happy
should make everybody happy, and anyone with contrary opinions is just not
with it enough to be worthy of being listened to.

Craig


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




Re: [New Subproject Proposal] ObjectBridge

2002-05-01 Thread Craig R. McClanahan



On 29 Apr 2002, Jason van Zyl wrote:

 Date: 29 Apr 2002 14:41:20 -0400
 From: Jason van Zyl [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: [New Subproject Proposal] ObjectBridge

 Hi,

 I would like to propose ObjectRelationalBridge
 (http://objectbridge.sourceforge.net/) as a top level subproject of
 Jakarta.


+1

Craig


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




Re: jakarta subproject scope (was Re: Quick! convert all your projectsto maven!)

2002-05-01 Thread Craig R. McClanahan



On Wed, 1 May 2002, Geir Magnusson Jr. wrote:

 Date: Wed, 01 May 2002 00:41:23 -0400
 From: Geir Magnusson Jr. [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: Jakarta General List [EMAIL PROTECTED]
 Subject: Re: jakarta subproject scope (was Re: Quick! convert all your
 projects to maven!)

 On 5/1/02 12:28 AM, John McNally [EMAIL PROTECTED] wrote:

  On Tue, 2002-04-30 at 20:38, Geir Magnusson Jr. wrote:
  On 4/30/02 11:31 PM, John McNally [EMAIL PROTECTED] wrote:
 
  I do not know where to locate Turbine's original charter and I think it
  is a good idea to try to follow it.  Are these published somewhere or
  should Turbine maintain it in its own documentation?  However the scope
  of a subproject is likely to grow/evolve over time.  Velocity does
  provide at least one servlet that allows it to be used to develop a
  webapp independent of any other framework.
 
  I think that's stretching 'webapp'  I guess tomcat does the same thing as it
  supplies servlets...  :)
 
  Well I would not be bothered if tomcat had developed a build system that
  it packaged as an independent entity with the idea that it might be more
  generally useful. Tomcat is a large project and they certainly could
  have had the itch. And if they promoted it occasionally what's the big
  deal.

 joke
 If you have ever built tomcat from source, you might wish they had a build
 system...
 /joke

 That used to be true - I don't know if it is anymore.

Actually, Tomcat *does* include a nice little build system for web apps --
in the Application Developer's Guide.  Among other things, it sets up your
compile class path to include everything Tomcat has in its shared
repositories (common/lib and so on) for you.  In the HEAD branch, and in
the 4.1.0 test release, it even includes custom Ant tasks that interact
with the Manager webapp to install, reload, and uninstall apps
dynamically.

The difference is that we don't badger people into using it -- their
choice.  :-)

 
 
 
  Struts is adding support for
  Velocity even though one of its primary reasons for being proposed with
  Turbine already existing was to limit the view to jsp exclusively.
 
  I think you are mistaken - we are building a toolkit to use Velocity as the
  view layer in Struts  Struts isn't adding any support AFAIK.
 
 
  Okay, I guess I could argue that developing a taglib (or something more
  elaborate) is outside the scope of a project around a template engine.

 We have one of those too. :)  Lets you do wacky things like

 jsp:useBean id=mybean  class=GeirBean /

 body
 vel:velocity strictaccess=true

  #set($mybean = $scopetool.getPageScope(mybean))

  #if(true)
 this is true!
  #end

  br

  $mybean.string

  br

 #foreach($item in $mybean.array)
 $item br
 #end

 /vel:velocity
 /body
 /html


Hey Geir, I though there weren't any scriptlets in Velocity?   :-)

  Except that I am arguing against such strict definition of scope.  And
  from what I saw I thought it was pretty cool.

 But I understand the point.  What we are hoping to do is to make
 tools/support so you can use Velocity templates as a view layer in Struts,
 so you have a choice about the view layer, like you do in Turbine.  :)  For
 us, it's all about making it easier to use Velocity as it isn't An Official
 Standard.

 This concludes the Velocity/Turbine/Struts plug-fest. :)


 --
 Geir Magnusson Jr. [EMAIL PROTECTED]
 System and Software Consulting
 POC lives!


Craig


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




Re: Java is dead... but it could still be saved!

2002-02-24 Thread Craig R. McClanahan



On Sun, 24 Feb 2002, Stefano Mazzocchi wrote:


 Gosh, I think I'll have to write my own programming platform one day to
 avoid all this.


I thought you already did ... you mean I *cannot* write device drivers and
run them on Cocoon?  Rats ...

:-)


Craig


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




Re: PMC Nomination - Craig McClanahan

2002-02-06 Thread Craig R. McClanahan



On Fri, 1 Feb 2002, Morgan Delagrange wrote:

 Date: Fri, 1 Feb 2002 16:16:55 -0600
 From: Morgan Delagrange [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED],
  Morgan Delagrange [EMAIL PROTECTED]
 To: General Jakarta [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: PMC Nomination - Craig McClanahan

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


I accept nomination for re-election to the PMC.

You can find out more about me on the Struts Who We Are page:

  http://jakarta.apache.org/struts/userGuide/volunteers.html

At Apache, I got involved in the Apache JServ project before there was a
Jakarta (along with other long timers like Jon, Pier, and Stefano), and at
the ApacheCon just after the Tomcat source code was finally handed over to
Apache, told James Duncan Davidson in front of several hundred people that
the Sun code sucked ;-). (Want proof?  Just go back to the sources for
Tomcat 3.0, but don't do this on a full stomach ;-).

Over the last couple of years, I've been a big-time contributor on Tomcat
(Catalina's architecture is basically what Apache JServ 2.0 was going to
be), Struts (I'm the primary architect), and Commons.  Along the way,
I've been somewhat less involved with Taglibs and Watchdog.  I'm also a
pretty good chunk of Apache's user support on the TOMCAT-USER list.

I believe in Apache's goals w.r.t. open sourcing Java.  I don't have a lot
of patience for diatribes and mailing list flame fests -- they tend to be
counterproductive to these goals.  Therefore, you'll see more CVS commits
than discussion participation from me when the topic strays in those
directions.  (Interestingly, the overall level of CVS commits seems to be
inversely proportional to the vitriol in the current discussions ...)

One last note -- as most of you are probably aware, I work for Sun.  If
that fact, by itself, affects your vote, then you need to think about how
much you really believe in Apache's credo that contributors should be
judged on what they do, not who they work for.  (I'm sure you can find
plenty of other reasons not to vote for me, if that's what you want ;-).


 - Morgan Delagrange


Craig McClanahan


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




Re: possibly bug with tomcat 4 vs oracle 8.1.7 ??

2002-01-29 Thread Craig R. McClanahan



On Tue, 29 Jan 2002, Giovanni Zorzan wrote:

 Date: Tue, 29 Jan 2002 17:17:00 +0100
 From: Giovanni Zorzan [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: possibly bug with tomcat 4 vs oracle 8.1.7 ??

 we try to use JDBCStore against a Oracle 8i database.
 the connection works (and tomcat insert some rows into table session), but
 in the log we have seen this:


This is a posting that should be directed to the TOMCAT-USER list, not
here -- subscription information, as well as documentation on what each
mailing list is for, can be found at:

  http://jakarta.apache.org/site/mail.html

Craig McClanahan


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




Re: BCEL project bug databas

2002-01-24 Thread Craig R. McClanahan

Stephen, I can help you get this set up.  Please send me offline what
you'd like for:
* Description of BCEL
* Identifier and description of each component (so people can
  submit bug reports against that component
* Version numbers to list in the bug database.

Craig McClanahan



On Thu, 24 Jan 2002, Stephen Cheng wrote:

 Date: Thu, 24 Jan 2002 17:22:44 +
 From: Stephen Cheng [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: BCEL project bug database

 Hello comrades,

 Is there a bug database for BCEL? I have found a bug in BCEL but
 unfortunately the project had not been added yet to
 http://nagoya.apache.org/bugzilla/.

 Thanks,
 Stephen


 --
 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: [PROPOSAL] POI @ Jakarta

2002-01-17 Thread Craig R. McClanahan

+1

Craig


On 17 Jan 2002, Andrew C. Oliver wrote:

 Date: 17 Jan 2002 14:45:26 -0500
 From: Andrew C. Oliver [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: general at jakarta [EMAIL PROTECTED]
 Cc: POI Development [EMAIL PROTECTED]
 Subject: [PROPOSAL] POI @ Jakarta

 Proposal for POI - A Jakarta Subproject
 version 1.0 - 17 Jan 2002

 (0) rationale

 The POI project seeks to provide pure Java APIs for reading, creating
 and manipulating files written in formats based on Microsoft OLE 2
 Compound Document Format.  The POI project has already successfully
 created a Pure Java OLE 2 Compound Document Format library (POIFS) and a
 port of the Microsoft Excel '97(-2002) file format (aka XLS, BIFF8) and
 tools for serializing XML in these formats (which will be hosted as part
 of Cocoon 2).

 The POI project user community is growing leaps and bounds in usage as
 evidenced by its position as one of the most active projects on
 SourceForge and the 2,290 people who have downloaded it so far this
 month.  The POI project currently has two active developers.  The
 development community  might be small but is fanatically committed (and
 growing rather  quickly).  It is likely that the upcoming port of the
 Microsoft Word 97 File format will increase the size of the development
 community, not to mention the user community.  The documentation is
 comprehensive and includes full documentation on the previously
 undocumented (or at least incompletely documented) Microsoft OLE 2
 Compound Document Format. There are also HOW-TO documents that
 illustrate use cases and examples. Lastly, The project founders have
 agreed to collaborate with a developer at the OpenOffice.org project on
 the Excel File Format Documentation.

 Many Jakarta projects could potentially take advantage of POI and its
 use in Jakarta will likely further seed the POI developer community.
 POI is a unique project in the Java world.  Up until now there have been
 no successful free attempts to provide read/write access to OLE 2 CDF or
 MS Excel (97+) file formats. POI coupled with other Jakarta technologies
 could produce some highly useful offspring.  A few specific examples
 might be Office Document indexing for Lucene, Velocity generating Excel
 and Word document presentations, Office document management capabilities
 for Slide as well as content delivery and editing in Turbine.

 POI would make it possible to use Jakarta and XML-Apache projects in
 many cases where currently a proprietary solution is currently required.

 (1) scope of the subproject

 The subproject shall create and maintain packages written in the Java
 language, intended for use in generating and reading files in formats
 based on the OLE 2 Compound Document Format.

 (2) identify the initial source from which the subproject is to be
 populated

 The initial packages would be based on existing POI codebase currently
 located at SourceForge:

 http://poi.sourceforge.net

 (3) identify the Jakarta resources to be created

 (3.1) mailing list(s)

 poi-user
 poi-dev

 (3.2) CVS repositories

 jakarta-poi

 (3.3) Bugzilla

 program - poi
 components - Web site, POIFS, HSSF, HDF

 (3.4) Jyve FAQ (when available)

 poi-general
 poi-poifs
 poi-hssf
 poi-hdf

 (4) identify the initial set of committers

 Andrew Oliver
 Marcus Johnson

 (5) identify apache sponsoring individual

 Stefano Mazzocchi
 --
 www.superlinksoftware.com
 www.sourceforge.net/projects/poi - port of Excel format to java
 http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
   - fix java generics!


 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]




Re: [PROPOSAL] Jakarta PMC bylaws change

2002-01-16 Thread Craig R. McClanahan



On Wed, 16 Jan 2002, Sam Ruby wrote:

 Date: Wed, 16 Jan 2002 14:27:54 -0500
 From: Sam Ruby [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: [PROPOSAL] Jakarta PMC bylaws change

 The number of PMC seats will be set at seven.  Annually, all seven seats
 will be up for renewal.  The ASF board will be asked to provide a person or
 persons to administer the nominations and a subsequent ballot. The
 administrator(s) will determine the mechanics of the voting procedures.
 Any committer to any Jakarta code base will be eligible to vote.  Once the
 new PMC is in place, the first order of business will be to determine a
 chairperson from amongst their ranks.

 Once ratified, this proposal would be effective immediately, and an
 election would be initiated.


+1

 - Sam Ruby



Craig


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




Re: commit mails not send

2002-01-12 Thread Craig R. McClanahan

Gerhard,

They went to the moderator queue, and I just OK'd them.  We'll fix the
mail permissions to let these go directly shortly.

Craig


On Sat, 12 Jan 2002, Gerhard Froehlich wrote:

 Date: Sat, 12 Jan 2002 18:02:02 +0100
 From: Gerhard Froehlich [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: Jakarta General List [EMAIL PROTECTED]
 Subject: commit mails not send

 Hi (Sam),
 when I commit things into jakarta-commons-sandbox
 no commit mails are send.

 Could [EMAIL PROTECTED] please check this?

 TIA
   Gerhard


 -
 Never share a foxhole with anyone
 braver than you are.
 -



 --
 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: Groupware Website Recommendations

2002-01-11 Thread Craig R. McClanahan



On Fri, 11 Jan 2002, Edson Alves Pereira wrote:

 Date: Fri, 11 Jan 2002 13:21:55 -0500
 From: Edson Alves Pereira [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: Jakarta General List [EMAIL PROTECTED]
 Subject: RE: Groupware Website Recommendations

   Sourceforge.net is free and it has mailing list, cvs, ftp, webhost.


CollabNet (employers of several familiar faces around here :-) is pretty
good at hosting this sort of thing too (NetBeans, OpenOffice, ...).

Craig


 Ted Husted [EMAIL PROTECTED] wrote:

 I'm working on an (unrelated) projects with some people, and wouldn't
 mind setting up an Apache-style collaborative environment.
 
 Just wondering if anyone has any personal recommendations for
 
 + A free groupware host, with calendar, mail-list/BBS, file upload that
 sort of thing.
 
 I know there are several but wondered if someone was using one they
 liked.
 
 + A private, fee-based sourceforge, where someone could collaborate on a
 private software project (I guess sourceforge may go fee-based, but I
 was wondering about someone who was already doing it).
 
 Of course, any place where you could setup some mailing lists and a CVS
 might work for the second. Just wondered if anyone was already doing
 that successfully for a reasonable price.
 
 
 -- Ted Husted, Husted dot Com, Fairport NY USA.
 -- Building Java web applications with Struts.
 -- Tel +1 585 737-3463.
 -- Web http://www.husted.com/struts/
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 
 
 --
 ///
 Better well done than well said.
  --//--
 To follow the path:
 look to the master,
 follow the master,
 walk with the master,
 see through the master,
 become the master.

 Modern Zen poem
 ///



 __
 Your favorite stores, helpful shopping tools and great gift ideas. Experience the 
convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

 Get your own FREE, personal Netscape Mail account today at 
http://webmail.netscape.com/


 --
 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: Code conventions

2002-01-09 Thread Craig R. McClanahan



On 9 Jan 2002, Andrew C. Oliver wrote:

 Date: 09 Jan 2002 00:07:00 -0500
 From: Andrew C. Oliver [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: general at jakarta [EMAIL PROTECTED]
 Subject: Re: Code conventions

  It's only two little lines extra to include the {}'s,
   Yeah, but those two lines will make my code run slower.
   Don't you know?
   The less space your source code takes, the less space
  your class file will take.
  And smaller classes run faster.
   It must be true - 90% of people I've worked with seem
  to live by that principle.
 
 Add to that the fact that if it was hard to write, it should be hard to
 read...

 :)

 Someone told me if you use a really small font like courier 6pt then
 you don't even need an optimizing compiler.


Thanks to this conversation, I finally did think of a good reason to use
braces on a separate line (which I detest, but that's just me) -- if your
manager judges you on how many lines of code you write, you get two free
lines for every if  statement.

:-)

 -Andy


Craig


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




Re: Commons Validator Packaging/Content

2002-01-07 Thread Craig R. McClanahan



On Mon, 7 Jan 2002, Sam Ruby wrote:


I continue to see the last 11 months as a period of progress.


+1

 - Sam Ruby


Craig McClanahan


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




Re: proposal for the jakarta startpage

2002-01-07 Thread Craig R. McClanahan



On Mon, 7 Jan 2002, Peter Donald wrote:

 Watchdog is TC specific - didn't know that ? Is it servlet/jsp specific or
 tomcat specific? Could it be reimplemented over the top of Cactus or is it
 tied to a specific infrastructure?


Watchdog is not Tomcat-specific - the validity tests should work on any
container that implements the appropriate servlet and JSP specifications.
It's based on the same tests that are in the J2EE compliance test suite
(CTS).

Craig


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




Re: crushed

2002-01-07 Thread Craig R. McClanahan



On 7 Jan 2002, Andrew C. Oliver wrote:


 This whole experience has become a bit disheartening.  Craig McClanahan
 who is like an idol of mine said this:

 
 We will continue to do what we've done in the past -- reject projects
 that
 only want the name recognition value of being under Apache, and don't
 have a development community compatible with Apache's style.  That's
 much
 more important than whether it's server-side versus client-side, or in
 one
 repository versus another.
 

 Seemingly directed at POI.

I know it's hard to tell from the convoluted way this thread have gone
back and forth, but the comment above was not intended to have *anything*
to do with POI specifically, or the proposal to move POI to Apache.  It
was a response to Ceki's concern about how to keep Jakarta from being just
a SourceForge-type code repository.

I'm trying to digest the discussions about POI, but they keep getting
buried in the discussions about Jakarta's future ... I haven't made up
my mind yet on this specific proposal.

Craig


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




Re: Jakarta Status [was Code conventions]

2002-01-04 Thread Craig R. McClanahan



On Fri, 4 Jan 2002, Ceki Gülcü wrote:

 
 - Sam Ruby
 
 P.S.  Food for thought: wouldn't it be nice if we could somehow merge xml
 and Jakarta?  Then discussions as to where POI should go would be moot.
 Gump doesn't care about these arbitrary distinctions, why should we?

 +1 on the principle of merging Jakarta and XML.

Agreed that it's definitely worth looking at.

 However, you realize
 there are technical considerations such as the look and fell of the
 merged web-site.

Sheesh ... just when I was starting to think that *nothing* could top the
rancor of arguing about coding conventions ... :-)

 Ceki Gülcü - http://qos.ch

Craig


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




Re: More abuse of coding styles...

2002-01-04 Thread Craig R. McClanahan



On Fri, 4 Jan 2002, Erik Hatcher wrote:

 Date: Fri, 4 Jan 2002 19:27:52 -0500
 From: Erik Hatcher [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: Jakarta General List [EMAIL PROTECTED]
 Subject: Re: More abuse of coding styles...

 Rule #1 from The Elements of Java Style is:

 Adhere to the style of the original


IIRC, we actually had this rule explicitly in the JServ code conventions
... looks like it didn't make the transition into the Jakarta docs though.

Craig


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




Re: Just the JARs

2002-01-01 Thread Craig R. McClanahan



On Tue, 1 Jan 2002, Ted Husted wrote:

 Date: Tue, 01 Jan 2002 14:54:30 -0500
 From: Ted Husted [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: Jakarta General List [EMAIL PROTECTED]
 Subject: Re: Just the JARs

 Geir Magnusson Jr. wrote:
  Putting aside *all* the stuff we are talking about for a moement, and
  looking at the simple notion of just having release jars available w/o docs,
  source, etc I don't think this is a bad idea :)
 
  However
 
  Any license issues?  Wouldn't we want to package the jar w/ a license ?

 This simple notion -- and my putting together a Jakarta release HOWTO --
 is why I opened this particular thread.

 The license issue is well taken. I think it would be a good practice for
 us to include a license in all of our JARs. Even when we don't
 distribute them seperately ourselves, they are intended to be
 distributed seperately by our licensees. Point noted.


How about including a copy of the LICENSE file in the META-INF
subdirectory of each JAR file produced by an Apache project?

 -Ted.

Craig


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




Re: Coding style addition

2001-12-15 Thread Craig R. McClanahan



On 15 Dec 2001, Kevin A. Burton - burtonator wrote:


 Perhaps.

 It might be a good idea to have a default recommendation or a global standard.

 ... anyway...


The most entertaining flamewars I've ever seen are atempts to gain
consensus on whether to use tabs or not, and then how many characters an
indent is :-).

 Kevin

Craig McClanahan



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




Re: Comment for Apache.org

2001-12-11 Thread Craig R. McClanahan



On Tue, 11 Dec 2001, robert burrell donkin wrote:


 if you want things to change, then you need to do something about it (am i
 sounding like jon? ;) if you were to answer newbie questions - to the best
 of your ability - then jon wouldn't have to make time to answer them.
 there's something in it for you too, since you'll learn far more by
 answering questions than you will by lurking. everybody would be a little
 happier.


This version of this same old thread isn't going to accomplish anything.

However, as a person who has been around Apache for a long time (including
working with Jon directly on Apache JServ), as a person who contributes a
lot of code also, and as a person who *does* take the time to do what
Robert suggests and answers user questions (striving to do so in a manner
that is polite and respectful, and *usually* succeeding at that), I'm
going to add one and only one comment.

I vastly respect Jon's contributions to Apache -- but I'm disappointed
that he doesn't seem to care that his approach to email makes the overall
community smaller than it otherwise would be (due to people not being
willing to deal with his style).

Now, I'm going to go back and start writing some more code (and answering
some more user questions).  I suggest we all do the same.

 - robert


Craig McClanahan


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




RE: Cross site scripting

2001-11-21 Thread Craig R. McClanahan



On Wed, 21 Nov 2001, Danny Angus wrote:

 Date: Wed, 21 Nov 2001 07:51:55 -
 From: Danny Angus [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: Jakarta General List [EMAIL PROTECTED]
 Subject: RE: Cross site scripting

 Craig wrote:
  That seems like a lot of extra work, and is unnecessary if all the dynamic
  output is processed appropriately.
 

 out of curiosity why do you say that, the unnecessary part?



IF 100% of the dynamic output (i.e. the part that an attacker might be
able to exploit) is generated by JSP custom tags (or equivalent, for other
technologies) that properly filter for dangerous characters, AND if your
static output is already immune to exploit (because the app developer
already checked it for vulnerabilities), THEN any effort exerted by the
container to filter *all* occurrences of  et. al., followed by
reconverting the safe  occurrences, is wasted.

IMHO, this is much more an application issue than a container issue.
However, Jon is asking for container-based solutions -- I guess that
requiring the use of Strut tags for all your output qualifies.  :-)

Craig


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




Re: Cross site scripting

2001-11-21 Thread Craig R. McClanahan

The code that Struts uses (which is probably closest to your proposed
getEscapedHtml() method) is the filter() method in
org.apache.struts.util.ResponseUtils.  But the mechanics (change any
occurrence of '', '', '', or '' to the corresponding escape sequence)
is the easy part of the problem.  The harder part is making sure that all
your webapps practice safe sex and use CSSCondom.  :-)

I don't know of any generic solutions to the getStrippedHtml() or
removeScriptTag() methods you propose - but are they still necesary if you
do the getEscapedHtml() processing on everything?

Craig


On Wed, 21 Nov 2001, Jon Stevens wrote:

 Date: Wed, 21 Nov 2001 00:49:36 -0800
 From: Jon Stevens [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: [EMAIL PROTECTED] [EMAIL PROTECTED]
 Subject: Re: Cross site scripting

 on 11/20/01 11:54 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote:

  However, Jon is asking for container-based solutions -- I guess that
  requiring the use of Strut tags for all your output qualifies.  :-)
 
  Craig

 Sigh. I am *not* asking for a container based solution.

 Because something got lost in your translation of what I'm saying, just to
 be clear, I'm asking for a library that takes a String as input and returns
 a String as output and provides the various encoding scheme's for preventing
 CSS attacks (it seems like none of them are a magic bullet, but combined,
 they do the job depending on the level of protection you need).

 Something like:

 public class CSSCondom
 {
 public String getEscapedHtml(String input);
 public String getStrippedHtml(String input);
 public String removeScriptTags(String input);
 }

 Velocity has a cool feature where you can attach what are called
 EventCartridges to items in the Context so that when they are rendered in a
 template, code is executed. This is similar to having a taglib bean return
 data that has been 'protected'.

 http://jakarta.apache.org/velocity/developer-guide.html#EventCartridge%20an
 d%20Event%20Handlers

 In this case, I'm developing a ReferenceInsertionEventHandler that would
 rely on this general CSSCondom library to help protect me from unwanted
 outcomes.

 Thanks.

 -jon


 --
 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: Using bzip2 for tarball

2001-11-19 Thread Craig R. McClanahan



On Tue, 20 Nov 2001, Tim Vernum wrote:

 Date: Tue, 20 Nov 2001 10:30:47 +1100
 From: Tim Vernum [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: 'Jakarta General List' [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: RE: Using bzip2 for tarball

 From: Daniel Rall [mailto:[EMAIL PROTECTED]]

  GOMEZ Henri [EMAIL PROTECTED] writes:
 
   What about using the bzip2 format for tarball along
   with gzip and zip format ?

  You have my +1, though I would instead recommend using bzip2 instead
  of gzip.

 +1 on adding bzip2
 -1 or removing gzip


I'm +0 on bzip2, but also -1 on removing gzip.

 Many (most?) non-linux users don't have bzip2 binaries, and forcing
 people to download the (somewhat larger) .zip files would most likely
 result in a net increase in traffic.


Beyond the size difference, zip files do not faithfully maintain Unix file
and directory permissions, leading to all sorts of niggly problems such as
unpacking things with executable shell scripts.


Craig


 --


 The information contained in this email is confidential.  If you are not the 
intended recipient, you may not disclose or use the information in this email in any 
way.  Macquarie Bank does not guarantee the integrity of any emails or attached files.


 --
 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: Integration

2001-11-02 Thread Craig R. McClanahan



On Sat, 3 Nov 2001, Frans Thamura wrote:

 Date: Sat, 3 Nov 2001 01:16:01 +0700
 From: Frans Thamura [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Integration

 Dear All,

 I see there is a lot of API in Apache... Jakarta and XML

 who resposible for integration, or is there a project for integrating of
 it..

 I think we need that. esp, the documentation..

 there is several issue said this..

 you must post this to this mailing list.. and bla..bla..bla..


Take a look at Alexandria http://jakarta.apache.org/alexandria.

This deals with the consolidated documentation problem, but you are
still going to be directed to the project-specific user lists for
project-specific questions.

 Frans

Craig McClanahan


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




Re: Distributing the JSSE

2001-11-02 Thread Craig R. McClanahan



On Fri, 2 Nov 2001, Guillaume Rousse wrote:

 Date: Fri, 2 Nov 2001 15:30:56 +0100
 From: Guillaume Rousse [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: Re: Distributing the JSSE

 Ainsi parlait Kasper Nielsen :
so this is an US export law issue and not a Sun License issue?
  
   I think so. It would be possible to distribute it but it would take a lot
 
  of
 
   work to get all paper work done and I think there was other conditions
   (ie must be us citizen, must get the connections from embargoed countries
 
  blocked
 
   etc)
 
  thats strange on http://java.sun.com/products/jsse/index-102.html they have
  a link to
 
  Download JSSE 1.0.2 global software and documentation with support for
  strong encryption.
 
  and a Download JSSE 1.0.2 domestic (US/Canada) software and documentation
  with support for strong encryption
 
  Don't know what the difference is, but I would imagine its legal to
  distribute something that is allready allowed to be globally distributed?
 Sofar no one answered this mail... Does US crytopgraphy export restrictions
 apply to both version of JSSE, or only to domestic version ? And do these
 restictions apply everywhere, or only for US-based download location ?

 Said otherwise, can jpackage project (jpackage.sourceforge.net) provide JSSE
 global version packages, as any other Sun java API packages, eventually only
 on non-US mirrors, or is it a special case ?

Crypto is different because of US export laws.  The Sun redistribution
licenses for JSSE have the same basic terms as the redistribution licenses
for the other Java APIs (see the license you had to click through to
download it for details.)

 --
 Guillaume Rousse [EMAIL PROTECTED]
 GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html


Craig


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




Re: Distributing the JSSE

2001-10-26 Thread Craig R. McClanahan



On Fri, 26 Oct 2001, Peter Donald wrote:

 Date: Fri, 26 Oct 2001 16:21:46 +1000
 From: Peter Donald [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Re: Distributing the JSSE

 On Fri, 26 Oct 2001 02:16, Kasper Nielsen wrote:
   Because the amount of paperwork needed to legally distribute it is
   hge. The US export laws do allow non-profits and indviduals to
   distribute crypto things but they have to jump through a few hoops and
 
  make
 
   sure they fill out oodles of stuff.
  
   Avalon was going to distribute it until Craig dropped a note on commons
   or ant list regarding this and gave a link. I followed it and it was much
   too much work to get it done legally so we dropped it. Craig do you still
   have that link ?
 

I cannot find the original link that I forwarded, but got it off the JSSE
web site.  It had to do with the still-existing registration requirements
for people who want to export crypto software.

  so this is an US export law issue and not a Sun License issue?

 I think so. It would be possible to distribute it but it would take a lot of
 work to get all paper work done and I think there was other conditions (ie
 must be us citizen, must get the connections from embargoed countries blocked
 etc)


Yep.

 --
 Cheers,

 Pete


Craig


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




Re: BCEL @ Jakarta

2001-10-25 Thread Craig R. McClanahan

+1

Craig


On Mon, 8 Oct 2001, Jason van Zyl wrote:

 Date: Mon, 08 Oct 2001 11:37:25 -0400
 From: Jason van Zyl [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: BCEL @ Jakarta

 Hi,

 Markus has just informed me that he has removed the GNU regexp dependency
 from the BCEL and is using the Jakarta Regexp package.

 I think it was generally agreed that the package is complete, highly useful
 and many people expressed an interested in having it be a Jakarta project.
 Markus has already made a first pass at organizing the source in a Jakarta
 like format and I have offered to help with the rest of work if we agree to
 accept the package into Jakarta.

 So, for the movement of BCEL to apache I would like to vote

 +1

 --

 jvz.

 Jason van Zyl

 http://tambora.zenplex.org
 http://jakarta.apache.org/turbine
 http://jakarta.apache.org/velocity
 http://jakarta.apache.org/alexandria
 http://jakarta.apache.org/commons



 -
 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]




Re: [VOTE] Making Commons-Cactus a top level projet

2001-09-15 Thread Craig R. McClanahan

I've set up the new top-level entry.  Let me know what components and
versions you would like set up, and I will do those as well.

Craig


On Sat, 15 Sep 2001, Vincent Massol wrote:

 Date: Sat, 15 Sep 2001 14:15:36 +0100
 From: Vincent Massol [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED], Vincent Massol [EMAIL PROTECTED]
 To: [EMAIL PROTECTED], [EMAIL PROTECTED]
 Subject: Re: [VOTE] Making Commons-Cactus a top level projet

 Can someone add Cactus to the Apache Bug Database (as a top level project)
 and remove its entry from Commons (as a sub component) ? Or tell me how to
 do it ...

 Thanks
 -Vincent


 -
 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]




Re: [VOTE] Making Commons-Cactus a top level projet

2001-09-15 Thread Craig R. McClanahan

Done.


On Sat, 15 Sep 2001, Vincent Massol wrote:

 Date: Sat, 15 Sep 2001 19:38:09 +0100
 From: Vincent Massol [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED], Vincent Massol [EMAIL PROTECTED]
 To: Craig R. McClanahan [EMAIL PROTECTED], [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: Re: [VOTE] Making Commons-Cactus a top level projet


 - Original Message -
 From: Craig R. McClanahan [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]; Vincent Massol [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Sent: Saturday, September 15, 2001 4:21 PM
 Subject: Re: [VOTE] Making Commons-Cactus a top level projet


  I've set up the new top-level entry.  Let me know what components and
  versions you would like set up, and I will do those as well.
 

 Thanks Craig. Do I have the correct rights to do it myself, as I don't want
 to bother you or anyone every time I'll need to change it ?

 For the time being, the versions are : 1.0, 1.1 and Nightly build. The
 components are : Web site, Documentation, Example, Tests, Unknown,
 Server side, Client side.

 -Vincent






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




Re: [VOTE] Making Commons-Cactus a top level projet

2001-09-13 Thread Craig R. McClanahan


On Thu, 13 Sep 2001, Vincent Massol wrote:

 Date: Thu, 13 Sep 2001 17:37:54 +0100
 From: Vincent Massol [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED], Vincent Massol [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: [VOTE] Making Commons-Cactus a top level projet


+1

Craig McClanahan


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




[ANNOUNCE] Tomcat 4.0 Release Candidate 1 Available

2001-09-10 Thread Craig R. McClanahan

The first Release Candidate for Tomcat 4.0 is now available.  Only serious
problems will be fixed between now and final release of Tomcat 4.0,
which is currently scheduled for September 17, 2001.  A second release
candidate, if necessary, will be distributed on Thursday, September 13.

Please download this version and run your existing web applications
against it, to help us ensure a final release that is as trouble free as
possible.  The release is available at:

  http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-rc1/

and bug reports should be submitted to:

  http://nagoya.apache.org/bugzilla/

under product category Tomcat 4.

Craig McClanahan



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




Re: Possible bug in web.xml

2001-08-06 Thread Craig R. McClanahan

Thanks for the report - I just checked in patches that will be reflected
in tonight's nightly build (and shortly on the web site as well).

For project-specific documentation like this, it would be helpful to
submit bug reports against the documentation for that project.

Craig McClanahan


On Mon, 6 Aug 2001, Wooyoung Kim wrote:

 Hi,
 I don't know if someone else already reported the bug...
 
 There are couple of typos in the example web.xml given in the documentation.
 
 http://jakarta.apache.org/tomcat/tomcat-4.0-doc/appdev/web.xml.txt
 
 In line 78 and 82, /paramName should be /param-name
 
 regards,
 -wooyoung
 
 _
 Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
 
 
 -
 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]




Re: Enhancement to jakarta-site2 -- XSLT stylesheet equivalent tosite.vsl

2001-07-27 Thread Craig R. McClanahan



On Fri, 27 Jul 2001, Jon Stevens wrote:

 on 7/27/01 12:08 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote:
 
  Please help me debug this stylesheet, and improve its compatibility with
  site.vsl, by checking out the jakarta-site2 module and running the
  xslt target.  NOTE:  you will need to make sure that your Ant install
  includes the appropriate optional.jar file, and has access to either
  JAXP/1.1 (crimson.jar, jaxp.jar, and xalan.jar) or Xerces+Xalan.
  
  Craig McClanahan
 
 For the life of me, I can't get the .jar file foo correct...
 

Empty classpath, right?

 -jon
 
 [204][ ~/checkout/jakarta-site2 ]% ant xslt
 Buildfile: build.xml
 
 xslt:
 [style] Transforming into /Users/jon/checkout/jakarta-site2/xslt
 [style] Loading stylesheet
 /Users/jon/checkout/jakarta-site2/xdocs/stylesheets/site.xsl
 [style] Failed to read stylesheet stylesheets/site.xsl
 
 BUILD FAILED
 
 /Users/jon/checkout/jakarta-site2/build.xml:103:
 javax.xml.transform.TransformerConfigurationException: Namespace not
 supported by SAXParser
 --- Nested Exception ---
 
 Total time: 2 seconds
 
 [205][ ~/checkout/jakarta-site2 ]% dir $ANT_HOME/lib/
 total 1584

Ant 1.3, right?

0 drwxrwxr-x   9 jon  staff 262 Jul 27 13:49 ./
0 drwxrwxr-x   9 jon  staff 262 Mar 11 13:40 ../
4 -rw-r--r--   1 jon  staff 153 Mar  2 04:46 README
  292 -rw-r--r--   1 jon  staff  295934 Mar  2 04:46 ant.jar
  184 -rw-rw-r--   1 jon  staff  187246 Mar 23 17:23 crimson.jar
  244 -rw-rw-r--   1 jon  staff  247802 Mar 14 07:09
 jakarta-ant-1.3-optional.jar
8 -rw-r--r--   1 jon  staff5537 Mar  2 04:46 jaxp.jar
  136 -rw-r--r--   1 jon  staff  136198 Mar  2 04:46 parser.jar
  716 -rw-r--r--   1 jon  staff  732330 May 23 05:45 xalan.jar
 

In my JAXP/1.1 release (and my $ANT_HOME/lib directory), file sizes are:
  187162  crimson.jar
   28404  jaxp.jar
 801714   xalan.jar

 [206][ ~/checkout/jakarta-site2 ]% dir lib
 total 1668
0 drwxrwxr-x   9 jon  staff 262 Jul 27 13:47 ./
0 drwxrwxr-x  18 jon  staff 568 Jul 27 13:43 ../
0 drwxrwxr-x   6 jon  staff 264 Jul 16 16:08 CVS/
  292 -rw-rw-r--   1 jon  staff  295934 Mar 11 13:48 ant-1.3.jar
  184 -rw-rw-r--   1 jon  staff  187246 Mar 23 17:23 crimson.jar
   28 -rw-rw-r--   1 jon  staff   28404 Mar  4 05:35 jaxp.jar
   80 -rw-r--r--   1 jon  staff   78541 Feb 14 11:56 jdom-b6.jar
  368 -rw-rw-r--   1 jon  staff  373565 Apr 30 13:24
 velocity-1.0.1.jar
  716 -rw-r--r--   1 jon  staff  732330 May 23 05:45 xalan.jar
 

This stuff shouldn't matter when you execute the ant script directly,
instead of through build.sh/build.bat.  The key issue is that
ant resolves to $ANT_HOME/bin/ant for the $ANT_HOME library directory
you listed above.

Craig


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




Struts install - error in SilverStream install doc (fwd)

2001-07-19 Thread Craig R. McClanahan

Forwarding to STRUTS-DEV, where this kind of a report belongs.  GENERAL is
for discussion of Jakarta-wide project issues, not project-specific things
like this.

Craig McClanahan

-- Forwarded message --
Date: Thu, 19 Jul 2001 19:25:49 -0700 (PDT)
From: Armen Papshev [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Struts install - error in SilverStream install doc

Hi,
I found small discrepancy at
http://jakarta.apache.org/struts/installation-sas.html
contents for struts-example-depl-plan.xml should be as
attached below.

- cut here -
?xml version=1.0 encoding=UTF-8?
!DOCTYPE warJarOptions PUBLIC
-//SilverStream Software, Inc.//DTD J2EE WAR
Deployment Plan//EN
deploy_war.dtd
warJarOptions
warJar
warJarNamestruts-documentation.war/warJarName
isEnabledtrue/isEnabled
urlselstruts-example/el/urls
/warJar
/warJarOptions
- cut here -

urlselstruts-documentation/el/urls should be
changed to 
urlselstruts-example/el/urls
This way if struts-example.war and
struts-documentation.war deployed to the same server
servlet urls would not conflict since
struts-documentation.war is listening on
struts-documentation url.

Thank you
Armen


__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

-
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]




Three Commons Packages Released

2001-07-14 Thread Craig R. McClanahan

The Jakarta Commons package is pleased to announce the availability of
Version 1.0 releases of three packages:

* Beanutils - Generic manipulation of JavaBeans wrapped around the Java
  reflection APIs, including the ability to get and set nested and
  indexed properties.

* Collections - A wide variety of classes that conform to the API
  contracts of the Java2 Collections APIs.

* Digester - Rules-based processor for XML input streams, providing a
  much simpler interface than the standard SAX APIs.

The fact that these packages have been released means that they are
considered to be of production quality (and therefore worthy of being
relied on by other projects), and that -- consistent with the charter of
the Commons project -- backwards API compatibility will be maintained to
the largest possible degree to protect dependent projects from arbitrary
API changes.

The source and binary distributions of these packages can be found at:

http://jakarta.apache.org/builds/jakarta-commons/release/
beanutils/v1.0/
collections/v1.0/
digester/v1.0/

Craig McClanahan



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




Re: Proposal to make BSF an ASF project

2001-06-22 Thread Craig R. McClanahan



On Fri, 22 Jun 2001, Bill Stoddard wrote:

  The common criteria that we use for any new project is to ask what the
  existing developer and user community is like. I know that there is a large
  user community, but what is the developer community like?
 
 BSF does not have a large developer community; Victor, Chuck and perhaps 3 other 
folks
 from IBM and a handful of occasional submitters.  This is definitely not a high 
volume
 project.
 
 Bill
 
 

+1 for BSF as a Jakarta project.

Craig


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




[ANNOUNCEMENT] Struts 1.0 (Final) Released

2001-06-15 Thread Craig R. McClanahan

As promised at JavaOne, the Struts project team is proud to announce the
availability of Version 1.0 (final release) of the Struts Framework.  The
binary distribution is available at:

  http://jakarta.apache.org/builds/jakarta-struts/release/v1.0/

and the source distribution is available at:

  http://jakarta.apache.org/builds/jakarta-struts/release/v1.0/src/


Craig McClanahan



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




Re: doinking around with a logo

2001-06-14 Thread Craig R. McClanahan



On Thu, 14 Jun 2001, bill parducci wrote:

 Pier P. Fumagalli wrote:
  
  bill parducci at [EMAIL PROTECTED] wrote:
  
   The little thinghie over the latter a is Copyright by Sun...
  
   it is LIKE it, but not the same. so i would disagree.
  
  I wouldn't want to even _raise_ the question with Sun... :)
  
  Pier
 
 well, yeah, there is that. then again, who knows with those guys? you
 might find them monitoring the list ready to make you put '(r)' every
 time you use java in an e-mail! :o)
 

You should see what the Sun lawyers made us do on our JavaOne session
slides ;-).

 
 b
 

Craig McClanahan


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




Re: Lucene acceptance in Jakarta

2001-06-09 Thread Craig R. McClanahan

+1 (back at home recovering from J1).

Craig


On Fri, 8 Jun 2001, Ted Husted wrote:

 Was there a post with a [VOTE] header?
 
 +1 
 
 I think Craig and Geir are tied up with Java One this week.
 
 Jon Stevens wrote:
  
  Re: Lucene being added as a Jakarta Project.
  
  5 of 10 (not counting Duncan) of the PMC members voted +1. The rest haven't
  voted (shame on you). Can I please get the rest of the people to cast a
  vote?
  
  thanks,
  
  -jon
  
  +1
  Daniel F. Savarese [EMAIL PROTECTED]
  Jason van Zyl [EMAIL PROTECTED]
  Ceki Gülcü [EMAIL PROTECTED]
  Peter Donald [EMAIL PROTECTED]
  Jon S. Stevens [EMAIL PROTECTED]
  
  No vote:
  Pierpaolo Fumagalli
  Ted Husted
  Geir Magnusson Jr.
  Craig McClanahan
  Sam Ruby
 
 -
 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]




Re: Theft of authorship

2001-06-08 Thread Craig R. McClanahan



On Thu, 7 Jun 2001, Ceki Gülcü wrote:

 
 Hi Jon,
 
 I am referring to otherwise honest people who choose to contribute
 their enhancements back to the project. They create new classes but in
 the process remove the names of previous authors. They do this in
 good-faith as otherwise they would not have contributed their code. I
 think it is a question of culture/custom.
 

It could be as innocent as someone not understanding that multiple @author
tags are legal.

But you don't know until you ask to the individuals involved why this
happened, and encourage them to behave differently.

 I do not think we have a document outlining authorship rules. Does
 anyone know one? Regards, Ceki
 

I think this is really a significant question.  How significant a patch
does it take for someone to legitimately be considered an additional
author of a particular source file?  Attribution in a CVS commit should
always be there -- but is that really enough.

Unfortunately, I don't have time at the moment to come up with ideas for a
document describing reasonable policies for making such a decision -- but
it would be useful to have such a thing (i.e. I vote +0 :-).

Craig


 At 11:51 07.06.2001 -0700, you wrote:
 on 6/7/01 11:42 AM, Ceki Gülcü [EMAIL PROTECTED] wrote:
 
  This comes up from time to time and usually has me jump through the roof. Good
  willing contributors, take a piece of  existing log4j code, modify or enhance
  it, but remove the previous author's names.  They then post their code as if
  it was their own. Regardless of how much they modified the code, by removing
  the previous author's names they are committing theft. I find this very
  disturbing. What do others think? What can we do to combat this phenomenon?
  Regards, Ceki
 
 There is a difference between doing this accidentally and doing it on
 purpose. If it is determined that it is done on purpose and the people who
 did it refuse to follow the license, then the Jakarta PMC should be notified
 and we can sick the ASF Legal team on the problem. Note, this seems like it
 would be a last resort type of situation. The best is to try to at least
 discuss with the villains (jokingly said) first and make sure that it was
 not intentional.
 
 -jon
  
 -- 
 Open source is not available to commercial companies.
 -Steve Balmer, CEO Microsoft
 http://www.suntimes.com/output/tech/cst-fin-micro01.html
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 --
 Ceki Gülcü
 
 
 -
 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]




Re: Tomcat as webserver

2001-05-18 Thread Craig R. McClanahan

Your best bet would be to ask Tomcat-specific questions like this on the
TOMCAT-USER mailing list (send an empty message to
[EMAIL PROTECTED] to subscribe).  You'll find
thousands of people there who use Tomcat in a large variety of ways,
including as a stand alone server.

Craig McClanahan


On Fri, 18 May 2001, Edson Alves Pereira wrote:

   Hello dudes! I wondering about is secure use Tomcat only as web
 server insteed Apache?
 
   With best wishes,
   Edson Alves Pereira
 __
 Get your own FREE, personal Netscape Webmail account today at 
http://webmail.netscape.com/
 
 -
 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]




Re: [proposal] Jakarta Deprecation Policy

2001-05-15 Thread Craig R. McClanahan



On Tue, 15 May 2001, Jon Stevens wrote:

 Well, there haven't been many flame wars around here recently, so let me
 start one. I seem to be good at that. :-)
 
 What I propose is that we take this document (or one similar to it) and
 migrate it up to the overall Jakarta Project instead of just being a Turbine
 policy and get all the projects to sign their name on it.
 
 http://jakarta.apache.org/turbine/deprecation.html
 
 I think it would go a long way towards raising awareness of the need to
 deprecate things (thanks to Sam starting this with Gump) as well as make the
 corporate types feel more comfortable with regards to depending on that
 Open Source Software stuff...
 
 Comments?
 

I'm generally +1 with the concept of having a deprecation policy
guideline, but have some suggested clarifications:

* It would seem that a deprecation policy like this should be
  enforced only after a version 1.0 release.  Prior to that
  time, you're still experimenting and defining architectures and
  interrelationships, so you don't really want to commit to
  anything until 1.0.

* Carrying on with that, a typical major release (2.0, 3.0, ...)
  will often be substantially different internally than the one
  before.  It seems reasonable to say that the overall compatibility
  guarantee lasts only within a major version series -- although
  you would not want to arbirarily change APIs at the next major
  version without a good reason.

* It's sort of implicit in your policy, but there are no guarantees
  in nightly builds -- only releases -- right?  Otherwise, you will
  risk slowing down development progress more than is necessary.

* If your definitions of product version numbers matches the typcial
  (major.minor.maintenance), I think it's way way way too fast to
  deprecate something in 2.1 and remove it in 2.1.1, no matter what
  the time interval is.  It would seem to me you would want to
  keep the deprecated calls through the next minor version (2.2 in
  the case at hand).  Of course, if it were up to me, I'd say that
  API changes should be disallowed in x.y.z maintenance releases,
  except perhaps to fix serious bugs.

On a more philosophical note, a deprecation policy like this can cause a
little conflict when you sit it next to the release early release often
mantra we like to quote.  People using this policy will want to think a
little longer than the might otherwise about what newly added features
should look like before creating a release containing them.  Once you've
done that, the toothpaste is out of the tube, and you're stuck with the
original APIs for longer than you might otherwise want to be.

 -jon
 

Craig



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




Re: Proposed dirlayout document

2001-05-08 Thread Craig R. McClanahan



On Tue, 8 May 2001, Ceki [iso-8859-1] Gülcü wrote:

 
 Agreed. Mandating that the docs contained in the distribution and the
 docs available on the jakarta web server match exactly is too
 restrictive.

+1 -- it should be up to the project.  I've got projects that do it both
ways.

 However, allowing the user to browse the documentation
 locally from the files contained within the distribution is a nice
 feature. Wouldn't you agree?


Also +1.  One approach is to include a webapp of static HTML files that
the user can drop into their container (if they have one), or use as a
static directory of files (if they don't).

 
 Ceki's description of log4j's doc dance works, but makes altering www
 docs post-release tricky. I think docs are likely to be a bit behind the
 curve, particularly for smaller projects. 
 
 True. 
 
 So, the current system of checking out www docs from cvs makes sense
 - it allows doc amends for last release to be tracked.
 
 I think no one is contesting that tracking source files using CVS is a
 good idea. However, the CVS update operation is one way of copying the
 latest version of doc files to the jakarta web server. It is certainly
 not the only way. Reading your comments below, I think that we are
 actually in total agreement.
 

I'm not a fan of the way jakarta-site2 makes you check in the generated
HTML either.  I'd rather see the cycle work like this:

Local machine:
  - Edit XML (or whatever) sources
  - Generate and test
  - Check in XML sources

Daedalus:
  - Check out XML sources
  - Generate in place

Formerly, we didn't have a useful Java2 environment on the server
(locus).  Now we do -- let's use it :-)

Craig



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




Re: Proposed dirlayout document

2001-05-07 Thread Craig R. McClanahan

On Mon, 7 May 2001, Ceki [iso-8859-1] Gülcü wrote:

 
 I have asked this before but is there a need for an intermediary
 directory? For example, to take an example I am familiar with, Tomcat
 4.x, a damn good project I might add, has a build/ directory and a
 dist/ directory where dist/ is a copy of build/. I do not know why
 Tomcat is doing this but it is. Other projects are doing similar
 things. I am obviously missing something...
 

The two targets are *not* identical.

Tomcat developers want to do the minimum amount of work necessary to
create a runnable version of Tomcat -- thus, they execute the default
build.xml target (deploy-main) that creates an executable Tomcat 4.0 in
the build directory.  To speed things up, this dispenses with Javadoc
creation, JARing things up, and stuff like that.

When you're ready to cut a release (or a nightly build), the dist target
is used, which creates a complete binary distribution.  Obviously, large
parts of this can be copied from the build output (it would not make
sense to recompile everything, and so on) -- but there are also additional
steps.  But this target is not used for daily development work.

Bottom line -- having an intermediate build directory substantially
improves the turnaround time for me as a Tomcat developer.

Craig


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




Re: Proposed dirlayout document

2001-05-07 Thread Craig R. McClanahan



On Mon, 7 May 2001, Ceki [iso-8859-1] Gülcü wrote:

 At 10:02 07.05.2001 -0700, you wrote:
 On Mon, 7 May 2001, Ceki [iso-8859-1] Gülcü wrote:
 
  
  I have asked this before but is there a need for an intermediary
  directory? For example, to take an example I am familiar with, Tomcat
  4.x, a damn good project I might add, has a build/ directory and a
  dist/ directory where dist/ is a copy of build/. I do not know why
  Tomcat is doing this but it is. Other projects are doing similar
  things. I am obviously missing something...
  
 
 The two targets are *not* identical.
 
 
 Tomcat developers want to do the minimum amount of work necessary to
 create a runnable version of Tomcat -- thus, they execute the default
 build.xml target (deploy-main) that creates an executable Tomcat 4.0 in
 the build directory.  To speed things up, this dispenses with Javadoc
 creation, JARing things up, and stuff like that.
 
 When you're ready to cut a release (or a nightly build), the dist target
 is used, which creates a complete binary distribution.  Obviously, large
 parts of this can be copied from the build output (it would not make
 sense to recompile everything, and so on) -- but there are also additional
 steps.  But this target is not used for daily development work.
 
 Bottom line -- having an intermediate build directory substantially
 improves the turnaround time for me as a Tomcat developer.
 
 Hi Craig,
 
 Thanks for taking the time to clarify the Tomcat build process. If I
 understand you correctly, the reason behind having two target
 directories is to speed up the creation of a work  version of
 Tomcat. Would it not be possible to have a build target that just
 creates compiled classes, a jar target to create jar files, a
 javadoc target to create javadocs and a dist target to create a
 complete distro? (The dist target would depend on jar and
 javadoc targets. The jar target would depend on build.)
 
 Thus, it would be possible to have a working version by invoking the
 build target? Regards, Ceki
 
 

Inside the scripts, that is essentially what happens.  To create a
runnable (for development) version of Tomcat 4.0 in a freshly checked out
repository, simply execute

./build.sh

in the top level directory.  Then, set CATALINA_HOME to the build
directory path (for me, that means
/home/craigmcc/Jakarta/jakarta-tomcat-4.0/build), and start it up by
saying

$CATALINA_HOME/bin/startup.sh

(or the equivalent if you're using Windows).

The default target creates a work version in the build directory,
without going to any efforts that are not yet necessary.  The dist
target assumes that the default target has been completed already (with a
depends rule) and does some extra stuff to create the binary
distribution -- which my nightly job does every night, and I do when I
create a release.  Otherwise, I never run the dist target.

Tomcat is not just a JAR file when you get done with it -- you need a
series of files in a series of directories to create the executable
product.  Therefore, in real life, the Tomcat build process is more
complex than this in its details, because there are independent build.xml
scripts for the major components (catalina, jasper, webapps) -- but they
all follow the same basic philosophy.


 -
 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]




Re: [PROPOSAL] Jakarta-Turbine-Jyve

2001-05-05 Thread Craig R. McClanahan



On Sat, 5 May 2001, Jon Stevens wrote:

 on 5/5/01 9:54 AM, Ted Husted [EMAIL PROTECTED] wrote:
 
  I think this is an important question, since the natural outcome of our
  providing open source frameworks is that people will eventually provide
  open source applications based on those frameworks.
  
  For example, I'm launching an online auction application Sunday for a
  public broadcasting station. My contract includes distributing the code
  as open source. I'd love to make that source available through Jakarta.
  If that happened, should it be jakarta-struts-gavel?
 
 Yes.
 
  We also have people
  working on Struts shopping cart application which could also go this
  route. 
  
  So, I guess my only question is that if we have three or four
  application projects in the works now, do we want to think about a
  jakarta-app group?
  
  I don't actually care myself, but I thought I should ask the question.
 
 Na. I'm happy keeping them organized with their respective code bases. Also,
 that would bring up the question of re-organizing the Jetspeed project which
 has already been grand fathered in as a top level project.
 
 Turbine and Struts both need as many sample applications as they can get.
 Might as well organize them closely together so that their progress can be
 carefully monitored.
 

That seems like a pretty reasonable incubator strategy for
applications.  The application developers will have direct access to the
community that is familiar with the framework (and can positively impact
the future development of the framework).  The frameworks can use the apps
as best practices examples of how they should be employed.

Apps that resonate with the user community, and attract their own
communities, can graduate to being full-fledged projects.  After all, the
original reason for Ant's existence was just to build Tomcat ...

 -jon
 

Craig


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




Re: Binaries in CVS

2001-04-13 Thread Craig R. McClanahan



On Fri, 13 Apr 2001, Geir Magnusson Jr. wrote:

 Sam Ruby wrote:
  
  Peter Donald wrote:
  
   The fact of the matter is you would contribute to it even if you had to
   pass the 12 heculean tests of power, jump tall buildings at lunch and
  beat
   deep blue on your breaks ... why ? It's your job.
  
  For the record, it is Craig's job because he did all the things you said,
  not the other way around.
  
  http://conferences.oreilly.com/java/sessions/bios.html
  
 
 Hey - Craig's picture :) 
 
 And they list him as doing bizdev for 'DAT Services'  Hmmm.
 

I updated the bio information before the conference (DAT was my employer
prior to Sun).  They must be using a VB app or something -- the update
never got committed :-).

I'll try again.

 
 -- 
 Geir Magnusson Jr.   [EMAIL PROTECTED]
 Developing for the web?  See http://jakarta.apache.org/velocity/
 

Craig


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




Re: Binaries in CVS

2001-04-13 Thread Craig R. McClanahan



On Fri, 13 Apr 2001, Ceki [iso-8859-1] Gülcü wrote:

 
 * How are you measuring "activity"?  I would guess from your statement
   that you are talking about developers doing commits -- but what about
   they users who just want to USE your project in their own work and could
   give a rip about how the thing is built.  By that measure, I would submit
   that Tomcat is far and away the most active Jakarta project, followed by
   Ant, followed by Struts, followed by everything else.  (Check download
   counts and -USER list subscriptions and activity for corroborating
   evidence).  Tomcat 3.x and Struts contains no checked in JARs, Tomcat 4
   only has patched versions of the stupid JAXP sealed jars until the next
   version of JAXP fixes that for us.
 
 Are the stats available? If so, I would appreciate a pointer.
 

For download counts, you have to go analyze the log files (and, of course,
we're only counting downloads from daedalus -- not from mirrors).  Tomcat
runs in the 50k-100k downloads per month range -- having up to date stats
would be quite nice.

For mailing lists, the following are subscription counts as of this
morning to the Jakarta-based mailing lists:

alexandria -dev   65-user   57
announcements 4183
ant-dev  517-user  860
avalon -dev  104-user   22
ecs-dev   53-user   96
general   1165
jakarta-commons   72
james  -dev  102-user  128
jetspeed   -dev  153-user  202
jmeter -dev   45-user   71
log4j  -dev  157-user  335
oro-dev   74-user  135
regexp -dev   97-user  156
slide  -dev  193-user  283
struts -dev  610-user 1189
taglibs-dev  348-user  510
tomcat -dev 1082-user 2176
turbine-dev  190-user  304
velocity   -dev  152-user  304

Craig


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




Re: Next PMC meeting times?

2001-04-12 Thread Craig R. McClanahan



On Thu, 12 Apr 2001, Ceki [iso-8859-1] Gülcü wrote:

 At 11:42 12.04.2001 -0400, Sam Ruby wrote:
 At the last PMC meeting we scheduled the next PMC meeting for Monday, 16
 April 2001 at 1900 GMT.  Now that daylight savings time has swapped
 hemispheres, it might make sense to revisit this.
 
 The two somewhat workable times are 1200 GMT and 2000 GMT.  I'd like to
 hear opinions on the following two options:
 
 A:
8AM California
11AMNY
1200GMT
1400Zurich
2200Melbourne
 
 +1
 
 
 B:
4PM California
7PM NY
2000GMT
2200Zurich
0600Melbourne (Tuesday)
 
 0K but A: is preferred.
 

Either time is fine with me.

  = = = = = = = =
 
 Proposed Venue:
 
irc: cvs.working-dogs.com:6667, #jakarta
 
 Proposed Agenda:
 
 1. Old Business:
 
1.1  Ted: reformat the rules for revolutionaries document from an email
 to a bylaw
 
1.2  Ted: revise bylaws
 
1.3  Ceki: proposal for cvs layout  build procedures
 
 As far as I know, no work has been done on the ANT build procedures yet. I'll have a 
shot at it unless someone else does it first. Ceki
 
 

There's some discussion of this topic going on in jakarta-commons at the
moment.  For now it's same-old same-old, but who knows ... we might agree
to agree someday, instead of agreeing to disagree.

 --
 Ceki Gülcü Web: http://qos.ch 
 email: [EMAIL PROTECTED] or [EMAIL PROTECTED]
 
 

Craig



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




Re: Binaries in CVS

2001-04-12 Thread Craig R. McClanahan



On Thu, 12 Apr 2001, Ceki [iso-8859-1] Gülcü wrote:

 
 Hi Craig,
 
 At 11:25 12.04.2001 -0700, Craig R. McClanahan wrote:
 Whether or not there is a nice, easy, "all in one" download with
 everything you need has absolutely nothing to do with whether binaries are
 checked into CVS.
 
 True. There is an important distinction indeed. Call it conventional
 thinking on my part.
 
 Nevertheless, it is quite natural to add binaries into CVS if they are
 part of the distribution.
 

Quite natural to those who like it, quite unnatural to those who don't :-)

 So if I understand you correctly, then having binaries (e.g. jar
 files) in the distribution is OK but it less so to put the same
 binaries into CVS. Do I understand you correctly?
 

Yep.  That is why Tomcat binary distributions have everything you need to
run Tomcat (except a JDK and the JSSE classes if you're using SSL).

 Why do you think that it is wrong to have binaries in CVS? 
 

All the disadvantages you listed.

All the disadvantages Sam listed.

The irrationality (IMHO) of checking generated artifacts into a source
repository (same goes for HTML that's generated from XML in some projects,
but we won't go there right now ;-)

The fact that, once in a while, you have to do maintenance on a dialup
connection instead of a nice fast DSL line.  Case in point -- I had to
update jakarta-site2 while at O'Reilly Enterprise Java over a modem
connection, just after all the checked-in JAR files were updated to recent
versions.  It took 45 f*cking minutes to do the CVS update.  Suffice it to
say that the web site can go hang the next time I'm in that position.

 I haven't heard anyone dispute the former -- only the latter.  Why are you
 linking the two issues?
 
 Granted, they are separate but related issues. Ceki
 

Craig


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




Re: Binaries in CVS

2001-04-12 Thread Craig R. McClanahan

On Thu, 12 Apr 2001, Ceki [iso-8859-1] Gülcü wrote:

 At 12:55 12.04.2001 -0700, Craig R. McClanahan wrote:
 
 [removed text]
 
  Why do you think that it is wrong to have binaries in CVS? 
  
 
 All the disadvantages you listed.
 
 All the disadvantages Sam listed.
 
 Sam objects to early binding. In other words to packages assuming a
 certain version of a dependency project where different versions of
 the dependency package behave differently. Is that correct?
 
 I fail to see how this is *directly* related to putting binary files
 in CVS. Gump works regardless of what people put in their CVS modules.
 Right?
 

Gump does that by overriding properties (same as a build.properties file
does in the proposed approach).  Given that you can make it work without
JARs in CVS, let's turn the question around - what does it buy you to have
them there?

Yes, it's nice to newbies to have the defaults set up to minimize the
effort of trying things.  But that can be accomplished in other ways,
without the disadvantages.

 The irrationality (IMHO) of checking generated artifacts into a source
 repository (same goes for HTML that's generated from XML in some projects,
 but we won't go there right now ;-)
 
 :-) That is a different issue.
 
 The fact that, once in a while, you have to do maintenance on a dialup
 connection instead of a nice fast DSL line.  Case in point -- I had to
 update jakarta-site2 while at O'Reilly Enterprise Java over a modem
 connection, just after all the checked-in JAR files were updated to recent
 versions.  It took 45 f*cking minutes to do the CVS update.  Suffice it to
 say that the web site can go hang the next time I'm in that position.
 
 I certainly empathize with that. One question that needs to be asked
 is whether placing the updated binaries in CVS is the culprit.
 

The "jakarta-site2" repository has the following JARs checked in:
  Ant 1.3 (296k)
  Jdom "b6" (78k)
  Velocity 1.0 (370k)
  Xerces 1.3 (1605k)

All four had been updated.

 I just compared downloading ant.jar (295'948 bytes) using CVS update,
 scp and http. The results were roughly the same. A 512Kbit/sec link
 was used to perform the tests. Results may vary depending on server
 load.
 
 Assuming performance scales up or down linearly with bandwidth, then
 the logical conclusion is that the problem lies with the automatic and
 recursive updating done by "cvs update" and not the cvs/ssh channel
 per se.
 
 Probably, what you really wanted was to update the files under xdocs/
 but not the jar files under lib/.
 

I could certainly do that, but what if someone updated a doc and needs one
of the new features?  Doing this (re)creates a version incompatibility,
which would defeat the whole point of having the JARs in CVS in the first
place.

 So the automatic update done by CVS eases the distribution of binaries
 but also increases the communication/networking overhead. The overhead
 is particularly irritating if the changes in the binary are minor.
 
 In other words, putting binary files under CVS decreases the need for
 developer to developer communication but increases computer to
 computer communication. Cheers, Ceki
 

Craig


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




Re: Binaries in CVS

2001-04-12 Thread Craig R. McClanahan

On Fri, 13 Apr 2001, Peter Donald wrote:

 At 08:16  12/4/01 -0400, Sam Ruby wrote:
 If you accept that you are in a world where interfaces that you are
 depending on change frequently, then the problem to solve is optimizing the
 communication paths.
 
 I don't accept that reality.
 
 I bet that 98% of the servlets out there would compile just fine against a
 version of servlet.jar that was built two years ago.  I bet that 98% of
 these servlets will compile just fine against the version of servlet.jar
 that will be built two years from now.
 
 The same can not be said for applications which depend on avalon or
 turbine.  Not two years, not one year, not six months, not three months.
 Heck, I doubt that 98% of the applications which depend on turbine would
 compile against the version of turbine that WAS BUILT LAST NIGHT.
 
 Welcome to opensource! Standards are not done here - we can implement them
 but we don't build them - for those please go elsewhere
 (IETF/W3C/JCP/Other). One of the advantages of opensource is people are
 free to adapt them to their own environments. Hence they do. If you want
 static versions go buy something from a major vendor. Even those generally
 do complete changes every major version (see MS and their DX1-8 or MFC
 versions).
 

In a backhanded way, I agree with this sentiment -- open source is
demonstrably good at creating great implementations, and not so good at
creating specifications.  I suspect this is partly/mostly because many
open source developers rebel against the very disciplines that a
"standard" implies.  (If you want a fight, let's talk about where the
curly braces should go on an "if" statement :-).

But this also raises an issue of who are the "users" we are trying to make
life easier for.  More on this below.

 Gump doesn't solve these problems.  Peter Donald has outsmarted it.  
 
 I haven't outsmarted it. I solved the problem that was presented. You have
 failed to pose any other problem that would make me adjust my position - I
 want low cost of entry.
 
 Have a look at all the projects under apache umbrella. Now rate the
 activity of each project excluding people who get paid to directly work on
 products. Now correlate this with cost of entry (of which jars in CVS is a
 factor). Excluding ant for the moment what do you see? ... Which ones have
 more community behind them? Which ones store binaries in CVS? Coincidence?? ;)
 

This paragraph begs for multiple responses, from different viewpoints (not
necessarily building on each other):

* How are you measuring "activity"?  I would guess from your statement
  that you are talking about developers doing commits -- but what about
  they users who just want to USE your project in their own work and could
  give a rip about how the thing is built.  By that measure, I would submit
  that Tomcat is far and away the most active Jakarta project, followed by
  Ant, followed by Struts, followed by everything else.  (Check download
  counts and -USER list subscriptions and activity for corroborating
  evidence).  Tomcat 3.x and Struts contains no checked in JARs, Tomcat 4
  only has patched versions of the stupid JAXP sealed jars until the next
  version of JAXP fixes that for us.

* The number of binary distro downloads of most Jakarta projects is orders
  of magnitude more than the number of people who download source distros
  or update via CVS.  Note that the popular packages for USERS include
  convenient "all in one" binary distributions, despite the fact that they
  don't use CVS to store JAR files.  (Ant is sorta an exception - they
  offer two downloads (Ant and optional.jar) but you have to go grab
  everything else yourself).

* There seems to be a theory that only people who build from source can
  contribute patches and enhancements.  That is not borne out by
  experience on the projects I'm involved in, because the source code is
  there for examination anyway -- very large percentages of patches come
  from people who are just looking at the "src" directory included with
  the binary distributions.

* Your exclusion of "people who get paid to directly work on products"
  in measuring activity doesn't sit well with me.  Is my contribution to
  Tomcat *illegitimate* because I'm paid to do it?  I guess we'd also need
  to throw out the contributions of lots of other people whose companies use
  Tomcat and who contribute to it on company time, but it's not their full
  time job.  This kind of attitude denigrates the substantial contributions
  of lots of people; you might want to rethink it.

* Finally, to show that I can be just as elitist :-), I'd say that being
  able to build something like Tomcat from sources (by following the
  directions included in the README) is a pretty good first level filter
  for people worthy of being committers in the future :-).

 The exception of course is Ant - it only stores the absolute minimum jars
 in CVS. It is still popular to developers though partially out of 

Tomcat 4.0-beta-3 Released (SECURITY VULNERABILITY)

2001-04-03 Thread Craig R. McClanahan

Tomcat 4.0-beta-3 is an update to the Tomcat 4.0-beta-2 distribution that
was released on 30 March 2001.  It fixes a further security vulnerability
related to potentially exposing JSP source that was only partially
corrected in beta 2.  Anyone using versions of Tomcat 4.0 earlier than the
beta 3 release (or the nightly build dated 20010403 or later) is strongly
encouraged to immediately update to the beta 3 release.

Craig McClanahan



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




Re: [ANNOUNCE] Tomcat 4.0 Beta 2

2001-03-31 Thread Craig R. McClanahan



On Sat, 31 Mar 2001, Kief Morris wrote:

 Craig R. McClanahan typed the following on 11:26 PM 3/30/2001 -0800
 I'm pleased to announce the availability of the Beta 2 release of the
 next generation of the Tomcat servlet container, 
 
 Rockin'! So can we consider the code unfrozen, or do we want to wait
 until the sealing problems are fixed and cut another release before making 
 major changes?
 

Go for it :-)

IMHO, the current workaround to the sealing violation problem, plus the
fact that you can now use Xerces 1.3.1 as your XML parser for Jasper,
means we don't have to wait any longer to do the next round of feature
additions.

What I'd ask, though, is that we discuss any refactoring of the core
interfaces (org.apache.catalina.Xxx) on TOMCAT-DEV first.  These changes
will affect people who embed Tomcat 4.0 in other environments, so we want
to consider minimizing the disrputions this can cause.

 Kief
 
Craig


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




Re: [ANNOUNCE] Tomcat 4.0 Beta 2

2001-03-31 Thread Craig R. McClanahan



On Sat, 31 Mar 2001, Willie Wheeler wrote:

 On Sat, 31 Mar 2001, Kief Morris wrote:
 
  Craig R. McClanahan typed the following on 11:26 PM 3/30/2001 -0800
  I'm pleased to announce the availability of the Beta 2 release of the
  next generation of the Tomcat servlet container, 
  
  Rockin'! So can we consider the code unfrozen, or do we want to wait
  until the sealing problems are fixed and cut another release before making 
  major changes?
 
 I thought that the JSP classloader fix *is* the sealing problem fix, no?  
 Sealing violations related to Tomcat's XML parser prevented the use of,
 say, JDOM as a parser for webapps, and prevented Cocoon from running in
 Tomcat 4.0.  This was all from months ago so I forget exactly what the
 issues were.  But Craig, if I understood your announcement correctly,
 this is what's now fixed...
 

There are changes to the way Jasper loads its XML parser that apparently
solved all of the sealing violation issues under JDK 1.2, but did not fix
them all under 1.3.  However, Tomcat 4.0 beta 2 includes a workaround to
this problem by virtue of the fact that it includes unsealed versions of
the jaxp.jar and crimson.jar files (pending discussions with the Crimson
group on unsealing their next release).

In addition, it was recently verified that Xerces 1.3.1 includes the
JAXP/1.1 functionality that Jasper requires, so you can now use Xerces
instead of Crimson if you wish.

See the release notes (RELEASE-NOTES-4.0-B2.txt in the top level
directory) for more details.

   Willie
 
 

Craig 

 
 
 -
 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]




Re: Sun Article On Velocity

2001-03-30 Thread Craig R. McClanahan



On Fri, 30 Mar 2001, Jon Stevens wrote:

 Velocity 1.0 will be released on Monday 4-2-01 (the article was published
 early).
 
 http://dcb.sun.com/practices/profiles/velocity.jsp
 
 :-)
 

Congrats on your upcoming release!

And it's refreshing to see Jon type a smiley after typing the ".jsp" in
the above URL.  :-)

 -jon
 

Craig


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




[ANNOUNCE] Tomcat 4.0 Beta 2

2001-03-30 Thread Craig R. McClanahan

I'm pleased to announce the availability of the Beta 2 release of the
next generation of the Tomcat servlet container, at:

http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b2/

Tomcat 4.0 beta 2 has many new features, including:

* Tomcat 4.0 can now run web applications out of an unpacked
  directory or directly from a WAR file.

* Web applications are now run under the control of a Java
  SecurityManager that can support fine-grained control over each
web-app's access to system resources.

* You can now specify a DefaultContext element in the server
  configuration file (server.xml) that defines default configuration  
information for contexts that are automatically configured.

* An example Filter implementation that supports on-the-fly GZIP
  compression for clients that support it.

* A servlet that implements all of the NCSA documented
  functionality for server side includes (*.shtml) except for   the
"exec" capability.

* Standard resource factories for JavaMail related resources
  accessible via a JNDI InitialContext, compatible with J2EE
  Specification requirements.

* Reflects the most up-to-date changes in the Servlet 2.3 and
  JSP 1.2 APIs that have been approved by the JSR-053 expert
  group, and will appear in the next published version of the
  corresponding specifications.

In addition, the following major bug fixes are included:

* Fixes for two reported security vulnerabilities (a "cross site
  scripting vulnerability" plus a "URL decoding vulnerability")

* The JSP servlet (Jasper) that compiles and executes JSP pages
  now uses its own classloader its associated XML parser, which
  avoids potential conflicts with parsers included with a web
  application.

* Bug fix updates for directory listings, the WebDAV support,
  binding to a single IP address (if requested), incorrectly
  named access log files, URL decoding improvements, form-based
  authentication, HTTP/1.1 chunking, isUserInRole(), JSP page
  parsing problems, and many other patches.

See the Tomcat 4.0 Beta 2 Release Notes (RELEASE-NOTES-4.0-B2.txt)
that are included in the top-level directory of the release for more
detailed information.

Craig McClanahan

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




Re: [PROPOSAL] J2EEUnit donation to ASF

2001-03-27 Thread Craig R. McClanahan

Catching up on this thread quite late, but ...

On Tue, 27 Mar 2001, Vincent Massol wrote:

 
 It's a pity if I have to change the name ... I would of course very much
 prefer to keep it. But I can see your point. Let's wait for others to
 comment on that.
 

The formal way to check Sun's position on this would be to send mail to
"[EMAIL PROTECTED]" -- but I've already seen indications that
"J2EEUnit" would be problematic because Sun asserts a trademark on
"J2EE".  The folks at the [EMAIL PROTECTED] address might have some
suggestions on what would be found acceptable; I suggest you write them
and ask about it.

Craig McClanahan


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




RE: Struts, velocity, turbine, jetspeed, lions, tigers and bears...oh my

2001-03-22 Thread Craig R. McClanahan



On Fri, 23 Mar 2001, Kuster, Egon wrote:

 Thanks for the welcome. now it is time to start learning how to use turbine.
 Fun.
 

Turbine + Jetspeed is a great combination if your application needs the
kinds of features they offer.  But if the best argument for Turbine is
that "JSP sucks balls", I'd keep looking  for some rational reasoning if I
were you.  :-)

Seriously, every framework has sweet spots and areas they do not
focus on.  You owe it to yourself to evaluate your own needs against those
capabilities.  The best way to do that is prototype based on your own
needs.

Oh, by the way, don't forget to decide how the frameworks you look at are
going to scale as your needs increase.  For example, Jon (primary
developer of Turbine) doesn't think much of EJBs either, so plan on having
to deal with those kinds of complexities yourself if you need that type
of functionality.

 Egon Kuster
 

Craig McClanahan (primary developer of Struts)


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




Re: New Subprojects

2001-03-22 Thread Craig R. McClanahan



On Thu, 22 Mar 2001, Jon Stevens wrote:

 on 3/22/01 7:23 PM, "Peter Donald" [EMAIL PROTECTED] wrote:
 
  No it couldn't from what I understand. Commons won't allow imports directly
  from turbine/avalon and to try to do such a complex system generic from
  start may be a bit of a PITA at this stage. Especially when both
  turbine/avalon already offer a lot of support.
 
 Woah. I didn't know that about the commons. So, we can't start with existing
 code already housed on our servers? If that is the case, I see no future for
 the Commons.
 
 In fact, looking at it...
 
 http://jakarta.apache.org/cvsweb/index.cgi/jakarta-commons/
 
 There still isn't any code in there.
 
 All discussion and no code makes the Commons a dull boy.
 
 Guess I will just keep plugging away with the perfectly working Turbine
 Connection Pool and Scheduler Services :-)
 

So, are you planning to propose these as reusable components after
jumping up and down about sharing?

tick ... tick ... tick ... (showing about as much patience as Jon ever
does) ... yawn ...

Nah, I didn't think so.

:-)

 -jon
 
 

Craig


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




Re: session question

2001-03-16 Thread Craig R. McClanahan



On Fri, 16 Mar 2001, [iso-8859-9] Altuð Altýntaþ (Koç.Net) wrote:

 Hi , 
 
 i have got two contexts , one of them is VARDIYA and other one is CIS.
 Two of these contexts are implemented by using  session object  . 
 

You will do much better asking Tomcat-related questions on the
TOMCAT-USER list.  This list is for general discussions about the Jakarta
project as a whole.

 i put  username and password in my sessions( for  VARDIYA and CIS context )
 . 
 What i want is , if i logon from VARDIYA context , then i dont want to logon
 CIS either . 
 i mean using a same session but i can't do this .. 
 
 my  server.xml  part is here : 
 
 Context path="/CIS"
  docBase="webapps/CIS"
  crossContext="true"
  debug="0"
  reloadable="false" 
 /Context
 
 Context path="/VARDIYA"
  docBase="webapps/VARDIYA"
  crossContext="true"
  debug="0"
  reloadable="true" 
  /Context
 
  i have got tomcat 3.2.1 and soloris 5.7 . 
 
 any idea ? 
 

Sessions cannot be shared across web applications.  That is part of the
servlet specification.

However, it is possible (in Tomcat 4.0) to share user identity across web
applications so your user only has to sign on once (he or she will have a
session in each app).  See the configuration documentation on the "Single
Sign On" facility:

http://jakarta.apache.org/tomcat/jakarta-tomcat-4.0/catalina/docs/

 thanks 
 


Craig McClanahan


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




Re: PMC meeting agenda

2001-03-13 Thread Craig R. McClanahan



On Tue, 13 Mar 2001, Sam Ruby wrote:

 Can we make this month's meeting on Friday? (Sorry Peter).  Via IRC as Jon
 has suggested...
 

Friday is fine for me (still 20:00 GMT?) -- please send the contact
details privately.

 
 - Sam Ruby


Craig McClanahan



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




Re: [NOTICE] + [PROPOSAL] nightly builds + nightly source checkouts

2001-03-13 Thread Craig R. McClanahan



On Tue, 13 Mar 2001, Jon Stevens wrote:

 Hey all,
 
 
 [NOTICE]
 Brian asked me to remind you to clean up the nightly builds so that we don't
 have tons of old stuff eating up disk space.
 
 Example:
 /x2/www/jakarta.apache.org/builds/jakarta-tomcat-4.0/nightly
 
 jakarta-tomcat-4.0/nightly  du -sk
 424790  .
 
 424790 megs seems like a lot to me.
 

Will be restarting my "clean out" job shortly.

 There are files all the way back to 20010216 which seems a bit excessive.
 Also excessive seems to be the .Z and .gz versions. I think it is safe to
 assume in this day and age that everyone can install gunzip on their server.
 
 
 [PROPOSAL]
 I would like to finagle this email into another discussion as well which is
 coming up with a more centralized system for doing nightly builds as well as
 nightly source checkouts.
 

+1, but see further discussion below on the details

 Right now, we have cronjobs run by a number of different people putting
 files in a number of different locations. It would be nice to try to
 centralize this down to just one primary script and one configuration file
 that handles this the majority of this stuff.
 
 So, in the builds directory, I would like to propose setting something up
 that looks like this:
 
 /www/jakarta.apache.org
 builds/
 scripts/
 build-all.sh (or .pl or .py)
 cleanup-all.sh (or .pl or .py)
 build.conf
 projects/
 velocity-source.sh (or .pl or .py)
 velocity-build.sh (or .pl or .py)
 tomcat-4.0-source.sh (or .pl or .py)
 tomcat-4.0-build.sh (or .pl or .py)
 ...
 ...
 
 build.conf:
 baseDirectory=/www/jakarta.apache.org/builds
 projectsDirectory=$baseDirectory/projects
 daysToKeep=7
 
 We could then have the build-all script run through the projects directory
 looking for scripts to execute. It would first attempt to execute all of the
 "*source*" scripts it finds and then attempt to execute all of the "*build*"
 scripts it finds. What this would allow is for projects to have their own
 scripts to be run in order to do any source/build specific things for their
 projects. It would also allow for individual testing. Adding a new project
 is as simple as adding another set of scripts.
 

We will want each subproject to maintain their own versions
(e.g. tomcat-4.0-source.sh and tomcat-4.0-build.sh) according to the
standard conventions, so that no one person would need to stay up to date
on all the subproject build procedures.

We will also want a few things like stable releases of Ant, XML parsers,
etc. installed in "well known" places for build processes that require
access to them.

 The individual scripts could set what their "output" directory is based on
 the projectsDirectory + projectName. projectsDirectory would be passed in to
 the source/build scripts on ARGV[0].
 
 The cleanup-all.sh script would be a global cleanup script that would run at
 the end of the build-all.sh script to prune the files in the directories,
 keeping the "daysToKeep" number of files.
 
 I know that I have most of the framework already done for the
 "project-build.sh" scripts and the "cleanup-all.sh" scripts, but I don't
 have the frameworks for the build scripts, however, I know that some
 projects already have that. Maybe we could consolidate those into this
 system?
 
 Notes: In order to put a system like this into place, we will also need to
 have everyone shut off their existing cronjobs. :-)
 

+1 for me (who does Servletapi, Tomcat 4.0, Struts, Watchdog), as soon as
it is ready.

 Sam, I'm sure that this probably fits into Gump somewhere as well, however,
 I'm not sure I want to or feel the need to go that far and come up with the
 "perfect" solution at this point. What do you feel about that?
 

IMHO Gump serves a different, also valid, purpose as a tinderbox detector
of incompatibilities.

The goal of nightly builds is different -- it is to create something that
ought to be marginally usable.  For that reason, a nightly build would use
a stable Ant (for example), instead of hot-off-the-CVS code that Gump
uses.

That being said, it might well be possible to tweak the Gump scripts so
that they operate in a different mode for nightly builds.  Sam?

 Comments?
 
 -jon
 

Craig McClanahan


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




Re: [POLL] Re: Code Sharing Concepts

2001-02-16 Thread Craig R. McClanahan

"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]




Re: [POLL] Re: Code Sharing Concepts

2001-02-15 Thread Craig R. McClanahan

Peter Donald wrote:


 I would also like to hear from the struts bean utils. I haven't looked at
 them but I presume they would be general enough (or could be made so) so
 Ant2.x could use it (ie remove converter/introspector elemenets from Ant2.0
 codebase).


They are -- and they have dependencies only on JDK classes for the following
org.apache.struts.util classes:  BeanUtils, ConvertUtils, and PropertyUtils.
Javadocs are online at

http://jakarta.apache.org/struts/api/index.html

I haven't voted yet in this thread because I haven't seen anyone else say
"let's figure out the process issues first."  I guess it's not as interesting
as writing code :-), but it is very much as important to a shared resource like
this.

I will coordinate contributing any or all of the code listed at the bottom of
my "Code Sharing Concepts" message, but I'm definitely not interested in making
any project I'm a part of dependent on an ad hoc collection of code with no
rules about who can change what.  I've been bitten way too many times in that
scenario.


 Cheers,

 Pete


Craig



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




  1   2   >