You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Henri Yandell <ba...@generationjava.com> on 2004/03/19 18:17:45 UTC
Jakarta embracing the JCP?
This is a little linked to the Apache-open source question raised a while
back, though it actually comes from trying to explain to someone what the
pro's and reasons for groovy as a jsr might be.
How about if Jakarta [or Apache-Java as a whole] embraced the latest JCP
process? If there's anything the ASF are not happy with in the JCP we can
adjust it, but generally we would manage our own projects in the same way
that ASF involvement in the JCP.org says we should manage standards.
What I'm largely interested in are the reasons why not, as these would be
perfect reasons why something like groovy, or ant or httpclient, should
not become jsr's.
So... why not run Java@Apache under the JCP process?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta embracing the JCP?
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Mar 19, 2004, at 12:17 PM, Henri Yandell wrote:
> This is a little linked to the Apache-open source question raised a
> while
> back, though it actually comes from trying to explain to someone what
> the
> pro's and reasons for groovy as a jsr might be.
>
> How about if Jakarta [or Apache-Java as a whole] embraced the latest
> JCP
> process? If there's anything the ASF are not happy with in the JCP we
> can
> adjust it, but generally we would manage our own projects in the same
> way
> that ASF involvement in the JCP.org says we should manage standards.
Are you kidding? We'd have to go to meetings and discuss process
documents. I do that 4 times a year as is as JCP rep, and that's more
than enough!
>
> What I'm largely interested in are the reasons why not, as these would
> be
> perfect reasons why something like groovy, or ant or httpclient, should
> not become jsr's.
Groovy is going through the JSR process so that the language will be
formalized into a spec and protected for compatibility. This will give
the "Java ecosystem" another language the runs on the JVM for which
claimed implementations are guaranteed to be compatible.
>
> So... why not run Java@Apache under the JCP process?
>
Because there is no real need to assert that every project at the ASF
in Java is some sort of standard, and further, doing a TCK is an awful
lot of work. If we do have something that is a candidate to be
standardized, we can go to the JCP and do it there.
geir
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: Jakarta embracing the JCP?
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Formulate new proposals to the Apache lists in a similar manner to a new
> JSR and write projects up in a similar format. Have named leads and ...
Having named "leads" of any sort is the antithesis of what I would like to
see within the ASF.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta embracing the JCP?
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 19 Mar 2004, Geir Magnusson Jr wrote:
>
> On Mar 19, 2004, at 4:52 PM, Henri Yandell wrote:
>
> >
> > I'm still in disagreement. I'm founding a lot of this on the idea that
> > Groovy is a good fit for a JSR. There's no reason for more than one
> > implementation to exist that I can think of and there's no reason why
> > an
> > open-source project would be hurt under a JCP process. Both big leaps.
>
> Suppose that BEA wants to embed the language in their app server stack,
> and for whatever reason they want to re-implement for monitoring or to
> limit what program someone can execute....
Pretty hypothetical. They might want to do the same for JUnit or Ant etc.
I think Groovy doesn't really fit the JSR-style so far, but I think it
will be a good thing if it happens as it will help to increase the JSR
from simply a spec-world into something more of a central clearing house
for Java concepts.
> When you say "under a JCP process" what do you mean?
>
> Formally, it means that someone proposes a project (just like now to
> incubator, their peers or a PMC I suppose), and a panel of judges (the
> Exec committed) decides if it can go forward.
>
> An expert group then meets and works on the spec, offering it for
> public comment, and then producing a final spec, a TCK and a RI.
>
> What part are you missing in your life?
Unsure. Mathematical beauty? Simplicity? I liked the idea of drawing
parallels between two processes and allowing them to feed off each other
and hopefully draw nearer [in terms of being more OSS friendly or more
organised].
Formulate new proposals to the Apache lists in a similar manner to a new
JSR and write projects up in a similar format. Have named leads and
specified active-committer groups on components. Understand more about
which apache-areas are active, which are actively watched and which are in
a coma.
> > Everyone seems to assume that the JCP.org exists to create
> > specifications
> > for other people to implement. I assumed that.
>
> It exists to create specifications. You could implement the spec, or
> if the business terms are acceptable to you, reuse the RI as the
> implementation, under whatever loony license the spec lead decides.
>
> > However, I see no reason
> > why Groovy fits under that assumption, and so I wonder what else Groovy
> > will get from being within the JCP.
>
> In no order :
>
> 1) If you are opposing my 'yes' vote on the part of the ASF, speak now.
> My official motivation for the 'yes' vote is that I believe that it
> would be a good addition to the Java universe (and at worst, not a
> harmful one) and more importantly is a OSS project from EG to license
> to TCK and RI and may even use the ASF's proposed TCK and RI licenses.
Wouldn't even if I could. I presume that opposing votes is an Apache
board/member thing.
I've made the point that Groovy as a JSR will be great as an OSS demo
of the JCP on a jug list, so am in complete agreement there.
> 2) It's not an ASf project, so anything we say here about the
> motivations of the Groovy team are sheer speculation. (FD - I'm a
> member of the EG)
>
> Groovy will get a formal spec protected by the compatibility
> requirements of the JCP. It will also get some vague status of
> 'officialdom' although I have no clear idea what that really means.
Seems useful for many projects, so if Groovy is hale and hearty in a year,
it would seem that we should ask the JSR question of any apache components
that might fit. Jelly, Ant, Maven leap to mind. Probably others.
> > .....
> > One big problem/difference is [I've heard anyway] that the project lead
> > has dictatorial powers. I'm not suggesting we ingest the bad water with
> > the good.
>
> didn't you just state only 1 paragraph ago that you thought it good to
> have a defined lead?
The bit I view as important is that a lead's responsibility is to the
community. Largely this is a Jakarta-blindess on my part. The lead is
yourself, the PMC Chair. In other projects it's blindingly obvious, but
the size of Jakarta made me not notice it.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta embracing the JCP?
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Mar 19, 2004, at 4:52 PM, Henri Yandell wrote:
>
> I'm still in disagreement. I'm founding a lot of this on the idea that
> Groovy is a good fit for a JSR. There's no reason for more than one
> implementation to exist that I can think of and there's no reason why
> an
> open-source project would be hurt under a JCP process. Both big leaps.
Suppose that BEA wants to embed the language in their app server stack,
and for whatever reason they want to re-implement for monitoring or to
limit what program someone can execute....
When you say "under a JCP process" what do you mean?
Formally, it means that someone proposes a project (just like now to
incubator, their peers or a PMC I suppose), and a panel of judges (the
Exec committed) decides if it can go forward.
An expert group then meets and works on the spec, offering it for
public comment, and then producing a final spec, a TCK and a RI.
What part are you missing in your life?
>
> Everyone seems to assume that the JCP.org exists to create
> specifications
> for other people to implement. I assumed that.
It exists to create specifications. You could implement the spec, or
if the business terms are acceptable to you, reuse the RI as the
implementation, under whatever loony license the spec lead decides.
> However, I see no reason
> why Groovy fits under that assumption, and so I wonder what else Groovy
> will get from being within the JCP.
In no order :
1) If you are opposing my 'yes' vote on the part of the ASF, speak now.
My official motivation for the 'yes' vote is that I believe that it
would be a good addition to the Java universe (and at worst, not a
harmful one) and more importantly is a OSS project from EG to license
to TCK and RI and may even use the ASF's proposed TCK and RI licenses.
2) It's not an ASf project, so anything we say here about the
motivations of the Groovy team are sheer speculation. (FD - I'm a
member of the EG)
Groovy will get a formal spec protected by the compatibility
requirements of the JCP. It will also get some vague status of
'officialdom' although I have no clear idea what that really means.
> Also, much of the JCP must be generic,
> towards developing a product and not towards a specification. TCK =
> unit
> tests? RI = binary? Spec = Docs?
Not at all. Nothing close actually. Take JavaMail. the only reason
why someone would re-implement is because Sun's binary license is so
stupid. Other than that, it's good to have a standard that anyone can
use.
Docs aren't a spec. A doc tells you how to use. A spec tells you what
will happen when you use it, and in very particular and careful ways.
My hats off to Richard for undertaking the spec writing responsibility
for Groovy.
>
> We already effectively have Expert Groups, we call them the PMC.
> Project
> Leads, aka active-voice on the project/component. I'm not sure it hurts
> for us to have a project-lead on things, in fact I think it's something
> Apache should have. Defined responsibility.
That notion is actually contrary to the way Apache projects are to run,
although it happens all the time, and I agree with you it's a good
thing. However, it's not a formal thing, nor will it be.
The codehaus way is different, where there is a project lead who has a
significant say.
It's too early to tell if one is better than the other. The ASF is
successful, but it's been my observation that the codehaus way is how
may projects run naturally, and a strong lead has precedent in OSS -
like RMS and Linus Torvalds.
>
> People view this as anti-community, but I think it's pro-community.
> Who is
> responsible to the community for Tomcat 3 at the moment? The community?
> That seems like we're kidding ourselves. The ASF-way merely means that
> it's easy to fill a project-lead gap, or to join in. Not that the
> project-leads don't exist.
>
> There are problems with the JCP system [unsure if 2.6 changes
> anything].
> One big problem/difference is [I've heard anyway] that the project lead
> has dictatorial powers. I'm not suggesting we ingest the bad water with
> the good.
didn't you just state only 1 paragraph ago that you thought it good to
have a defined lead?
Yes, 2.6 does changes things, but tangibly and intangibly.
And yes, the lead has dictatorial powers if the lead wants it. Given
that companies are spending big $ and contributing their IP to some of
these JSRs, it's hard to imagine that they wouldn't demand control.
However, there is no requirement that the lead be a dictator, and the
Groovy JSR will show that OSS style consensus with strong lead works.
>
> Anyway. That's the basis of my questionsuggestion. Why [apart from
> non-Java Apache political reasons] would a Java@Apache process, built
> on
> the JCP [with changes we want to enact in the JCP] be such a horrid
> idea?
It's designed for a different purpose, and what we have works really,
really well :)
>
> Bear in mind. It's the end of the week, and this is a typical over a
> table
> of beer question :)
Except I don't have a beer at the moment...
geir
>
> Hen
>
> On Fri, 19 Mar 2004, Geir Magnusson Jr wrote:
>
>>
>> On Mar 19, 2004, at 1:44 PM, Noel J. Bergman wrote:
>>
>>>> How about if Jakarta [or Apache-Java as a whole] embraced the latest
>>>> JCP
>>>> process?
>>>
>>> In what way? Can you be specific? As I understand the JCP, what you
>>> are
>>> asking makes little sense.
>>>
>>> We don't have "spec leads", nor do we want them. We don't have
>>> ownership of
>>> a project/specification. Everything here is communal and consensual.
>>> That
>>> is not true of the JCP. Actually, I would prefer to see the JCP
>>> continue to
>>> evolve to become more like the ASF.
>>>
>>>> What I'm largely interested in are the reasons why not, as these
>>>> would be
>>>> perfect reasons why something like groovy, or ant or httpclient,
>>>> should
>>>> not become jsr's.
>>>
>>> A JSR is a specification. It should have a TCK and an RI, but at
>>> heart it
>>> is a specification. Some people have talked about proposing the
>>> Apache
>>> Repository Specification, which I understand Maven will evolve to
>>> use,
>>> as a
>>> JSR. If that happened, I'd prefer to see us run a JCP Expert Group
>>> more in
>>> line with an ASF project, not run ASF projects like an JCP Expert
>>> Group.
>>
>> That would be a good example of something that would be appropos for a
>> JSR - something that others will/might implement, and if so, you want
>> to be sure that your software which works with one implementation of
>> it
>> works with others.
>>
>>>
>>> Geir? Your thoughts?
>>
>> We are always working to help move the JCP towards the OSS model, but
>> it's a slow process. In JCP 2.5 (the guidelines for the JCP), the
>> ASF's work was key in getting TCKs and RIs to be able to be licensed
>> under and OSS license. Before that, there was no way to do an OSS
>> JSR.
>> Now, w/ 2.6 that just went into effect last week, the process now
>> formally encourages as much openness and transparency as possible in
>> an
>> EG (although you still can do pretty much what you want...) as well as
>> require an early release of the spec to the community to enable as
>> much
>> feedback and commentary as possible. Previously, the EGs had to
>> release a community draft late in the process, and that made them
>> afraid to have not enough time to fix stuff, so they would tend to
>> really delay.
>>
>> The Groovy EG will be run as an OSS project, btw...
>>
>> geir
>>
>>>
>>> --- Noel
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: general-help@jakarta.apache.org
>>>
>>>
>> --
>> Geir Magnusson Jr 203-247-1713(m)
>> geir@4quarters.com
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: general-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta embracing the JCP?
Posted by Tetsuya Kitahata <te...@apache.org>.
On Mon, 22 Mar 2004 11:14:13 +1100
dion wrote:
> I've seen this 'defined responsibility' drive people
> away from projects. (*1)
Agreed. Often *innovative* guys run away from such projects.
OSS guys do not want to take *responsibilites*, generally speaking.
Also, this often dampens the motivation of the "not-defined" guys.
> I've also seen projects with a strong leader wallow as their leader
> has gone off and started something new and more fun. (*2)
Agreed, too. Often *conservative* guys hate such projects - and
say - "This project is very primitive."
--
Required would be *balance*, i guess.
In case (*1), "warm-hearted" enemies would be often able to
resuscitate (*1) projects.
NOTE: If not-"warm-hearted", (*1) would lose in competition.
In case (*2), "public appeal" method would be required. In open
source world, anyone can take over. - just people do not know
what they can do (and they are shy enough) and where such projects exist.
- Mechanism would resolve. "offer for public subscription" *plus*
- "allocation of appropriate rights"
Again and again, just a balancing issue.
Also, community often loses balance. - Be careful.
-- Tetsuya. (tetsuya@apache.org)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta embracing the JCP?
Posted by di...@multitask.com.au.
Henri Yandell <ba...@generationjava.com> wrote on 20/03/2004 08:52:35 AM:
[snip]
> We already effectively have Expert Groups, we call them the PMC. Project
> Leads, aka active-voice on the project/component. I'm not sure it hurts
> for us to have a project-lead on things, in fact I think it's something
> Apache should have. Defined responsibility.
I've seen this 'defined responsibility' drive people away from projects.
I've also seen projects with a strong leader wallow as their leader has
gone off and started something new and more fun. Bugs lie unfixed and the
software stagnates.
Having multiple people share the load is a far better model, IMHO.
> People view this as anti-community, but I think it's pro-community. Who
is
> responsible to the community for Tomcat 3 at the moment? The community?
> That seems like we're kidding ourselves. The ASF-way merely means that
> it's easy to fill a project-lead gap, or to join in. Not that the
> project-leads don't exist.
[snip]
--
dIon Gillard, Multitask Consulting
Re: Jakarta embracing the JCP?
Posted by Henri Yandell <ba...@generationjava.com>.
I'm still in disagreement. I'm founding a lot of this on the idea that
Groovy is a good fit for a JSR. There's no reason for more than one
implementation to exist that I can think of and there's no reason why an
open-source project would be hurt under a JCP process. Both big leaps.
Everyone seems to assume that the JCP.org exists to create specifications
for other people to implement. I assumed that. However, I see no reason
why Groovy fits under that assumption, and so I wonder what else Groovy
will get from being within the JCP. Also, much of the JCP must be generic,
towards developing a product and not towards a specification. TCK = unit
tests? RI = binary? Spec = Docs?
We already effectively have Expert Groups, we call them the PMC. Project
Leads, aka active-voice on the project/component. I'm not sure it hurts
for us to have a project-lead on things, in fact I think it's something
Apache should have. Defined responsibility.
People view this as anti-community, but I think it's pro-community. Who is
responsible to the community for Tomcat 3 at the moment? The community?
That seems like we're kidding ourselves. The ASF-way merely means that
it's easy to fill a project-lead gap, or to join in. Not that the
project-leads don't exist.
There are problems with the JCP system [unsure if 2.6 changes anything].
One big problem/difference is [I've heard anyway] that the project lead
has dictatorial powers. I'm not suggesting we ingest the bad water with
the good.
Anyway. That's the basis of my questionsuggestion. Why [apart from
non-Java Apache political reasons] would a Java@Apache process, built on
the JCP [with changes we want to enact in the JCP] be such a horrid idea?
Bear in mind. It's the end of the week, and this is a typical over a table
of beer question :)
Hen
On Fri, 19 Mar 2004, Geir Magnusson Jr wrote:
>
> On Mar 19, 2004, at 1:44 PM, Noel J. Bergman wrote:
>
> >> How about if Jakarta [or Apache-Java as a whole] embraced the latest
> >> JCP
> >> process?
> >
> > In what way? Can you be specific? As I understand the JCP, what you
> > are
> > asking makes little sense.
> >
> > We don't have "spec leads", nor do we want them. We don't have
> > ownership of
> > a project/specification. Everything here is communal and consensual.
> > That
> > is not true of the JCP. Actually, I would prefer to see the JCP
> > continue to
> > evolve to become more like the ASF.
> >
> >> What I'm largely interested in are the reasons why not, as these
> >> would be
> >> perfect reasons why something like groovy, or ant or httpclient,
> >> should
> >> not become jsr's.
> >
> > A JSR is a specification. It should have a TCK and an RI, but at
> > heart it
> > is a specification. Some people have talked about proposing the Apache
> > Repository Specification, which I understand Maven will evolve to use,
> > as a
> > JSR. If that happened, I'd prefer to see us run a JCP Expert Group
> > more in
> > line with an ASF project, not run ASF projects like an JCP Expert
> > Group.
>
> That would be a good example of something that would be appropos for a
> JSR - something that others will/might implement, and if so, you want
> to be sure that your software which works with one implementation of it
> works with others.
>
> >
> > Geir? Your thoughts?
>
> We are always working to help move the JCP towards the OSS model, but
> it's a slow process. In JCP 2.5 (the guidelines for the JCP), the
> ASF's work was key in getting TCKs and RIs to be able to be licensed
> under and OSS license. Before that, there was no way to do an OSS JSR.
> Now, w/ 2.6 that just went into effect last week, the process now
> formally encourages as much openness and transparency as possible in an
> EG (although you still can do pretty much what you want...) as well as
> require an early release of the spec to the community to enable as much
> feedback and commentary as possible. Previously, the EGs had to
> release a community draft late in the process, and that made them
> afraid to have not enough time to fix stuff, so they would tend to
> really delay.
>
> The Groovy EG will be run as an OSS project, btw...
>
> geir
>
> >
> > --- Noel
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
> >
> --
> Geir Magnusson Jr 203-247-1713(m)
> geir@4quarters.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta embracing the JCP?
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Mar 19, 2004, at 1:44 PM, Noel J. Bergman wrote:
>> How about if Jakarta [or Apache-Java as a whole] embraced the latest
>> JCP
>> process?
>
> In what way? Can you be specific? As I understand the JCP, what you
> are
> asking makes little sense.
>
> We don't have "spec leads", nor do we want them. We don't have
> ownership of
> a project/specification. Everything here is communal and consensual.
> That
> is not true of the JCP. Actually, I would prefer to see the JCP
> continue to
> evolve to become more like the ASF.
>
>> What I'm largely interested in are the reasons why not, as these
>> would be
>> perfect reasons why something like groovy, or ant or httpclient,
>> should
>> not become jsr's.
>
> A JSR is a specification. It should have a TCK and an RI, but at
> heart it
> is a specification. Some people have talked about proposing the Apache
> Repository Specification, which I understand Maven will evolve to use,
> as a
> JSR. If that happened, I'd prefer to see us run a JCP Expert Group
> more in
> line with an ASF project, not run ASF projects like an JCP Expert
> Group.
That would be a good example of something that would be appropos for a
JSR - something that others will/might implement, and if so, you want
to be sure that your software which works with one implementation of it
works with others.
>
> Geir? Your thoughts?
We are always working to help move the JCP towards the OSS model, but
it's a slow process. In JCP 2.5 (the guidelines for the JCP), the
ASF's work was key in getting TCKs and RIs to be able to be licensed
under and OSS license. Before that, there was no way to do an OSS JSR.
Now, w/ 2.6 that just went into effect last week, the process now
formally encourages as much openness and transparency as possible in an
EG (although you still can do pretty much what you want...) as well as
require an early release of the spec to the community to enable as much
feedback and commentary as possible. Previously, the EGs had to
release a community draft late in the process, and that made them
afraid to have not enough time to fix stuff, so they would tend to
really delay.
The Groovy EG will be run as an OSS project, btw...
geir
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: Jakarta embracing the JCP?
Posted by "Noel J. Bergman" <no...@devtech.com>.
> How about if Jakarta [or Apache-Java as a whole] embraced the latest JCP
> process?
In what way? Can you be specific? As I understand the JCP, what you are
asking makes little sense.
We don't have "spec leads", nor do we want them. We don't have ownership of
a project/specification. Everything here is communal and consensual. That
is not true of the JCP. Actually, I would prefer to see the JCP continue to
evolve to become more like the ASF.
> What I'm largely interested in are the reasons why not, as these would be
> perfect reasons why something like groovy, or ant or httpclient, should
> not become jsr's.
A JSR is a specification. It should have a TCK and an RI, but at heart it
is a specification. Some people have talked about proposing the Apache
Repository Specification, which I understand Maven will evolve to use, as a
JSR. If that happened, I'd prefer to see us run a JCP Expert Group more in
line with an ASF project, not run ASF projects like an JCP Expert Group.
Geir? Your thoughts?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org