You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Corey Scott <co...@gmail.com> on 2004/10/26 17:09:20 UTC
[Commons websites] not updated recently
Is there a reason why a some of the commons sites have not been
updated for a few months? Isnt this giving people (outsiders) a false
sense of how active/inactive the projects are?
I thought that seeing as most sites are probably
auto-generated/updated using maven that someone would have cron'd
this?
Thanks,
Corey
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [Commons websites] not updated recently
Posted by Martin Cooper <mf...@gmail.com>.
Excellent. Thanks for clearing this up.
--
Martin Cooper
On Wed, 3 Nov 2004 16:49:59 +0800, Corey Scott <co...@gmail.com> wrote:
>
>
> On Tue, 2 Nov 2004 20:42:03 -0800, Martin Cooper <mf...@gmail.com> wrote:
> > It's not a question of whether anyone could tell, or whether or not
> > you should have mentioned it. The point is that the ASF can not accept
> > LGPL derived code, for legal reasons.
>
> Sorry I was kidding, guess i shouldnt have :-)
>
> >
> > What you originally said was "I 'borrowed' and modified the jdiff
> > code", which says that your code is derived from JDiff code, which is
> > LGPL code. If what you meant is that you took the code from the JDiff
> > *Maven plugin*, and that is existing Apache code, then that is a very
> > different story.
>
> Obviously my mistake, it was the Jdiff maven plugin code (i have not
> read and do not intended to read the jdiff code, im sures it great but
> it doesnt interest me :-D )
>
> For the record and hopefully to clear everything up, my plugin.jelly
> file used this:
> http://cvs.apache.org/viewcvs/maven-plugins/jdiff/plugin.jelly as a reference
>
> I hope helps sort out the situation.
> -Corey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [Commons websites] not updated recently
Posted by Corey Scott <co...@gmail.com>.
On Tue, 2 Nov 2004 20:42:03 -0800, Martin Cooper <mf...@gmail.com> wrote:
> It's not a question of whether anyone could tell, or whether or not
> you should have mentioned it. The point is that the ASF can not accept
> LGPL derived code, for legal reasons.
Sorry I was kidding, guess i shouldnt have :-)
>
> What you originally said was "I 'borrowed' and modified the jdiff
> code", which says that your code is derived from JDiff code, which is
> LGPL code. If what you meant is that you took the code from the JDiff
> *Maven plugin*, and that is existing Apache code, then that is a very
> different story.
Obviously my mistake, it was the Jdiff maven plugin code (i have not
read and do not intended to read the jdiff code, im sures it great but
it doesnt interest me :-D )
For the record and hopefully to clear everything up, my plugin.jelly
file used this:
http://cvs.apache.org/viewcvs/maven-plugins/jdiff/plugin.jelly as a reference
I hope helps sort out the situation.
-Corey
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [Commons websites] not updated recently
Posted by Martin Cooper <mf...@gmail.com>.
It's not a question of whether anyone could tell, or whether or not
you should have mentioned it. The point is that the ASF can not accept
LGPL derived code, for legal reasons.
What you originally said was "I 'borrowed' and modified the jdiff
code", which says that your code is derived from JDiff code, which is
LGPL code. If what you meant is that you took the code from the JDiff
*Maven plugin*, and that is existing Apache code, then that is a very
different story.
If you're sure that your code is free of LGPL encumbrances, then by
all means feel free to send it here. Just for the record (in the mail
archives), it would be helpful if you could provide a ViewCVS URL to
what you based your code on in the Apache repository, to clear up any
confusion and make sure we dot the i's and cross the t's.
--
Martin Cooper
On Wed, 3 Nov 2004 11:49:25 +0800, Corey Scott <co...@gmail.com> wrote:
> Maybe I should not have mentioned it?
>
> All I did was checkout the jdiff maven plugin (plugin.jelly file) from
> apache CVS, and use it as a base for the code for this. This was just
> because I didnt really know what I was doing and this was the quickest
> way. Looking at the code again, if I had removed the jdiff, from the
> var names, I dont think anyone would have been able to tell?
>
> Is this ok?
> -Corey
>
> ---------------------------------------------------------------------
>
>
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [Commons websites] not updated recently
Posted by Corey Scott <co...@gmail.com>.
Maybe I should not have mentioned it?
All I did was checkout the jdiff maven plugin (plugin.jelly file) from
apache CVS, and use it as a base for the code for this. This was just
because I didnt really know what I was doing and this was the quickest
way. Looking at the code again, if I had removed the jdiff, from the
var names, I dont think anyone would have been able to tell?
Is this ok?
-Corey
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [Commons websites] not updated recently
Posted by Emmanuel Bourg <sm...@lfjr.net>.
Martin Cooper wrote:
> On Wed, 3 Nov 2004 02:38:16 +0800, Corey Scott <co...@gmail.com> wrote:
>
>>PS. I have to acknowledge the fact that I 'borrowed' and modified the
>>jdiff code (thanks go out to those responsible)
>
>
> AFAIK, JDiff is LGPL. That being the case, I don't believe we can
> accept your code here.
Well, was the code copied from the jdiff plugin or from jdiff itself ?
If it was just derived from the plugin which is licensed under the ASL
there would be no licensing issue.
Emmanuel Bourg
Re: [Commons websites] not updated recently
Posted by Martin Cooper <mf...@gmail.com>.
On Wed, 3 Nov 2004 02:38:16 +0800, Corey Scott <co...@gmail.com> wrote:
> Great,
>
> Attached is the plugin.jelly file, as I said before, this is my first
> one, so no guarantees to quality. Maybe someone could help me test
> this and get it to where it needs to be?
>
> Thanks,
> Corey
>
> PS. I have to acknowledge the fact that I 'borrowed' and modified the
> jdiff code (thanks go out to those responsible)
AFAIK, JDiff is LGPL. That being the case, I don't believe we can
accept your code here.
--
Martin Cooper
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [Commons websites] not updated recently
Posted by Corey Scott <co...@gmail.com>.
Great,
Attached is the plugin.jelly file, as I said before, this is my first
one, so no guarantees to quality. Maybe someone could help me test
this and get it to where it needs to be?
Thanks,
Corey
PS. I have to acknowledge the fact that I 'borrowed' and modified the
jdiff code (thanks go out to those responsible)
Re: [general] Website? Re: [Commons websites] not updated recently
Posted by Henri Yandell <fl...@gmail.com>.
On Wed, 03 Nov 2004 18:09:28 -0500, Mark R. Diggory
<md...@latte.harvard.edu> wrote:
> Hen and all,
>
> We put allot of work over the summer into getting the top level site to
> its current state. Having it be modular and easily updatable. Why is
> this coming across as difficult to maintain?
>
> jakarta-commons/commons-build/ `maven site:deploy` updates the top level.
Yep, my fault, sorry. Last time I tried (months ago) I could have
sworn it wanted to build all the components rather than just the
commons-build project.
I'll add your instructions to the site page on the wiki, as I don't
think we have it documented anywhere but email archives yet (?).
http://wiki.apache.org/jakarta-commons/CreatingStandardWebPresence
I'll try to commit some time to flesh out an example of my opinion on
where I think the site should go next. The main idea is a split
between a release site (the current one, with very few custom reports)
and a developer site (very few custom docs, lots of reports), loosely
based on the builds.osjava prototyping.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] Website? Re: [Commons websites] not updated recently
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Hen and all,
We put allot of work over the summer into getting the top level site to
its current state. Having it be modular and easily updatable. Why is
this coming across as difficult to maintain?
jakarta-commons/commons-build/ `maven site:deploy` updates the top level.
jakarta-commons/commons-build/ is where we maintain all the top level
documentation. Each project uses this plus their own project to generate
their maven site with the commons branding. There are references to the
commons-build jsl and menu contents in each project.properties for the
subprojects. You checkout commons-build and your project, go to your
project directory and run `maven site:deploy` and your site is updated.
Currently each project is responsible for the content of its site. This
was the only way to maintain the fact that different projects wanted to
have different strategies for publishing reports and javadoc
documentation. Its a solution that unified the look and feel while
maintaining sub-project autonomy.
Don't get me wrong, I'd like to see a fully integrated commons site and
I like the idea of a common javadoc/xref for the whole thing. Its just
getting all the custom reporting in line. And allowing the individual
projects to update pages when they want is very important too.
-Mark
Henri Yandell wrote:
> Oh. Sales pitches (that I've made before and need to move on again):
>
> http://multidoc.osjava.org/ (needs hacking to work with Clover)
> http://builds.osjava.org/
>
> I've had both setup for Commons before and need to get them going again.
>
> Idea being, we would have a jakarta.apache.org/commons/builds site
> which had the developer stuff, and a lot of the current commons site
> could be removed (all the maven reports etc), and we could tighten the
> release site down a lot; which will help get rid of a lot of the extra
> noise.
>
> Hen
>
> On Wed, 3 Nov 2004 17:18:51 -0500, Henri Yandell <fl...@gmail.com> wrote:
>
>>I think we should have two websites.
>>
>>The first is a user-based one and contains information on the latest releases.
>>The second is a developer-based one and contains information on HEAD
>>and diff's between the latest release and HEAD.
>>
>>The second one would be generated nightly, perhaps as part of a
>>nightly build and would be report-centric. The first would only be
>>changed on a release, and would be documentation-centric. It should be
>>much quicker to make changes to than the current one is.
>>
>>I'd like to multidoc both of them (currently many components don't
>>have a javadoc for the last release, or in the alternative case, a
>>javadoc for HEAD) to make it easier to see
>>
>>I'd also like to decouple the Commons part of the site from all the
>>release parts. Currently it seems to me that we've coupled the Commons
>>site itself to the components and it's a pain in the arse. Might have
>>improved in the last month or so.
>>
>>Just thoughts that I eternally hope to have time to work on...
>>
>>Hen
>>
>>On Tue, 02 Nov 2004 18:40:23 +0100, Emmanuel Bourg <sm...@lfjr.net> wrote:
>>
>>>That looks great, I'm definitely interested. It solves a part of the
>>>problem, the only issue left is the generation of the documentation.
>>>
>>>I guess the best would be to integrate this as a maven plugin, maybe as
>>>an enhancement of the javadoc plugin. In the meantime we could integrate
>>>your code in the commons-build scripts.
>>>
>>>Emmanuel Bourg
>>>
>>>
>>>
>>>
>>>Corey Scott wrote:
>>>
>>>>To whom might be interested,
>>>>
>>>>I have developed an extension (sort of) to the JDiff maven plugin that
>>>>checks-out a version (defined by property ${maven.jdiff.javadoc.tag},
>>>>defaults to CURRENT) and then generates the javadoc.
>>>>The docs are generated in:
>>>>${docsDest}/apidocs/${maven.jdiff.javadoc.tag}
>>>>
>>>>There is probably more to be done, eg. adding links to the menu, but
>>>>this is my first attempt with jelly (so the code is likely to be a
>>>>little sloppy also)
>>>>
>>>>Questions:
>>>>1) Is anyone is interested?
>>>>2) Does this solves our problem with auto-generating the commons
>>>>website regularly?
>>>>3) As its strictly not related to the JDiff plugin, where should I submit it?
>>>>
>>>>Many thanks,
>>>>Corey
>>>>
>>>>PS. I going to post this to the Maven dev list as well, sorry for
>>>>anyone who ends up with 2 copies, but I just wanted to make sure
>>>>Commons people where aware of it, cause I thought it might be useful
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] Website? Re: [Commons websites] not updated recently
Posted by Henri Yandell <fl...@gmail.com>.
Oh. Sales pitches (that I've made before and need to move on again):
http://multidoc.osjava.org/ (needs hacking to work with Clover)
http://builds.osjava.org/
I've had both setup for Commons before and need to get them going again.
Idea being, we would have a jakarta.apache.org/commons/builds site
which had the developer stuff, and a lot of the current commons site
could be removed (all the maven reports etc), and we could tighten the
release site down a lot; which will help get rid of a lot of the extra
noise.
Hen
On Wed, 3 Nov 2004 17:18:51 -0500, Henri Yandell <fl...@gmail.com> wrote:
> I think we should have two websites.
>
> The first is a user-based one and contains information on the latest releases.
> The second is a developer-based one and contains information on HEAD
> and diff's between the latest release and HEAD.
>
> The second one would be generated nightly, perhaps as part of a
> nightly build and would be report-centric. The first would only be
> changed on a release, and would be documentation-centric. It should be
> much quicker to make changes to than the current one is.
>
> I'd like to multidoc both of them (currently many components don't
> have a javadoc for the last release, or in the alternative case, a
> javadoc for HEAD) to make it easier to see
>
> I'd also like to decouple the Commons part of the site from all the
> release parts. Currently it seems to me that we've coupled the Commons
> site itself to the components and it's a pain in the arse. Might have
> improved in the last month or so.
>
> Just thoughts that I eternally hope to have time to work on...
>
> Hen
>
> On Tue, 02 Nov 2004 18:40:23 +0100, Emmanuel Bourg <sm...@lfjr.net> wrote:
> > That looks great, I'm definitely interested. It solves a part of the
> > problem, the only issue left is the generation of the documentation.
> >
> > I guess the best would be to integrate this as a maven plugin, maybe as
> > an enhancement of the javadoc plugin. In the meantime we could integrate
> > your code in the commons-build scripts.
> >
> > Emmanuel Bourg
> >
> >
> >
> >
> > Corey Scott wrote:
> > > To whom might be interested,
> > >
> > > I have developed an extension (sort of) to the JDiff maven plugin that
> > > checks-out a version (defined by property ${maven.jdiff.javadoc.tag},
> > > defaults to CURRENT) and then generates the javadoc.
> > > The docs are generated in:
> > > ${docsDest}/apidocs/${maven.jdiff.javadoc.tag}
> > >
> > > There is probably more to be done, eg. adding links to the menu, but
> > > this is my first attempt with jelly (so the code is likely to be a
> > > little sloppy also)
> > >
> > > Questions:
> > > 1) Is anyone is interested?
> > > 2) Does this solves our problem with auto-generating the commons
> > > website regularly?
> > > 3) As its strictly not related to the JDiff plugin, where should I submit it?
> > >
> > > Many thanks,
> > > Corey
> > >
> > > PS. I going to post this to the Maven dev list as well, sorry for
> > > anyone who ends up with 2 copies, but I just wanted to make sure
> > > Commons people where aware of it, cause I thought it might be useful
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[general] Website? Re: [Commons websites] not updated recently
Posted by Henri Yandell <fl...@gmail.com>.
I think we should have two websites.
The first is a user-based one and contains information on the latest releases.
The second is a developer-based one and contains information on HEAD
and diff's between the latest release and HEAD.
The second one would be generated nightly, perhaps as part of a
nightly build and would be report-centric. The first would only be
changed on a release, and would be documentation-centric. It should be
much quicker to make changes to than the current one is.
I'd like to multidoc both of them (currently many components don't
have a javadoc for the last release, or in the alternative case, a
javadoc for HEAD) to make it easier to see
I'd also like to decouple the Commons part of the site from all the
release parts. Currently it seems to me that we've coupled the Commons
site itself to the components and it's a pain in the arse. Might have
improved in the last month or so.
Just thoughts that I eternally hope to have time to work on...
Hen
On Tue, 02 Nov 2004 18:40:23 +0100, Emmanuel Bourg <sm...@lfjr.net> wrote:
> That looks great, I'm definitely interested. It solves a part of the
> problem, the only issue left is the generation of the documentation.
>
> I guess the best would be to integrate this as a maven plugin, maybe as
> an enhancement of the javadoc plugin. In the meantime we could integrate
> your code in the commons-build scripts.
>
> Emmanuel Bourg
>
>
>
>
> Corey Scott wrote:
> > To whom might be interested,
> >
> > I have developed an extension (sort of) to the JDiff maven plugin that
> > checks-out a version (defined by property ${maven.jdiff.javadoc.tag},
> > defaults to CURRENT) and then generates the javadoc.
> > The docs are generated in:
> > ${docsDest}/apidocs/${maven.jdiff.javadoc.tag}
> >
> > There is probably more to be done, eg. adding links to the menu, but
> > this is my first attempt with jelly (so the code is likely to be a
> > little sloppy also)
> >
> > Questions:
> > 1) Is anyone is interested?
> > 2) Does this solves our problem with auto-generating the commons
> > website regularly?
> > 3) As its strictly not related to the JDiff plugin, where should I submit it?
> >
> > Many thanks,
> > Corey
> >
> > PS. I going to post this to the Maven dev list as well, sorry for
> > anyone who ends up with 2 copies, but I just wanted to make sure
> > Commons people where aware of it, cause I thought it might be useful
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [Commons websites] not updated recently
Posted by Emmanuel Bourg <sm...@lfjr.net>.
That looks great, I'm definitely interested. It solves a part of the
problem, the only issue left is the generation of the documentation.
I guess the best would be to integrate this as a maven plugin, maybe as
an enhancement of the javadoc plugin. In the meantime we could integrate
your code in the commons-build scripts.
Emmanuel Bourg
Corey Scott wrote:
> To whom might be interested,
>
> I have developed an extension (sort of) to the JDiff maven plugin that
> checks-out a version (defined by property ${maven.jdiff.javadoc.tag},
> defaults to CURRENT) and then generates the javadoc.
> The docs are generated in:
> ${docsDest}/apidocs/${maven.jdiff.javadoc.tag}
>
> There is probably more to be done, eg. adding links to the menu, but
> this is my first attempt with jelly (so the code is likely to be a
> little sloppy also)
>
> Questions:
> 1) Is anyone is interested?
> 2) Does this solves our problem with auto-generating the commons
> website regularly?
> 3) As its strictly not related to the JDiff plugin, where should I submit it?
>
> Many thanks,
> Corey
>
> PS. I going to post this to the Maven dev list as well, sorry for
> anyone who ends up with 2 copies, but I just wanted to make sure
> Commons people where aware of it, cause I thought it might be useful
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [Commons websites] not updated recently
Posted by Corey Scott <co...@gmail.com>.
To whom might be interested,
I have developed an extension (sort of) to the JDiff maven plugin that
checks-out a version (defined by property ${maven.jdiff.javadoc.tag},
defaults to CURRENT) and then generates the javadoc.
The docs are generated in:
${docsDest}/apidocs/${maven.jdiff.javadoc.tag}
There is probably more to be done, eg. adding links to the menu, but
this is my first attempt with jelly (so the code is likely to be a
little sloppy also)
Questions:
1) Is anyone is interested?
2) Does this solves our problem with auto-generating the commons
website regularly?
3) As its strictly not related to the JDiff plugin, where should I submit it?
Many thanks,
Corey
PS. I going to post this to the Maven dev list as well, sorry for
anyone who ends up with 2 copies, but I just wanted to make sure
Commons people where aware of it, cause I thought it might be useful
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [Commons websites] not updated recently
Posted by Emmanuel Bourg <sm...@lfjr.net>.
Corey Scott wrote:
> Forgive me if I am speaking out of turn, but would this only be a
> matter of running the maven reports target against the release branch
> of the cvs not the latest?
> (this sound like something obtainable with a reasonably small amount of effort)
>
> Then hacking together a menu which indicated this?
>
> Please tell me if I am missing the point here.
Yes that's mostly that. I don't think generating the code reports (unit
tests, coverage, checkstyle...) for the older release is really
relevant. We just need the javadoc for every release and the
documentation pages.
Emmanuel Bourg
Re: [Commons websites] not updated recently
Posted by Corey Scott <co...@gmail.com>.
Forgive me if I am speaking out of turn, but would this only be a
matter of running the maven reports target against the release branch
of the cvs not the latest?
(this sound like something obtainable with a reasonably small amount of effort)
Then hacking together a menu which indicated this?
Please tell me if I am missing the point here.
Thanks,
Corey
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [Commons websites] not updated recently
Posted by Emmanuel Bourg <sm...@lfjr.net>.
Corey Scott wrote:
> Is there a reason why a some of the commons sites have not been
> updated for a few months? Isnt this giving people (outsiders) a false
> sense of how active/inactive the projects are?
>
> I thought that seeing as most sites are probably
> auto-generated/updated using maven that someone would have cron'd
> this?
I believe the last time we spoke about this topic we stumbled on the
lack of distinction between stable and unstable documentation in maven.
With the default maven configuration, updating the site automatically
means publishing unstable javadoc API and documentation pages that do
not apply to the latest release, which is confusing for users. Some
projects likes [collections] or [digester] have hacked the publishing
process to generate separated documentations for released API and
developpement API, but this is not generalized yet. We just need someone
courageous to step in and harmonize the maven configurations for all
commons projects, or even better patch maven directly.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org