Re: [LANG] Jenkins Pipeline DSL

> >> ones (or both). The log4net Jenkinsfile has an example of building > >> across multiple agents: > >> > >> > >> https://github.com/apache/logging-log4net/blob/feature/cd-pipeline/Jenkinsfile > >> > >> On Mon, 18 Feb 2019 at 12:44

Re: [ALL][RFC] Github subjects don't contain the repo name

This has now been implemented. Unfortunately Infra did not agree to remove the [GitHub] prefix. On Sat, 2 Mar 2019 at 09:19, sebb wrote: > > Created https://issues.apache.org/jira/browse/INFRA-17940 > > On Sat, 2 Mar 2019 at 08:39, Stefan Bodewig wrote: > > > > O

Re: [LANG] Jenkins Pipeline DSL

On Mon, 4 Mar 2019 at 09:47, Benedikt Ritter wrote: > > Am So., 3. März 2019 um 14:57 Uhr schrieb sebb : > > > On Sun, 3 Mar 2019 at 13:28, Benedikt Ritter wrote: > > > > > > Hi all, > > > > > > here is my proposal for a Jenkins Pipeline fil

Re: [ALL] Avoiding duplication of work between GitHub PRs and JIRA

On Wed, 6 Mar 2019 at 13:54, Gary Gregory wrote: > > Hi All: > > I'll start with this example from Commons VFS and its changes.xml: > > > Update Apache Commons Collections from 4.2 to 4.3. > > > > Add support for customizing FTP transfer aborted status codes. >

Re: [Parent] RAT check

OK, but please provide a property to switch it off on the command-line. I think it is going to be very annoying for local development, especially if it runs at such an early phase. It could also be done in a much later phase, e.g. verify That would certainly be sufficient for RC creation. On Sun

MD5/SHA1 links - make sure they are removed in component source!

DIGESTER-191 - md5 checksum: 404 Not Found noted that the hash download links did not work. It transpired that many of the commons download pages still linked to the SHA1/MD5 hashes, even if these had been replaced on the download site. I think I have now fixed all the links - and dropped old md5

Re: MD5/SHA1 links - make sure they are removed in component source!

> Bernd > -- > http://bernd.eckenfels.net > > > Von: sebb > Gesendet: Dienstag, März 12, 2019 9:56 AM > An: CommonsDev > Betreff: MD5/SHA1 links - make sure they are removed in component source! > > DIGESTER-191 - md5 checksum: 404 Not Found > noted that the hash dow

Re: MD5/SHA1 links - make sure they are removed in component source!

e links anywhere else is I > guess moot. > > BTW the (Imaging] Download (still) points to incubator, are we planning to > change this? Please start a new thread for a new issue, thanks! > Gruss > Bernd > -- > http://bernd.eckenfels.net >

Re: [RDF] Graduated from the Incubator but Releases remain in Incubator Dist SVN

On Thu, 14 Mar 2019 at 18:02, Dave Fisher wrote: > > Hi - > > You still have Commons RDF releases in the Incubator’s area of SVN - > https://dist.apache.org/repos/dist/release/incubator/ > > > Please plan to move or remove these soon. Remo

Re: [codec] Java 8

I see no reason to update to Java 8 unless continuing with Java 7 becomes a big hassle. Why penalise people stuck on Java 7 unnecessarily? On Fri, 22 Mar 2019 at 15:31, Rob Tompkins wrote: > > That seems reasonable. > > > On Mar 22, 2019, at 11:23 AM, Gary Gregory wrote: > > > > This comes up f

Re: [codec] Java 8

On Fri, 22 Mar 2019 at 18:56, Gary Gregory wrote: > > On Fri, Mar 22, 2019 at 2:53 PM sebb wrote: > > > I see no reason to update to Java 8 unless continuing with Java 7 > > becomes a big hassle. > > > > Why penalise people stuck on Java 7 unnecessarily? >

Re: [all] What versions of java do we support?

On Fri, 22 Mar 2019 at 21:27, Matt Sicker wrote: > > Ensuring projects are source compatible with 1.8 but buildable and > usable using Java 11 or whatever the latest release is at the time > (currently 12) seems like a good compromise for most of the libraries. > I wouldn't require 9+ in anything

Confluence space (was: GitHub Pull Requests (and Confluence))

On Mon, 25 Mar 2019 at 15:32, Jochen Wiedmann wrote: > > Which reminds me: Do we have a Confluence space? If not: Would anyone > mind, if I asked for one on Jira? Remember that Moin Moin is being withdrawn. There is quite a large Commons Wiki on it; maybe that should be migrated rather than start

