Re: [Dbutil] Java 8 -> 11

[John Patrick]

As a consumer, I would prefer all java version changes to be considered
major breaking changes for all apache commons components.
I've waste lots of hours trying to find the oldest released version that
supports a specific java version as the project can't yet upgrade for
various reasons.


On Sun, 15 Oct 2023 at 15:49, sebb  wrote:

> On Sun, 15 Oct 2023 at 15:37, Elric  wrote:
> >
> > On 15/10/2023 16:31, Gary Gregory wrote:
> > > A major version bump is rather heavy handed when no one is asking for a
> > > "real" 2.0 with breaking changes.
> >
> > Agreed. My 2 cents: a minor version and a clear release note is plenty.
> > Critical bug fixes can still be made by bumping the patch version,
>
> Are you sure about that ?
> Has that been tried?
>
> > though given that Java 8 is nearly ten years old, it's really time for
> > folks to upgrade.
> >
> > -
> > 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: [fileupload] jakarta versus javax?

[John Patrick]

That would probably need to be a major release as it would break backwards
compatibility for other consumers.
I don't know the roadmap for fileupload but I would suggest raising a jira
ticket for this new feature request.

Looking at Tomcat 10.x it appears to be Servlet 5.0 specification which is
either Jakarta EE 9 or Jakarta EE 9.1.
Then looking at Jakarta EE 9 release in 2020-12-08, that did the breaking
change from javax. to jakarta.

I think this type of issue will happen more as I don't think all Apache
Commons are at Java 1.8, but once they support Java 9 or new and they can
support Multi Jar Releases it will be easier to support newer Java LTS
like, 11 and 17. Then in 15 months we get Java 21 which i understand is the
new 2 year LTS release schedule instead of the 3 year release schedule.

Cheers,
John


On Wed, 30 Mar 2022 at 21:33, Mark Foley  wrote:

> Just now joining this list. I've installed Tomcat 10.0.17 which uses the
> jakarta class, not javax. FileUpload 1.4 (the most recent as far as I
> can tell) uses javax. Is FileUpload schedule for a new version using
> jakarta?
>
> Thanks --Mark

Commons VFS Approve Workflows

[John Patrick]

Evening,

Could someone approve my PR's workflow as still 1st time contributor for
vfs. If they pass they are read for review and potential merge.

Upgrades all the easy tests to JUnit v5
https://github.com/apache/commons-vfs/pull/240

Extracts test methods out of AbstractVfsTestCase, and also deleted
AbstractVfsTestCase.
https://github.com/apache/commons-vfs/pull/241

Cheers,
John

Commons Jelly not currently building PR's

[John Patrick]

So wanted to update commons-jelly.

It's using travis and the default distro won't allow Java 1.7 to be
installed. So raised PR https://github.com/apache/commons-jelly/pull/8 to
fix that.

Now the build starts but I think due to Java 1.5 being the source and
target it's got another issue with DataSourceWrapper missing
getParentLogger.

Questions;

1) Should I just look at getting GitHub Actions working? And drop travis?

2) What min Java version should I bump it too, as Java 1.5 seams too old?

3) If I'm doing a major java version change, should I bump the version?
should I create jira ticket covering work?

Cheers,
John

Re: CODED-285 - JUnit5

[John Patrick]

If they are my PR's they cover;
) @Test(expected=xxx.class) to using assertThrows
) trying to use assertAll
) removing unused imports

As I've been having issues with large PR changes, I've been trying to do
smaller PR's with a single item, or test being changed.

John


On Sun, 20 Feb 2022 at 05:31, Itamar C  wrote:

> Just finished changing all tests to JUnit5 and dropped junit-vintage-engine
> from pom.xml.
>
> It's on PR #113.
>
> I saw that there are another 8 PRs in the issue, I hope there are not too
> many conflicts in there for the reviewer.
>
> Any doubt about my changes, I'm here to answer.
>
> (By the way, I just sent my ICLA to the Apache Foundation Secretary.)
>
> Regards,
>
> Itamar Carvalho
>
>
> On Thu, Feb 17, 2022 at 11:09 PM Matt Sicker  wrote:
>
> > The same applies to changing access modifiers. JUnit 5 encourages use of
> > package private everything as it’s the least typing and now supported (as
> > in v5 will reflectively allow access to your test code if it’s not
> public).
> >
> > —
> > Matt Sicker
> >
> > > On Feb 17, 2022, at 19:59, Gary Gregory 
> wrote:
> > >
> > > On Thu, Feb 17, 2022 at 8:47 PM Itamar C  wrote:
> > >
> > >>> On Thu, Feb 17, 2022 at 8:16 PM Gilles Sadowski <
> gillese...@gmail.com>
> > >>> wrote:
> > >>>
> > >>> Which discussion (since this thread covered more than one subject)?
> > >>> If you mean the "migration to Junit 5" task for [Codec], it's already
> > >>> there.[1]
> > >>> If you mean the method rename (to remove the "test" prefix), then
> > >>> the "dev" ML is where to continue the discussion (and/or start a vote
> > >>> if there is no clear agreement).
> > >>>
> > >>> Regards,
> > >>> Gilles
> > >>>
> > >>>
> > >> Hi.
> > >>
> > >> I was talking about the method rename (to remove the "test" prefix).
> > >> If this ML is the right place to continue the discussion or make a
> > vote, ok
> > >> then.
> > >>
> > >
> > > I am opposed to changing hundreds if not thousands of methods names
> just
> > > for cosmetic reasons, it is certainly not required to use JUnit 5.
> > >
> > > Gary
> > >
> > >
> > >> Regards,
> > >> Itamar
> > >>
> >
>

Re: [commons-vfs] Failure in bump ftpserver-core from 1.1.1 to 1.1.2

[John Patrick]

oh, didn't thinking about that resource depletion. probably a useful
feature that github actions should thinking about adding;
- if pro account allow
- if account previously approved for project allow

i added '.tmp', then committed, then removed '.tmp', then committed, the
pushed to my fork, so the diff is exactly the same but the commit hash is
different. i've got a zsh function that does it automatically as i use that
'hack' lots as use to rubbish cicd with random intermittent failures.

John



On Fri, 31 Dec 2021 at 16:50, Xeno Amess  wrote:

