Re: [VOTE] Release Apache Commons Configuration 2.9.0 based on RC1

2023-03-28 Thread Gary Gregory 
This vote passes with the following binding +1s:

- Henri Biestro
- Bruno Kinoshita
- Gary Gregory

Gary

On Tue, Mar 28, 2023 at 11:23 PM Gary Gregory 
wrote:

> My +1
>
> Gary
>
> On Mon, Mar 27, 2023 at 8:43 AM Bruno Kinoshita  wrote:
>
>>[x] +1 Release these artifacts
>>
>> Tested from tag with:
>>
>> Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
>> Maven home: /opt/apache-maven-3.8.5
>> Java version: 17.0.6, vendor: Private Build, runtime:
>> /usr/lib/jvm/java-17-openjdk-amd64
>> Default locale: en_US, platform encoding: UTF-8
>> OS name: "linux", version: "5.15.0-67-generic", arch: "amd64", family:
>> "unix"
>>
>> Building OK, reports look good.
>>
>> Thanks!
>>
>> -Bruno
>>
>>
>> On Sun, 26 Mar 2023 at 01:40, Gary Gregory 
>> wrote:
>>
>> > We have fixed a few bugs and made some enhancements since Apache
>> > Commons Configuration 2.8.0 was released, so I would like to release
>> > Apache Commons Configuration 2.9.0.
>> >
>> > Apache Commons Configuration 2.9.0 RC1 is available for review here:
>> >
>> https://dist.apache.org/repos/dist/dev/commons/configuration/2.9.0-RC1
>> > (svn revision 60824)
>> >
>> > The Git tag commons-configuration-2.9.0-RC1 commit for this RC is
>> > 1208fcf3697fc04aaff51c7fdaf15123e41db2a5 which you can browse here:
>> >
>> >
>> https://gitbox.apache.org/repos/asf?p=commons-configuration.git;a=commit;h=1208fcf3697fc04aaff51c7fdaf15123e41db2a5
>> > You may checkout this tag using:
>> > git clone
>> > https://gitbox.apache.org/repos/asf/commons-configuration.git
>> > --branch
>> > 
>> > commons-configuration-2.9.0-RC1
>> > commons-configuration-2.9.0-RC1
>> >
>> > Maven artifacts are here:
>> >
>> >
>> https://repository.apache.org/content/repositories/orgapachecommons-1629/org/apache/commons/commons-configuration2/2.9.0/
>> >
>> > These are the artifacts and their hashes:
>> >
>> > #Release SHA-512s
>> > #Sat Mar 25 20:26:08 EDT 2023
>> >
>> >
>> org.apache.commons_commons-configuration2-2.9.0.spdx.json=e44968793cfc3e76e7219f3eee77b9ea9cf563f08210145443d688d31a227fa034c7406508a94454b9b1c61c1e673ef7ea6a057aef909e1a6733010c164a6b1d
>> >
>> >
>> commons-configuration2-2.9.0-test-sources.jar=81afa85b7e9106456d2f39e0048acd952ce61c91a399472ce1dcf85658b56e6f8490b78d8dda7a7ac55bd1c15e84e7547c9aedf813aada2c34576dfdfc12
>> >
>> >
>> commons-configuration2-2.9.0-src.zip=df79d8a2d51029bae1700b67e2567a219a4d74fb1cc91ea92998ecd9c68c50c5ddfa67f06533348a03292c2c097fe8baa7fba1a441ceb84c741c80f7e293349a
>> >
>> >
>> commons-configuration2-2.9.0-sources.jar=1057ff30b5bd3ed49a9e7a374a26ed4d34caaa7ab7efa11b0c674843ca1cb5d6ce00e434e014a6758d697d66686c1f511025f07f1840c3fb29c06fef7c73b669
>> >
>> >
>> commons-configuration2-2.9.0-bin.zip=aa3d52bd9ceb0dfdc1cba953e1819a0296240c3d75f0bcb65b32f636d7394c65885397c44439be3276d532fcd95e5aaa628b2084b7f96d426979ecf8a856bdf6
>> >
>> >
>> commons-configuration2-2.9.0-bom.json=fa7030cf2fe9671124245ed02e0609d943d8e60886b6c02f95e0d9975839bb463e83a174097ced929fb0772eafab0e89656e98b5ab07b2526ba3cfcdf290a8e1
>> >
>> >
>> commons-configuration2-2.9.0-bom.xml=531a85f638fb7e5b08313296c2e322d21127b48ea2977d33e2ddbc1514dc3c6c4e8be26a3954f72a55291d9cbc3a36bc14c7d21090fdc15023e74785fe0badf4
>> >
>> >
>> commons-configuration2-2.9.0-src.tar.gz=61091f483aa531b52e4b97b5671042bd6b8b6080c5f8951c3de27fbf1beb5c5d93c2deb2e641bb39b3fd4e7e24de6f49e931ff248501f864ea2e2f9804defdfa
>> >
>> >
>> commons-configuration2-2.9.0-bin.tar.gz=b8116991f587e7cb708d4fa693fac8a2501d6c2523db50233d17eb388aff2ecc1b1181fca3001b7276a1e41c7c7675e996d543356f1894253a8b8858213a8021
>> >
>> >
>> commons-configuration2-2.9.0-javadoc.jar=69841bda81d36fcb4a2bb7d2774966badcf1254009813d55e612df22fe62da3afd5ff144916a7367d8c682b48d0d65250dd0ffdfbca2e7b50373345600f8c2f9
>> >
>> >
>> commons-configuration2-2.9.0-tests.jar=03ef15faa363247050be985cd8e7c8dfdcbb3c4ad6d2992b36bc07eacef78d20b76e7352bf647846d73f6ed64169cf5d981ff77592a572460ef2cee06073b746
>> >
>> > I have tested this with:
>> >
>> > mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site
>> > deploy
>> >
>> > Using:
>> >
>> > Apache Maven 3.9.1 (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
>> > Maven home: /usr/local/Cellar/maven/3.9.1/libexec
>> > Java version: 11.0.18, vendor: Homebrew, runtime:
>> > /usr/local/Cellar/openjdk@11/11.0.18/libexec/openjdk.jdk/Contents/Home
>> > Default locale: en_US, platform encoding: UTF-8
>> > OS name: "mac os x", version: "13.2.1", arch: "x86_64", family: "mac"
>> > Darwin gdg-mac-mini.local 22.3.0 Darwin Kernel Version 22.3.0: Mon Jan
>> > 30 20:42:11 PST 2023; root:xnu-8792.81.3~2/RELEASE_X86_64 x86_64
>> >
>> > Note that I had to use Java 11 instead of Java 8 to get one of the
>> > SBOM plugins to play nice.
>> >
>> > Details of changes since 2.8.0 are in the release notes:
>> >
>> >
>> https://dist.apache.org/repos/dist/dev/commons/configuration/2.9.0-RC1/RELEASE-NOTES.txt
>> >
>> >
>> https://dist.apache.

Re: [VOTE] Release Apache Commons Configuration 2.9.0 based on RC1

2023-03-28 Thread Gary Gregory 
My +1

Gary

On Mon, Mar 27, 2023 at 8:43 AM Bruno Kinoshita  wrote:

>[x] +1 Release these artifacts
>
> Tested from tag with:
>
> Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
> Maven home: /opt/apache-maven-3.8.5
> Java version: 17.0.6, vendor: Private Build, runtime:
> /usr/lib/jvm/java-17-openjdk-amd64
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.15.0-67-generic", arch: "amd64", family:
> "unix"
>
> Building OK, reports look good.
>
> Thanks!
>
> -Bruno
>
>
> On Sun, 26 Mar 2023 at 01:40, Gary Gregory  wrote:
>
> > We have fixed a few bugs and made some enhancements since Apache
> > Commons Configuration 2.8.0 was released, so I would like to release
> > Apache Commons Configuration 2.9.0.
> >
> > Apache Commons Configuration 2.9.0 RC1 is available for review here:
> >
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.9.0-RC1
> > (svn revision 60824)
> >
> > The Git tag commons-configuration-2.9.0-RC1 commit for this RC is
> > 1208fcf3697fc04aaff51c7fdaf15123e41db2a5 which you can browse here:
> >
> >
> https://gitbox.apache.org/repos/asf?p=commons-configuration.git;a=commit;h=1208fcf3697fc04aaff51c7fdaf15123e41db2a5
> > You may checkout this tag using:
> > git clone
> > https://gitbox.apache.org/repos/asf/commons-configuration.git
> > --branch
> > 
> > commons-configuration-2.9.0-RC1
> > commons-configuration-2.9.0-RC1
> >
> > Maven artifacts are here:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1629/org/apache/commons/commons-configuration2/2.9.0/
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> > #Sat Mar 25 20:26:08 EDT 2023
> >
> >
> org.apache.commons_commons-configuration2-2.9.0.spdx.json=e44968793cfc3e76e7219f3eee77b9ea9cf563f08210145443d688d31a227fa034c7406508a94454b9b1c61c1e673ef7ea6a057aef909e1a6733010c164a6b1d
> >
> >
> commons-configuration2-2.9.0-test-sources.jar=81afa85b7e9106456d2f39e0048acd952ce61c91a399472ce1dcf85658b56e6f8490b78d8dda7a7ac55bd1c15e84e7547c9aedf813aada2c34576dfdfc12
> >
> >
> commons-configuration2-2.9.0-src.zip=df79d8a2d51029bae1700b67e2567a219a4d74fb1cc91ea92998ecd9c68c50c5ddfa67f06533348a03292c2c097fe8baa7fba1a441ceb84c741c80f7e293349a
> >
> >
> commons-configuration2-2.9.0-sources.jar=1057ff30b5bd3ed49a9e7a374a26ed4d34caaa7ab7efa11b0c674843ca1cb5d6ce00e434e014a6758d697d66686c1f511025f07f1840c3fb29c06fef7c73b669
> >
> >
> commons-configuration2-2.9.0-bin.zip=aa3d52bd9ceb0dfdc1cba953e1819a0296240c3d75f0bcb65b32f636d7394c65885397c44439be3276d532fcd95e5aaa628b2084b7f96d426979ecf8a856bdf6
> >
> >
> commons-configuration2-2.9.0-bom.json=fa7030cf2fe9671124245ed02e0609d943d8e60886b6c02f95e0d9975839bb463e83a174097ced929fb0772eafab0e89656e98b5ab07b2526ba3cfcdf290a8e1
> >
> >
> commons-configuration2-2.9.0-bom.xml=531a85f638fb7e5b08313296c2e322d21127b48ea2977d33e2ddbc1514dc3c6c4e8be26a3954f72a55291d9cbc3a36bc14c7d21090fdc15023e74785fe0badf4
> >
> >
> commons-configuration2-2.9.0-src.tar.gz=61091f483aa531b52e4b97b5671042bd6b8b6080c5f8951c3de27fbf1beb5c5d93c2deb2e641bb39b3fd4e7e24de6f49e931ff248501f864ea2e2f9804defdfa
> >
> >
> commons-configuration2-2.9.0-bin.tar.gz=b8116991f587e7cb708d4fa693fac8a2501d6c2523db50233d17eb388aff2ecc1b1181fca3001b7276a1e41c7c7675e996d543356f1894253a8b8858213a8021
> >
> >
> commons-configuration2-2.9.0-javadoc.jar=69841bda81d36fcb4a2bb7d2774966badcf1254009813d55e612df22fe62da3afd5ff144916a7367d8c682b48d0d65250dd0ffdfbca2e7b50373345600f8c2f9
> >
> >
> commons-configuration2-2.9.0-tests.jar=03ef15faa363247050be985cd8e7c8dfdcbb3c4ad6d2992b36bc07eacef78d20b76e7352bf647846d73f6ed64169cf5d981ff77592a572460ef2cee06073b746
> >
> > I have tested this with:
> >
> > mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site
> > deploy
> >
> > Using:
> >
> > Apache Maven 3.9.1 (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
> > Maven home: /usr/local/Cellar/maven/3.9.1/libexec
> > Java version: 11.0.18, vendor: Homebrew, runtime:
> > /usr/local/Cellar/openjdk@11/11.0.18/libexec/openjdk.jdk/Contents/Home
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "mac os x", version: "13.2.1", arch: "x86_64", family: "mac"
> > Darwin gdg-mac-mini.local 22.3.0 Darwin Kernel Version 22.3.0: Mon Jan
> > 30 20:42:11 PST 2023; root:xnu-8792.81.3~2/RELEASE_X86_64 x86_64
> >
> > Note that I had to use Java 11 instead of Java 8 to get one of the
> > SBOM plugins to play nice.
> >
> > Details of changes since 2.8.0 are in the release notes:
> >
> >
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.9.0-RC1/RELEASE-NOTES.txt
> >
> >
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.9.0-RC1/site/changes-report.html
> >
> > Site:
> >
> >
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.9.0-RC1/site/index.html
> > (note some *relative* links are broken and the 2.9.0 directories
> > are not yet created -

Re: Re: Release Commons Fileupload 1.4.1?

2023-03-28 Thread Gary Gregory 
You can use the git master branch in your projects and let us know if you
find issues.

Gary


On Mon, Mar 27, 2023, 23:01 Maxim Solodovnik  wrote:

> Q1 is almost over :(
> Are you still planning to release 2.0?
> Do you need any help? :))
>
> On 2022/12/07 17:30:35 Gary Gregory wrote:
> > The next release will be 2.0 which will hopefully happen Q1 2023.
> >
> > Gary
> >
> > On Wed, Dec 7, 2022, 11:28 Dennis Kieselhorst  wrote:
> >
> > > Well this is the change I'm particularly interested in to have clean
> > > transitive dependencies but looking at the commit logs other useful
> > > things happened as well. The last release happened in 2019. I
> understand
> > > though that fileupload is implemented differently nowadays and
> > > maintaining this project no longer is a priority.
> > >
> > > Dennis
> > >
> > >
> > > On 2022/12/07 16:01:48 Gary Gregory wrote:
> > >  > This is unlikely to happen for only a dependency update, and also
> > > since it
> > >  > is simple to override in Maven, Ivy, and so on.
> > >  > Recall that we are volunteers here where each person spends their
> > >  > valuable time as they best see fit ;-)
> > >  >
> > >  > Gary
> > >  >
> > >  > On Wed, Dec 7, 2022, 10:49 Dennis Kieselhorst 
> wrote:
> > >  >
> > >  > > Hi folks,
> > >  > >
> > >  > > would it be possible to release Commons Fileupload 1.4.1? 1.4
> still
> > >  > > contains commons-io 2.2 and requires to explicitly exclude it
> > >  > > (CVE-2021-29425).
> > >  > >
> > >  > > Thanks,
> > >  > > Dennis
> > >  > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [ALL] Queries related to inconsistent naming of security pages

2023-03-28 Thread Gilles Sadowski 
Hello.

Le mar. 28 mars 2023 à 13:40, sebb  a écrit :
>
> Here are the security page sources I could find:
>
> bcel/src/site/xdoc/security.xml
> collections/src/site/xdoc/security-reports.xml
> compress/src/site/xdoc/security.xml
> configuration/src/site/xdoc/security.xml
> crypto/src/site/xdoc/security.xml
> email/src/site/xdoc/security-reports.xml
> fileupload/src/site/xdoc/security-reports.xml
> net/src/site/xdoc/security.xml
> text/src/site/xdoc/security.xml
>
> These are not consistent, which results in problems such as the broken
> link for Compress on the page:
> https://commons.apache.org/security.html
>
> Does anyone know if there was a change in the convention for renaming these?
> If so, which is correct?
>
> It looks like the 'security.html' links are added to the site menu via
> site.xml, but that does not appear to be the case for the
> 'security-reports.html' links.
>
> Does anyone know how these get added?
>
> Note, it would probably be a good idea to standardise on the placement
> of the links in the menu.
> Just after Downloads is probably as good a place as any.
>

How about having the list of vulnerabilities (that has to be
managed "manually" anyways) part of the common "Commons"
site?
A link on each component's "sub-site" could refer back to that
page but it should not be left to every component to design its
"own" security listing.

Note: On that page, there is this line
  Apache Commons BCEL Security Vulnerabilities
linking to
  https://commons.apache.org/proper/commons-bcel/security.html
that states
  For information about reporting or asking questions about security,
please see the security page of the Apache Commons project.
where "security page" links back to the common page.

IMHO, all security issues should have one line on a single page,
that line linking to a page with more details (such as links to CVE
reports, commits, blog posts, ...).

Regards,
Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

JDK 20 is now GA, JDK 21 Early-Access builds, and 2 important heads-up!

2023-03-28 Thread David Delabassee 

Welcome to the latest OpenJDK Quality Outreach update!

Last week was busy as we released both Java 20 and JavaFX 20. To 
celebrate the launch, we hosted a live event focused on Java 20, i.e. 
Level Up Java Day. All the sessions recordings will be made available 
shortly on the YouTube Java channel.


Some recent events shown us that it is useful to conduct tests using the 
latest early-access OpenJDK builds. This will benefit the OpenJDK 
codebase but also your own codebase. Sometime, a failure could be due to 
an actual regression introduced in OpenJDK. In that case, we obviously 
want to hear about it while we can still address it. But sometime, a 
failure could also be due to a subtle behaviour change... that works as 
expected. Regardless of if it's a bug or a test that is now broken due 
to a behaviour change, we want to hear from you. In the latter case, it 
might also mean that we should probably communicate more about those 
changes even if they might seem subtle. On that note, please make sure 
to check all the 2 Heads-Up below: "Support for Unicode CLDR Version 42" 
and "New network interface names on Windows".


So please, let us know if you observe anything using the latest 
early-access builds of JDK 21.



## Heads-Up - JDK 20 - Support for Unicode CLDR Version 42

The JDK's locale data is based on the Unicode Consortium's Unicode 
Common Locale Data Repository (CLDR). As mentioned in the December 2022 
Quality Outreach newsletter [1], JDK 20 upgraded CLDR [2] to version 42 
[3], which was released in October 2022. This version includes a "more 
sophisticated handling of spaces" [4] that replaces regular spaces with 
non-breaking spaces (NBSP / `\u00A0`) or narrow non-breaking spaces 
(NNBSP / `\u202F`):

- in time formats between `a` and time
- in unit formats between {0} and unit
- in Cyrillic date formats before year marker such as `г`

Other noticeable changes include:
* " at " is no longer used for standard date/time format ’ [5]
* fix first day of week info for China (CN) [6]
* Japanese: Support numbers up to 京 [7]

As a consequence, production and test code that produces or parses 
locale-dependent strings like formatted dates and times may change 
behavior in potentially breaking ways (e.g. when a handcrafted datetime 
string with a regular space is parsed, but the parser now expects an 
NBSP or NNBSP). Issues can be hard to analyze because expected and 
actual strings look very similar or even identical in various text 
representations. To detect and fix these issues, make sure to use a text 
editor that displays different kinds of spaces differently.


If the required fixes can't be implemented when upgrading to JDK 20, 
consider using the JVM argument `-Djava.locale.providers=COMPAT` to use 
legacy locale data. Note that this limits some locale-related 
functionality and treat it as a temporary workaround, not a proper 
solution. Moreover, the `COMPAT` option will be eventually removed in 
the future.


It is also important to keep in mind that this kind of locale data 
evolves regularly so programs parsing/composing the locale data by 
themselves should be routinely checked with each JDK release.


[1] 
https://mail.openjdk.org/pipermail/quality-discuss/2022-December/001100.html

[2] https://bugs.openjdk.org/browse/JDK-8284840
[3] https://cldr.unicode.org/index/downloads/cldr-42
[4] https://unicode-org.atlassian.net/browse/CLDR-14032
[5] https://unicode-org.atlassian.net/browse/CLDR-14831
[6] https://unicode-org.atlassian.net/browse/CLDR-11510
[7] https://unicode-org.atlassian.net/browse/CLDR-15966


## Heads-Up - JDK 21 - New network interface names on Windows

Network Names that the JDK assigns to network interfaces on Windows are 
changing in JDK 21 [8].


The JDK historically synthesized names for network interfaces on 
Windows. This has changed to use the names assigned by the Windows 
operating system. For example, the JDK may have historically assigned a 
name such as “eth0” for an ethernet interface and “lo” for the loopback. 
The equivalent names that Windows assigns may be names such as 
“ethernet_32768” and “loopback_0".


This change may impact code that does a lookup of network interfaces 
with the `NetworkInterace.getByName(String name)` method. It also may 
also be surprising to code that enumerates all network interfaces with 
the `NetworkInterfaces.networkInterfaces()` or 
`NetworkInterface.getNetworkInterfaces()` methods as the names of the 
network interfaces will look different to previous releases. Depending 
on configuration, it is possible that enumerating all network interfaces 
will enumerate network interfaces that weren’t previously enumerated 
because they didn’t have an Internet Protocol address assigned. The 
display name returned by `NetworkInterface::getDisplayName` has not 
changed so this should facilitate the identification of network 
interfaces when using Windows native tools.


[8] https://bugs.openjdk.org/browse/JDK-8303898


## JDK 20

Re: [ALL] Queries related to inconsistent naming of security pages

2023-03-28 Thread Gary Gregory 
I don't think there ever was an effort to standardize the file name or menu
placement, nor is there a way to enforce it; not unless you want to make
the parent pom work harder through some custom enforcer plugin rules (I am
guessing).

Gary

On Tue, Mar 28, 2023, 07:41 sebb  wrote:

> Here are the security page sources I could find:
>
> bcel/src/site/xdoc/security.xml
> collections/src/site/xdoc/security-reports.xml
> compress/src/site/xdoc/security.xml
> configuration/src/site/xdoc/security.xml
> crypto/src/site/xdoc/security.xml
> email/src/site/xdoc/security-reports.xml
> fileupload/src/site/xdoc/security-reports.xml
> net/src/site/xdoc/security.xml
> text/src/site/xdoc/security.xml
>
> These are not consistent, which results in problems such as the broken
> link for Compress on the page:
> https://commons.apache.org/security.html
>
> Does anyone know if there was a change in the convention for renaming
> these?
> If so, which is correct?
>
> It looks like the 'security.html' links are added to the site menu via
> site.xml, but that does not appear to be the case for the
> 'security-reports.html' links.
>
> Does anyone know how these get added?
>
> Note, it would probably be a good idea to standardise on the placement
> of the links in the menu.
> Just after Downloads is probably as good a place as any.
>
> Sebb
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[ALL] Queries related to inconsistent naming of security pages

2023-03-28 Thread sebb 
Here are the security page sources I could find:

bcel/src/site/xdoc/security.xml
collections/src/site/xdoc/security-reports.xml
compress/src/site/xdoc/security.xml
configuration/src/site/xdoc/security.xml
crypto/src/site/xdoc/security.xml
email/src/site/xdoc/security-reports.xml
fileupload/src/site/xdoc/security-reports.xml
net/src/site/xdoc/security.xml
text/src/site/xdoc/security.xml

These are not consistent, which results in problems such as the broken
link for Compress on the page:
https://commons.apache.org/security.html

Does anyone know if there was a change in the convention for renaming these?
If so, which is correct?

It looks like the 'security.html' links are added to the site menu via
site.xml, but that does not appear to be the case for the
'security-reports.html' links.

Does anyone know how these get added?

Note, it would probably be a good idea to standardise on the placement
of the links in the menu.
Just after Downloads is probably as good a place as any.

Sebb

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org