Re: [codec] Java 8

> > > Am 22. März 2019 19:56:29 MEZ schrieb Gary Gregory : > > >On Fri, Mar 22, 2019 at 2:53 PM sebb wrote: > > > > > >> I see no reason to update to Java 8 unless continuing with Java 7 > > >> becomes a big hassle. > > >> > > &g

Re: [CLI] Option arguments without - or --

On Fri, 29 Mar 2019 at 07:04, Amey Jadiye wrote: > > Hi, > > Looks like the functionality is not present in the code base. > > I'm proposing the SimpleCommandParser which can implement CommandLineParser > for achieving below requirements. let me know your thoughts on this. Thanks for the suggesti

Re: [all] Should we use MathJaX in Javadoc on all repos? (Was: Re: [jira] [Commented] (NUMBERS-58) Javadoc: Use MathJaX)

On Tue, 12 Mar 2019 at 12:28, Rob Tompkins wrote: > > For those unfamiliar with MathJaX, is the javascript mechanism for > accommodating for LaTeX (the math typesetting language, written by Donald > Knuth) in html. > > It could be convenient to use mathematical notation in our javadoc generally.

Re: [VOTE] Release Apache Commons Pool 2.6.2 based on RC1

On Sat, 6 Apr 2019 at 03:15, Gary Gregory wrote: > > We have fixed a few bugs since Apache Commons Pool 2.6.1 was released, so I > would like to release Apache Commons Pool 2.6.2. > > Apache Commons Pool 2.6.2 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/p

Re: [release-plugin] sha’s (Was: Re: [VOTE] Release Apache Commons Pool 2.6.2 based on RC1)

On Sat, 6 Apr 2019 at 17:59, Gary Gregory wrote: > > On Sat, Apr 6, 2019 at 12:48 PM Rob Tompkins wrote: >> >> >> >> > On Apr 6, 2019, at 12:24 PM, Gary Gregory wrote: >> > >> > Hi Sebb, >> > >> > Thank you for your review

Re: [lang] LANG-1442

On Sat, 6 Apr 2019 at 17:18, Gilles Sadowski wrote: > > Le sam. 6 avr. 2019 à 16:59, Rob Tompkins a écrit : > > > > @Gilles - thoughts on this wording: > > https://github.com/apache/commons-lang/commit/3f43706192b1b75c5023f165534a12b192c31442 > > > >

Re: [release-plugin] sha’s (Was: Re: [VOTE] Release Apache Commons Pool 2.6.2 based on RC1)

On Sun, 7 Apr 2019 at 11:25, Rob Tompkins wrote: > > > > > On Apr 7, 2019, at 5:52 AM, sebb wrote: > > > >> On Sat, 6 Apr 2019 at 17:59, Gary Gregory wrote: > >> > >>> On Sat, Apr 6, 2019 at 12:48 PM Rob Tompkins wrote: > >>> >

Re: [commons-lang] branch master updated: (docs) update user use -> user explore

On Mon, 8 Apr 2019 at 13:16, Rob Tompkins wrote: > > I think that maybe hits what you guys were getting after with my wording. > > And you know me, english as a first language, still writing poorly :-p > > Do we think lang 3.9 is ready? I still think the sentence starting "Consider instead using

Re: [commons-lang] branch master updated: (docs) update user use -> user explore

On Mon, 8 Apr 2019 at 14:25, Gilles Sadowski wrote: > > Hi Rob. > > Le lun. 8 avr. 2019 à 14:16, Rob Tompkins a écrit : > > > > I think that maybe hits what you guys were getting after with my wording. > > You probably missed a thread. > I've just committed the alternative text. Looks good to me

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

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

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

On Tue, 9 Apr 2019 at 11:43, Gilles Sadowski wrote: > > > [...] > > > > > > $ 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} > > >

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

On Tue, 9 Apr 2019 at 13:32, Jochen Wiedmann wrote: > > On Tue, Apr 9, 2019 at 10:48 AM John Patrick wrote: > > > > 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

Re: [lang] 3.9, switch from cobertura to jacoco?

On Tue, 9 Apr 2019 at 13:39, Rob Tompkins wrote: > > Thoughts on doing this switch? I’m heavily leaning towards it because I can’t > get code coverage to work on java 11 with the current build. +0 It's trivial to switch back isn't it? > -Rob > --

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

On Tue, 9 Apr 2019 at 13:54, Jochen Wiedmann wrote: > > On Tue, Apr 9, 2019 at 2:43 PM sebb wrote: > > > Unless I am misunderstanding this, the property value won't be checked > > to see if i is changed when an incompatible versioni s released. > > True, but that

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