> @Gary Gregory
> Alright I woke up.
> Hard to fall asleep when thinking my ex-fiancée should be happing with her
> new boyfriend...
> (sigh.)
> I will help you upgrade slf4j first, as I think it should be easier. then
> one by one..
>
> Xeno Amess  于2022年1月1日周六 00:43写道：
>
> > btw, I didn't get what you changed comparing to the original pr...
> > If a re-trigger can work, then it is quite amazing, as several actions
> all
> > died but they all die because of just false failed build?
> > Not very likely IMO...
> >
> > Xeno Amess  于2022年1月1日周六 00:42写道：
> >
> >> > any reason pr's have to be manually approved before the ci jobs
> execute?
> >>
> >> 2 reasons.
> >>
> >> 1. github actions is free but only under some rate liminition.
> >>
> >> So if there is no such rule, some  bad guys can create 100 accounts
> >> and drain every open-source repo's github actions account.
> >>
> >> 2. some repos using github actions with cache, and use it to auto-deploy
> >>
> >> which means there is a chance for some bad guys to inject the repo's
> >> auto-deploy artifact by creating pr and inject something in cache.
> >>
> >> John Patrick  于2022年1月1日周六 00:27写道：
> >>
> >>> so wanted to try and help out but unable to as pr won't build until
> it's
> >>> approved by maintainer.
> >>> from what i can tell it should have worked. tried that branch and
> master
> >>> and both pass locally
> >>> tried to kick off another build to see if just false failed build, so
> >>> created new branch but it linked to previous commit, so added and
> remove
> >>> a
> >>> file to trick github to try and do a new build again.
> >>> any reason pr's have to be manually approved before the ci jobs
> execute?
> >>>
> >>> John
> >>>
> >>>
> >>> On Fri, 31 Dec 2021 at 13:50, Xeno Amess  wrote:
> >>>
> >>> > need sleep now，will have a look 10 hours later
> >>> >
> >>> > XenoAmess
> >>> > 
> >>> > From: Gary Gregory 
> >>> > Sent: Friday, December 31, 2021 9:28:36 PM
> >>> > To: Commons Developers List 
> >>> > Subject: [commons-vfs] Failure in bump ftpserver-core from 1.1.1 to
> >>> 1.1.2
> >>> >
> >>> > Does anyone have any free time to look at this failure?
> >>> >
> >>> > I'm still dealing with Log4j fallout...
> >>> >
> >>> > Gary
> >>> >
> >>> > -- Forwarded message -
> >>> > From: GitBox 
> >>> > Date: Fri, Dec 31, 2021 at 6:05 AM
> >>> > Subject: [GitHub] [commons-vfs] dependabot[bot] opened a new pull
> >>> request
> >>> > #231: Bump ftpserver-core from 1.1.1 to 1.1.2
> >>> > To: 
> >>> >
> >>> >
> >>> >
> >>> > dependabot[bot] opened a new pull request #231:
> >>> > URL: https://github.com/apache/commons-vfs/pull/231
> >>> >
> >>> >
> >>> >Bumps [ftpserver-core](https://github.com/apache/mina-ftpserver)
> >>> from
> >>> > 1.1.1 to 1.1.2.
> >>> >
> >>> >Commits
> >>> >
> >>> >https://github.com/apache/mina-ftpserver/commit/a04a44d756e9ae18d0461326c761a851b8346d3d
> >>> > ">a04a44d
> >>> > [maven-release-plugin] prepare release ftpserver-parent-1.1.2
> >>> >https://github.com/apache/mina-ftpserver/commit/d7fdad2429cf7b2ae433e10fa7df3b7961fe3704
> >>> > ">d7fdad2
> >>> > Fixed the javadoc failures
> >>> >https://github.com/apache/mina-ftpserver/commit/b4e8d0e39622ce5b121c183f070fe1ad67b41c4f
> >>> > ">b4e8d0e
> >>> > [maven-release-

Re: [commons-vfs] Failure in bump ftpserver-core from 1.1.1 to 1.1.2

[John Patrick]

so wanted to try and help out but unable to as pr won't build until it's
approved by maintainer.
from what i can tell it should have worked. tried that branch and master
and both pass locally
tried to kick off another build to see if just false failed build, so
created new branch but it linked to previous commit, so added and remove a
file to trick github to try and do a new build again.
any reason pr's have to be manually approved before the ci jobs execute?

John


On Fri, 31 Dec 2021 at 13:50, Xeno Amess  wrote:

> need sleep now，will have a look 10 hours later
>
> XenoAmess
> 
> From: Gary Gregory 
> Sent: Friday, December 31, 2021 9:28:36 PM
> To: Commons Developers List 
> Subject: [commons-vfs] Failure in bump ftpserver-core from 1.1.1 to 1.1.2
>
> Does anyone have any free time to look at this failure?
>
> I'm still dealing with Log4j fallout...
>
> Gary
>
> -- Forwarded message -
> From: GitBox 
> Date: Fri, Dec 31, 2021 at 6:05 AM
> Subject: [GitHub] [commons-vfs] dependabot[bot] opened a new pull request
> #231: Bump ftpserver-core from 1.1.1 to 1.1.2
> To: 
>
>
>
> dependabot[bot] opened a new pull request #231:
> URL: https://github.com/apache/commons-vfs/pull/231
>
>
>Bumps [ftpserver-core](https://github.com/apache/mina-ftpserver) from
> 1.1.1 to 1.1.2.
>
>Commits
>
>https://github.com/apache/mina-ftpserver/commit/a04a44d756e9ae18d0461326c761a851b8346d3d
> ">a04a44d
> [maven-release-plugin] prepare release ftpserver-parent-1.1.2
>https://github.com/apache/mina-ftpserver/commit/d7fdad2429cf7b2ae433e10fa7df3b7961fe3704
> ">d7fdad2
> Fixed the javadoc failures
>https://github.com/apache/mina-ftpserver/commit/b4e8d0e39622ce5b121c183f070fe1ad67b41c4f
> ">b4e8d0e
> [maven-release-plugin] rollback the release of ftpserver-parent-1.1.2
>https://github.com/apache/mina-ftpserver/commit/59947ea85dc7db2529f619886fd901fd0284bd42
> ">59947ea
> [maven-release-plugin] prepare for next development iteration
>https://github.com/apache/mina-ftpserver/commit/92c6af05cdf0eddd3d2e613b52def57984d78d33
> ">92c6af0
> [maven-release-plugin] prepare release ftpserver-parent-1.1.2
>https://github.com/apache/mina-ftpserver/commit/455a4336a4e9b319e1f6b5836b29dc095467c091
> ">455a433
> Fixed the outputStatement to make Javadoc plugin happy
>https://github.com/apache/mina-ftpserver/commit/94fabe3c1e4776a1754e20403f9c5830231542f7
> ">94fabe3
> [maven-release-plugin] rollback the release of ftpserver-parent-1.1.2
>https://github.com/apache/mina-ftpserver/commit/fd1a0d89870c89a7a7c619d1b8f19786e7ce75fb
> ">fd1a0d8
> [maven-release-plugin] prepare for next development iteration
>https://github.com/apache/mina-ftpserver/commit/990a5cebd692361b41e99d1bdf9cd2a9b1eed38a
> ">990a5ce
> [maven-release-plugin] prepare release ftpserver-parent-1.1.2
>https://github.com/apache/mina-ftpserver/commit/402dbb1298aa897ec15ef854d3c2493a0c766141
> ">402dbb1
> [maven-release-plugin] rollback the release of ftpserver-1.1.3
>Additional commits viewable in https://github.com/apache/mina-ftpserver/compare/ftpserver-1.1.1...ftpserver-parent-1.1.2
> ">compare
> view
>
>
>
>
>
>[![Dependabot compatibility score](
>
> https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=org.apache.ftpserver:ftpserver-core=maven=1.1.1=1.1.2)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores
> )
>
>Dependabot will resolve any conflicts with this PR as long as you don't
> alter it yourself. You can also trigger a rebase manually by commenting
> `@dependabot rebase`.
>
>[//]: # (dependabot-automerge-start)
>[//]: # (dependabot-automerge-end)
>
>---
>
>
>Dependabot commands and options
>
>
>You can trigger Dependabot actions by commenting on this PR:
>- `@dependabot rebase` will rebase this PR
>- `@dependabot recreate` will recreate this PR, overwriting any edits
> that have been made to it
>- `@dependabot merge` will merge this PR after your CI passes on it
>- `@dependabot squash and merge` will squash and merge this PR after
> your CI passes on it
>- `@dependabot cancel merge` will cancel a previously requested merge
> and block automerging
>- `@dependabot reopen` will reopen this PR if it is closed
>- `@dependabot close` will close this PR and stop Dependabot recreating
> it. You can achieve the same result by closing it manually
>- `@dependabot ignore this major version` will close this PR and stop
> Dependabot creating any more for this major version (unless you reopen the
> PR or upgrade to it yourself)
>- `@dependabot ignore this minor version` will close this PR and stop
> Dependabot creating any more for this minor version (unless you reopen the
> PR or upgrade to it yourself)
>- `@dependabot ignore this dependency` will close this PR and stop
> Dependabot 

Re: Has Dependabot alerted us to any security issues?

[John Patrick]

snyk just looks at security issues, not all avaliable updates.

i see dependabot (personally use renovate bot as dependabot has a broken
security mode regarding forks, as you can't disable dependabot on a fork),
as pro-actively upgrading dependencies, so the older dependency with a
security issue is then not being used when the venerability gets announced
as you have already upgraded.

John


On Wed, 29 Dec 2021 at 14:48, sebb  wrote:

> Genuine question: has Dependabot alerted us to any security issues?
>
> If so which ones, and was it the only alert mechanism for that issue?
>
> Sebb
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Pull Request Reviews/Feedback Please

[John Patrick]

So dependabot, most commons project already have it, so was helping out
adding it the the rest.
But the main reason was pro-active DevSecOps. So automatically testing the
current main branch against the latest releases of dependencies. Save
developer and contributors manually watching out for new dependencies being
release, saves having to manually create a commit and manually raise a pr.
Basically wanting to save those with write privileges time and you can pick
what and when you merge and know all all potential dependencies are being
tested.

JUnit, so running against the latest v4.x.

Hamcrest, as junit v4.x depends upon the v1.3 version, it upgrades to the
v2. So when in 5 or 10 years i'm able to just my java 8 and junit 5 pull
requests approved they won't break as already using the v2.x hamcrest.

Dot git ignore, if you checkout those project and build them, a few don't
exclude target so status shows lots. Also I believe discussed on this
mailing list that ide specific excludes shouldn't be part of the project as
it's the developer choosing that ide so it should be in their users git
ignore.

I would like to do some releases to bump everything to at least java 8, and
then spend my time upgrade unit tests to junit v5 jupiter.

But I might try that next year or the year after, after all we are only 3
years away from the Java 23 LTS.

John


On Wed, 8 Sept 2021 at 23:47, Gilles Sadowski  wrote:

> Hello.
>
> Le mer. 8 sept. 2021 à 21:10, John Patrick  a
> écrit :
> >
> > Hi,
> >
> > Could someone look at this pr's, some coming up to a year open.
>
> Thanks for the reminder; however ...
>
> >
> > Dependabot, adding the commons standard.
> > [...]
> > https://github.com/apache/commons-math/pull/160
> > https://github.com/apache/commons-numbers/pull/86
> > [...]
> > https://github.com/apache/commons-rng/pull/79
> > https://github.com/apache/commons-statistics/pull/25
> > [...]
> >
>
> What is the added value for projects' maintainers?
> [IIUC, this script advertises a new version that, most often than not,
> provides a solution to a problem that does not exist (for the target
> project)...]
>
> IOW, you (for example) are welcome to watch those update
> messages and, when a real problem would be solved through an
> upgrade, a specific PR will be most welcome.
>
> Best regards,
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Pull Request Reviews/Feedback Please

[John Patrick]

Hi,

Could someone look at this pr's, some coming up to a year open.

Dependabot, adding the commons standard.
https://github.com/apache/commons-jci/pull/3
https://github.com/apache/commons-jelly/pull/7
https://github.com/apache/commons-jxpath/pull/21
https://github.com/apache/commons-math/pull/160
https://github.com/apache/commons-numbers/pull/86
https://github.com/apache/commons-proxy/pull/5
https://github.com/apache/commons-rng/pull/79
https://github.com/apache/commons-statistics/pull/25
https://github.com/apache/commons-weaver/pull/5

JUnit bumping to latest v4
https://github.com/apache/commons-bsf/pull/21
https://github.com/apache/commons-digester/pull/5
https://github.com/apache/commons-jci/pull/2
https://github.com/apache/commons-jelly/pull/6
https://github.com/apache/commons-jxpath/pull/20
https://github.com/apache/commons-proxy/pull/4
https://github.com/apache/commons-weaver/pull/3

Hamcrest, change from junit embdedded v1.x to external v.2.x
https://github.com/apache/commons-chain/pull/5
https://github.com/apache/commons-collections/pull/251
https://github.com/apache/commons-configuration/pull/143
https://github.com/apache/commons-dbutils/pull/43
https://github.com/apache/commons-logging/pull/55
https://github.com/apache/commons-weaver/pull/4

Missing .gitignore, following discussions on mailing list that IDE specific
exclusions should be in users global .gitignore instead of all possible IDE
being in each project
https://github.com/apache/commons-jci/pull/1
https://github.com/apache/commons-logging/pull/19
https://github.com/apache/commons-proxy/pull/6

Cheers,
John

Re: [EXTERNAL] Re: [Numbers][All] Separate Java target version for "src/test"

[John Patrick]

So I want to start using Java 11 and take advantage of Java Modules. But
with a bug in Java Multi-Jar not supporting 1.8 as base and 11 upon that,
and most dependencies I want to upgrade eventually get stuck on a commons
project holding a pure JPMS solution.

Potentially someone raise an enhancement to drop support for Java 1.8 which
isn't happening for Java 17, but for Java 18 which is only 8 month away it
could happen. So at that point it might be a shock for commons projects as
you might be blocking open source projects, or they roll off commons
projects... just a thought.

I've tried to do a seamless upgrade, or suggest a roadmap, but haven't got
anywhere, but think I might just raise a JEP to drop 1.8 in Java 18...

John


On Thu, 10 Jun 2021 at 14:07, Gilles Sadowski  wrote:

> Le jeu. 10 juin 2021 à 14:42, John Patrick  a
> écrit :
> >
> > If the tests are valid and useful once post Java 1.8, what about
> > starting the next release branch where the min version bumps to Java
> > 11.
>
> [Numbers] and related components were meant to replace and
> improve some functionalities provided in [Math] v3.6.1 whose
> target was Java 5 (!).
> A few years ago, the bump to Java 8 was considered a bold move
> (for "Commons"). :-}
>
> If we are sure that Java 11 is no problem for anyone who'd go
> through the upgrade effort, then indeed why not?
>
> Gilles
>
> > As Java 17 starting ramp down starts today I believe so in 3 months we
> > will have 3 LTS (1.8, 11 and 17) releases. So technically Java 18
> > development starts tomorrow and I expect 1.8 will be dropped shortly
> > from backwards support as they want to get off the classpath fully and
> > onto the modules path.
> >
> > Anyway, just a thought.
> >
> > John
> >
> > On Thu, 10 Jun 2021 at 12:05, sebb  wrote:
> > >
> > > Thanks.
> > >
> > > I've updated the RELEASE-NOTES accordingly (feel free to tweak the
> text)
> > >
> > > On Thu, 10 Jun 2021 at 00:58, Alex Herbert 
> wrote:
> > > >
> > > > I have removed the requirement for Java 9 from the build. It is
> still used
> > > > in the performance testing module.
> > > >
> > > > Alex
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [EXTERNAL] Re: [Numbers][All] Separate Java target version for "src/test"

[John Patrick]

If the tests are valid and useful once post Java 1.8, what about
starting the next release branch where the min version bumps to Java
11.
As Java 17 starting ramp down starts today I believe so in 3 months we
will have 3 LTS (1.8, 11 and 17) releases. So technically Java 18
development starts tomorrow and I expect 1.8 will be dropped shortly
from backwards support as they want to get off the classpath fully and
onto the modules path.

Anyway, just a thought.

John

On Thu, 10 Jun 2021 at 12:05, sebb  wrote:
>
> Thanks.
>
> I've updated the RELEASE-NOTES accordingly (feel free to tweak the text)
>
> On Thu, 10 Jun 2021 at 00:58, Alex Herbert  wrote:
> >
> > I have removed the requirement for Java 9 from the build. It is still used
> > in the performance testing module.
> >
> > Alex
>
> -
> 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: [Numbers][All] Separate Java target version for "src/test"

[John Patrick]

Have you tried "9" instead of "1.9"?
I believe the 1.x was dropped with Java 9's release.
Also might want to bump it to Java 11 as that is a LTS release, as 9
was only supported for 6 months from september 2017 to march 2018.

Also with 9 and newer, maven.compiler.source/maven.compiler.target
have been replaced with maven.compiler.release. Not sure if the test
versions also changed or not.

I've no zero luck with a single pom with multiple src/test/java
directories, using different jdk's. The compiler supports toolchain
but when I last tried only for src/main directories, not for src/test
directories.

Also when the tests run they see everything in target/test-classes so
do you run them with 1.8 or 9?

JEP 238 supports multiple java versions in a single jar, but last time
i tried it appears to have a bug that the base version has to be java
9.

Not sure if the above helps or not, or give any insight.

John

On Wed, 9 Jun 2021 at 15:29, Gilles Sadowski  wrote:
>
> Hi.
>
> "Commons Numbers" POM of module "commons-numbers-core"
> contains
> ---CUT---
> 
> 1.9
> 1.9
> ---CUT---
>
> Running
> $ JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mvn test site site:stage
> fails:
> ---CUT---
> [...]
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:testCompile
> (default-testCompile) on project commons-numbers-core: Fatal error
> compiling: invalid target release: 1.9 -> [Help 1]
> ---CUT---
>
> Regards,
> Gilles
>
> -
> 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: [exec][email] Java 7 to 8

[John Patrick]

Some customers might need to use Java 7, but what about the customers
who want to use it on Java 17 which will be in rampdown in 5 months
and released in 6 months?
Also from memory from conferences ~ 2018/2019 I thought Java 17 was
planning on removing the Classpath so everything needed to be Modules
as well as raising the support min Java version to 8 or maybe even 11.

Also I understand that some customers might still be running Java 6 or
7 or 8, but would they be actively upgrading to newer versions and if
they have not found any bugs in the current version in the past ~10
years will they find any new ones in next 16 months...

On Sat, 21 Nov 2020 at 22:48, sebb  wrote:
>
> On Sat, 21 Nov 2020 at 17:13, Gary Gregory  wrote:
> >
> > On Sat, Nov 21, 2020 at 11:46 AM sebb  wrote:
> >
> > > Note that Java 7 and later are all on lndefinite Sustaining Support:
> > >
> > > https://www.oracle.com/java/technologies/java-se-support-roadmap.html
> > >
> > > This is presumably because there are customers who need Java 7.
> > >
> >
> > And those paying Oracle customers are welcome to NOT upgrade to new
> > versions or provide PRs and request releases.
>
> It's not just paying customers:
>
> "The Extended Support fee will be waived for the period June 2019 -
> July 2022 for Java SE 7."
>
> I don't see any pressing need to move to Java 8.
>
> > Gary
> >
> >
> > >
> > > On Sat, 21 Nov 2020 at 16:18, Gary Gregory  wrote:
> > > >
> > > > I do not see a reason to maintain EXEC and EMAIL on Java 7 at this 
> > > > point,
> > > > it's simpler to maintain Commons builds locally, on GitHub Actions, and
> > > > Travis CI by using Java 8.
> > > >
> > > > FYI, DAEMON is still on Java 6, presumably to support Tomcat. I will
> > > start
> > > > a separate thread about that, just to check status.
> > > >
> > > > Gary
> > >
> > > -
> > > 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
>

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

Re: [ JEXL ] Preparing release

[John Patrick]

What version of java is the command line maven using and what is
intellij using for;
1. Settings -> "Build, Execution, Deployment" -> "Build Tools" ->
Maven -> Importing -> "JDK for importer"
2. Settings -> "Build, Execution, Deployment" -> "Build Tools" ->
Maven -> Runner -> "JDK for importer"
3. "Project Structure" -> Project -> "Project SDK"

As when running maven tasks within IntelliJ, I can never remember
which of 1, 2 or 3 is used.

1 is used when importing and refreshing maven projects, so if you have
conditional profiles with activation based upon jvm, changing this
might be needed.
2 i think is used when running tasks
3 is used when writing code, validating code and also compiling code.
3 i think is also used when running unit tests

Not sure if that will show other issues of fix this issue, hopefully
it maybe highlight if different jvm's are being used when comparing
inside and outside intellij.

John


On Tue, 5 Jan 2021 at 17:06, Henri Biestro  wrote:
>
> Hello Team; Happy new year!
>
> I'm trying (again) to release JEXL 3.2 and I'm stuck at the 'Maven release 
> plugin' step in https://commons.apache.org/releases/prepare.html.
>
> Despite the fact a 'maven site' from IntelliJ does succeed, a 'mv 
> release:prepare -DtryRun' fails generating the Javadoc with a:
> [INFO] [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-javadoc-plugin:3.2.0:jar (attach-javadocs) on 
> project commons-jexl3: MavenReportException: Error while generating Javadoc:
> [INFO] [ERROR] Exit code: 1 - 
> /Users/henri.biestro/Java/Jexl/git/commons-jexl/src/main/java/org/apache/commons/jexl3/parser/SimpleNode.java:128:
>  warning: no description for @param
>
> The package is excluded in the configuration so I must be missing an obvious 
> step somewhere else to let maven do its magic properly.
> Any help appreciated :-)
>
>
>
> -
> 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

Jenkins has unset JAVA_HOME on windows slave

[John Patrick]

Just spotted an issue with maven enforcer and JDK 15, not related to
Java 15 issues but missing setup.

Anyone aware of an issue with NODE_NAME = jenkins-win-he-de-2? as when
it's doing the build windows-jdk15-m3.6.x_build it fails with the
error below;

f:\jenkins\jenkins-slave\712657a4\workspace\_maven-box_maven-enforcer_master@2\windows-jdk15-m3.6.x_build>mvn
-P+run-its -Dmaven.test.failure.ignore=true
-Dfindbugs.failOnError=false -e clean verify
- withMaven Wrapper script -
The JAVA_HOME environment variable is not defined correctly
This environment variable is needed to run this program
NB: JAVA_HOME should point to a JDK not a JRE
script returned exit code 1

Links here;
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-enforcer/job/master/29
https://ci-builds.apache.org/blue/organizations/jenkins/Maven%2Fmaven-box%2Fmaven-enforcer/detail/master/29/pipeline

John

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

Re: [commons-bsf] Question(s)

[John Patrick]

Rony,
Check emails that I started or replied too, from 1st March 2020
onwards. Probably up to about 10 separate email chains covering
dependabot, java 1.6/1.7/8/11+, junit 4.13, junit jupiter, getting
repo's in sync.
So I wasn't raising pr's blindly, I was doing them in conjunction with
email conversations...

John

On Tue, 24 Nov 2020 at 16:00, Gary Gregory  wrote:
>
> There has been lots of talk around Dependabot on the dev ML in the last few
> months. The current issue is that we want all robot emails off the dev ML
> and on to another probably new list.
>
> WRT Java 6, I would say forget it from my POV and interest. I am trying to
> move all components to Java 8, which is the oldest Java LTS release.
>
> Remember that no one will force an app onto a new version, it's up to the
> app.
>
> It's not clear to me if we have even interest for a BSF release. It looks
> like the last functional commit was from 2014, not a great sign...
>
> Any thoughts folks?
>
> Gary
>
> On Tue, Nov 24, 2020, 10:15 Rony G. Flatscher (Apache) 
> wrote:
>
> > Just noticed that there was some activity on GitHub related to BSF (e.g.
> >  (updating to JUnit 4.13.1),
> >  (dependabot), and the
> > like), but I cannot find any
> > discussions about it in dev@commons or in user@commons so wondering about
> > this.
> >
> > Regarding BSF 2.4 it would be important to have a Java minimum requirement
> > that allows for using it
> > in rather old Java runtime environments so I would be a little bit
> > preoccupied if the policy is to
> > upgrade the dependencies to the latest versions such that e.g. BSF 2.4
> > could not be deployed against
> > e.g. Java 1.6/6 anymore.
> >
> > So seeking information about where discussions/decisions took place or
> > should take place w.r.t. BSF?
> >
> > ---rony
> >
> > P.S.: Also it would be interesting to learn whether there is a demand for
> > creating a BSF 2.5 release?
> >
> > P.P.S.: Readying a script taglib that allows scripts in any script
> > language using the Apache Commons
> > BSF 2.4 to be used for creating web pages (and in this context even
> > allowing servlets to be
> > implemented with scripts), testing currently against Tomcat 9 ("javax.")
> > and Tomcat 10 ("jakarta.").
> > Tests being developed and carried out for [BSF4]ooRexx and Groovy (also
> > PHP using the JSR-223
> > sibling script taglib).
> >
> >
> >
> > -
> > 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: How to run Test cases of Apache Commons Lang in Intellij?

[John Patrick]

Standard steps for a Maven project in IntelliJ...

a.k.a. open maven pom.xml in IntelliJ as a project.

You should see a "Maven" tab and inside that tab see "Apache Commons Lang".

Then expand commons-lang->src->test->java->org.apache.commons.lang3.

Then right click or secondary click on the folder, then select "Run
'Tests in 'org.apache.commons.lang3''.

Tests will now execute.

Change the maven project name and java package name, the above steps
are the standard maven steps for importing and running any unit tests
in intellij.

See screenshot from mac... windows or linux might be different.

John


On Tue, 1 Dec 2020 at 10:19, Kanak Sony  wrote:
>
> Hey Developers,
>
> I have been trying to debug the library in Intellij and in respect to that
> trying to run test cases of Apache Commons Lang in intellij but I was
> unable to find the same. Can anyone of you please suggest me if any such
> resources are available?
>
> --
> Regards,
> Kanak Sony


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

Re: latest jar file of commons-cli 1.4

[John Patrick]

You'll have to build it yourself probably, I'm guessing 'c12260c'
relates to the hash, so to this specific commit;
'''
commit c12260c05ebcd27558265395df79b8b049534fbd
Author: Gary Gregory 
Date:   Wed Dec 18 15:28:13 2019 -0500

Remove trailing white spaces on all lines.
'''

Like you said yourself, it's a custom build of the latest code from
"Wed Dec 18 15:28:13 2019 -0500", so you might need to talk to the
person who built that jar for you or added that dependency version
into your build.

Good news, they understood it wasn't an official release so gave you
the hash of when it was from. I've had nightmares before when someone
wanted the latest open source project code but made up random version
numbers, or bumped a minor or a major version number so then caused
even more issues when the next official release happened.

John

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

Re: JUnit assertAll and assertThrows question

[John Patrick]

Circa 2016 or 2017 I was trying to get commons projects ready for java
9, so trying to get Automatic-Module-Name added into the manifest.
Moved onto other non commons projects for 2018 and 2019, helped with
modules and jupiter upgrades.
End of 2019 most of the java 9 work on other projects was blocked as
everything had dependencies on commons projects before they could be
true java 9+ modules projects.
Attempt to suggest a commons roadmap towards Java 11 as min version,
i.e. release current code at current version, bump to 1.8 and release
by end of 2020 say. Bump to Java 11 and release by mid 2021. So for a
year or 2 some projects might have multiple active master branches, so
if people do need commons-X on jdk 1.6 it is supported, but if no one
reports any issues it's maybe closed at the end of 2022.
Start of this year, try sorting out missing .gitignore and getting
them more standard, as some have target/ others /target/ others
**/target others **/target/. Upgrade to hamcrest v2.x. Move from junit
v4.x to junit-vintage v5.x and add junit-jupiter so dual support. Move
tests to junit jupiter classes. Upgrade maven dependencies/plugins to
latest versions. Look at adding using toolchain to select the jdk
instead of using the environment version.
Adding mvnw in prep for maven 3.7.0 which will have it now as part of
core maven instead of takari mvnw. So the project controls the maven
version, and when to upgrade.
I was going to start suggesting looking at moving commons-* to
org.apache.commons groupId so all are standard. Also how commons-lang3
does it's packages so commons-lang and also be a dependency and have
different packages so they don't clash. But held off...

Hope that gives an insight into my history with commons... some are
emails, some are jira tickets conversions, some are github
conversations.

My goal is to get commons upgrade to jpms, so the downstream projects
I help out in 2018/2019 can upgrade and do a final jdk 1.8 release and
move onto jdk 11.

So pr's for junit assertThrows I think are all done for
commons-collections, commons-digester and commons-validator.

Will look at vfs and maybe also rng regarding tidying up the tests etc.

John

On Thu, 15 Oct 2020 at 13:06, Gilles Sadowski  wrote:
>
> Hello.
>
> Le mer. 14 oct. 2020 à 21:41, John Patrick  a écrit :
> >
> > before i waste time looking at upgrading tests...
> >
> > any objections if i upgrade tests to use assertAll and assertThrows
> > introduced in JUnit jupiter?
> >
> > I see it as less tech debt removal and I'm happy to spend time doing
> > the upgrade which I've done from maybe several projects now. Just
> > don't want to get to raising PR and them being rejected, which I feel
> > happens with everything I try to help out with related to commons
> > projects at the moment...
>
> I did notice that (or forgot it).  Could you please remind of what you've
> proposed?
>
> AFAICT, the main contributors to
>   Commons Math
>   Commons Numbers
>   Commons Statistics
>   Commons Geometry
>   Commons RNG
> are glad to keep in line with the evolution of the best Java practices.
> Except for [RNG], which requires Java 1.6, all the above components
> are at Java 8.
>
> If you are into improving our testing suites, please note that help
> would be welcome in ironing out issues in Commons Math, where
> sometimes (but too often) the use of "randomly" generated data
> with a *fixed seed* hides the fact that the test actually fails for most
> input (i.e. data generated from another seed).
>
>
> Thanks,
> Gilles
>
> -
> 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: JUnit assertAll and assertThrows question

[John Patrick]

Looking at commons-collections, commons-digester and commons-validator
at the moment.
Will look at commons-vfs next regarding getting to JUnit v4, then
adding assertThrows afterwards.

What are views about adding
`1.8`? I've not
done it at the moment as suspect builds are not setup for that and
will fail etc.

But it does mean I need to add;
final ThrowingRunnable testMethod = new ThrowingRunnable() {
public void run() {
// The Code
}
};
assertThrows(ExceptionClass.class, testMethod);

instead of just;
final Executable testMethod = () -> // The Code
assertThrows(ExceptionClass.class, testMethod);

John

On Wed, 14 Oct 2020 at 22:07, Gary Gregory  wrote:
>
> For my money:
>
> - I REALLY like assertThrows
> - Might as well go to JUnit 5 if you feel up for it.
> - BUT: My biggest pain point ATM is that while Commons VFS is on JUnit 4,
> most tests are still JUnit 3 (TestCase) classes that won't run properly
> from Eclipse.
>
> So I would really like help getting VFS to at least be off of anything
> JUnit 3-like and at least to JUnit 4 but that won't stop a release which I
> hope to do within a week or two.
>
> TY!
> Gary
>
> On Wed, Oct 14, 2020 at 3:56 PM Romain Manni-Bucau 
> wrote:
>
> > Hi John,
> >
> > Would be +1 from me if:
> >
> > 1. It does not require to move from junit4 to junit5 (no gain IMHO)
> > 2. Test goes further than a Exception rule or @Test(expected)
> >
> > If both points are matched it makes sense to me, otherwise it will likely
> > add more issues from my experience.
> >
> >
> > Le mer. 14 oct. 2020 à 21:40, John Patrick  a
> > écrit :
> >
> > > before i waste time looking at upgrading tests...
> > >
> > > any objections if i upgrade tests to use assertAll and assertThrows
> > > introduced in JUnit jupiter?
> > >
> > > I see it as less tech debt removal and I'm happy to spend time doing
> > > the upgrade which I've done from maybe several projects now. Just
> > > don't want to get to raising PR and them being rejected, which I feel
> > > happens with everything I try to help out with related to commons
> > > projects at the moment...
> > >
> > > cheers,
> > > john
> > >
> > > -
> > > 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

JUnit assertAll and assertThrows question

[John Patrick]

before i waste time looking at upgrading tests...

any objections if i upgrade tests to use assertAll and assertThrows
introduced in JUnit jupiter?

I see it as less tech debt removal and I'm happy to spend time doing
the upgrade which I've done from maybe several projects now. Just
don't want to get to raising PR and them being rejected, which I feel
happens with everything I try to help out with related to commons
projects at the moment...

cheers,
john

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

Dependabot pr's

[John Patrick]

to shortcut multiple people telling me not to manually raise pr's to
upgrade dependencies, and dependabot is the preferred option for
commons to be raising these upgrades, and i should raise a pr to
enable dependabot.

so... here are all the pr's to enable dependabot on the repo's which
lack a dependabot.yml file.

https://github.com/apache/commons-bsf/pull/2
https://github.com/apache/commons-chain/pull/6
https://github.com/apache/commons-crypto/pull/108
https://github.com/apache/commons-daemon/pull/20
https://github.com/apache/commons-digester/pull/6
https://github.com/apache/commons-functor/pull/3
https://github.com/apache/commons-geometry/pull/102
https://github.com/apache/commons-jci/pull/3
https://github.com/apache/commons-jcs/pull/16
https://github.com/apache/commons-jelly/pull/7
https://github.com/apache/commons-jexl/pull/27
https://github.com/apache/commons-jxpath/pull/21
https://github.com/apache/commons-math/pull/160
https://github.com/apache/commons-numbers/pull/86
https://github.com/apache/commons-ognl/pull/10
https://github.com/apache/commons-proxy/pull/5
https://github.com/apache/commons-rng/pull/79
https://github.com/apache/commons-scxml/pull/9
https://github.com/apache/commons-statistics/pull/25
https://github.com/apache/commons-weaver/pull/5

They all have the change md5sum for .github/dependabot.yml which
matches the files in the other repos. I don't believe any other change
is required but i might be wrong.

John

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

.gitignore commons-chain

[John Patrick]

hi,

is someone able to review this pr please.
https://github.com/apache/commons-chain/pull/3

It's the last commons project that doesn't have a .gitignore file. My
other pr's adding a .gitignore have either been merged or someone
noticed and added one themselves.

cheers,
john

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

Re: [All] New repo for all proper components as submodules?

[John Patrick]

On Mon, 31 Aug 2020 at 14:16, Gary Gregory  wrote:
>
> On Mon, Aug 31, 2020 at 9:11 AM Matt Sicker  wrote:
>
> > Git submodules are pointers to other git commits. Therefore, any component
> > changes made don’t affect the mono repo until you update said mono repo to
> > point to the new commit. If you do this to point at the latest release
> > tags, this makes for less updates. Otherwise, you’ll want to figure out a
> > CI system for automatically updating submodules to the latest master
> > commits as they pass CI.
> >
>
> Can that commit be HEAD?

Used git submodules loads 2010-2015, and not much since. But from
memory it can't be HEAD it has to be a specific commit hash.

We had loads of issues when people worked on the sub modules
independently, it was easier when every worked with the parent git
module. But that was early 2010's so it might now allow HEAD or a
named branch say develop or master/main.

We also had loads of maven warnings because we had a wrapper project
so from the git parent module it saw the submodules as maven modules.
But the git parent module maven pom wasn't the parent pom of the git
submodules maven pom. As parent automatically is
../pom.xml

Our setup was;

git-module
-> pom.xml (GAV project:maven-wrapper:1)
-> git-submodule-parent
--> pom.xml (GAV project:parent:1)
-> git-submodule-core
--> pom.xml (GAV project:core:1, parent GAV project:parent:1) So
correct relative path is ../git-submodule-parent/poml.xml

They had ~35 git submodules, not sure if they are still using submodules.

So it can be useful if you want to have component based git repo's but
it does add an extra overhead layer of maintenance and everyone needs
to be onboard from experience.

John

>
> Gary
>
>
> >
> > On Mon, Aug 31, 2020 at 05:17 sebb  wrote:
> >
> > > On Sun, 30 Aug 2020 at 15:01, Gary Gregory 
> > wrote:
> > >
> > > >
> > >
> > > > On Sun, Aug 30, 2020 at 9:47 AM Rob Tompkins 
> > wrote:
> > >
> > > >
> > >
> > > > >
> > >
> > > > >
> > >
> > > > > > On Aug 30, 2020, at 9:44 AM, sebb  wrote:
> > >
> > > > > >
> > >
> > > > > > Some questions:
> > >
> > > > > >
> > >
> > > > > > - does it affect any existing usage?
> > >
> > > > > >  i.e. can people continue to use the individual repos exactly as
> > > before
> > >
> > > > >
> > >
> > > > > no they can’t
> > >
> > > > >
> > >
> > > >
> > >
> > > > Yes they can... this would be a new repo, and changes nothing for
> > current
> > >
> > > > usage. This does not affect existing repos.
> > >
> > >
> > >
> > > What about my other queries?
> > >
> > >
> > >
> > > - changes to commit messages:
> > >
> > >  can people commit to components directly from the new repo?
> > >
> > > If so, does that change the commit messages?
> > >
> > >
> > >
> > > - maintenance of the new repo:
> > >
> > > what is involved, and how will the project know when updates are needed?
> > >
> > >
> > >
> > > > Gary
> > >
> > > >
> > >
> > > > >
> > >
> > > > > >
> > >
> > > > > > - does it affect Git emails in any way?
> > >
> > > > > >  e.g. do they have different text?
> > >
> > > > >
> > >
> > > > > same emails
> > >
> > > > >
> > >
> > > > > >
> > >
> > > > > > - will it need much maintenance?
> > >
> > > > > > If so, how do we know when it needs updating?
> > >
> > > > >
> > >
> > > > > more maintainance, have to maintain a git hash at a symlink pointing
> > > to an
> > >
> > > > > external repository
> > >
> > > > >
> > >
> > > > > -Rob
> > >
> > > > >
> > >
> > > > > >
> > >
> > > > > > On Sun, 30 Aug 2020 at 14:26, Gary Gregory  > >
> > >
> > > > > wrote:
> > >
> > > > > >>
> > >
> > > > > >> Yes yes "girl" -> "git"
> > >
> > > > > >>
> > >
> > > > > >> On Sun, Aug 30, 2020, 09:24 Gary Gregory 
> > >
> > > > > wrote:
> > >
> > > > > >>
> > >
> > > > > >>> I'm talking about girl's own submodules:
> > >
> > > > > >>>
> > >
> > > > > >>> https://git-scm.com/book/en/v2/Git-Tools-Submodules
> > >
> > > > > >>>
> > >
> > > > > >>> https://git-scm.com/docs/git-submodule
> > >
> > > > > >>>
> > >
> > > > > >>> Gary
> > >
> > > > > >>>
> > >
> > > > > >>> On Sun, Aug 30, 2020, 09:09 Rob Tompkins 
> > > wrote:
> > >
> > > > > >>>
> > >
> > > > >  By git submodules, are you talking about a symlink to another
> > git
> > >
> > > > >  repository inside one of our repositories?
> > >
> > > > > 
> > >
> > > > >  -Rob
> > >
> > > > > 
> > >
> > > > > > On Aug 29, 2020, at 6:52 PM, Gary Gregory <
> > > garydgreg...@gmail.com>
> > >
> > > > >  wrote:
> > >
> > > > > >
> > >
> > > > > > Hi All,
> > >
> > > > > >
> > >
> > > > > > Any thoughts for or against creating a new git repository which
> > > would
> > >
> > > > > > contain all 'proper' Commons components as git submodules?
> > >
> > > > > >
> > >
> > > > > > The idea is to be able to checkout all of Commons 'proper' in
> > > one go
> > >
> > > > > in
> > >
> > > > >  one
> > >
> > > > > > place.
> > >
> > > > > >
> > >
> > > > > > Gary
> > >
> > > > > 
> > >
> 

Re: Introducing Maven Wrapper

[John Patrick]

I've now closed all PR's, and deleted the source branches.

Giles I've pushed the changes back into my commons-lang fork, so this
would recreate that branch
https://github.com/nhojpatrick/apache_commons-lang/pull/new/takari.maven-wrapper.

The PR if raised again, would include changes needed for github
workflow, travis and Jenkinsfile, also documentation updates.

You don't need to use mvnw if you are an advanced user with a specific
use case and know what you're doing. But for 90% of use cases just
saying use mvnw will be fine, advising mvnw won't stop you using mvn
to perform builds.

Everytime I install a new Java 15 or 16 EA version, and update my
toolchains.xml, I normally delete both ~/.m2/wrapper and
~/.m2/repository at the same time so regularly spring clean. So I'll
only have an old version of maven if I've needed to build an older
branch which was designed to be used on an older maven. Most modern
new CI's are creating slaves on demand per execution, so it won't
slowly build up older maven wrapper versions like the old style
jenkins slave.

John

On Wed, 19 Aug 2020 at 22:23, Gilles Sadowski  wrote:
>
> Le mer. 19 août 2020 à 22:49, Gary Gregory  a écrit :
> >
> > The consensus is do nothing IMO.
>
> "Those who do the work" etc. (see below).
>
> >
> > What I really dislike is that if I have 20 components that over time end up
> > containing 20 different versions of these Cmd/Sh/JavaSource/PropertiesFiles
> > that point to 20 different versions of Maven, and I build everything, I'll
> > end up with 20 different versions of Maven downloaded on my machine that I
> > did not ask.
>
> That seems like "business as usual" for maven-based development...
> But I'd tend to agree that it must at least be optional.
> Is someone willing to demonstrate that it is so, i.e. make the
> needed changes (for a single component)?
>
> Regards,
> Gilles
>
> >>> [...]
>
> -
> 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: Introducing Maven Wrapper

[John Patrick]

All the suggestions I'm seeing appear to be hard code solutions to
specific implementations, require defining things in multiple places,
or needing developers to select the correct version.

https://github.com/marketplace/actions/setup-maven won't work on my laptop
https://github.com/marketplace/actions/setup-maven won't work on travis
https://github.com/marketplace/actions/setup-maven won't work on jenkins
https://github.com/marketplace/actions/setup-maven will work for github actions

mvnw will work on my laptop
mvnw will work on your laptop
mvnw will work on the machine of a new contributor that has never
installed maven before
mvnw will work on travis
mvnw will work on jenkins
mvnw will work on github
mvnw puts control into each commons-* project as to what maven version
is needed and specific for each branch

Anyway, I'll be closing my PR's.

I'll take the hint and stop trying to contribute and help out.

I tried helping with early testing of java 9 early access releases,
and the response I received was basically "it's not out yet we don't
care".
I tried attempting getting multi release jars working so newer feature
for Java 11 LTS can be started to added, and got similar feedback, "
well we are still using java 1.6, 1.7 or 1.8, we don't care if people
want to use java 11 or newer, they will have to wait"
I tried help adding junit 5 jupiter to clean up so we can use
assertAll or assertThrows, some project accepted but I think others
are still outstanding.

John

On Wed, 19 Aug 2020 at 13:48, Romain Manni-Bucau  wrote:
>
> Le mer. 19 août 2020 à 14:33, Gary Gregory  a
> écrit :
>
> > On Wed, Aug 19, 2020 at 7:49 AM Gary Gregory 
> > wrote:
> >
> > > -1 from me, use a set up action instead, for example:
> > >
> > > https://github.com/marketplace?type=actions=maven
> > >
> > > In particular:
> > >
> > > https://github.com/marketplace/actions/setup-maven
> > >
> > > As recommended here:
> > > https://github.com/actions/setup-java/issues/40#issuecomment-675817329
> > >
> > > Gary
> > >
> >
> > Looking at https://github.com/marketplace/actions/setup-maven
> >
> > I am wondering why this is not done as a "simple" wget and tar call instead
> > of some big old node project.
> >
>
> Not sure what you have in mind with the "big old" (guess it was a "plain
> old" ?) but think the rationale is generally to use the GH Action SDK which
> is mainly js/ts.
> You can indeed replace it by whatever sh you want but you will have to
> reimplement the caching, assume about the running VM and reimplement a
> config strategy + maintain it if gh action strategy about it changes - or
> do something fully custom which is IMHO a bad idea.
> Nothing not doable but it is surely saner for a widely used OS project to
> stick to "standard" for things outside the scope of the project itself.
> That said a java GH Action SDK can be nice - but would likely still call
> node as of today :s.
>
>
> > I am leaning toward having our own Apache Commons setup action. Any
> > thoughts or volunteers?
> >
> > Gary
> >
> > PS: For Windows node, we could use Powershell if available to use wget.
> >
> >
> > >
> > > On Sat, Aug 15, 2020, 09:46 John Patrick  wrote:
> > >
> > >> I've raised some pull requests to add the Takari maven wrapper.
> > >>
> > >> The Takari maven wrapper is EOL and will be replaced with the Maven
> > >> Wrapper when Maven v3.7.0 is released.
> > >>
> > >> I've added the Takari version as maven v3.7.0 is not yet out. I've
> > >> been using the Takari maven wrapper for about 4 years now and it has
> > >> reduced a lot of maintenance and setup tasks.
> > >>
> > >> - Maven Wrapper is Maven-As-Code
> > >> - CI/CD, your docker images or Jenkins slaves no longer need maven pre
> > >> installed, so less maintenance tasks
> > >> - Developers don't need to pre install maven
> > >> - Projects control what version of maven to use, maybe a legacy
> > >> project needs v3.3.1 and a newer project needs v3.6.3. A developer
> > >> doesn't need to keep changing their PATH, they just use ./mvnw.
> > >> - Want to check a new version of maven, just change the properties,
> > >> then it can undergo the standard pull request build checks to make
> > >> sure the project works with that version.
> > >>
> > >> The first PR I raised was for commons-code and can be found here
> > >> https://github.com/apache/commons-codec/pull/58

Re: Github action versioning

[John Patrick]

I wonder if openjdk has considered all the auto generated traffic that
might be triggered from github. As for JDK 16 they are moving from
Mercurial to Git, and moving from internal hosting to Github. I guess
we will know shortly as ramp down for JDK 16 will start something in
december.

Having seen renovate (similar to dependabot) enabled for cucumber in
july, and the spike of ~50 pr initially, which each having an email
about code coverage, then another when approved and merged, then each
time rebased, another email and another code coverage email, until the
final merge email. It was a downpour of emails.

I expect commons will see similar spikes after a release of a project,
as so many projects on the same mailing lists, and when a release
train starts it cascades automatically, but it's better than someone
having to manually perform those tasks.

The question I guess is how do those with commit/approve privileges
want to receive notifications about PR's, comments and merges. With
dependabot adding automation, is it time to split out those github
event triggered emails to maybe commons-github or commons-lang-github.
If the people with the power believe they are being overloads with an
increase of traffic, it would give them the opportunity to only
receive notifications for projects they want to maintain. Splitting
dependabot from user triggered events, if you're wanting to avoid or
mute dependabot emails, you might as well simply disable dependabot.

Using gmail, it does allow simple filtering and displaying those
threads, I wouldn't want to receive github event emails using an email
client that doesn't automatically group email threads.

That reminds me, should I be top commenting or bottom commenting or
inline commenting for commons emails, as gmail defaults to top.

John

On Sun, 16 Aug 2020 at 14:10, Mark Thomas  wrote:
>
> On 16/08/2020 13:58, Gary Gregory wrote:
> > I would not do that for Maven plugins in a POM, so I would not do that
> > either for GitHub actions.
>
> Fair enough. It looked to me as if these updates were being approved
> largely automatically hence the suggestion to skip that and just let the
> upgrades happen. The option is there for components that want to use it.
>
> > Mailing list volume is a different topic.
>
> Indeed.
>
> Mark
>
> >
> > Gary
> >
> > On Sun, Aug 16, 2020, 05:55 Mark Thomas  wrote:
> >
> >> Hi,
> >>
> >> I am seeing an awful lot of list traffic generated for patch updates to
> >> github actions e.g. updating from v1.4.0 to v1.4.1
> >>
> >> Having read [1], my understanding is that we can specify v1 and that
> >> will always point to the latest 1.x.x release.
> >>
> >> Would it not be better to specify v1 for these actions as that way:
> >> - we use the latest version automatically (until 2.x.x is released)
> >> - we avoid all the noise on the mailing list
> >>
> >> Mark
> >>
> >>
> >>
> >> [1] https://docs.github.com/en/actions/creating-actions/about-actions
> >>
> >> -
> >> 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
>

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

Re: Github fork issue with dependabot

[John Patrick]

I think it's a bug with dependabot at github, so have raised it as
such with them.

>From what I can tell the .github/dependabot.yml is the configuration
part but it also has an approval part to enable and disable under the
projects settings. Under my fork's settings, dependabot is disabled,
so it looks like this enable/disable doesn't actually do anything for
forks, and it's purely triggered by the presence of the configuration
file.

I've tried with some of the apps that integrate with github, which I
use for dependency management and automatic merging/rebasing. They
only activate on the fork once I explicitly approve them.

John


On Sat, 15 Aug 2020 at 04:21, Gary Gregory  wrote:
>
> Typo:  I think the way it works is that when you forked the Commons Lang
> repo, you *copied* the whole repo of course including its .github folder
> which means you therefore asked for the Dependabot to run since its
> configuration file is there.
>
> On Fri, Aug 14, 2020 at 11:19 PM Gary Gregory 
> wrote:
>
> > I think the way it works is that when you forked the Commons Lang repo,
> > you the whole repo of course including its .github folder which means you
> > therefore asked for the Dependabot to run since its configuration file is
> > there.
> >
> > Obviously if you do not want Dependabot to run, then just disable it
> > (remove the file)
> >
> > Gary
> >
> >
> > On Fri, Aug 14, 2020 at 7:56 PM John Patrick 
> > wrote:
> >
> >> Cheers for that Giles,
> >> I read those emails as PR's raised at say
> >> https://github.com/apache/commons-lang and dependabot, which I
> >> understand.
> >> I'm talking about my fork for commons-lang at
> >> https://github.com/nhojpatrick/commons-lang.
> >>
> >> Dependabot appears to have been authorised against my fork without my
> >> approval?
> >>
> >> If i visit
> >> https://github.com/nhojpatrick/commons-lang/settings/security_analysis
> >> dependabot is showing as disabled, but it appears to be
> >> active.
> >>
> >> Hope that help explain I'm talking about my fork
> >> (https://github.com/nhojpatrick/commons-lang) and my the forked
> >> (https://github.com/apache/commons-lang) project.
> >>
> >> As I say, I totally understanding about getting emails regarding
> >> dependabot as it's been authorised on the
> >> https://github.com/apache/commons-lang project.
> >>
> >> John
> >>
> >>
> >> On Fri, 14 Aug 2020 at 23:54, Gilles Sadowski 
> >> wrote:
> >> >
> >> > Hi.
> >> >
> >> > Le sam. 15 août 2020 à 00:02, John Patrick  a
> >> écrit :
> >> > >
> >> > > I've just noticed a load of pull requests that have been auto created
> >> > > by dependabot, for changes to be merged into my forked version of
> >> > > master.
> >> > >
> >> > > For commons-lang I've 20 PR's, commons-logging 10 PR's, I've not
> >> > > checked all the other commons forks I've got.
> >> > >
> >> > > They are getting automatically closed once I sync the commons fork
> >> > > into my forked repo.
> >> > >
> >> > > Has anyone else seen this issue?
> >> >
> >> > Oh, yes:
> >> > https://markmail.org/message/2vutc4p3b3eqv73f
> >> > https://markmail.org/message/6apxz6vrc75uq6ge
> >> >
> >> > Gilles
> >> >
> >> > >
> >> > > It seems to be a change that happened about 20 days ago, as that is
> >> > > when the first PR was raised.
> >> > >
> >> > > These changes also seem to be triggering cicd github actions, see
> >> > >
> >> https://github.com/nhojpatrick/commons-lang/runs/965399930?check_suite_focus=true
> >> .
> >> > >
> >> > > John
> >> >
> >> > -
> >> > 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
> >>
> >>

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

Re: [ALL] Drop Travis in favor of Apache CI and GitHub Actions

[John Patrick]

Personally I wouldn't use GitHub Actions, it seems wrong coupling
yourself to what is hosting your code. I'm not saying anything is
wrong with GitHub Actions it just feels like vendor lock in.

When you say pushing SNAPSHOT to github.io would that be a nightly or
weekly or merge triggered releases?

John


On Sat, 15 Aug 2020 at 22:09, Gilles Sadowski  wrote:
>
> 2020-08-15 22:51 UTC+02:00, Geoffrey Blake :
> > Not familiar with Apache CI, but github actions do not support Arm builds.
> > Arm should be recognized as a first class build target these days.  Travis
> > allows Arm builds so not sure about the reasoning for moving off.
>
> Also, is Travis computing time a donation to the ASF?
> If so, we could continue using it for providing "convenience"
> builds for various architectures and thus spare some load on
> the Jenkins cluster, using the latter only for ensuring an
> independent build in a stable environment, and the generation
> of snapshots.
>
> Regards,
> Gilles
>
> >
> > -Geoff
> >
> > On Sat, Aug 15, 2020 at 1:11 PM Matt Sicker  wrote:
> >
> >> Agreed on the GitHub Actions. Neutral about how snapshot sites are
> >>
> >> published since there are multiple methods of doing the same thing,
> >>
> >> though if that's also simple to set up via the action to commit the
> >>
> >> output to the gh-pages branch, I'd say go for it!
> >>
> >>
> >>
> >> On Sat, 15 Aug 2020 at 13:07, Gary Gregory 
> >> wrote:
> >>
> >> >
> >>
> >> > Hi All,
> >>
> >> >
> >>
> >> > In order to ease maintenance, I propose that we drop Travis CI in favor
> >> of
> >>
> >> > Apache CI and GitHub Actions. 2 CI systems instead of 3 seems like
> >> > plenty
> >>
> >> > to me. The exception would be a component with an existing complex
> >> > Travis
> >>
> >> > build that was not or cannot be reproduced in GitHub Actions.
> >>
> >> >
> >>
> >> > Looking ahead, I think we should consider publishing SNAPSHOT sites to
> >>
> >> > GitHub.io.
> >>
> >> >
> >>
> >> > Gary
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >>
> >> Matt Sicker 
>
> -
> 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: [LOGGING][DAEMON] Update Java 6 to 7

[John Patrick]

What if you're wanting to use it on Java 14, 15 RC, 16 EA or in 6
months time 17 EA, will they support such an old version?
Reading the website;
Tomcat 7 needs Java 6 and later and (Java 7 for WebSockets),
Tomcat 8 is Java 7 and later
Tomcat 9 is Java 8 and later
Tomcat 10 is Java 8 and later

They are supporting multiple versions and back porting, or merging or
cherry-picking changes where applicable. If tomcat finds issues then
I'm sure we would put out a support release to fix their issue.

What if my project mandates Java 1.5 will commons demon downgrade back
to Java 1.5? What makes a downstream project a blocker for upgrading?
Do a major version bump and they can keep using the current version
they have, they don't have to upgrade if that breaks their
application...

John

On Sat, 15 Aug 2020 at 21:14, sebb  wrote:
>
> On Sat, 15 Aug 2020 at 19:01, Gary Gregory  wrote:
> >
> > On Sat, Aug 15, 2020 at 1:14 PM Mark Thomas  wrote:
> >
> > > On 10/08/2020 17:26, Gary Gregory wrote:
> > > > As recently done for [EMAIL], I propose we update [LOGGING] and [DAEMON]
> > > > from Java 6 to 7 to streamline building on CIs.
> > >
> > > -1 for DAEMON. Tomcat 7 depends on it and has a specification mandated
> > > requirement to run on Java 6.
> > >
> >
> > Yikes ;-) how long is rein in antiquity planned to last? ;-)
> >
> > We might need a branch for Tomcat so the project can move ahead in a more
> > modern setting IMO.
>
> -1
>
> Have you looked at DAEMON recently?
> It has just 10 Java files under src/main.
>
> Is it really worth converting these to require a later version of Java?
>
>
>
> > Gary
> >
> > >
> > > Are there any features / bugs in Jira that require this increase?
> > >
> > > Mark
> > >
> > > -
> > > 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
>

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

Introducing Maven Wrapper

[John Patrick]

I've raised some pull requests to add the Takari maven wrapper.

The Takari maven wrapper is EOL and will be replaced with the Maven
Wrapper when Maven v3.7.0 is released.

I've added the Takari version as maven v3.7.0 is not yet out. I've
been using the Takari maven wrapper for about 4 years now and it has
reduced a lot of maintenance and setup tasks.

- Maven Wrapper is Maven-As-Code
- CI/CD, your docker images or Jenkins slaves no longer need maven pre
installed, so less maintenance tasks
- Developers don't need to pre install maven
- Projects control what version of maven to use, maybe a legacy
project needs v3.3.1 and a newer project needs v3.6.3. A developer
doesn't need to keep changing their PATH, they just use ./mvnw.
- Want to check a new version of maven, just change the properties,
then it can undergo the standard pull request build checks to make
sure the project works with that version.

The first PR I raised was for commons-code and can be found here
https://github.com/apache/commons-codec/pull/58

I've also done similar or;
commons-collections
commons-configuration
commons-io
commons-lang
commons-parent
httpcomponent-client
httpcomponent-core
httpcomponent-parent

John

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

Re: Github fork issue with dependabot

[John Patrick]

Cheers for that Giles,
I read those emails as PR's raised at say
https://github.com/apache/commons-lang and dependabot, which I
understand.
I'm talking about my fork for commons-lang at
https://github.com/nhojpatrick/commons-lang.

Dependabot appears to have been authorised against my fork without my approval?

If i visit 
https://github.com/nhojpatrick/commons-lang/settings/security_analysis
dependabot is showing as disabled, but it appears to be
active.

Hope that help explain I'm talking about my fork
(https://github.com/nhojpatrick/commons-lang) and my the forked
(https://github.com/apache/commons-lang) project.

As I say, I totally understanding about getting emails regarding
dependabot as it's been authorised on the
https://github.com/apache/commons-lang project.

John


On Fri, 14 Aug 2020 at 23:54, Gilles Sadowski  wrote:
>
> Hi.
>
> Le sam. 15 août 2020 à 00:02, John Patrick  a écrit :
> >
> > I've just noticed a load of pull requests that have been auto created
> > by dependabot, for changes to be merged into my forked version of
> > master.
> >
> > For commons-lang I've 20 PR's, commons-logging 10 PR's, I've not
> > checked all the other commons forks I've got.
> >
> > They are getting automatically closed once I sync the commons fork
> > into my forked repo.
> >
> > Has anyone else seen this issue?
>
> Oh, yes:
> https://markmail.org/message/2vutc4p3b3eqv73f
> https://markmail.org/message/6apxz6vrc75uq6ge
>
> Gilles
>
> >
> > It seems to be a change that happened about 20 days ago, as that is
> > when the first PR was raised.
> >
> > These changes also seem to be triggering cicd github actions, see
> > https://github.com/nhojpatrick/commons-lang/runs/965399930?check_suite_focus=true.
> >
> > John
>
> -
> 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

Github fork issue with dependabot

[John Patrick]

I've just noticed a load of pull requests that have been auto created
by dependabot, for changes to be merged into my forked version of
master.

For commons-lang I've 20 PR's, commons-logging 10 PR's, I've not
checked all the other commons forks I've got.

They are getting automatically closed once I sync the commons fork
into my forked repo.

Has anyone else seen this issue?

It seems to be a change that happened about 20 days ago, as that is
when the first PR was raised.

These changes also seem to be triggering cicd github actions, see
https://github.com/nhojpatrick/commons-lang/runs/965399930?check_suite_focus=true.

John

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

Re: [io] can we delete release 20030203.000550 in maven central?

[John Patrick]

I keep thinking that too, and ended up just using a custom versions
rule to ignore it.

Other idea maybe change to GAV to;
1) org.apache.commons:commons-io
2) org.apache.commons:commons-io2

So starting to match the commons-lang3 approach.

I find commons-lang3 is a really good pattern and is much easier, as
it supports older and newer versions on the classpath at the same time
without conflict. Allowed phased upgrades.

And an upgrade to lang3 from lang is just a find/replace
"org.apache.commons.lang." to "org.apache.commons.lang3." and ticket
off the build process to check it worked.

Hopefully they will keep the same style for lang4 and it will just be
another find/replace upgrade when i choose.


On Sun, 14 Jun 2020 at 11:40, Xeno Amess  wrote:
>
> every time my update tool chain thinks 20030203.000550 is a greater version
> than 2.7 (actually it is, if see it in number).
> So have we some way to delete it from maven central? (or rename it?)
> The same problem happened in BeanUtils, version 20030211.134440

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

Re: Java Modules Codec, Collections, IO and Lang

[John Patrick]

So spring and other scanners scan classes under /META-INF/versions/...
i was unaware of that.
So probably need a major version bump then, so it indicates a major
change, so that consumers treat it as such and test it.

On Sun, 1 Mar 2020 at 17:11, Romain Manni-Bucau  wrote:
>
> Le dim. 1 mars 2020 à 18:00, John Patrick  a écrit :
>
> > Romain, The 4 commons projects I'm referring to already have
> > Automatic-Module-Name in the Manifest, if that is what you mean by
> > "explicit module name in the manifest".
> >
> > I've been playing around with jdk 1.8, 9, 10, 11, 12, 13 and 14, for
> > about 18 months and not seen the issue you described about needing
> > module-info being in the jar root.
> >
> > Regarding jpms classifier, I don't think that will help transitive
> > dependency, so A project depending upon collections which depends upon
> > codec. So will collections depend upon codec or codec-jpms. From what
> > I've got working I can add module-info without breaking pre java 11
> > users.
> >
>
> Test in j8 apps which didnt upgrade their scanner (spring, xbean,
> reflections, asm and friends, all have version limited to java 8 and not
> multirelease friendly), all are broken and it is one reason why adding
> .class with bytecode version > java 8 is very risky while java 8 apps are
> maintained (and we are still at ~50% of java 8 apps in prod today).
> Best case it requires to upgrade these libs...so all the stack too which is
> not always desired to upgrade a commons dep, worse case there is to upgrade
> possible so dep is forked or dropped.
> Indeed you dont see it in plain javase but commons being "commons", we must
> consider this common case too IMHO.
>
>
> > Peter, I'm trying to do as smaller change as possible to add
> > module-info, and also only using core maven plugins
> >
> > Commons Developers, I'll start raising jira tickets per project, per step.
> >
> > John
> >
> >
> >
> > John
> >
> > On Sun, 1 Mar 2020 at 11:44, Peter Verhas  wrote:
> > >
> > > I used Jabel, and Maven profiles to generate jvm8 and also jvm11 jars in
> > > the Java::Geci project.
> > >
> > > I also wrote a document about what, why, and how I did it:
> > >
> > >
> > > https://javax0.wordpress.com/2019/11/06/supporting-java-8/
> > >
> > > It may help.
> > >
> > > Peter
> > >
> > >
> > > On Sun, 1 Mar 2020 at 12:38, Romain Manni-Bucau 
> > > wrote:
> > >
> > > > Hi John,
> > > >
> > > > Didnt check on java 11 ga but in early versions module-info was
> > required to
> > > > be at the root of the jar even if overriden for some version (
> > > > http://openjdk.java.net/jeps/238) so it ends up in the fact that some
> > java
> > > > 8 apps will be broken by this addition and that only doing it in a mjar
> > > > will lead to the same kind of issues + will be likely ignored for other
> > > > apps.
> > > >
> > > > What about doing classified jar "jpms" at the same time than current
> > > > default jar to propose jpms integration early (worse case)?
> > > >
> > > > Alternative to just have an explicit module name in the manifest but no
> > > > module-info also sounds safer to me and still enables to use jpms.
> > > >
> > > > Hope it makes sense.
> > > >
> > > > Le dim. 1 mars 2020 à 12:08, John Patrick  a
> > > > écrit :
> > > >
> > > > > I'm wanting to correctly use Collections and Lang as Java Modules.
> > > > >
> > > > > Looking at the dependencies, I'll need to tackle all four projects.
> > > > >
> > > > > I'm planning on doing the following as if I'm touching the projects I
> > > > > might as well help out;
> > > > > 1) spring clean .gitignore, each project has different list, some
> > > > > documented others not
> > > > > 2) update to hamcrest v2.2
> > > > > 3) update to junit v5.6 (jupiter and vintage)
> > > > > 4) tackle low hanging fruit tests that can quickly be moved to
> > jupiter
> > > > > 5) update maven-dependencies to latest for compiler, jar, install
> > > > > 6) discuss how toolchain should be setup for build tools have access
> > > > > to jdk 1.8 and jdk 11, ideally the same pattern/approach for all
> > > > > commons projects
> > > > > 7) ad

