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
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
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
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
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
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
> &g
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
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
, 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
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
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 val
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
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
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
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.
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;
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
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
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
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..
ected)
> >
> > 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 a
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
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
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
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
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
S 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
> > thou
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
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, 202
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
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
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
/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,
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
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
s 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 play
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 s
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
t;
> 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
>>&
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
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
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
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
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
ent 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 messa
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
46 matches
Mail list logo