On Tue, 9 Apr 2019 at 16:53, Jochen Wiedmann wrote: > > On Tue, Apr 9, 2019 at 3:51 PM sebb wrote: > > > We already have a process for ensuring that Maven coords and package > > names are changed when API breaks. > > Do we really want to have yet another nam

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

On Tue, 9 Apr 2019 at 17:06, Rob Tompkins wrote: > > > > > On Apr 9, 2019, at 11:57 AM, sebb wrote: > > > > On Tue, 9 Apr 2019 at 16:53, Jochen Wiedmann > > wrote: > >> > >> On Tue, Apr 9, 2019 at 3:51 PM sebb wrote: > >> > &

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

On Tue, 9 Apr 2019 at 18:14, Rob Tompkins wrote: > > > > > On Apr 9, 2019, at 1:11 PM, sebb wrote: > > > > On Tue, 9 Apr 2019 at 17:06, Rob Tompkins > <mailto:chtom...@gmail.com>> wrote: > >> > >> > >> > >>> On

Re: Build failed in Jenkins: commons-lang #517

On Tue, 16 Apr 2019 at 14:43, Gary Gregory wrote: > > Is this a credentials issue in Jenkins or an issue with our release plugin? > > Why are we even invoking our release plugin here? The profile -Prelease may have something to do with that. > Gary > > -- Forwarded message - > Fr

Re: [compress] Java 7 to Java 8

On Tue, 16 Apr 2019 at 14:51, Stefan Bodewig wrote: > > On 2019-04-16, Gary Gregory wrote: > > > On Tue, Apr 16, 2019 at 9:39 AM Stefan Bodewig wrote: > > >> As long as using Java 7 doesn't hurt us, I don't see any reason to > >> update. > > > Using old dead versions of Java turns off potential c

Re: Build failed in Jenkins: Commons-Compress JDK-Matrix Build » JDK 1.7 (latest) #799

On Tue, 16 Apr 2019 at 16:15, Stefan Bodewig wrote: > > After Compress has been upgraded to Parent 48 the JDK 7 build started to > fail as the new version of the bnd plugin has been compiled with > -target 8, or so it seems. > > I'll downgrade the bnd plugin for compress for now. An alternative i

Re: [compress] Java 7 to Java 8

for another year or more, though, so not an immediate problem; just > something to consider for long term. Note that Java 7 has extended support until at least July 2022: https://www.oracle.com/technetwork/java/java-se-support-roadmap.html > On Tue, 16 Apr 2019 at 09:53, sebb wrote: > > >

[ALL] Confluence Wiki permissions - allow all Commons committers write access?

tter write access to the Wiki. Agreed? [Administrators can always grant write access to individual non-committers if that proves necessary.] Sebb. [1] https://lists.apache.org/thread.html/33d84ab4720f56827895b9cac6743943c0bfe1af2f838cdab2a026d4@%3Cusers.infra.apa

Re: [compress] Java 7 to Java 8

On Wed, 17 Apr 2019 at 16:15, Matt Sicker wrote: > > On Wed, 17 Apr 2019 at 10:05, sebb wrote: > > Note that Java 7 has extended support until at least July 2022: > > https://www.oracle.com/technetwork/java/java-se-support-roadmap.html > > Right, but does that mean that

Re: [VFS] Sftp oddity?

On Sat, 27 Apr 2019 at 18:09, Gary Gregory wrote: > > Hi All: > > Can anyone say why we build a SftpFileSystem here: > > https://github.com/apache/commons-vfs/blob/master/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/sftp/SftpFileProvider.java#L90 > > > instead of here: > > https://g

Re: [VFS] Deleting the git branch 'trunk'

On Wed, 1 May 2019 at 21:48, Gary Gregory wrote: > > On Wed, May 1, 2019 at 3:54 PM Gary Gregory wrote: > > > I created https://issues.apache.org/jira/browse/INFRA-18316 > > > > And the work is done. Note that open PRs on trunk have been closed > automatically, so they would need to be re-opened.

Re: [VFS] Deleting the git branch 'trunk'

On Wed, 1 May 2019 at 23:02, Gary Gregory wrote: > > On Wed, May 1, 2019 at 5:30 PM sebb wrote: > > > On Wed, 1 May 2019 at 21:48, Gary Gregory wrote: > > > > > > On Wed, May 1, 2019 at 3:54 PM Gary Gregory > > wrote: > > > > > > >