Re: Java Modules Codec, Collections, IO and Lang

[John Patrick]

Romain, The 4 commons projects I'm referring to already have
Automatic-Module-Name in the Manifest, if that is what you mean by
"explicit module name in the manifest".

I've been playing around with jdk 1.8, 9, 10, 11, 12, 13 and 14, for
about 18 months and not seen the issue you described about needing
module-info being in the jar root.

Regarding jpms classifier, I don't think that will help transitive
dependency, so A project depending upon collections which depends upon
codec. So will collections depend upon codec or codec-jpms. From what
I've got working I can add module-info without breaking pre java 11
users.

Peter, I'm trying to do as smaller change as possible to add
module-info, and also only using core maven plugins

Commons Developers, I'll start raising jira tickets per project, per step.

John



John

On Sun, 1 Mar 2020 at 11:44, Peter Verhas  wrote:
>
> I used Jabel, and Maven profiles to generate jvm8 and also jvm11 jars in
> the Java::Geci project.
>
> I also wrote a document about what, why, and how I did it:
>
>
> https://javax0.wordpress.com/2019/11/06/supporting-java-8/
>
> It may help.
>
> Peter
>
>
> On Sun, 1 Mar 2020 at 12:38, Romain Manni-Bucau 
> wrote:
>
> > Hi John,
> >
> > Didnt check on java 11 ga but in early versions module-info was required to
> > be at the root of the jar even if overriden for some version (
> > http://openjdk.java.net/jeps/238) so it ends up in the fact that some java
> > 8 apps will be broken by this addition and that only doing it in a mjar
> > will lead to the same kind of issues + will be likely ignored for other
> > apps.
> >
> > What about doing classified jar "jpms" at the same time than current
> > default jar to propose jpms integration early (worse case)?
> >
> > Alternative to just have an explicit module name in the manifest but no
> > module-info also sounds safer to me and still enables to use jpms.
> >
> > Hope it makes sense.
> >
> > Le dim. 1 mars 2020 à 12:08, John Patrick  a
> > écrit :
> >
> > > I'm wanting to correctly use Collections and Lang as Java Modules.
> > >
> > > Looking at the dependencies, I'll need to tackle all four projects.
> > >
> > > I'm planning on doing the following as if I'm touching the projects I
> > > might as well help out;
> > > 1) spring clean .gitignore, each project has different list, some
> > > documented others not
> > > 2) update to hamcrest v2.2
> > > 3) update to junit v5.6 (jupiter and vintage)
> > > 4) tackle low hanging fruit tests that can quickly be moved to jupiter
> > > 5) update maven-dependencies to latest for compiler, jar, install
> > > 6) discuss how toolchain should be setup for build tools have access
> > > to jdk 1.8 and jdk 11, ideally the same pattern/approach for all
> > > commons projects
> > > 7) add src/main/java11/module-info.java
> > > 8) add toolchain plugin and update compiler plugin to make Multi Release
> > > jar
> > >
> > > my questions are;
> > > a) how many jira tickets? one pre project? one per task/pr?
> > > b) prepare into new release i.e. commons-collection5
> > > c) should i do all my pom changes to a parent pom?
> > > d) toolchains developers, how should I document the requirement for
> > > developers want to build locally, give example which they need to
> > > complete
> > > e) toolchains cicd, how should i set that up? i'm use to jenkins and
> > > circle ci, not travis or gitflow?
> > >
> > > I'm doing this for other open source projects and work projects, but
> > > can't finish the open source or work projects until the open source
> > > dependency projects get fixed. Updating these 4 commons project will
> > > unblock about 10 downstream pr's i'm working on.
> > >
> > > I don't want to break backwards compatibility so don't want to just
> > > update to jdk 11, that is why I'm suggesting to use multi release
> > > jars, so module-info.java is in META-INF/versions/11/module-info.jar.
> > > I don't want to add new features, I just want the module-info so if
> > > you are using a newer jdk you can use modules.
> > >
> > > John
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
> --
> Peter Verhas
> pe...@verhas.com
> t: +41791542095
> skype: verhas

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

