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

[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: boilerplate LICENSE text in different formats

[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

[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: questions license for site documents

[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 http://jakarta.apache.org/LICENSE"/>
> line would be more practical ... under /document/properties/ element.
> (generated htmls should have  tag,  tag or something equivalent)
> 

The instructions at the very end of

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
"", 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: Using apache feather logo

[Craig R. McClanahan]

Quoting TANAKA Yoshihiro <[EMAIL PROTECTED]>:

> I,m Yoshi TANAKA, a member of Japanese Jakarta user's group.
> We're planning to make our stickers for give-aways to attendees at
> Java Technology Conference in Japan to be held next week.
> We'd like to include your feather logo into our stickers.
> These stickers will not be used for commercial purposes.
> Those will be given as an expression of our gratitude to the
> persons who answered our questionnaires about Jakara products.
> 
> Pleae inform me if there will be any license violation in usage
> of this feather logo.
> 
> BTW, we will hold a party at the Conference and are expecting
> Craig to attend.
> 

You can count on it :-).

> --
>TANAKA Yoshihiro  /   http://www.ytp.ne.jp/
>  ---
> 

Craig McClanahan



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

Re: jakarta-site karma?

[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: The Name Jakarta

[Craig R. McClanahan]

Quoting Uncle Roastie <[EMAIL PROTECTED]>:

 
> Why/how was the name Jakarta choosen?
> 
> Thanks,
> [EMAIL PROTECTED]

It was the name of the conference room at Sun where a large number of the
discussions about the original formation of the project, as well as the
contribution of Tomcat from Sun to Apache, took place.  I guess the name sort
of stuck.

Craig McClanahan



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

Re: Differences

[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

[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

[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: [VOTE] ORO 2.0.8 maintenance release

[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: Jakarta: Confederation or Single Project?

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

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: Why you *want* to be on the PMC

[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 
  to .

>   --- Noel

Craig


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

Re: Jakarta: Confederation or Single Project?

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


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!  :-)


Craig


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

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

[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: [Proposal] HiveMind Service Framework

[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: Forrest skin for Jakarta-XX project

[Craig R. McClanahan]

Tetsuya Kitahata wrote:

(What about Struts?)

 

At the moment, Struts uses hand-crafted XSLT stylesheets that preceeded 
the existence of Forrest (and Maven), but we are considering some 
alternatives based on both Forrest's and Maven's site generation 
facilities.  Some proof-of-concept prototypes (not necessarily polished) 
of the Struts main page, using three different Forrest skins, are at:

Krysalis style:   http://www.twdata.org/dakine/site/
Avalon/Tigris style:  http://www.twdata.org/dakine/site1/
Forrest/XML Apache style: http://www.twdata.org/dakine/site2/
Personally, I would prefer either the Krysalis or Avalon/Tigris styles 
to the default Forrest/XML Apache style, but that's just me.  Various 
Struts developers have various opinions, as well as concerns about the 
processing time implications of using Forrest.

We also use XSLT transformations for other reasons as well (i.e. 
generating tag library descriptors and reference documentation), and 
already enjoy nice things like print-friendly styles without the 
navigation menu -- to say nothing of XHTML-compatible generated output 
-- so I don't feel any great sense of urgency to make a migration.  I'm 
personally not going to have time to even think about it in the very 
near term, due to day-job commitments.  But, it's certainly an option 
for us to share a common look and feel.

Craig



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

Re: Changes to the jakarta-site

[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: [ERR] [ANN] Cactus 1.5-beta1 has been released

[Craig R. McClanahan]

n

On Wed, 16 Jul 2003 [EMAIL PROTECTED] wrote:

> Date: Wed, 16 Jul 2003 00:44:34 +0900
> From: [EMAIL PROTECTED]
> Reply-To: Jakarta General List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: [ERR] [ANN] Cactus 1.5-beta1 has been released
>
> Transmit Report:
>
>  To: [EMAIL PROTECTED], 402 Local User Inbox Full ([EMAIL PROTECTED])
>

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

Re: karma anyone?

[Craig R. McClanahan]

In general, [EMAIL PROTECTED] is a good place, but I've filled in
some blanks where I could.

On Thu, 3 Jul 2003, Nathan Bubna wrote:

> Date: Thu, 3 Jul 2003 21:03:31 -0700
> From: Nathan Bubna <[EMAIL PROTECTED]>
> Reply-To: Jakarta General List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: karma anyone?
>
> hi folks,
>
> i'm trying to get a 1.0 Velocity Tools release going on, but i lack much karma
> and know-how.  Here's my hang-ups:
>
> 1. There's no good place to report bugs.  We really need a "Tools" component
> in Bugzilla under the Velocity project.  i have no idea how to get this done,
> and i'm sure i lack the karma.
>

Added.  I presume you will continue to use the "1.0-Release" version
number?  If not, just holler and we can add an appropriate entry for the
version number field as well (although version #s are global across a
project in Bugzilla).

> 2.  Getting the documentation up on http://jakarta.apache.org/velocity/tools/.
> i have no karma for logging onto that machine to create the directory and
> update/upload the files.  Do i need that?  Can i get it?  Am i just way off
> here?  The website maintenance doc
> (http://jakarta.apache.org/site/jakarta-site2.html) speaks of doing this, but
> i'm just a lowly jakarta-velocity-tools committer sitting on the streetcorner
> holding a "no karma. please help!" sign.
>

There's two pieces to this -- being able to commit your changes to the
jakarta-site2 CVS repository (I see you've now got that already) and the
ability to log on to the web server machine and do the updates there
(requires an account on daedalus.apache.org).  SEe below for more.

> 3.  In terms of actually putting the release out there, the commons'
> guide(http://jakarta.apache.org/commons/releases.html) also speaks of logging
> into jakarta.apache.org.  Anyone with karma wanna lend a hand?
>

I think this got dealt with by others ... if not, give a shout and I can
do the update.  Otherwise, folks at infrastructure@ should be able to
help.

> 4.  i'd also like to update the main jakarta site pages with appropriate
> notice of this release (if/when i figure out how to make it happen).  So, can
> i get karma for jakarta-site2 as well?
>

Should be done already.

> All apologies for any ignorant, misguided, or OT questions.
>
> Nathan Bubna
> [EMAIL PROTECTED]
>

Craig

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

Re: Issues with XMLBeans proposal

[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

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

[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

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

[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

[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

[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: Karma for jakarta-site2

[Craig R. McClanahan]

On Sun, 23 Feb 2003, Jeffrey D. Brekke wrote:

> Date: 23 Feb 2003 21:41:06 -0600
> From: Jeffrey D. Brekke <[EMAIL PROTECTED]>
> Reply-To: Jakarta General List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Karma for jakarta-site2
>
>
> I recently was involved with the release of Commons Net 1.0.0 and got to
> the point where I needed to update jakarta-site2 and found I had no
> karma.  I was instructed to ask for the ability on this list.
>

Done.  You should have the correct karma next time you try a commit on
this repository.

> Thanks in advance.
>
> jb

Craig McClanahan

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

Re: Licensing again.

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

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

[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

[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:   
> For additional commands, e-mail: 
>
>


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

Re: Forum Software.

[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:   
For additional commands, e-mail: 

Re: New Jakarta proposal: Pluto

[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:   
For additional commands, e-mail: 

Re: [discussion] jakarta-gump as community property

[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 ).
>
> 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:   
For additional commands, e-mail: 

RE: Short Apache licence for source files

[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:   
For additional commands, e-mail: 

Re: [xdocs] Bug report (fwd)

[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 (&) 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 &, 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=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Commons&component=Lang&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=Reuse+same+sort+as+last+time
>
> Hen

Craig


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

Re: [Poll result] Committers, who are we?

[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:   
For additional commands, e-mail: 

RE: Bug handling survey - 80:20 rule

[Craig R. McClanahan]

On Fri, 4 Oct 2002, Danny Angus wrote:

> Date: Fri, 4 Oct 2002 17:45:48 +0100
> From: Danny Angus <[EMAIL PROTECTED]>
> Reply-To: Jakarta General List <[EMAIL PROTECTED]>
> To: Jakarta General List <[EMAIL PROTECTED]>
> Subject: RE: Bug handling survey - 80:20 rule
>
>
> > So, how come the
> > commercial software can still compete with open source products.
>

You're assuming, of course, that you can't have commercial software that
*is* open source :-).  Such models do exist -- so I'm assuming you are
primarily talking about closed source commercial software.

>
> IMHO its because on the whole OpenSource contributors are not doing it
> to compete with commercial software, in fact many of us do this to
> provide an alternative to the daily pressures, restrictive working
> practices and profit driven project management of commercial IT.

Having been (and still am) sitting on both sides of this fence, there is
quite a bit of truth to this observation.

>
> We're either much less interested in producing a competitor for a
> commercial product than producing an intelligent, elegant and efficient
> solution to a particular problem, or we're here to collaborate on a
> product to use in our own commercial interests, not in competing in the
> market place.
>

I don't think you can generalize to *all* open source projects not being
interested in competing with commercial packages, but this attitude is
certainly common.

IMHO, there are at least three major factors that means commercial
software isn't going to go away any time soon, no matter what happens in
the open source community:

* SCHEDULE - we all know the standard (and usually pretty sarcastic)
  response that we open source developers give to the "when's the next
  version going to be released".  But this is a very very important
  issue for people who are planning projects that depend on that next
  release being completed.  Yes, commercial software vendors sometimes
  miss their dates too, but at least they generally try to meet a
  predicatable schedule that can be communicated to customers.

* CUSTOMER FOCUS - like any product, commercial software must meet the
  needs of customers in order to be viable.  While there are certainly
  open source projects that try to do this, I'd bet that commercial
  software vendors are perceived as being more responsive in this regard
  generally -- it's their whole livelihood at stake, versus an open
  source project that is being done for fun or to collaborate on something
  interesting.

* SERVICE/SUPPORT - While it is a myth that you can't get support for
  widely popular open source projects (check out the Resources pages
  for something as small as Struts, for example), it is *definitely*
  true for less popular projects, or projects where the developer
  community is fairly limited.

Individual open source projects can clearly choose to deal with the
objective realities in each of these three areas, and the ones that do
have no problem competing with commercial closed source software.  But the
general perceptions in these areas about the open source community, as a
whole, are fairly accurate IMHO.

On the other hand, the real world is also getting more complex in this
regard, with companies choosing to build commercial products that are
partially or (almost) completely constructed with open source software --
licenses like the Apache Software Foundation license make this trivially
simple.

If a company chooses to leverage an open source product (such as, for
example, what IBM does with the Apache httpd server by building Websphere
around it), do you count that as an open source success, or as a failure?
How about all the hardware products that embed Tomcat to provide a web
based configuration interface?  Or commercial application development
frameworks and IDEs that support things like Struts?

Don't forget that many companies leveraging open source packages in this
way *also* fund some of their developers to work on contributing changes
and improvements back to the open source community, too ...

> Yes? No?
>

Ah, if only life were that simple!  :-)

> d.
>

Craig McClanahan



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

Re: karma for jakarta-site2

[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:   
> >For additional commands, e-mail: 
>
>
>
>
> _
> Send and receive Hotmail on your mobile device: http://mobile.msn.com
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


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

Re: You guys are so funny.

[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:   
For additional commands, e-mail: 

Re: You guys are so funny.

[Craig R. McClanahan]

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

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


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


Craig


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

Re: You guys are so funny.

[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:   
For additional commands, e-mail: 

Re: Trademarks, copyright etc

[Craig R. McClanahan]

On Thu, 2 May 2002, Peter Donald wrote:

> Date: Thu, 2 May 2002 09:13:47 +1000
> From: Peter Donald <[EMAIL PROTECTED]>
> Reply-To: Jakarta General List <[EMAIL PROTECTED]>
> To: Jakarta General List <[EMAIL PROTECTED]>
> Subject: Re: Trademarks, copyright etc
>
> Hi,
>
> On Thu, 2 May 2002 08:41, Hans Bergsten wrote:
> > Related to this, I was just asked what formal names we should use for
> > Jakarta subproject products, say Struts, in books and articles. Is it:
> > a) Apache Jakarta Struts
> > b) Apache Struts
> > c) Jakarta Struts
> >
> > I have a feeling it's a) but the other forms also seem reasonable.
>
> FWIW I tend to use (b) when discussing them and if I want to get in jakarta it
> would be something like
>
> Apache Struts at Jakarta
>
> Jakarta is just the container where Stuts is hosted while Apache are the
> "real" owners
>

I use (b) as well when I describe our subprojects.

> --
> Cheers,
>
> Peter Donald

Craig McClanahan



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

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

[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.
>
> 
> If you have ever built tomcat from source, you might wish they had a build
> system...
> 
>
> 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
>
> 
>
> 
> 
>
>  #set($mybean = $scopetool.getPageScope("mybean"))
>
>  #if(true)
> this is true!
>  #end
>
>  
>
>  $mybean.string
>
>  
>
> #foreach($item in $mybean.array)
> $item 
> #end
>
> 
> 
> 
>

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:   
For additional commands, e-mail: 

Re: [New Subproject Proposal] ObjectBridge

[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:   
For additional commands, e-mail: 

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

[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:   
For additional commands, e-mail: 

Re: PMC Nomination - Craig McClanahan

[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:   
For additional commands, e-mail: 

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

[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:   
For additional commands, e-mail: 

Re: [PATCH] xdocs/stylesheets/site.vsl

[Craig R. McClanahan]

On Mon, 28 Jan 2002, Geir Magnusson Jr. wrote:

> Date: Mon, 28 Jan 2002 14:44:14 -0500
> From: Geir Magnusson Jr. <[EMAIL PROTECTED]>
> Reply-To: Jakarta General List <[EMAIL PROTECTED]>
> To: Jakarta General List <[EMAIL PROTECTED]>
> Subject: Re: [PATCH] xdocs/stylesheets/site.vsl
>
> On 1/28/02 2:35 PM, "Jon Scott Stevens" <[EMAIL PROTECTED]> wrote:
>
> > on 1/28/02 6:13 AM, "Ceki Gulcu" <[EMAIL PROTECTED]> wrote:
> >
> >> I have modified xdocs/stylesheets/site.vsl so that  elements in
> >> the XML file are translated into meta tags in the HTML header. This is
> >> useful for example to add keyword meta tags which make it easy for
> >> search engines to categorize the page.
> >
> > HA! My evil plan worked. Now I can say that Ceki writes Velocity code. :-)
> >
> > Who's next?
> >
>
> Craig...
>

Sorry ... that would be old news.  I had to patch a couple of
jakarta-site2 things earlier ... :-)

> :->
>

Craig


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

Re: BCEL project bug databas

[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:   
> For additional commands, e-mail: 
>
>


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

Re: [PROPOSAL] POI @ Jakarta

[Craig R. McClanahan]

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
>

+1

Craig McClanahan


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

Re: [PROPOSAL] POI @ Jakarta

[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:   
For additional commands, e-mail: 

Re: [PROPOSAL] Jakarta PMC bylaws change

[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:   
For additional commands, e-mail: 

Re: commit mails not send

[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:   
> For additional commands, e-mail: 
>
>


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

RE: Groupware Website Recommendations

[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:   
> >For additional commands, e-mail: 
> >
> >
> --
> ///
> 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:   
> For additional commands, e-mail: 
>
>


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

Re: Code conventions

[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:   
For additional commands, e-mail: 

Re: crushed

[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:   
For additional commands, e-mail: 

Re: proposal for the jakarta startpage

[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:   
For additional commands, e-mail: 

RE: Commons Validator Packaging/Content

[Craig R. McClanahan]

On Mon, 7 Jan 2002, Ceki Gülcü wrote:

> Date: Mon, 07 Jan 2002 18:56:30 +0100
> From: Ceki Gülcü <[EMAIL PROTECTED]>
> Reply-To: Jakarta General List <[EMAIL PROTECTED]>
> To: Jakarta General List <[EMAIL PROTECTED]>
> Subject: RE: Commons Validator Packaging/Content
>
> At 19:00 07.01.2002 +0100, Paulo Gaspar wrote:
> >> Jon wrote:
> >>
> >> There is no community. There is projects which have people who follow them
> >> blindly.
> >
> >I do not believe that.
> >
> >What I am seeing are the same signs Sam sees:
> >
> >> Sam wrote:
> >>
> >> In my, admittedly biased, perspective, I see significant improvement in
> >> terms of community over the course of the past eleven months or so.  For
> >> starters, the following results would have been inconceivable at the time:
> >>
> >>http://jakarta.apache.org/builds/gump/2002-01-07/
> >>
> >> I also see an initiative by Ted and others to build a commons are which
> >> promotes reuse.  Conscientious objectors notwithstanding, they plow
> >> relentlessly ahead, continuing to make incremental and enduring progress.
>
> Projects building cleanly is very nice and gump is great. However, I
> would not declare victory just yet. (Very few people can resists Sam's
> polite nudges.) Jon's concerns about the existence of a community are
> valid and should not be lightly dismissed.
>

They aren't being dismissed, but the sky isn't falling either.

Perusing Gump's cross reference page is quite interesting:

  http://jakarta.apache.org/builds/gump/latest/xref.html

Just to pick an example of a package I'm involved in, check out the line
for commons-digester:

   ... jakarta-turbine-tdk maven scarab ...

as well as the developers who have recently been adding features and
tests.  That would have *never* happened a year ago (when this code was
inside the Struts community and Commons didn't exist).

The point from Jon that I *do* dismiss is his feeling that there should be
one and only one implementation of any particular functionality -- "one
size fits all" is a very rare phenomenon in my experience, and having some
choice is helpful.


> With the pending/rumored commercialization of SourceForge there will be
> even larger hordes of projects wanting to be hosted under Jakarta.
> What will we do then?

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.

> Regards, Ceki
>

Craig


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

Re: Commons Validator Packaging/Content

[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:   
For additional commands, e-mail: 

Re: More abuse of coding styles...

[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:   
For additional commands, e-mail: 

Re: Jakarta Status [was Code conventions]

[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:   
For additional commands, e-mail: 

Re: proposal for the jakarta startpage

[Craig R. McClanahan]

On Thu, 3 Jan 2002, Ted Husted wrote:

> Date: Thu, 03 Jan 2002 09:45:06 -0500
> From: Ted Husted <[EMAIL PROTECTED]>
> Reply-To: Jakarta General List <[EMAIL PROTECTED]>
> To: Jakarta General List <[EMAIL PROTECTED]>
> Subject: Re: proposal for the jakarta startpage
>
> If everyone thinks the Bugzilla page descriptions are a reasonable
> starting point, I'll do it.

+1

If the descriptions aren't complete enough for the web site front page, we
can always change 'em ...

> People are forever asking for this in the
> Webmaster box, and it will save me the trouble of replying. I also need
> to put one of Jon's "gatekeeper" pages in front of the Webmaster link,
> to induce people to send mail to the User list first.
>
> -Ted.
>

Craig


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

Re: Just the JARs

[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:   
For additional commands, e-mail: 

Re: is a statement of the license in all source files?

[Craig R. McClanahan]

On Thu, 27 Dec 2001, robert burrell donkin wrote:

> am i right in thinking that for legal reasons we need to
> include the complete license text in every source file (rather than just
> the short form)?
>

My recollection is that you are correct ... we need to be using the long
form, at least for the version 1.1 license (i.e. the current one).

> - robert

Craig


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

Re: Coding style addition

[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:   
For additional commands, e-mail: 

Re: Comment for Apache.org

[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:   
For additional commands, e-mail: 

Re: Cross site scripting

[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: Cross site scripting

[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:   
For additional commands, e-mail: 

RE: Cross site scripting

[Craig R. McClanahan]

On Tue, 20 Nov 2001, Jeff Schnitzer wrote:

> Date: Tue, 20 Nov 2001 17:23:48 -0800
> From: Jeff Schnitzer <[EMAIL PROTECTED]>
> Reply-To: Jakarta General List <[EMAIL PROTECTED]>
> To: Jakarta General List <[EMAIL PROTECTED]>
> Subject: RE: Cross site scripting
>
> > From: Jon Stevens [mailto:[EMAIL PROTECTED]]
> >
> >Does anyone have code they want to contribute to get this started? How
> are
> >you currently dealing with these issues? What is your favorite way to
> escape
> >things? Do you filter/escape all content or only some content? Etc.
>
> In the world of XSL, I think these issues are already taken care of.  At
> least in a "domified" approach, the data only ever gets translated into
> XML as a final step, and the XSL processor automatically escapes
> anything that will have XML or HTML meaning.
>
> In the world of JSP, I would expect that bean-access custom tags would
> do this escaping.  Do the Struts taglibs or any of the jakarta taglibs
> take care of this?
>

Struts does, by default.  On a few tags you can explicitly turn this off
if you are willing to take the risks.

Struts does, unless you explicitly tell it not to.  As long as you use
tags like 

> In the world of Velocity... is there a switch that can be set on
> Velocity to automatically escape anything with XML/HTML meaning?  Should
> there be?
>
> Of course, all these effectively disable _all_ htmlish tags, which might
> not be wholly desirable... still, it seems to me that that the best
> approach is to escape everything and then selectively translate *back*
> only the tags you want working (like ).
>

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

> Jeff Schnitzer
> [EMAIL PROTECTED]
>

Craig


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

RE: Using bzip2 for tarball

[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:   
> For additional commands, e-mail: 
>
>


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

Re: Standardized jar manifest entries? (Re: How do you version jarfiles?)

[Craig R. McClanahan]

On Fri, 16 Nov 2001, Jeff Turner wrote:

>
> Java's official versioning spec [1] seems curiously irrelevant. It talks
> about API specifications, and implementations thereof; not the sort of
> scenario most people deal with. It's primary use-case seems to be
> applets (it amuses me how Sun documents can be dated this way;)
>

I'm not so sure this concept is irrelevant to general purpose application
development.

* Does your application architecture expose abstractions as
  interfaces (or abstract classes)?

* Do you have more than one implementation of those abstractions?

* Do the implementations rev independently of (and probably at a faster
  rate than) the abstractions?

If so, exactly the same versioning model is quite reasonable.

Craig McClanahan


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

Re: Distributing the JSSE

[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:   
For additional commands, e-mail: 

Re: Integration

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

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:   
For additional commands, e-mail: 

Re: Distributing the JSSE

[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

[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

[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

[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

[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

[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: Using mod_jk with apache 1.3.20

[Craig R. McClanahan]

On Tue, 21 Aug 2001, Gonyou, Austin wrote:

> Thanks for the response, but I don't know if it answers the question. Let me
> expount a bit and I'll see if it makes things clearer.
> 

Could you *please* do your expounding on the correct mailing list?

The GENERAL list is for issues about Jakarta project development as a
whole.  You want to discuss things like this on the TOMCAT-USER list --
after reading the mailing list guidelines at:

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

you can follow the link to subscribe.

Craig McClanahan


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

Re: Possible bug in web.xml

[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,  should be 
> 
> 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 to"site.vsl"

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

Enhancement to jakarta-site2 -- XSLT stylesheet equivalent to"site.vsl"

[Craig R. McClanahan]

For those folks who like the idea of using a common stylesheet for
generating documentation and web sites from XML input documents across
multiple Jakarrta projects, but don't necessarily want to be tied to
Anakia, you now have a choice.  I've added an XSLT stylesheet
(xdocs/stylesheets/site.xsl) that is pretty close to functional
equivalence with the "site.vsl" macros used by Anakia.  Remaining TODOs
are listed at the top of the file to finish up, but you can run "ant xslt"
in jakarta-site2 and examine the generated pages to see how close it
already is.  The last few things are relatively minor.

Both approaches can read the same XML input documents, because they use
the same sets of elements to render the same kind of HTML.  The only
important difference when you set things up in Ant relates to the
generation of relative URLs.

* Anakia is typically invoked with an includes attribute like
  "**/*.xml", to recursively process an entire tree of XML sources.
  The Anakia processor creates a "relativePath" variable reflecting
  the location of the current source file in the directory hierarchy,
  so that things like the navigation menu links are calculated
  appropriately.

* To use XSLT, the simplest solution I found was to generate each
  directory's worth of HTML in a separate invocation of the 

jakarta-site2 process changes needed (heads up)

[Craig R. McClanahan]

Heads up ... the old process for updating the Jakarta web site no longer
works, since the CVS repositories are no longer present on daedalus.  It's
too late tonight, or I'd actually figure out how to update fix -- but
wanted to warn anyone else who was going to try.  The workaround is to use
scp from your generated copies of the HTML files (instead of using cvs
update on daedalus).

Also, there are three files in the /www/jakarta.apache.org/site directory
that have incorrect permissions that disallow anyone else from updating
them.  Marc and Daniel, *please* set your umask values to 002 so that this
doesn't happen again, and also update the permissions to add group write
on the following files:

  binindex.html (marcsaeg owner)
  mail.html (dfs owner)
  sourceindex.html (marcsaeg owner)

Craig McClanahan

  


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

Struts install - error in SilverStream install doc (fwd)

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




struts-documentation.war
true
struts-example


- cut here -

struts-documentation should be
changed to 
struts-example
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

[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: Helma XML-RPC @ Jakarta

[Craig R. McClanahan]

On Thu, 5 Jul 2001, Jason van Zyl wrote:

> [  ]Craig McClanahan

Just getting back from vacation, I've read this thread and tend to agree
with the general consensus that it belongs more on the xml.apache.org side
of the house, for several reasons:

* This particular implementation is written in Java, but the spec itself
   has been implemented in many languages.

* Having a Java implementation first is cool and all, but we should be
  able and willing to host non-Java implementations as well -- and Jakarta
  is not the right place for that.  That's what xml.apache.org is about.

* In the pure-Java world, I think an "RPC over XML" solution that
  implements the JAX-RPC API (JSR 101) would make sense as a Jakarta
  project (assuming the issues that Apache has with the Java Community
  Process can be worked out :-).  There, it's not an issue of supporting
  the same spec in multiple languages -- it's an issue of supporting a
  Java-specific API with a robust, high-performance implementation.

Officially, this counts as
  [-0] Craig McClanahan

Craig

PS:  By the way (to Sam and others), I don't consider the use of a
specialized XML parser (or an embedded HTTP server, for that matter) to be
a fatal design flaw.  Performance should have a strong influence on that
sort of choice, and if it runs faster with specialized tools instead of
Xerces and Tomcat for this particular application, more power to 'em.

On the other hand, if they cannot *significantly* outperform general
purpose tools, then it's pretty much wasted effort to spend the developer
time necessary to maintain those components.  Time will tell -- therefore,
hosting this initially as a separate top-level project makes the most
sense to me.  But I'd hope that the XML-RPC developers recognize that this
is an important tradeoff.


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

Re: Proposal to make BSF an ASF project

[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

[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

[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

[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

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

Struts 1.0-beta-3 Released

[Craig R. McClanahan]

Struts 1.0-beta-3 is a release candidate version of the Struts Framework,
likely to be the final beta prior to the Struts 1.0 Final Release, which
is currently scheduled for June 15, 2001.  Please help identify any
remaining bugs that need to be fixed prior to final release, and report
them to our bug tracking system at:

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

The binary distribution of Struts 1.0-beta-3 is available at:

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

The source distribution of Struts 1.0-beta-3 is available at:

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

Craig McClanahan



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

RE: [GUMP] Build Failure - Turbine

[Craig R. McClanahan]

Philosophical discussions are always worth a couple of cents of my own :-)

On Wed, 23 May 2001, Tim Vernum wrote:

> 
> From: Sam Ruby (23 May 2001 10:02 AM)
> 
> > Jason van Zyl wrote:
> > >
> > > What is going on here? I fixed this code almost two days ago.
> > 
> > http://jakarta.apache.org/builds/gump/2001-05-21/cvs_index.html
> > http://jakarta.apache.org/builds/gump/2001-05-22/cvs_index.html
> > 
> > Compare this to the "good old days":
> > 
> > http://jakarta.apache.org/builds/gump/2001-04-15/cvs_index.html
> > 
> > Daedalus performance (or lack thereof) has basically gotten 
> > to the point
> > where programs like Gump are great in theory, but impractical in
> > practice...
> 
> (Disclaimer: I'm not a committer on any project, so my opinion is
>  objective, but slightly under-informed, and without authority)
> 
> In general, I believe that automated build/test processes are *very*
> important, an do work.
> We've got some teams using CruiseControl here, and it is doing well.
> The reasons I think that gump registers so many failures are:
> 
> 1) The environment in which gump runs is not identical to the 
> environment the developers run (OS, jdk, jars, etc), and I'm
> not sure if it is even well defined.
>Now, given that these are supposed to be cross platform
> java projects, that shouldn't be an issue, but it has been,
> and will continue to be.
>Unless each developer replicates the Gump environment on his/her
> workstation, they will not find all problems. However doing so
> will only fix problems for that environment, so in some ways
> leaving it slightly undefined is helpful to keep portability.

Most of the failure issues here are based on slow CVS updates, not on
environmental differences.

But the important point is a little more subtle - the "write once run
anywhere" Java mantra is not just a marketing slogan.  We as Java
developers should be designing to minimize environmental
dependencies.  GUMP focuses on one kind of dependency (cross project
dependency at compile time), which is important, but it's not the only one
(for example, code to build file paths that uses hardcoded '/' or '\'
delimiters).  However, GUMP has served a valuable role in just raising
awareness of these issues, above and beyond it's usefulness as a tool.

> 
> 2) Developers can't/don't run the tests before checkin.
>In our situation, if you checkin something that breaks the tests,
> you're an idiot.
>I don't think that happens in apache, for a few reasons.

What does "in apache" mean?  There is no one single project here -- each
Jakarta project (for example) consists of its own constellation of
developers.  Sure, there is overlap, but nobody at all is involved in
everything.

>The primary one being that most people are doing this in the spare
> time, and a channeling in patches from numerous sources. Forcing
> full rebuilds with unit tests would make that channel so small that
> work would grind to a virtual stand-still.
> 

Part of the issue is a (good) increase in expectations.  It used to be
that, if you didn't break the build on your own project, you were doing
good.  (For amusement, check out the warnings about what to do before
checking code in on many of the project README files).  Now, if we don't
run the appropriate unit test suites, other developers on the same project
start frowning at you.  GUMP (along with attitudes like yours about "test
first before committing") are becoming much more widespread.

The other reality is that Moore's law tends to make the "full rebuilds"
issue moot.  I just upgraded my home PC, and as a result I can build
Tomcat (modest-sized but still complex), from scratch, in less than 20
seconds.  There is absolutely no excuse not to do that kind of thing on
your own project any more.

> 3) Developers can't/don't test other projects.
>This is particularly relevant to ant, but also to some of the XML
> and (soon) commons modules.
>A number of build failures have been due to changes in ant.
>Ant should continue to be free to change things as needed to make
> ant better, and that will continue to break projects that rely
> on specific ant features/bugs.
>Unless the developers are going to rebuild all the dependant
> projects everytime they make a change, then this will keep 
> happening.
> 

Having to rebuild "foreign" projects is not something that I should really
have to worry about.  Moreover, I don't know the code of that project well
enough to test it anyway.  I want to just trust the developers of the
projects I depend on.

GUMP has raised awareness of the negative impacts that API changes have on
other projects (be careful what methods you make public, because people
will use them :-).  Next step is to be more picky about functionality
changes that don't involve API changes a compiler will catch for you.

> 4) Gump (I think) only runs once a day.
>This means that there's up t

Struts 1.0-beta-2 Released

[Craig R. McClanahan]

Struts 1.0-beta-2 is an update release in preparation for a final release
of Struts 1.0 prior to JavaOne 2001.  The changes included are documented
in the release notes, at:

  http://jakarta.apache.org/struts/release-notes-1.0-b2.html

You can pick up your copy of this latest release at:

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

Craig McClanahan



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

Re: Tomcat as webserver

[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

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

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]

[ANNOUNCE] Tomcat 4.0-beta-4 Released

[Craig R. McClanahan]

Tomcat 4.0-beta-4 is the latest update to the next generation version of
Tomcat 4.0.  It supports the most recent specification updates (Servlet
2.3 Proposed Final Draft 2, JavaServer Pages 1.2 Proposed Final Draft 2),
support for looking up users and roles in a JNDI-accessed directory
server, and many bug fixes.  See the "RELEASE-NOTES-4.0-B4.txt" file in
the top-level directory for details on all of the changes.

Pick up your copy of the Tomcat 4.0-beta-4 binary distribution at:

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

The source code for this distribution is available at:

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

Craig McClanahan



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