Re: [VFS] Deleting the git branch 'trunk'

Thursday, 2 May 2019, 10:23:50 am NZST, sebb wrote: > > On Wed, 1 May 2019 at 23:02, Gary Gregory wrote: > > > > On Wed, May 1, 2019 at 5:30 PM sebb wrote: > > > > > On Wed, 1 May 2019 at 21:48, Gary Gregory wrote: > > > > > > > &

Re: [bcel] broken repo?

Same issue applies to commons-net and -daemon. However commons-io and -lang are OK. Looks like the default branch has not been set up correctly for some of the repos (probably the ones that were migrated last). How does one set the default branch? On Mon, 6 May 2019 at 19:09, Rob Tompkins wrote

Re: [bcel] broken repo?

https://issues.apache.org/jira/browse/INFRA-18339 On Mon, 6 May 2019 at 19:24, Rob Tompkins wrote: > > > > > On May 6, 2019, at 2:14 PM, sebb wrote: > > > > Same issue applies to commons-net and -daemon. > > However commons-io and -lang are OK. > > > &g

Re: Commons Validator

On Sat, 11 May 2019 at 08:30, Andre van der Wal wrote: > > Hi, > > When can we expect a new release of the validator? When someone decides to release it... > New email domains we > need were added in April 2017 but the latest release is still from Feb 2017. The list changes too frequently to be

Re: Immutable Keys message

On Sat, 11 May 2019 at 13:19, Blaise Carie wrote: > > To Whom This May Concern: > I received the following message when applying for a job. I did not > receive this message when applying for it yesterday, and today I am unable > to access my application or other jobs. > Entry.next=null, data

Using email addresses in exception messages