Java Modules Codec, Collections, IO and Lang

[John Patrick]

I'm wanting to correctly use Collections and Lang as Java Modules.

Looking at the dependencies, I'll need to tackle all four projects.

I'm planning on doing the following as if I'm touching the projects I
might as well help out;
1) spring clean .gitignore, each project has different list, some
documented others not
2) update to hamcrest v2.2
3) update to junit v5.6 (jupiter and vintage)
4) tackle low hanging fruit tests that can quickly be moved to jupiter
5) update maven-dependencies to latest for compiler, jar, install
6) discuss how toolchain should be setup for build tools have access
to jdk 1.8 and jdk 11, ideally the same pattern/approach for all
commons projects
7) add src/main/java11/module-info.java
8) add toolchain plugin and update compiler plugin to make Multi Release jar

my questions are;
a) how many jira tickets? one pre project? one per task/pr?
b) prepare into new release i.e. commons-collection5
c) should i do all my pom changes to a parent pom?
d) toolchains developers, how should I document the requirement for
developers want to build locally, give example which they need to
complete
e) toolchains cicd, how should i set that up? i'm use to jenkins and
circle ci, not travis or gitflow?

I'm doing this for other open source projects and work projects, but
can't finish the open source or work projects until the open source
dependency projects get fixed. Updating these 4 commons project will
unblock about 10 downstream pr's i'm working on.

I don't want to break backwards compatibility so don't want to just
update to jdk 11, that is why I'm suggesting to use multi release
jars, so module-info.java is in META-INF/versions/11/module-info.jar.
I don't want to add new features, I just want the module-info so if
you are using a newer jdk you can use modules.

John

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

Re: [exec] Update from Java 5 to 6

[John Patrick]

what about people wanting to use it on java 12 or java 13.

if java 1.5 and not wanting to upgrade is the argument, why would they be 
upgrading the software...

if a company is choosing to use and run an out of support jvm’s then it is a 
risk they are choosing to accept, either implicity or explicitly.

maven and modules are two different things, in a few releases time the 
classpath disappears and so any framework/jar that has not upgraded won’t 
execute on the modern and current jvm.

Sent from my iPhone

> On 10 Oct 2019, at 08:40, Luis Panadero Guardeño  
> wrote:
> 
> The problem sometimes not are the developers and their desire of upgrading. 
> The problem are the clients that don't desire to upgrade the JVM that have 
> installed in their servers.
> I had a case where a client was running a Sun Java 5 JVM with a bug on String 
> class that sometimes calculated bad string lengths and was making to our 
> product to fail. The solution was to updated to a more modern JVM, but they 
> don't like to do it.
> 
> 
> 
> De: Xeno Amess 
> Enviado: jueves, 10 de octubre de 2019 8:16
> Para: Commons Developers List 
> Asunto: Re: [exec] Update from Java 5 to 6
> 
> +1 for java 8
> I just assume developers who still using java 6 do not care about
> upgrading their commons too...
> But what is the meaning of jigsawI mean, everybody use maven and
> maven is good, right?
> 
> sebb  于2019年10月10日周四 上午6:55写道：
>> 
>>> On Wed, 9 Oct 2019 at 22:38, John Patrick  wrote:
>>> 
>>> Regarding the question, it was by Simon Ritter (Azul Systems
>>> previously Oracle previously Sun). "Put your hand up if your running
>>> applications in production using Java X", started with Java 8, then
>>> asked about 11, then 12 and 13, then asked 7 and then 6. Not sure if
>>> he said Java 5 but I don't think he did.
>> 
>> OK, thanks.
>> 
>>> It's great java is backwards compatible, but Java 5 was EOL 2009, Java
>>> 6 was EOL 2013, Java 7 was EOL 2015, java 8 EOL 2019 personal usage
>>> 2020 and AdoptOpenJDK 2023).
>>> 
>>> People jokes and complained about Java was dead or slow and releases
>>> took 2-5 years... JPMS has now been released for 2 years and how many
>>> frameworks/applications have actually release a version where you can
>>> take advantage of modules and create real lightweight images.
>> 
>> Most of Commons components are quite small, so is this really a concern?
>> 
>>> I've been using Java since 1.1, I was annoyed major releases took
>>> ages, but I'm more annoyed about the whole java ecosystem not stepping
>>> up as they have got use to the previously slow release cycles. I
>>> realise OpenSource project is done in peoples spare time and they are
>>> choosing to participate, but I've tried with multiple projects to
>>> raise pull requests to help taking the next steps.
>>> 
>>> My personal view is all commons projects should aim from Jan 2020 to
>>> bump to creating multi release jars of Java 8 and Java 11, so people
>>> using Java 8 are still supported and people using Java 11+ can uses
>>> modules.
>> 
>> And anyone using Java 7 or earlier is excluded.
>> 
>> Unless I am mistaken, if we don't create these multi-release jars,
>> people will still be able to use existing releases.
>> 
>>> 
>>> On Wed, 9 Oct 2019 at 18:21, Alex Herbert  wrote:
>>>> 
>>>> On 09/10/2019 14:12, Gary Gregory wrote:
>>>>> Hi All,
>>>>> 
>>>>> I'd like to update Commons Exec from Java 5 to 6 to get it to build on 
>>>>> Java
>>>>> 11.
>>>>> 
>>>>> Gary
>>>> 
>>>> Gary changed git master to update to 1.6 but travis was not able to
>>>> build for older JDKs.
>>>> 
>>>> I have tried following the recommended instructions for their trusty
>>>> distribution to use JDK 6 [1]. This did not work [2]. It would appear
>>>> that travis cannot support openjdk6 any more.
>>>> 
>>>> Using 'dist: trusty' allows a clean build on JDK 7, 8, 11.
>>>> 
>>>> I recommend dropping openjdk6 from the build matrix.
>>>> 
>>>> Other items from the .travis.yml are the broken configuration for the
>>>> coveralls report. This can be fixed separately as the pom needs some
>>>> updating.
>>>> 
>>>> Alex
>>>> 
>>>> [1]
>>>> https://docs.t