Some of our code has Exception messages such as the following: >> (Collections:LRUMap) throw new IllegalStateException("Entry.before is null." + " Please check that your keys are immutable, and that you have used synchronization properly." + " If so, then please report this to dev@commons.apache.o

Re: Using email addresses in exception messages

On Mon, 13 May 2019 at 18:42, Bill Igoe wrote: > > In a prop shop long ago , I also emailed all exception messages. It is a > great way to correct logic errors and capture potentially sloppy code. > Graphing the errors resulted in an exponential decline in errors. > > I also developed a handy per

Re: [Text] Case conversion

On Sat, 18 May 2019 at 13:37, Gary Gregory wrote: > > Hi All: > > What do you all think about this addition for Commons Text (I currently do > use it): I think it's unnecessary and should not be added. > import java.util.Locale; > > /** > * Enumerates letter cases and converts strings. > * >

Re: [IO] Update to Java 8

On Sat, 18 May 2019 at 12:51, Gary Gregory wrote: > > On Thu, May 16, 2019 at 3:40 PM Chesney, Mark > wrote: > > > I think it's a good idea. A recent update of the parent POM version seems > > to have broken the Travis build for Java 7. Discontinuing Java 7 support > > would make that a non-issue

Re: [Configuration] Optional Includes in Properties files

On Mon, 20 May 2019 at 14:58, Gary Gregory wrote: > > On Mon, May 20, 2019 at 9:16 AM Gilles Sadowski > wrote: > > > Le lun. 20 mai 2019 à 14:51, Gary Gregory a > > écrit : > > > > > > Hi All: > > > > > > Right now, if you uses an 'include' in a properties file and that file is > > > missing, th

Re: [rng] binary compatibility with final modifier

Are the classes supposed to be final? Or just the existing constructor(s)? On Thu, 23 May 2019 at 12:51, Gilles Sadowski wrote: > > Hello. > > Le jeu. 23 mai 2019 à 13:43, Alex Herbert a écrit : > > > > [rng] has three classes with a private constructor that are not > > currently marked as final

Re: svn commit: r1859859 [1/5] - in /commons/proper/jcs/trunk/commons-jcs-core/src: main/java/org/apache/commons/jcs/ main/java/org/apache/commons/jcs/access/ main/java/org/apache/commons/jcs/admin/ m

On Fri, 24 May 2019 at 11:34, Gary Gregory wrote: > > -1 > > We are now on gitbox https://gitbox.apache.org/repos/asf/commons-jcs.git > > We have to make the old repos read only. We did make commons/proper read-only for most people. However members of the Commons PMC are still allowed to update t

Lost SVN updates following conversion to Git

Some updates have been made to the Commons 'proper' SVN repos since they were converted to Git. Such changes should not have been made, as they are not automatically reflected in the Git repos. I think we need to do the following: - revert the spurious changes so SVN reflects the state at conver

Re: Lost SVN updates following conversion to Git

On Fri, 24 May 2019 at 22:37, Emmanuel Bourg wrote: > > Le 24/05/2019 à 22:59, sebb a écrit : > > > The simplest way to stop further updates is probably to rename the SVN > > directory from /proper to /_moved_to_git. This will still allow > > updates by PMC members,

Re: Lost SVN updates following conversion to Git

On Sat, 25 May 2019 at 00:13, Gary Gregory wrote: > > I like the pointer idea. This is an example of what we did for the original moves: http://svn.apache.org/repos/asf/commons/proper/io/IoNowUsesGit.txt > Gary > > On Fri, May 24, 2019, 18:35 sebb wrote: > > > On F

scm.html or source-repository.html?

Why do some components use: http://commons.apache.org/proper/commons-lang/scm.html and some use http://commons.apache.org/proper/commons-math/source-repository.html They have the same content, so why the different URLs? Should we standardise on one (and add redirects for the other?) Are there a

Re: scm.html or source-repository.html?

nuisance. We cannot remain on the original version of the plugin forever so we are forced to break the existing URLs. Question is: what do we do about it, if anything? > > On Sat, 25 May 2019 at 17:24, sebb wrote: > > > Why do some components use: > > > > http://commons.

Re: Changes to SVN proper that have occurred since move to Git

Forgot to say that I have yet to check the commons-* trees (commons-build etc) On Sun, 26 May 2019 at 13:13, sebb wrote: > > I've done a comparison of the latest SVN revision with the most recent > trunk(master) Git entry that includes a line of the following form: > git-svn-i

Changes to SVN proper that have occurred since move to Git

I've done a comparison of the latest SVN revision with the most recent trunk(master) Git entry that includes a line of the following form: git-svn-id: https://svn-us.apache.org/repos/asf/commons/proper/jexl/trunk@1821853 13f79535-47bb-0310-9956-ffa450edef68 AFAICT any discrepancies mean that the

Re: svn commit: r1859859 [1/5] - in /commons/proper/jcs/trunk/commons-jcs-core/src: main/java/org/apache/commons/jcs/ main/java/org/apache/commons/jcs/access/ main/java/org/apache/commons/jcs/admin/ m

On Sun, 26 May 2019 at 12:27, Thomas Vandahl wrote: > > On 24.05.19 12:33, Gary Gregory wrote: > > -1 > > > > We are now on gitbox https://gitbox.apache.org/repos/asf/commons-jcs.git > > > > When did that happen? I don't remember an announcement or a vote. Jan 2019 https://lists.apache.org/threa

Re: Changes to SVN proper that have occurred since move to Git

I think all but jcs have now been dealt with. On Sun, 26 May 2019 at 13:28, sebb wrote: > > Forgot to say that I have yet to check the commons-* trees (commons-build etc) > > On Sun, 26 May 2019 at 13:13, sebb wrote: > > > > I've done a comparison of the latest SVN

Re: svn commit: r1859859 [1/5] - in /commons/proper/jcs/trunk/commons-jcs-core/src: main/java/org/apache/commons/jcs/ main/java/org/apache/commons/jcs/access/ main/java/org/apache/commons/jcs/admin/ m

On Sun, 26 May 2019 at 17:42, Thomas Vandahl wrote: > > On 26.05.19 15:54, sebb wrote: > > Jan 2019 > > > > https://lists.apache.org/thread.html/053bb8f18e90800d918956f69364167b23c0cdca175568300b1108f6@%3Cdev.commons.apache.org%3E > > Ok, I missed that one comp

Re: Proposal to introduce JUnit 5 in commons-numbers

On Tue, 28 May 2019 at 21:44, Karl Heinz Marbaise wrote: > > Hi, > > just a small comment of mine. > > to get very good support for exceptions etc. I would suggest to use > assertj which will work in JUnit 4 and Jupiter (aka 5)... What License does it use? > Furthermore I would not rely on a uni

Re: svn commit: r1859859 [1/5] - in /commons/proper/jcs/trunk/commons-jcs-core/src: main/java/org/apache/commons/jcs/ main/java/org/apache/commons/jcs/access/ main/java/org/apache/commons/jcs/admin/ m

Thanks, I've reverted SVN back to r1852304 which corresponds to git ad897014842fc830483f32fdfb903f3bb8f70289, i.e. immediately after conversion to Git. Also moved SVN to _moved_to_git On Wed, 29 May 2019 at 07:02, Thomas Vandahl wrote: > > On 27.05.19 10:21, sebb wrote: > > Eit

[ALL] Issues with Git repos: bad HEADs and unexpected refs - need Git guru

I noticed that JCS still has a trunk branch and that appears to be the default, so I did a check of all the commons git repos. The command used is: git ls-remote #{repo} HEAD master trunk where repo = https://gitbox.apache.org/repos/asf/{commons-???}.git I then compared the hashes for HEAD and r

Re: Changes to SVN proper that have occurred since move to Git

FTR jcs has also now been sorted On Sun, 26 May 2019 at 15:27, sebb wrote: > > I think all but jcs have now been dealt with. > > On Sun, 26 May 2019 at 13:28, sebb wrote: > > > > Forgot to say that I have yet to check the commons-* trees (commons-build > > etc)

Re: [All] Alpha/beta releases

I'm not sure what problem this is trying to solve. How is it intended to use the facility? On Tue, 4 Jun 2019 at 17:35, Matt Sicker wrote: > > This sounds like a shade feature, yes. However, in order to > automatically extract the version extra data and detect a version > keyword like "alpha" ma

Re: [All] Alpha/beta releases

On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski wrote: > > Le mer. 5 juin 2019 à 15:18, sebb a écrit : > > > > I'm not sure what problem this is trying to solve. > > > > How is it intended to use the facility? > > Ideally: > $ mvn -Pbetarelease [...

Re: [All] Alpha/beta releases

On Wed, 5 Jun 2019 at 15:06, Gilles Sadowski wrote: > > Le mer. 5 juin 2019 à 15:59, sebb a écrit : > > > > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski wrote: > > > > > > Le mer. 5 juin 2019 à 15:18, sebb a écrit : > > > > > >

Re: [All] Alpha/beta releases

On Wed, 5 Jun 2019 at 17:16, Gilles Sadowski wrote: > > Le mer. 5 juin 2019 à 17:57, James Carman a > écrit : > > > > I’m having a hard time understanding the comparing APIs use case. If I > > were to want to try that, I’d create a branch and import the new dependency > > version and see what b

Re: [All] Alpha/beta releases

gt; opt in such naming. +1 I think it would be worth documenting step by step how the proposal works overall, to make sure that nothing has been overlooked. One can then look at whether any additional tooling is needed, or if it already exists. > Gary > > > On Wed, Jun 5, 2019 at 6:25

Re: [All] Alpha/beta releases

On Sun, 9 Jun 2019 at 12:01, James Carman wrote: > > On Sun, Jun 9, 2019 at 5:40 AM Gilles Sadowski wrote: > > > > > Ultimately the PMC still needs to vote on the release, no? > > Hence I don't see what advantage there is in allowing different > > beta policies. [Of course, no component is requi

Re: [All] Alpha/beta releases

On Sun, 9 Jun 2019 at 14:20, Gilles Sadowski wrote: > > Hi. > > Le dim. 9 juin 2019 à 14:06, James Carman a > écrit : > > > > On Sun, Jun 9, 2019 at 7:36 AM sebb wrote: > > > > > > > > Huh? > > > That can still cause jar issues

Re: [ALL] Issues with Git repos: bad HEADs and unexpected refs - need Git guru

Ping - any comment on the unexpected HEAD references? Should they be changed? On Mon, 3 Jun 2019 at 15:15, Gary Gregory wrote: > > Did we git guru ourselves out of all of these? > > Gary > > On Wed, May 29, 2019 at 9:39 AM sebb wrote: > > > I noticed that JCS still

Re: [lang] ArrayUtils.addFirst(T[], T)?

On Wed, 12 Jun 2019 at 22:11, Mark Dacek wrote: > > I’d support adding both. +1 How about overloading as follows: ArrayUtils.add(T[], T, index) It seems inconsistent to have add() and addFirst(); that suggests there should be an addLast() > On Wed, Jun 12, 2019 at 5:09 PM James Carman > wrot

Re: [lang] ArrayUtils.addFirst(T[], T)?

On Thu, 13 Jun 2019 at 13:43, Gary Gregory wrote: > > On Thu, Jun 13, 2019 at 8:32 AM sebb wrote: > > > On Wed, 12 Jun 2019 at 22:11, Mark Dacek wrote: > > > > > > I’d support adding both. > > > > +1 > > > > How about overloading as fol

Re: [lang] ArrayUtils.addFirst(T[], T)?

t/addLast but I'm not convinced it is the best choice. The add() method should probably be deprecated whatever happens. > Gary > > On Thu, Jun 13, 2019 at 9:03 AM Mark Dacek wrote: > > > addFirst is commonly used with LinkedLists. I wouldn't think it to be > > uni

Re: [lang][rng] org.apache.commons.lang3.ArrayUtils.shuffle()

On Thu, 13 Jun 2019 at 16:35, Alex Herbert wrote: > > > On 13/06/2019 15:59, Gary Gregory wrote: > > Now that RNG is up and going, it seems odd to still have: > > > > org.apache.commons.lang3.ArrayUtils.shuffle(double[], Random) > > > > Should we deprecate these APIs in favor of Commons RNG and if

Re: [lang][rng] org.apache.commons.lang3.ArrayUtils.shuffle()

27;s really nice, > I had never even thought of that. Thanks. > > On Thu, Jun 13, 2019 at 10:11 AM Alex Herbert > wrote: > > > > > On 13/06/2019 17:56, Eric Barnhill wrote: > > > On Thu, Jun 13, 2019 at 9:36 AM sebb wrote: > > > > > >> > &g

Re: [lang][rng] org.apache.commons.lang3.ArrayUtils.shuffle()

On Fri, 14 Jun 2019 at 12:57, Alex Herbert wrote: > > > On 14/06/2019 12:01, sebb wrote: > > I meant that the iterator would use the shuffled and/or selected > > indices to return the appropriate entry from the original array. > > > > No need to modify the origin

Re: [CSV] Broken build

On Sat, 15 Jun 2019 at 15:14, Gary Gregory wrote: > > The current master build yields: > > [ERROR] CSVFormatTest.testHashCodeAndWithIgnoreHeaderCase:523 > [ERROR] CSVFormatTest.testWithHeaderComments:972 > > I do not think it is OK to push fixes that break the build. Already fixed. > Gary -

Re: [ALL] Issues with Git repos: bad HEADs and unexpected refs - need Git guru

Sun, Jun 9, 2019, 09:54 sebb wrote: > > > Ping - any comment on the unexpected HEAD references? > > Should they be changed? > > > > On Mon, 3 Jun 2019 at 15:15, Gary Gregory wrote: > > > > > > Did we git guru ourselves out of all of these? >

Re: [ALL] Issues with Git repos: bad HEADs and unexpected refs - need Git guru

On Sat, 15 Jun 2019 at 17:36, Rob Tompkins wrote: > > > > > On Jun 15, 2019, at 11:26 AM, sebb wrote: > > > > https://issues.apache.org/jira/browse/INFRA-18616 raised to fix the > > default branch. > > > > Deletion of trunk can be done later > &

[CODEC] CRLF files in macOS checkout

Most of the files in my clone of codec have LF endings, however a few are CRLF: ./README.md ./src/assembly/bin.xml ./src/assembly/src.xml ./src/changes/changes.xml ./src/main/java/org/apache/commons/codec/cli/Digest.java ./src/main/java/org/apache/commons/codec/language/DaitchMokotoffSoundex.java

Re: [CODEC] CRLF files in macOS checkout

On Tue, 18 Jun 2019 at 08:15, Julian Reschke wrote: > > On 17.06.2019 23:26, sebb wrote: > > Most of the files in my clone of codec have LF endings, however a few are > > CRLF: > > > > ./README.md > > ./src/assembly/bin.xml > > ./src/assembly/src.xml &g

Re: [CODEC] CRLF files in macOS checkout

On Tue, 18 Jun 2019 at 10:40, Alex Herbert wrote: > > > On 18/06/2019 09:55, sebb wrote: > > On Tue, 18 Jun 2019 at 08:15, Julian Reschke wrote: > >> On 17.06.2019 23:26, sebb wrote: > >>> Most of the files in my clone of codec have LF en

Re: [CODEC] CRLF files in macOS checkout

On Tue, 18 Jun 2019 at 12:58, Alex Herbert wrote: > > > On 18/06/2019 11:00, sebb wrote: > > On Tue, 18 Jun 2019 at 10:40, Alex Herbert wrote: > >> > >> On 18/06/2019 09:55, sebb wrote: > >>> On Tue, 18 Jun 2019 at 08:15, Julian Reschke > &

Re: [CODEC] CRLF files in macOS checkout

On Tue, 18 Jun 2019 at 16:01, Alex Herbert wrote: > > > On 18/06/2019 15:38, sebb wrote: > > On Tue, 18 Jun 2019 at 12:58, Alex Herbert wrote: > >> > >> On 18/06/2019 11:00, sebb wrote: > >>> On Tue, 18 Jun 2019 at 10:40, Alex Herbert > &

Re: [Rng] Jenkins JDK 1.6 failing

On Thu, 20 Jun 2019 at 13:06, Alex Herbert wrote: > > On 20/06/2019 12:45, Apache Jenkins Server wrote: > > The Apache Jenkins build system has built commons-rng (build #361) > > > > Status: Still Failing > > > > Check console output at https://builds.apache.org/job/commons-rng/361/ to > > view t

Re: [ANNOUNCEMENT] Apache Commons Collections 4.4

ompositeSet, and CompositeMap. Thanks to Yu Shi, Gary Gregory. > > Changes: > o COLLECTIONS-718: Fix LRUMap exception message. Thanks to Eitan Adler. > o COLLECTIONS-716: Don't include email address in Exception messages. > Thanks to Sebb. > > For complete information

Re: [ANNOUNCEMENT] Apache Commons Collections 4.4

ptions in CompositeCollection, > CompositeSet, and CompositeMap. Thanks to Yu Shi, Gary Gregory. > > Changes: > o COLLECTIONS-718: Fix LRUMap exception message. Thanks to Eitan Adler. > o COLLECTIONS-716: Don't include email address in Exception messages. > Thanks to Seb

Re: [ANNOUNCEMENT] Apache Commons VFS 2.4

On Thu, 18 Jul 2019 at 14:25, Gary Gregory wrote: > > The Apache Commons VFS Project team is pleased to announce the release of > Apache Commons VFS Project 2.4. > > Apache Commons VFS is a Virtual File System library. > > New features and bug fix release. > > Changes in this version include: > >

Re: [ANNOUNCEMENT] Apache Commons VFS 2.4

On Thu, 18 Jul 2019 at 15:29, Gary Gregory wrote: > > On Thu, Jul 18, 2019 at 10:06 AM sebb wrote: > > > On Thu, 18 Jul 2019 at 14:25, Gary Gregory wrote: > > > > > > The Apache Commons VFS Project team is pleased to announce the release of >

Re: [ANNOUNCEMENT] Apache Commons VFS 2.4

On Fri, 19 Jul 2019 at 03:51, Gary Gregory wrote: > > On Thu, Jul 18, 2019 at 11:09 AM sebb wrote: > > > On Thu, 18 Jul 2019 at 15:29, Gary Gregory wrote: > > > > > > On Thu, Jul 18, 2019 at 10:06 AM sebb wrote: > > > > > > >

[ALL] Checkstyle DTDs have moved

Further to NET-672 and https://github.com/apache/commons-net/pull/42, it seems the location for the checkstyle DTDs has moved. See also: https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/suppressions-filter.html and https://github.com/checkstyle/checkstyle/blob/master/config/suppr

Re: [commons-collections] branch master updated: Fix download page for 3.2.2.

On Fri, 2 Aug 2019 at 14:55, wrote: > > This is an automated email from the ASF dual-hosted git repository. > > ggregory pushed a commit to branch master > in repository https://gitbox.apache.org/repos/asf/commons-collections.git > > > The following commit(s) were added to refs/heads/master by thi

Re: [IO] Build fails with 3 checkstyle errors

I think checkstyle is correct here. It's confusing to see an import that is only used by Javadoc. On Fri, 9 Aug 2019 at 21:50, Gary Gregory wrote: > > Checkstyle is not perfect :-( I will hack that in a little bit... > > Gary > > On Fri, Aug 9, 2019, 15:22 Rob Spoor wrote: > > > See https://tra

Re: [All][parent] RAT check

On Sat, 10 Aug 2019 at 15:42, Gary Gregory wrote: > > Hi all, > > It seems to me the commons-parent should cause the RAT check to run for all > builds, say in the... validate phase? I think that might quickly become annoying; the verify phase might be better. > Gary

[ALL] Problems with default download page hash types

* be specified in the pom, rather than relying on a default (*) How does one know whether the setting is missing by accident or design? (It does not help that the default has been changed twice fairly recently) Sebb. (*) IMO built-in defaults should only be used for values that are almost always

[BEANUTILS] website still refers to SVN

It looks like the pom has not been updated to change the SCM. There are various other issues, e.g. download hash types. The tag obviously cannot/must not be updated, so I wonder if one approach would be to create a branch from the tag and build the site from that? Sebb

[ALL] POM file standardisation of layout

ate a lot of the work. Thoughts? I have had a look at the Maven Model [1] and Maven Code Style [2], however I don't think they are suitable. The developer/contributor sections are in the middle, which makes navigation harder. Also the customised sections are scattered throughout. Sebb.

  1   2   3   4   5   6   7   8   9   10   >