Re: [exec] Update from Java 5 to 6

[John Patrick]

Regarding the question, it was by Simon Ritter (Azul Systems
previously Oracle previously Sun). "Put your hand up if your running
applications in production using Java X", started with Java 8, then
asked about 11, then 12 and 13, then asked 7 and then 6. Not sure if
he said Java 5 but I don't think he did.

It's great java is backwards compatible, but Java 5 was EOL 2009, Java
6 was EOL 2013, Java 7 was EOL 2015, java 8 EOL 2019 personal usage
2020 and AdoptOpenJDK 2023).

People jokes and complained about Java was dead or slow and releases
took 2-5 years... JPMS has now been released for 2 years and how many
frameworks/applications have actually release a version where you can
take advantage of modules and create real lightweight images.

I've been using Java since 1.1, I was annoyed major releases took
ages, but I'm more annoyed about the whole java ecosystem not stepping
up as they have got use to the previously slow release cycles. I
realise OpenSource project is done in peoples spare time and they are
choosing to participate, but I've tried with multiple projects to
raise pull requests to help taking the next steps.

My personal view is all commons projects should aim from Jan 2020 to
bump to creating multi release jars of Java 8 and Java 11, so people
using Java 8 are still supported and people using Java 11+ can uses
modules.


On Wed, 9 Oct 2019 at 18:21, Alex Herbert  wrote:
>
> On 09/10/2019 14:12, Gary Gregory wrote:
> > Hi All,
> >
> > I'd like to update Commons Exec from Java 5 to 6 to get it to build on Java
> > 11.
> >
> > Gary
>
> Gary changed git master to update to 1.6 but travis was not able to
> build for older JDKs.
>
> I have tried following the recommended instructions for their trusty
> distribution to use JDK 6 [1]. This did not work [2]. It would appear
> that travis cannot support openjdk6 any more.
>
> Using 'dist: trusty' allows a clean build on JDK 7, 8, 11.
>
> I recommend dropping openjdk6 from the build matrix.
>
> Other items from the .travis.yml are the broken configuration for the
> coveralls report. This can be fixed separately as the pom needs some
> updating.
>
> Alex
>
> [1]
> https://docs.travis-ci.com/user/reference/trusty/#jvm-clojure-groovy-java-scala-images
>
> [2] https://travis-ci.org/apache/commons-exec/builds/595713743
>
>
> -
> 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: [exec] Update from Java 5 to 6

[John Patrick]

What about Java 5 to 8.
I'm current sat at Jax London and was the sole person who put their
hand up for Java 6, and next Conference I hope to have migrated
everything to at least Java 8. From the rest I saw 1 hand being raised
for Java 7, about 2/3rd's said Java 8 and 1/3rd said Java 11, with a
handful saying Java 12 or 13.

On Wed, 9 Oct 2019 at 14:12, Gary Gregory  wrote:
>
> Hi All,
>
> I'd like to update Commons Exec from Java 5 to 6 to get it to build on Java
> 11.
>
> Gary

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

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

[John Patrick]

On Tue, 9 Apr 2019 at 08:54, sebb  wrote:
>
> On Tue, 9 Apr 2019 at 07:59, Jochen Wiedmann  
> wrote:
> >
> > Hi,
> >
> > I have studied EMAIL-186. My impression is, that all commons jar files
> > should provide a fixed module name, rather than trusting in the choice
> > of the JDK. Thus, it seems best to handle this in parent. So, here's
> > my proposal for a change. Please, let me know, what you think of that,
> > so that I can either fix it, op proceed with committing.
>
> What exactly does 'fixed' mean in this context?
>
> If it is supposed to be tied to API compatibility, then strictly
> speaking it needs the group-id as well.
>
> If there is only supposed to be one module name regardless of API
> compatibility, then artifact-id won't do as it is not immutable.
>
> > Thanks,
> >
> > Jochen
> >
> >
> > $ git diff pom.xml
> > diff --git a/pom.xml b/pom.xml
> > index 2612dd6..54a88e4 100644
> > --- a/pom.xml
> > +++ b/pom.xml
> > @@ -570,6 +570,7 @@
> >
> > ${implementation.build}
> >
> > ${maven.compiler.source}
> >
> > ${maven.compiler.target}
> > +  
> > ${commons.module.name}
> >  
> >
> >  
> > @@ -1608,6 +1609,9 @@
> >  1.3
> >  1.3
> >
> > +
> > +${project.artifactId}
> > +
> >  
> >  false
> >  
> >
> > -
> > 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
>

Really like this change, but as a consumer of the jars generated by
this parent patch, could the default not be the artifactId, as it will
just mean 2 migrations.

As commons-lang3 has the module name org.apache.commons.lang3, not
commons-lang3 which is the artifactId, because "-" is invalid in a
real module name and they realised this when starting to support jpms.

So could the default be something like OVERRIDE_PER_RELEASED_JAR, so
it's very very clear.

John

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

Re: [IO] Update to Java 8 [WAS Re: regarding IO-597]

[John Patrick]

Personally as a consumer/user I wouldn't expect a minor update to bump
the min java version required, I would expect a major version number
bump.

Also I think all commons projects should be bumped to Java 8 asap, as
those on java 5, 6 or 7 are probably happy with the current versions
and would only be upgrading for bug fixes and security reasons.

Java 8 was released nearly 5 years ago, Java 7 was released 8 years
ago, people complained about Java being slow, now Java has become
rapid it seams the frameworks need to speed up.

Just my view after coding Java for 20 years.

John



On Sat, 12 Jan 2019 at 13:43, Gary Gregory  wrote:
>
> I am OK with updating Commons IO to Java 8 for release 2.7.
>
> Others?
>
> Gary
>
> On Sat, Jan 12, 2019 at 6:54 AM Arvind Venugopal 
> wrote:
>
> > Hello,
> >
> > This is regarding the JIRA issue IO-597. I am not sure if this has to be
> > taken up because the fix for this bug would need Java 8 which would be
> > breaking all existing code(using Java 7 or earlier) which uses this
> > library.
> >
> > Thanks
> > Arvind
> >

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

Re: Java 8 curiousity

[John Patrick]

i've experience the same, a build about ~75 and another around ~95
introduced from the limited versions I've tested introduced some
dramatic performance and memory improvements

i think one was around streams and the other around lambdas

but that is also about u40 was April 14, 2015, and u121 was April 18,
2017, so you have 2 years of people using java 8 with real life
applications and feeding back those changes

John


On 10 October 2017 at 00:03, Ole Ersoy  wrote:
> Are you using streams?  A while back I experimented with matrix
> multiplication using streams and they can be very slow:
>
> https://stackoverflow.com/questions/35037893/java-8-stream-matrix-multiplication-10x-slower-than-for-loop
>
> So I would think that Java has a lot of performance tuning and optimization
> it could do in this space.
>
> Cheers,
>
> Ole
>
>
>
> On 10/09/2017 04:20 PM, Rob Tompkins wrote:
>>
>> Hey all,
>>
>> At my day job we saw a 60% performance improvement (cpu utilization)
>> between 1.8.0_40 and 1.8.0_121, and I was wondering if anyone else out there
>> has seen anything like that before or if anyone might know what could cause
>> that given that the release notes  don’t directly point to anything.
>>
>> Cheers,
>> -Rob
>> -
>> 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
>

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

Re: Commons CLI Nested Groups

[John Patrick]

Imaging your stand alone jar runs an embedded http server, by default
it has a embedded testing certificate for the https listener. But in
some environments you need to disable https and others you want to
overwrite with values.

So you have options, something like;
[ A or [ B and C and [ D or E ] ] ]

[ -no-https | [ -https-port  -keyStoreLocation
 [ -keyStorePassword  |
-keyStorePassword-prompt ] ] ]

-no-https
> will explicitly disable https

-https-port 
> will explicitly enabled https and has and optional port parameter
> if you specify -https-port you also need to explicitly specify the keystore 
> location and either the password on the command line or state it will prompt 
> via the console

-keyStoreLocation 
> required if -https-port is specified and also has a required parameter

-keyStorePassword 
-keyStorePassword-prompt
> only one of the above must be supplied, not both
> if "-keyStorePassword" supplied then it has a required password property
> if "keyStorePassword-prompt" supplied then it will request via the console 
> when booting

I hope that is a clear example. This is something that I'm trying to
implement at the moment but having to do several if/else if/else
blocks to get it working as needed.

Cheers,
John



On 14 October 2016 at 00:26, Gilles <gil...@harfang.homelinux.org> wrote:
> Hi.
>
> On Thu, 13 Oct 2016 15:57:00 +0100, John Patrick wrote:
>>
>> I've posted a message to the users list, but on reflecting I think
>> what I'm trying to achieve might be beyond commons-cli current
>> ability.
>>
>> If I fork and work on adding nested OptionGroup's, would it stand a
>> change of being merged?
>> Is it a feature you want to support/provide?
>
>
> Please describe what you propose in more details.
>
>>
>> I want to check with dev's before wasting time on the potential feature...
>
>
> Good precaution, indeed...
>
> Regards,
> Gilles
>
>>
>> cheers,
>> John
>>
>
>
> -
> 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

Commons CLI Nested Groups

[John Patrick]

I've posted a message to the users list, but on reflecting I think
what I'm trying to achieve might be beyond commons-cli current
ability.

If I fork and work on adding nested OptionGroup's, would it stand a
change of being merged?
Is it a feature you want to support/provide?

I want to check with dev's before wasting time on the potential feature...

cheers,
John

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