Re: [LANG] Jenkins Pipeline DSL
I think you can combine the analysis steps into one mvn command. On Sun, 3 Mar 2019 at 14:15, Pascal Schumacher wrote: > > Am 03.03.2019 um 14:56 schrieb sebb: > > For example, what about notifications for failed builds - is that > > maintained in Jenkins or in the pipeline file? > > Notification can be defined in the pipeline. > > Pretty much everything can be defined in a jenkins file nowadays (some > plugins do not have pipeline support (yet)). > > https://jenkins.io/doc/book/pipeline/ has a lot of useful information. > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LANG] Jenkins Pipeline DSL
On Mon, Mar 4, 2019 at 03:46, Benedikt Ritter wrote: > Am Mo., 4. März 2019 um 00:17 Uhr schrieb Matt Sicker : > > > I think you can combine the analysis steps into one mvn command. > > > > Makes sense. What I really want to have is all the analyze steps running in > parallel. Is that passible? > Yeah, you can use a parallel block to do that. Each command is a separate branch in the parallel, so no combining commands there. That should break it up into multiple executors. > > > > > On Sun, 3 Mar 2019 at 14:15, Pascal Schumacher > > > wrote: > > > > > > Am 03.03.2019 um 14:56 schrieb sebb: > > > > For example, what about notifications for failed builds - is that > > > > maintained in Jenkins or in the pipeline file? > > > > > > Notification can be defined in the pipeline. > > > > > > Pretty much everything can be defined in a jenkins file nowadays (some > > > plugins do not have pipeline support (yet)). > > > > > > https://jenkins.io/doc/book/pipeline/ has a lot of useful information. > > > > > > > > > ----- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > -- > > Matt Sicker > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > -- Matt Sicker
Re: [all] GitHub Release Notes
Isn't there a related convo at the Incubator about that? Anyways, this would be a neat feature for adding mirrors of official releases. The automatic releases feature for when you make a git tag can look weird, though, since they're not the actual release typically. On Sat, 9 Mar 2019 at 19:16, Rob Tompkins wrote: > > Now that we have gitbox enabled, committers can “draft releases” in github > which includes the ability to upload artifacts and add release notes to tags. > I’ll give an example of what’s possible with the upcoming release of the > [commons-release-plugin]. At $work I’ve been using this functionality for > quite some time and have found it convenient. > > Figured I’d let folks know about it. As it could be a user friendly item. > Obviously we would not want to put anything in the releases area that we are > not keeping direct track of in Apache infrastructure. > > Cheers, > -Rob > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] GitHub Release Notes
Quite possibly. I find a bit of overlapping concerns between Incubator and Commons due to the diversity of projects within. On Sun, Mar 17, 2019 at 03:50, Rob Tompkins wrote: > > > > On Mar 15, 2019, at 1:05 PM, Matt Sicker wrote: > > > > Isn't there a related convo at the Incubator about that? > > I’m not on at the incubatorguess I should subscribe. But wait...didn’t > you tell me to do something like that some where else like a month ago :-P > > -Rob > > > > > Anyways, this would be a neat feature for adding mirrors of official > > releases. The automatic releases feature for when you make a git tag > > can look weird, though, since they're not the actual release > > typically. > > > >> On Sat, 9 Mar 2019 at 19:16, Rob Tompkins wrote: > >> > >> Now that we have gitbox enabled, committers can “draft releases” in > github which includes the ability to upload artifacts and add release notes > to tags. I’ll give an example of what’s possible with the upcoming release > of the [commons-release-plugin]. At $work I’ve been using this > functionality for quite some time and have found it convenient. > >> > >> Figured I’d let folks know about it. As it could be a user friendly > item. Obviously we would not want to put anything in the releases area that > we are not keeping direct track of in Apache infrastructure. > >> > >> Cheers, > >> -Rob > >> ----- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > > > > > > -- > > 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 > > -- Matt Sicker
Re: [all] What versions of java do we support?
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 unless it's pointless for earlier releases of Java or if it's necessary to continue the logical path of development by supporting new APIs. On Fri, 22 Mar 2019 at 07:30, Gary Gregory wrote: > > On Thu, Mar 21, 2019 at 10:29 PM Rob Tompkins wrote: > > > > > > > > On Mar 21, 2019, at 10:22 PM, Bernd Eckenfels > > wrote: > > > > > > Nearly all vendors I have seen announced to follow voluntarily or > > commercial guaranteed the OpenJDK LTS versions (11, some 8) (Redhat, > > adoptopenjdk, Azul, ojdkbuild, sapengine, Amazon, Ubuntu/Debian, suse). > > Actually only Oracle‘s OpenJDK is not. > > > > > > > Cool. Then pardon my being tied to a vendor. > > > > Regardless, I suppose the question remains the same though right? We > > should be compatible with both 8 and 11. > > > > I think we should generalize this to Oracle and anyone's LTS version for > Java >= 8. > > Gary > > > > -Rob > > > > > Gruss > > > Bernd > > > -- > > > http://bernd.eckenfels.net > > > > > > > > > Von: Rob Tompkins > > > Gesendet: Freitag, März 22, 2019 2:59 AM > > > An: Commons Developers List > > > Betreff: Re: [all] What versions of java do we support? > > > > > > Is there LTS with those other imolementations? > > > > > >> On Mar 21, 2019, at 9:43 PM, Ralph Goers > > wrote: > > >> > > >> Why are you singling out Corretto? What about AdoptOpenJDK or RedHat’s > > OpenJDK support? The ASF is supposed to be vendor neutral. > > >> > > >> Ralph > > >> > > >>> On Mar 21, 2019, at 11:05 AM, Rob Tompkins wrote: > > >>> > > >>> Hello all, > > >>> > > >>> I would think that with the Amazon Corretto play at long term support > > for java 8 and 11 we would want to build using the latest version of the > > Corretto 8-JDK, and we would want to ensure that we work for Java 11. > > Regarding later versions of Java I’m a tad agnostic currently as we are > > less certain with their stability. > > >>> > > >>> What are folks’ thoughts? > > >>> > > >>> -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 > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Maven Magic & Javadoc 9
This might work: https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#jdkToolchain Combine with profiles to activate by default when using jdk 9+. On Tue, 26 Mar 2019 at 13:04, Gary Gregory wrote: > > Hi All: > > Is it possible to tell Maven using the toolchains.xml to use Java >= 9 if > present to run Javadoc? > > Starting with Java 9, Javadoc creates _searchable_ Javadoc's, the top right > of the page has a search box, quite handy. > > If would be nice to add this to commons-parent. > > Gary -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [codec] Java 8
I'd like to know what developers are both stuck in Java 7 (or earlier) and also have the liberty to upgrade any of their dependencies regardless of compatibility concerns. My thoughts are that being stuck in the past for one dependency tends to leak into every other dependency for the same underlying reasons. On Sat, 23 Mar 2019 at 06:27, Pascal Schumacher wrote: > > > > 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. > >> > >> Why penalise people stuck on Java 7 unnecessarily? > >> > > > >I see it the other way around: Why do we want to handcuff new > >development > >on a dead platforms? For new contributors, this is a huge turn off. > > +1 > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [codec] Java 8
If it were easier to maintain branches against various releases of Java, perhaps this wouldn't be as much of an issue. Also, philosophically, I'm already at the point where I consider Java 8 to be the "old" version of Java that's considered a bare minimum, and new/existing projects should be running on Java 12 (or 11) even if they're not targeting that source level yet. Hearing about people still stuck with older versions is disheartening. On Tue, 26 Mar 2019 at 14:13, Bruno P. Kinoshita wrote: > > Indeed. I worked in a bank and in a research company, where in both at least > one department was stuck in an old version for issues with the code base or > environment policies/decisions. > Agree not the best choice, but sometimes developers simply cannot immediately > upgrade jvm. > Some managers may even prefer to pay a vendor (eg oracle) for extra time > support. > B > > Sent from Yahoo Mail on Android > > On Wed, 27 Mar 2019 at 8:10, sebb wrote: On Tue, 26 Mar > 2019 at 19:01, Matt Sicker wrote: > > > > I'd like to know what developers are both stuck in Java 7 (or earlier) > > and also have the liberty to upgrade any of their dependencies > > regardless of compatibility concerns. My thoughts are that being stuck > > in the past for one dependency tends to leak into every other > > dependency for the same underlying reasons. > > There is a big difference between upgrading the JVM and upgrading one > or two dependencies. > > It's much easier to test against a new version of a single dependency > than to test against a new version of Java. > > Changing JVM is akin to asking a business to upgrade from Windows 7 to > Windows 8 just to use an updated version of one application on a > system that has many other apps that rely on Windows 7. > > > On Sat, 23 Mar 2019 at 06:27, Pascal Schumacher > > wrote: > > > > > > > > > > > > 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. > > > >> > > > >> Why penalise people stuck on Java 7 unnecessarily? > > > >> > > > > > > > >I see it the other way around: Why do we want to handcuff new > > > >development > > > >on a dead platforms? For new contributors, this is a huge turn off. > > > > > > +1 > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > -- > > 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 > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Java 7 to Java 8
How long until javac removes -source and -target 1.7? They already removed 1.6 in Java 12. At some point, we'll be forced to upgrade just to remain source compatible with recent compilers. That's likely not for another year or more, though, so not an immediate problem; just something to consider for long term. On Tue, 16 Apr 2019 at 09:53, sebb wrote: > > 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 contributors IMO. > > > You have to go dig around and install an archived version of the JDK > > > which Oracle has EOLed. > > > > How so? You can build Compress with Java 13 and nobody is going to stop > > you. If you happen to use a feature of something not supported in Java 7 > > then this may point to a reason to switch. > > > > > Not only that but you can't use the more modern features and APIs. > > > > This sounds as if you believed switching to more modern language > > constructs and APIs would magically attract collaborators. Been there, > > see the dead compress-2 branch, and don't buy this anymore. > > > > Note I haven't cast any vote (and this is not a vote at all), I just > > don't see any reason to add requirements as long as doing so doesn't > > provide any benefits. As soon as it does, I'll be happy to switch. > > +1, well put. > > > Stefan > > > > - > > 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 > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Java 7 to Java 8
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 OpenJDK (and its various forks) will also keep 1.7 input and output formats for just as long? Because in July 2022, you'll still be able to compile Java 7 code with their extended support version of Java 7, though not necessarily whatever the latest release of Java is at the time. -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [io] NIO2 and non-default file system support
I’ve been interested in seeing IO be updated to include support for using Path instead of just File. I can review your PR this week, though I’m certainly not the only one who can. On Tue, May 14, 2019 at 13:19, Chesney, Mark wrote: > Hello, > > Awhile back I ran into a situation where I needed to read the lines of a > file that might be on a non-default file system, like an in-memory file > system, on Java 7+. I looked to the commons-io ReversedLinesFileReader, but > it only works with java.io.File files which are always on the default file > system only. I duplicated the class in my project and found it was > relatively straightforward to adapt it to support both java.io.File and > java.nio.file.Path file. Commons-io 2.6 seems to be the first version to > require Java 7 which introduced NIO2. I think others would appreciate the > NIO2 constructors, saving a call to Path#toFile(), even if they're not > using non-default file systems. I previously created a JIRA issue IO-578< > https://issues.apache.org/jira/browse/IO-578> and an GitHub pull request > #62<https://github.com/apache/commons-io/pull/62>. I feel the PR is of > very high quality, short and to the point, ready or nearly ready to merge. > I would appreciate any feedback I can get on the JIRA issue or GitHub PR. > I'm hopeful this could make commons-io 2.7. Thanks for your attention and > consideration. > > > > Regards, > > Mark > -- Matt Sicker
Re: [io] NIO2 and non-default file system support
Thanks, Gary! On Thu, 16 May 2019 at 05:37, Gary Gregory wrote: > > The one patch has been merged. > > Gary > > On Thu, May 16, 2019, 02:03 Matt Sicker wrote: > > > I’ve been interested in seeing IO be updated to include support for using > > Path instead of just File. I can review your PR this week, though I’m > > certainly not the only one who can. > > > > On Tue, May 14, 2019 at 13:19, Chesney, Mark > > wrote: > > > > > Hello, > > > > > > Awhile back I ran into a situation where I needed to read the lines of a > > > file that might be on a non-default file system, like an in-memory file > > > system, on Java 7+. I looked to the commons-io ReversedLinesFileReader, > > but > > > it only works with java.io.File files which are always on the default > > file > > > system only. I duplicated the class in my project and found it was > > > relatively straightforward to adapt it to support both java.io.File and > > > java.nio.file.Path file. Commons-io 2.6 seems to be the first version to > > > require Java 7 which introduced NIO2. I think others would appreciate the > > > NIO2 constructors, saving a call to Path#toFile(), even if they're not > > > using non-default file systems. I previously created a JIRA issue IO-578< > > > https://issues.apache.org/jira/browse/IO-578> and an GitHub pull request > > > #62<https://github.com/apache/commons-io/pull/62>. I feel the PR is of > > > very high quality, short and to the point, ready or nearly ready to > > merge. > > > I would appreciate any feedback I can get on the JIRA issue or GitHub PR. > > > I'm hopeful this could make commons-io 2.7. Thanks for your attention and > > > consideration. > > > > > > > > > > > > Regards, > > > > > > Mark > > > > > -- > > Matt Sicker > > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [io] NIO2 and non-default file system support
I previously noted my ideas in https://issues.apache.org/jira/browse/IO-595 On Thu, 16 May 2019 at 14:53, Chesney, Mark wrote: > > Thank you both. I'd be willing to make some more contributions towards > modernization of the API if you have some idea where the greatest need or > highest value is. Are there any existing JIRA issues that come to mind? > > Regards, > Mark > > > -----Original Message- > > From: Matt Sicker > > Sent: Thursday, May 16, 2019 8:22 AM > > To: Commons Developers List > > Subject: Re: [io] NIO2 and non-default file system support > > > > Thanks, Gary! > > > > On Thu, 16 May 2019 at 05:37, Gary Gregory wrote: > > > > > > The one patch has been merged. > > > > > > Gary > > > > > > On Thu, May 16, 2019, 02:03 Matt Sicker wrote: > > > > > > > I’ve been interested in seeing IO be updated to include support for > > > > using Path instead of just File. I can review your PR this week, > > > > though I’m certainly not the only one who can. > > > > > > > > On Tue, May 14, 2019 at 13:19, Chesney, Mark > > > > > > > > wrote: > > > > > > > > > Hello, > > > > > > > > > > Awhile back I ran into a situation where I needed to read the > > > > > lines of a file that might be on a non-default file system, like > > > > > an in-memory file system, on Java 7+. I looked to the commons-io > > > > > ReversedLinesFileReader, > > > > but > > > > > it only works with java.io.File files which are always on the > > > > > default > > > > file > > > > > system only. I duplicated the class in my project and found it was > > > > > relatively straightforward to adapt it to support both > > > > > java.io.File and java.nio.file.Path file. Commons-io 2.6 seems to > > > > > be the first version to require Java 7 which introduced NIO2. I > > > > > think others would appreciate the > > > > > NIO2 constructors, saving a call to Path#toFile(), even if they're > > > > > not using non-default file systems. I previously created a JIRA > > > > > issue IO-578< https://issues.apache.org/jira/browse/IO-578> and an > > > > > GitHub pull request > > > > > #62<https://github.com/apache/commons-io/pull/62>. I feel the PR > > > > > is of very high quality, short and to the point, ready or nearly > > > > > ready to > > > > merge. > > > > > I would appreciate any feedback I can get on the JIRA issue or GitHub > > > > > PR. > > > > > I'm hopeful this could make commons-io 2.7. Thanks for your > > > > > attention and consideration. > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Mark > > > > > > > > > -- > > > > Matt Sicker > > > > > > > > > > > > -- > > Matt Sicker > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [configuration]
ativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke (Method.java:498) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced > (Launcher.java:282) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch > (Launcher.java:225) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode > (Launcher.java:406) > at org.codehaus.plexus.classworlds.launcher.Launcher.main > (Launcher.java:347) > Caused by: java.io.FileNotFoundException: > > C:\git\commons-configuration\target\site\org.apache.commons_commons-configuration2_2.4C:\git\commons-configuration\target\commons-configuration2-2.5-SNAPSHOT.jar_output.html > (The filename, directory name, or volume label syntax is incorrect) > at java.io.FileOutputStream.open0 (Native Method) > at java.io.FileOutputStream.open (FileOutputStream.java:270) > at java.io.FileOutputStream. (FileOutputStream.java:213) > at java.io.FileOutputStream. (FileOutputStream.java:162) > at org.codehaus.plexus.util.WriterFactory.newWriter > (WriterFactory.java:175) > at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render > (DefaultSiteRenderer.java:347) > at org.apache.maven.plugins.site.render.SiteMojo.renderLocale > (SiteMojo.java:198) > at org.apache.maven.plugins.site.render.SiteMojo.execute > (SiteMojo.java:147) > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo > (DefaultBuildPluginManager.java:137) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:210) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:156) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:148) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:117) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:81) > at > > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build > (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute > (LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:192) > at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke (Method.java:498) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced > (Launcher.java:282) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch > (Launcher.java:225) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode > (Launcher.java:406) > at org.codehaus.plexus.classworlds.launcher.Launcher.main > (Launcher.java:347) > [ERROR] > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, > please read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException > > I get it when I run: > > mvn install site -DskipTests -Ddoclint=none -e > > Using: > > Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; > 2019-04-04T15:00:29-04:00) > Maven home: C:\Java\apache-maven-3.6.1\bin\.. > Java version: 1.8.0_212, vendor: Oracle Corporation, runtime: C:\Program > Files\Java\jdk1.8.0_212\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > > Gary > -- Matt Sicker
Re: [beanutils2] CVE-2014-0114 Pull Request
Hi, I've gone ahead and approved it after review. Since I'm not active in beanutils, I'd prefer someone else to either merge it or add an approval review first. My company has also been moving toward eliminating vulnerable versions of dependencies, and we use beanutils (1.9.x currently) in some limited fashion. On Thu, 23 May 2019 at 06:29, Melloware Inc wrote: > > Hey All!, > > First time contributor here. My company has a corporate goal to only use > open source libraries with NO open Security CVE's marked as critical. > > BeanUtils has CVE-2014-0114 marked as critical so I opened a ticket: > https://issues.apache.org/jira/browse/BEANUTILS-520 > > I submitted my first Apache Commons PR which addresses the issue which I > was hoping I could get code reviewed and hopefully merged. I followed all > guidelines and included a specific unit test to prove the issue and the fix. > > Pull Request: https://github.com/apache/commons-beanutils/pull/7 > > I really feel like this is an important fix to have security on by default > and still allow the ability to opt-out and make it backwards compatible. I > hope the Apache community feels the same way! > > Thanks, > Melloware -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Giant StringUtils vs. NullSafeStrings.
The JDK is the only source allowed to modify java.lang.String, so they'd likely add static methods to that directly like String.join() and the others. The plural name thing was more of an issue with an interface Thing and utility class Things. As of Java 8, there's typically no need to have a Things class because the Thing interface can have static methods on it. For example, see all the static methods added to Comparator that would have typically gone into a class named Comparators (like Collector/Collectors). On Tue, 4 Jun 2019 at 06:07, Xeno Amess wrote: > > Then 10 years later JDK has its own Strings, and users get confused then. > > Emmanuel Bourg 于2019年6月4日周二 下午6:58写道： > > > Le 28/05/2019 à 13:46, Gary Gregory a écrit : > > > > > Thoughts? > > > > Maybe we could make a more ambitious 'Strings' class with methods taken > > from StringUtils and refactored with a fluent API to avoid the > > combinatorial explosion of StringUtils? Just a wild idea. > > > > Emmanuel Bourg > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All] Alpha/beta releases
This sounds like a shade feature, yes. However, in order to automatically extract the version extra data and detect a version keyword like "alpha" may require some additional code, though maybe the shade plugin already supports that. Alternatively, JUnit 5.x uses a tool called API Guardian for marking which APIs are stable or not: https://github.com/apiguardian-team/apiguardian On Tue, 4 Jun 2019 at 05:53, Gilles Sadowski wrote: > > Hello. > > Does someone see a practical way to automate package names > and source files conversions so that each all alpha/beta releases > can be used together (e.g. to compare their behaviours). > > I mean, for release version "1.0-alpha1", the top-level package > name "o.a.c.compid" would be turned into "o.a.c.compid.alpha1". > > This would also solve issues with compatibility checkers (with the > added bonus that JAR hell could never happen). > > Couldn't the "shade" plugin be put to use (so that all artefacts have > their top-level package transparently set to "o.a.c.compid.alpha1" > and all the tools operate on that)? > > > Regards, > Gilles > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All] Alpha/beta releases
Maybe we should have a separate maven repo for alpha and beta releases. That could make them less likely to cause jar hell conflicts. It could even be similar to snapshots if they’re not voted on. On Wed, Jun 5, 2019 at 10:33, Gilles Sadowski wrote: > Le mer. 5 juin 2019 à 17:04, James Carman a > écrit : > > > > What sort of comparison are you looking to do within the same code? > > Performance? > > Yes, that's one possibility; another is comparing different APIs. > > Gilles > > >>>> [...] > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [commons-dbcp] branch master updated: [DBCP-547] Add a ConnectionFactory class name setting for BasicDataSource.createConnectionFactory() #33.
Thanks, Mark! I’m in complete agreement on your formatting philosophy here (consistency over bikeshedding). And also kinda like the new line after operator, too, though no strong opinion there since I seem to forget which style I prefer sometimes. On Thu, Jul 11, 2019 at 04:21, Mark Thomas wrote: > On 10/07/2019 22:47, Gary Gregory wrote: > > On Wed, Jul 10, 2019 at 11:52 AM Mark Thomas wrote: > > > >> On 10/07/2019 15:49, Gary Gregory wrote: > >> > >>> Without arguing about the merits of one kind of formatting vs. > another... > >>> If you can configure the Eclipse formatter to do that, I'd consider it, > >>> otherwise, I'm not into what I'd call "artisanal formatting" ;-) > >> > >> > >> The Eclipse setting you want is: > >> > >> Formatter > Line Wrapping > Default indentation for wrapped lines > >> > >> and set it to 2 (which should be the default). > >> > >> > >> That seems to do the trick when I run it locally. I'd commit the result > >> but the default settings change nearly every line in the file. > >> > >> Looking more closely, that appears to be a line ending issue. I thought > >> the accepted practice was to use unix line endings in the repo and > >> native line endings locally. It looks like there are some Windows line > >> endings in the repo. > >> > >> It would be worth saving your Eclipse formatter settings in the source > >> tree somewhere so everybody can work from the same set. > >> > > > > I set the setting you mentioned to 2 and saved my config > > here: src/conf/eclipse/formatter.xml > > I did not reformat anything. > > Thanks. I applied that to BasicDataSource. > > I haven't applied that formatting to all files although it probably > makes sense to do so. > > I've looked through the formatting and my personal preference would be > to change one more thing (actually a handful of settings for different > operators): > - wrap before operator -> wrap after operator > > but that is a low priority for me. If the consensus is against that I'm > fine with that. I'd rather spend time convincing people it is helpful > for the project to use a consistent formatting throughout than endlessly > debate the merits of each individual option. > > I also fixed the line endings of the 10 or so files that were using \r\n > line endings rather than the recommended \n. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [Commons] Error : Expected feature release number in range of 9 to 14, but got: 8
Oracle JDK 8 is a commercial product at this point, isn’t it? OpenJDK 8 should be mostly equivalent, and starting at some later point, they’re the same. On Thu, Jul 11, 2019 at 19:26, Virendra singh Rajpurohit < virendrasing...@gmail.com> wrote: > Hi all, > I'm working on Commons-Statistics, and my PR > <https://github.com/apache/commons-statistics/pull/18> failed with the > following error: > > [image: travis-error.PNG] > > It failed for "oraclejdk8 > <https://travis-ci.org/apache/commons-statistics/jobs/557070245>" but > worked fine with "openjdk8 > <https://travis-ci.org/apache/commons-statistics/jobs/557070246>". > Does anybody else faced the same issue before? How to resolve this issue? > > Thank you > Regards > -- > *Virendra Singh Rajpurohit* > > -- Matt Sicker
Re: [pool] OK to commit?
I believe it’s CTR on Pool, so go for it. On Sat, Jul 20, 2019 at 18:45, Phil Steitz wrote: > I am working on a patch for POOL-361. I think the analysis in the > ticket is correct and I think I know how to fix it (move validation into > create()). I think I still have commit karma, but have not committed to > commons in quite a while. Any objections to me committing directly to > [pool]? > > Phil > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [lang3][collection4][text] Investigation on the diffusion of innovation along with java releases
Yeah, Commons libraries are almost intentionally behind the times in order to provide functionality to the most people. Sometimes, Java even adds things that make a Commons library somewhat redundant in theory (like NIO2 from Java 7 which could theoretically replace Commons VFS as an API). I can also say that personally, I can’t even think of a good Commons functional programming library that would be possible with the current limitations of the Java type system. Scala and now even Kotlin have a lot of interesting libraries in that space. On Tue, Jul 30, 2019 at 06:39, Gary Gregory wrote: > Fernando, > > In general, it feels to me the Apache Commons community is split and slow > moving to adopt newer version of Java. Currently, updating the platform > requirements of a component to Java 8 causes some people to react with > "What about people running on Java 7?!" comments, or "What Java 8 features > are required? Why update Java if we don't need to?". Others, like me, would > prefer to move to Java 8 as the base version for all components, and build > on that, showing contributors that we are set up to accept code that > use modern language constructs like lambdas. We've had to reject or rework > some PRs because they depended on Java 8 APIs when the component was still > on Java 7, not a great position IMO. > > Argument for whether or not lambdas "improve readability" or is a debate I > care not to enter ;-) > > Gary > > On Tue, Jul 30, 2019 at 4:54 AM wrote: > > > Dear Developers, > > > > we are members of the ZEST research group (Zurich Empirical Software > > Engineering Team) based at the University of Zurich and the Delft > > University of Technology. We are conducting an investigation on the > > diffusion of innovations and we focus on the adoption of new language > > features. Our research is focused on how API producers adapt their > > interfaces to introduce support for Java 8’s lambdas. During the course > of > > our investigation, we manually inspected commons-collections, > commons-text, > > and commons-lang’s source code and documentations to understand whether > > Java’s lambdas have widespread adoption. We would like to have your > > feedback on our findings. > > > > Our study focuses primarily on Functional Interfaces and Lambda > > Expressions as these new features were introduced by the Java language > and > > adopted the Java JDK API, as they reduce implementation complexity, > improve > > readability, offer performance benefits and improve security > > contextualization. > > Our analysis showed that though commons-collection 4.2, commons-text 1.7, > > and commons-lang3 3.9 did not explicitly introduce support for functional > > interfaces (e.g. by using the @FunctionalInterface annotation). We > noticed > > that the APIs provide compatibility with Java 8+ features, including > lambda > > expressions (since the APIs’s build platform is now on JDK 1.8+). We > would > > like to better understand as to why no major change was necessitated to > > facilitate the usage of lambda expressions with the API. > > > > In most cases, developers choose to move to new releases to satisfy > > particular dependency requirements, to take advantage of new Java > features > > (like streams and functional interfaces in the case of Java 8), or just > to > > standardize their implementation to align the API with the Java JDK API. > > Can you provide us with more information about this? > > How did you and your team tackle the choice to change the version of Java > > supported? > > Which factors did you take into account when doing this? > > Are there any documented sources (e.g. Jira tickets, or issue tracker > > issues) about that discussion you can provide us with? > > Why were no explicit changes made to the interface to support lambda > > expressions? > > Are there any future plans in place to make larger changes to the API > such > > that lambda expressions would be supported? > > > > We thank you for taking the time to answer our questions. If you would > > like to be posted about the results of this study, please let us know! > > > > Kind Regards, > > Fernando Petrulio. > > > > > > [photo-logo] > > Fernando Petrulio > > PhD Student University of Zurich UZH > > Department of Informatics > > > > [linkedin] https://www.linkedin.com/in/fernando-petrulio > > > -- Matt Sicker
Re: [lang3][collection4][text] Investigation on the diffusion of innovation along with java releases
On Tue, 30 Jul 2019 at 08:50, Gilles Sadowski wrote: > I certainly agree with Gary as to why "Commons" is not there being a > practical issue (of no concerted road map and lacking developers to > implement it). However, did I understand correctly that you consider > such a development to be useless? I.e. rather than updating "Commons" > do you suggest that application developers should not use it? I meant that writing Commons libraries for functional programming still isn't possible with Java's limited generics and type system. I'm talking about higher kinded types, dependent types, monads, functors, etc. While there are some Java libraries out there that attempt to do this [1] [2], there's no "natural" way to express type classes and other functional programming concepts in Java. Considering the lack of Kotlin and Scala libraries in Commons at the moment, I'd conclude that this isn't the most appropriate place for functional programming libraries at the moment. Or maybe more accurately, Commons doesn't have any libraries for this yet (not like we're limited to purely Java here). However, that isn't to say that Commons libraries can't offer anything useful that relies on lambda functions, streams, completable futures, etc., but that is a fairly limited subset of functional programming, and any academic study looking at this should know that due to familiarity with languages like Haskell where "real" functional programming tends to take place still. Or maybe I'm misunderstanding the point of this question entirely. [1]: https://www.functionaljava.org/ [2]: https://www.vavr.io/ -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang3][collection4][text] Investigation on the diffusion of innovation along with java releases
Commons Functor <https://commons.apache.org/proper/commons-functor/> looks more like Java 8 functional programming, that's for sure. I'd never looked at that before. On Wed, 31 Jul 2019 at 01:05, Bruno P. Kinoshita wrote: > > Hi, > > >Or maybe more accurately, Commons doesn't have any libraries for this yet > >(not like we're limited to purely Javahere). > We have the unreleased Commons Functor. I believe this was the intention of > the project, though it lost momentum. But some interesting code there that > could be simplified and released if there's still interest. > > Bruno > > On Wednesday, 31 July 2019, 3:59:25 am NZST, Matt Sicker > wrote: > > On Tue, 30 Jul 2019 at 08:50, Gilles Sadowski wrote: > > I certainly agree with Gary as to why "Commons" is not there being a > > practical issue (of no concerted road map and lacking developers to > > implement it). However, did I understand correctly that you consider > > such a development to be useless? I.e. rather than updating "Commons" > > do you suggest that application developers should not use it? > > I meant that writing Commons libraries for functional programming > still isn't possible with Java's limited generics and type system. I'm > talking about higher kinded types, dependent types, monads, functors, > etc. While there are some Java libraries out there that attempt to do > this [1] [2], there's no "natural" way to express type classes and > other functional programming concepts in Java. Considering the lack of > Kotlin and Scala libraries in Commons at the moment, I'd conclude that > this isn't the most appropriate place for functional programming > libraries at the moment. Or maybe more accurately, Commons doesn't > have any libraries for this yet (not like we're limited to purely Java > here). > > However, that isn't to say that Commons libraries can't offer anything > useful that relies on lambda functions, streams, completable futures, > etc., but that is a fairly limited subset of functional programming, > and any academic study looking at this should know that due to > familiarity with languages like Haskell where "real" functional > programming tends to take place still. Or maybe I'm misunderstanding > the point of this question entirely. > > [1]: https://www.functionaljava.org/ > [2]: https://www.vavr.io/ > > -- > Matt Sicker > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang3][collection4][text] Investigation on the diffusion of innovation along with java releases
Oh I’d be interested in a functor2 that’s adapted for Java 8. I might work on a proof of concept proposal first. On Fri, Aug 2, 2019 at 20:09, Bruno P. Kinoshita wrote: > Hi Gilles > I can't speak for others, but I agree we would need to remove most of the > code that is now available in Java 8. I think [functor] would need more a > place for functional code that does not belong to lang, but is still useful > to other devs & components. > > Bruno > > > On Saturday, 3 August 2019, 1:48:50 am NZST, Gilles Sadowski < > gillese...@gmail.com> wrote: > > Hello Bruno. > > Le mer. 31 juil. 2019 à 08:05, Bruno P. Kinoshita a > écrit : > > > > Hi, > > > > >Or maybe more accurately, Commons doesn't have any libraries for this > yet (not like we're limited to purely Javahere). > > We have the unreleased Commons Functor. I believe this was the intention > of the project, though it lost momentum. > > The site is outdated: link to the source repository returns 404.[1] > > > But some interesting code there that could be simplified and released if > there's still interest. > > From a quick browsing of the documentation[2], it seems that a large chunk > is now covered by the JDK's "java.util.function" package. If so, the > first step > would probably be a purge of everything that duplicates functionality > available > in standard classes. > > It would be most interesting to read what the developers who contributed > to that component think.[3] > > Regards, > Gilles > > [1] > https://commons.apache.org/proper/commons-functor/source-repository.html > [2] https://commons.apache.org/proper/commons-functor/apidocs/index.html > [3] https://commons.apache.org/proper/commons-functor/team-list.html > > > > > Bruno > > > >On Wednesday, 31 July 2019, 3:59:25 am NZST, Matt Sicker < > boa...@gmail.com> wrote: > > > > On Tue, 30 Jul 2019 at 08:50, Gilles Sadowski > wrote: > > > I certainly agree with Gary as to why "Commons" is not there being a > > > practical issue (of no concerted road map and lacking developers to > > > implement it). However, did I understand correctly that you consider > > > such a development to be useless? I.e. rather than updating "Commons" > > > do you suggest that application developers should not use it? > > > > I meant that writing Commons libraries for functional programming > > still isn't possible with Java's limited generics and type system. I'm > > talking about higher kinded types, dependent types, monads, functors, > > etc. While there are some Java libraries out there that attempt to do > > this [1] [2], there's no "natural" way to express type classes and > > other functional programming concepts in Java. Considering the lack of > > Kotlin and Scala libraries in Commons at the moment, I'd conclude that > > this isn't the most appropriate place for functional programming > > libraries at the moment. Or maybe more accurately, Commons doesn't > > have any libraries for this yet (not like we're limited to purely Java > > here). > > > > However, that isn't to say that Commons libraries can't offer anything > > useful that relies on lambda functions, streams, completable futures, > > etc., but that is a fairly limited subset of functional programming, > > and any academic study looking at this should know that due to > > familiarity with languages like Haskell where "real" functional > > programming tends to take place still. Or maybe I'm misunderstanding > > the point of this question entirely. > > > > [1]: https://www.functionaljava.org/ > > [2]: https://www.vavr.io/ > > > > -- > > Matt Sicker -- Matt Sicker
Re: [lang3][collection4][text] Investigation on the diffusion of innovation along with java releases
I just noticed there's no 1.0 release, so I suppose it doesn't even need to change the version yet. On Sat, 3 Aug 2019 at 12:24, Matt Sicker wrote: > > Oh I’d be interested in a functor2 that’s adapted for Java 8. I might work on > a proof of concept proposal first. > > On Fri, Aug 2, 2019 at 20:09, Bruno P. Kinoshita wrote: >> >> Hi Gilles >> I can't speak for others, but I agree we would need to remove most of the >> code that is now available in Java 8. I think [functor] would need more a >> place for functional code that does not belong to lang, but is still useful >> to other devs & components. >> >> Bruno >> >> >> On Saturday, 3 August 2019, 1:48:50 am NZST, Gilles Sadowski >> wrote: >> >> Hello Bruno. >> >> Le mer. 31 juil. 2019 à 08:05, Bruno P. Kinoshita a écrit >> : >> > >> > Hi, >> > >> > >Or maybe more accurately, Commons doesn't have any libraries for this yet >> > >(not like we're limited to purely Javahere). >> > We have the unreleased Commons Functor. I believe this was the intention >> > of the project, though it lost momentum. >> >> The site is outdated: link to the source repository returns 404.[1] >> >> > But some interesting code there that could be simplified and released if >> > there's still interest. >> >> From a quick browsing of the documentation[2], it seems that a large chunk >> is now covered by the JDK's "java.util.function" package. If so, the first >> step >> would probably be a purge of everything that duplicates functionality >> available >> in standard classes. >> >> It would be most interesting to read what the developers who contributed >> to that component think.[3] >> >> Regards, >> Gilles >> >> [1] https://commons.apache.org/proper/commons-functor/source-repository.html >> [2] https://commons.apache.org/proper/commons-functor/apidocs/index.html >> [3] https://commons.apache.org/proper/commons-functor/team-list.html >> >> > >> > Bruno >> > >> >On Wednesday, 31 July 2019, 3:59:25 am NZST, Matt Sicker >> > wrote: >> > >> > On Tue, 30 Jul 2019 at 08:50, Gilles Sadowski >> > wrote: >> > > I certainly agree with Gary as to why "Commons" is not there being a >> > > practical issue (of no concerted road map and lacking developers to >> > > implement it). However, did I understand correctly that you consider >> > > such a development to be useless? I.e. rather than updating "Commons" >> > > do you suggest that application developers should not use it? >> > >> > I meant that writing Commons libraries for functional programming >> > still isn't possible with Java's limited generics and type system. I'm >> > talking about higher kinded types, dependent types, monads, functors, >> > etc. While there are some Java libraries out there that attempt to do >> > this [1] [2], there's no "natural" way to express type classes and >> > other functional programming concepts in Java. Considering the lack of >> > Kotlin and Scala libraries in Commons at the moment, I'd conclude that >> > this isn't the most appropriate place for functional programming >> > libraries at the moment. Or maybe more accurately, Commons doesn't >> > have any libraries for this yet (not like we're limited to purely Java >> > here). >> > >> > However, that isn't to say that Commons libraries can't offer anything >> > useful that relies on lambda functions, streams, completable futures, >> > etc., but that is a fairly limited subset of functional programming, >> > and any academic study looking at this should know that due to >> > familiarity with languages like Haskell where "real" functional >> > programming tends to take place still. Or maybe I'm misunderstanding >> > the point of this question entirely. >> > >> > [1]: https://www.functionaljava.org/ >> > [2]: https://www.vavr.io/ >> > >> > -- >> > Matt Sicker > > -- > Matt Sicker -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RESULT][VOTE] Release Apache Commons BeanUtils 1.9.4 based on RC2
Was this release made to Maven Central? On Sat, 3 Aug 2019 at 07:41, Rob Tompkins wrote: > > This vote passes with a +1 from: > > Gary Gregory, > Pascal Schumacher, and > Rob Tompkins. > > Many thanks to Gary and Pascal for their time. > > Cheers, > -Rob > > > On Jul 28, 2019, at 6:35 PM, Rob Tompkins wrote: > > > > We have fixed quite a few bugs and added some significant enhancements > > since Apache Commons BeanUtils 1.9.3 was released, so I would like to > > release Apache Commons BeanUtils 1.9.4. > > > > Apache Commons BeanUtils 1.9.4 RC2 is available for review here: > >https://dist.apache.org/repos/dist/dev/commons/beanutils/1.9.4-RC2 (svn > > revision 35044) > > > > The Git tag commons-beanutils-1.9.4-RC2 commit for this RC is > > 32ceb2c92512d44f97638805e2f3fd9d70dfcfc6 which you can browse here: > > > > https://gitbox.apache.org/repos/asf?p=commons-beanutils.git;a=commit;h=32ceb2c92512d44f97638805e2f3fd9d70dfcfc6 > > You may checkout this tag using: > > git clone https://gitbox.apache.org/repos/asf/commons-beanutils.git > > --branch > > commons-beanutils-1.9.4-RC2 commons-beanutils-1.9.4-RC2 > > > > Maven artifacts are here: > > > > https://repository.apache.org/content/repositories/orgapachecommons-1455/commons-beanutils/commons-beanutils/1.9.4/ > > > > These are the Maven artifacts and their hashes in Nexus: > > > > #Nexus SHA-1s > > commons-beanutils-1.9.4.jar=d52b9abcd97f38c81342bb7e7ae1eee9b73cba51 > > commons-beanutils-1.9.4-tests.jar=bf66a5197f0abb2c44d68a59e70487f5710c679a > > commons-beanutils-1.9.4-javadoc.jar=6daf5afaab5f8d1c578d72c548d84b4e15b91c6c > > commons-beanutils-1.9.4.pom=42e7c39331e1735250b294ce2984d0e434ebc955 > > commons-beanutils-1.9.4-sources.jar=f00e0ba867d1810f255876631ab440e0725a9af0 > > commons-beanutils-1.9.4-test-sources.jar=f97fc6a1b742bc18f1a80963d1e82d9d28fd5404 > > > > #Release SHA-256s > > #Sun Jul 28 18:16:53 EDT 2019 > > commons-beanutils-1.9.4-src-tar.gz=2d46a5ac37000cad57ed338dbc5a0ae08cb924471afb5b3d4cff084afa0c728e > > commons-beanutils-1.9.4-src-zip=48e12cff3d3621d2055ec0dfdf49a416bfe3e50bf0768488da878bbcca77d599 > > commons-beanutils-1.9.4-bin-tar.gz=313682f4a13b5b8f3c5e7e6351605f62ff431913c51b6ed94cc83563086e4295 > > commons-beanutils-1.9.4-bin-zip=02093566d50497e6cc732b561c74b1ce226c0e6fe7a679c91c2113689bb1a547 > > > > > > I have tested this with 'mvn clean install site' using: > > Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; > > 2019-04-04T15:00:29-04:00) > > Maven home: /usr/local/Cellar/maven/3.6.1/libexec > > Java version: 1.8.0_202, vendor: Amazon.com Inc., runtime: > > /Library/Java/JavaVirtualMachines/amazon-corretto-8.jdk/Contents/Home/jre > > Default locale: en_US, platform encoding: UTF-8 > > OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac" > > > > > > Details of changes since 1.9.3 are in the release notes: > > > > https://dist.apache.org/repos/dist/dev/commons/beanutils/1.9.4-RC2/RELEASE-NOTES.txt > > > > https://dist.apache.org/repos/dist/dev/commons/beanutils/1.9.4-RC2/site/changes-report.html > > > > Site: > >https://dist.apache.org/repos/dist/dev/commons/beanutils/1.9.4-RC2/site > >(note some *relative* links are broken and the 1.9.4 directories are not > > yet created - these will be OK once the site is deployed.) > > > > RAT Report: > > > > https://dist.apache.org/repos/dist/dev/commons/beanutils/1.9.4-RC2/site/rat-report.html > > > > KEYS: > > https://www.apache.org/dist/commons/KEYS > > > > Please review the release candidate and vote. > > This vote will close no sooner that 72 hours from now. > > > > [ ] +1 Release these artifacts > > [ ] +0 OK, but... > > [ ] -0 OK, but really should fix... > > [ ] -1 I oppose this release because... > > > > Thank you, > > > > Rob Tompkins, > > Release Manager (using key B6E73D84EA4FCC47166087253FAAD2CD5ECBB314) > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Need Feedback for COMPRESS-479
The enum makes sense. Are there any feasible ways to, say, configure some sort of handler class that can implement logic around unknown fields? Sort of an extensibility model there, but hopefully without having to extend ZipInputStream or anything like that. On Tue, 13 Aug 2019 at 14:01, Stefan Bodewig wrote: > > Hi > > https://issues.apache.org/jira/browse/COMPRESS-479 highlights a problem > where our zip reading code may reject an archive because it uses extra > fields that we only partially understand. In this case the archive is > not a real one, but it is easy to envision extra fields in the wild that > use more advanced versions than we currently support. > > For most of our users the ZIP extra fields will be noise and they really > are only interested in the actual content of the archives. > > Therefore I have decided to treat any such "not quite as we expect" > extra field the same way as any "we have no idea how this extra field > looks internally" field - i.e. just store it but don't try to parse > it. > > In addition I have provided an API inside of ZipArchiveEntry that allows > users to specify in detail how strict they want the extra field parsing > to be. > > Does this make sense to you? Would you recommend taking a different > approach? And it if makes sense, are the enum names I've chosen in > https://github.com/apache/commons-compress/blob/2bf678bbc6c6002569559b90ea29a031f035f067/src/main/java/org/apache/commons/compress/archivers/zip/ZipArchiveEntry.java#L1117 > understandable? > > Thanks > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Need Feedback for COMPRESS-479
Yes, I think you understand us. A strategy pattern with default sensible strategies to choose. On Wed, Aug 14, 2019 at 06:08, Stefan Bodewig wrote: > On 2019-08-13, Matt Sicker wrote: > > > The enum makes sense. Are there any feasible ways to, say, configure > > some sort of handler class that can implement logic around unknown > > fields? > > Not really. The only extension point here currently is plugging in your > own implementations of ZipExtraField via the static > ExtraFieldUtils.register - which could use some ServiceLoader magic one > day :-) > > IIUC you and Gary are both saying the same thing. The enum values are > sensible defaults but it would be good to provide a way to do the same > things with custom code (callbacks or interface implementations). > > It should be possible to split ExtraFieldParsingMode into a strategy > pattern interface implemented by the enum providing default > implementations. This may also reduce some other implementation quirks > (I'm not too happy with the current exception handler inside > mergeExtraFields). > > Thanks! > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [ALL] POM file standardisation of layout
The layout you propose sounds reasonable to me. On Thu, Aug 15, 2019 at 08:32, sebb wrote: > The Ruby tool and some sample output: > > http://svn.apache.org/repos/asf/commons/scripts/ > examples/ > pomskel.rb > > On Thu, 15 Aug 2019 at 14:08, sebb wrote: > > > > On Thu, 15 Aug 2019 at 13:06, Claude Warren wrote: > > > > > > Since the POM is an XML document how about a simple XSLT that will > convert > > > them all to the same format. > > > > Unfortunately I don't think it's simple. > > > > Comments on their own line apply to the following tag -- but not always. > > And a comment at the end of a line applies to the line it is on, but > > appears after it in the DOM. > > There may be some white-space issues as well. > > > > > Alternatively an XML diff could be performed where each leaf node is > > > contextualized by generating the the path from the root to the leaf, > the > > > can be sorted and a standard diff performed to determine where they are > > > different. > > > > I've written a simple Ruby script to produce a skeleton file showing > > the major components. > > This can be used to analyse the existing layouts. > > Once a standard has been chosen, the tool can show which sections need > > to be moved. > > > > > The above being said, having a standard POM format makes sense to me. > > > > Great. > > > > > Claude > > > > > > On Thu, Aug 15, 2019 at 11:40 AM sebb wrote: > > > > > > > I think it might be useful to try to work towards standardising the > > > > order of sections within POMs. > > > > > > > > This will make it easier to compare them across components. > > > > (e.g. to see why one pom works and another fails!) > > > > And should be easier to maintain. > > > > > > > > In particular, I would like to move the developer and contributor > > > > sections to the end. > > > > They can be quite long, so they make it harder to read the pom. > > > > > > > > Also to move properties near the beginning, as they are the most > > > > likely to need change. > > > > i.e. the main custom elements should be near the start. > > > > > > > > I'm hoping that many poms will have a similar layout (probably many > > > > were copied from another component). > > > > > > > > Maybe start by extracting layouts from existing poms to create a few > > > > skeleton poms. > > > > Once a suitable layout has been agreed, components can be updated as > > > > they are worked on. > > > > > > > > Poms have a very regular structure, so it should be possible to > > > > automate 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] https://maven.apache.org/ref/3.6.1/maven-model/maven.html > > > > [2] > > > > > http://maven.apache.org/developers/conventions/code.html#POM_Code_Convention > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > -- > > > I like: Like Like - The likeliest place on the web > > > <http://like-like.xenei.com> > > > LinkedIn: http://www.linkedin.com/in/claudewarren > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [ALL] Problems with default download page hash types
I know it’s policy, but why exactly do we have to provide checksum files when the asc file is a already a checksum (and most likely based on SHA256 or 512 anyways)? On Thu, Aug 15, 2019 at 04:03, sebb wrote: > I have had to fix several download pages recently because they > referred to sha512 instead of sha256. > > Please would RMs double-check that the pom has the correct setting and > that the generated download_xyz.xml file corresponds with the file > names? > > In future, I think the hash setting should *always* 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 correct, i.e. where it is unusual to see a different > value. Defaults should never be changed. > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [LANG] Q: introduction of new development tool
The idea of automatically using unit tests as code samples in the documentation sounds great! This sounds fairly interesting to me. On Tue, Aug 27, 2019 at 08:00, Peter Verhas wrote: > I have seen looking over the code of the LANG3 project that there are a lot > of places where the code is copy/paste. Many times these copy/paste code is > the result of the shortages of the Java language. We implement methods that > look more or less the same but they have to be created for all primitive > types. The maintenance of this code is cumbersome, changed at one place has > to be changed at the other places as well. > > The framework Java::Geci can automate the maintenance of those code > fragments. The framework is a test dependency ONLY, so it does not present > an extra dependency for the users. > > The application of the framework can also be used to automatically > copy/update code from the unit tests into the JavaDoc documentation, like > copying and converting assertion statements into tables with inputs and > results. > > I would be happy to create a few pull requests as a demonstration of how > Java::Geci can be used for the purposes. > > QUESTION: > > What is your attitude towards a new tool like this? I do not ask a final > decision for "yes we want to use it" or "no we do not want". I just want to > know if the developer community would consider the use of such a tool. > > A last note: The tool is extremely non-invasive. Any project using it can > decide at any point to discontinue the use. All it needs is to delete the > tests that start the tool, remove the dependency from the POM file and that > is it. > > -- > Peter Verhas > pe...@verhas.com > t: +41791542095 > skype: verhas > -- Matt Sicker
Re: [bcel][all] GitHub Actions for Maven builds
GitHub Actions are more of a replacement for Travis currently. Provided you’re not doing anything fancy in your pipelines, it might not require Jenkins, either. On Sat, Aug 31, 2019 at 11:17, Stefan Bodewig wrote: > On 2019-08-31, Gary Gregory wrote: > > > On Sat, Aug 31, 2019 at 10:58 AM Gilles Sadowski > > wrote: > > >> Links returns "404". > > > Works for me, anyone else? > > Only works if you are logged in - an probably a member of the apache > organization. github returns 404 for links you are not allowed to see. > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [bcel][all] GitHub Actions for Maven builds
If you enable the project authorization setting on Jenkins, you can store credentials in a specific user who the build runs as. It’s somewhat primitive at the moment, but I’ve been working on related features lately to improve the situation there for more complex CICD scenarios. Jenkins pipelines aren’t going away anytime soon unlike SaaS fads sometimes do. ;) On Sat, Aug 31, 2019 at 18:37, Gilles Sadowski wrote: > Le sam. 31 août 2019 à 19:22, Gary Gregory a > écrit : > > > > That is what I thinking, using GitHub actions we can keep builds and > > sources in one place. Well two places: sources+builds in Apache and > GitHub. > > It feels like we can remove Travis. > > I can see this page > https://travis-ci.org/apache/commons-bcel > without being logged in. > Concluding to the opposite. > > Moreover, not having any control over the evolution of one or the other's > policy, why put all one's eggs in one basket? > > Gilles > > > > > Gary > > > > On Sat, Aug 31, 2019, 12:53 Matt Sicker wrote: > > > > > GitHub Actions are more of a replacement for Travis currently. Provided > > > you’re not doing anything fancy in your pipelines, it might not require > > > Jenkins, either. > > > > > > On Sat, Aug 31, 2019 at 11:17, Stefan Bodewig > wrote: > > > > > > > On 2019-08-31, Gary Gregory wrote: > > > > > > > > > On Sat, Aug 31, 2019 at 10:58 AM Gilles Sadowski < > gillese...@gmail.com > > > > > > > > > wrote: > > > > > > > > >> Links returns "404". > > > > > > > > > Works for me, anyone else? > > > > > > > > Only works if you are logged in - an probably a member of the apache > > > > organization. github returns 404 for links you are not allowed to > see. > > > > > > > > Stefan > > > > > > > > ----- > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > -- > > > Matt Sicker > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [bcel][all] GitHub Actions for Maven builds
I think I replied to the wrong email. On Sun, Sep 1, 2019 at 04:53, Gilles Sadowski wrote: > Hi. > > 2019-09-01 6:08 UTC+02:00, Matt Sicker : > > If you enable the project authorization setting on Jenkins, you can store > > credentials in a specific user who the build runs as. It’s somewhat > > primitive at the moment, but I’ve been working on related features lately > > to improve the situation there for more complex CICD scenarios. Jenkins > > pipelines aren’t going away anytime soon unlike SaaS fads sometimes do. > ;) > > Sorry but I don't understand how to apply this so that I could > see GitHub's "actions" pages. > > Regards, > Gilles > > > On Sat, Aug 31, 2019 at 18:37, Gilles Sadowski > > wrote: > > > >> Le sam. 31 août 2019 à 19:22, Gary Gregory a > >> écrit : > >> > > >> > That is what I thinking, using GitHub actions we can keep builds and > >> > sources in one place. Well two places: sources+builds in Apache and > >> GitHub. > >> > It feels like we can remove Travis. > >> > >> I can see this page > >> https://travis-ci.org/apache/commons-bcel > >> without being logged in. > >> Concluding to the opposite. > >> > >> Moreover, not having any control over the evolution of one or the > other's > >> policy, why put all one's eggs in one basket? > >> > >> Gilles > >> > >> > > >> > Gary > >> > > >> > On Sat, Aug 31, 2019, 12:53 Matt Sicker wrote: > >> > > >> > > GitHub Actions are more of a replacement for Travis currently. > >> > > Provided > >> > > you’re not doing anything fancy in your pipelines, it might not > >> > > require > >> > > Jenkins, either. > >> > > > >> > > On Sat, Aug 31, 2019 at 11:17, Stefan Bodewig > >> wrote: > >> > > > >> > > > On 2019-08-31, Gary Gregory wrote: > >> > > > > >> > > > > On Sat, Aug 31, 2019 at 10:58 AM Gilles Sadowski < > >> gillese...@gmail.com > >> > > > > >> > > > > wrote: > >> > > > > >> > > > >> Links returns "404". > >> > > > > >> > > > > Works for me, anyone else? > >> > > > > >> > > > Only works if you are logged in - an probably a member of the > >> > > > apache > >> > > > organization. github returns 404 for links you are not allowed to > >> see. > >> > > > > >> > > > Stefan > >> > > > > >> > > > > - > >> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> > > > For additional commands, e-mail: dev-h...@commons.apache.org > >> > > > > >> > > > -- > >> > > Matt Sicker > >> > > > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> -- > > Matt Sicker > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: Outreachy Program Workshops
Well, if anyone has project ideas or would like to mentor, then yes. I'm avoiding mentoring this round since I'm a coordinator, though I might be mentoring for a Jenkins project anyways. On Tue, 3 Sep 2019 at 16:17, Gilles Sadowski wrote: > > Hi Matt. > > Do you expect something to happen here (at "Commons")? > Suggestions? > > Best regards, > Gilles > > 2019-09-03 22:37 UTC+02:00, Katia Rojas : > > Hello folks, > > > > We are very happy to announce that we are receiving emails from folks > > showing their interest in joining the Outreachy program! > > > > Remember, the deadline to submit your applications is getting closer: > > 2019-Sep-17 23:00 UTC. > > > > To make the process faster and smoothly, we are here to provide some help > > and clarifications! > > > > We are going to organize a workshop to address all your questions: > > > > > >1. > > > >How to scope your project. > >2. > > > >What is this PMC consensus about? => host an Outreachy intern, > >understand the commitment to be a mentor, and ensure we can capture a > >contribution friction log from your interns. > > > > => Get consensus from your project’s PMC about the previous points would > > usually involve a discussion on the dev list about the proposed project, > > resulting in lazy consensus to proceed. > > > >1. > > > >And any other questions that you may have! > > > > > > To do so, please, contact us, the Apache coordinators: "Matt Sicker" < > > boa...@gmail.com>,. "Awasum Yannick" ,. "Katia > > Rojas" . > > > > Providing: > > > > > >1. > > > >Your questions. > >2. > > > >Availability in case you need one to one conference call. > > > > > > Remember, the deadline to submit your applications is getting closer: > > 2019-Sep-17 23:00 UTC. > > > > Looking forward to hearing from you soon! > > > > Cheers, > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Outreachy Program Workshops
I believe Commons was contacted directly with this due to past participation in GSoC. Otherwise, we’ve emailed committers@ along with some specific lists related to GSoC and Outreachy. On Wed, Sep 4, 2019 at 06:44, Gilles Sadowski wrote: > Le mar. 3 sept. 2019 à 23:48, Matt Sicker a écrit : > > > > Well, if anyone has project ideas or would like to mentor, then yes. > > I'm avoiding mentoring this round since I'm a coordinator, though I > > might be mentoring for a Jenkins project anyways. > > We (Alex, Eric, Rob and I) tried something with GSoC but it didn't > work out too well partly due to expectations mismatch. > I think that it would be good that "Commons" be proactive in showing > that we are welcoming new people but to not repeat the same mistakes > we need something more objective than a general principle. > > Regards, > Gilles > > > > > On Tue, 3 Sep 2019 at 16:17, Gilles Sadowski > wrote: > > > > > > Hi Matt. > > > > > > Do you expect something to happen here (at "Commons")? > > > Suggestions? > > > > > > Best regards, > > > Gilles > > > > > > 2019-09-03 22:37 UTC+02:00, Katia Rojas : > > > > Hello folks, > > > > > > > > We are very happy to announce that we are receiving emails from folks > > > > showing their interest in joining the Outreachy program! > > > > > > > > Remember, the deadline to submit your applications is getting closer: > > > > 2019-Sep-17 23:00 UTC. > > > > > > > > To make the process faster and smoothly, we are here to provide some > help > > > > and clarifications! > > > > > > > > We are going to organize a workshop to address all your questions: > > > > > > > > > > > >1. > > > > > > > >How to scope your project. > > > >2. > > > > > > > >What is this PMC consensus about? => host an Outreachy intern, > > > >understand the commitment to be a mentor, and ensure we can > capture a > > > >contribution friction log from your interns. > > > > > > > > => Get consensus from your project’s PMC about the previous points > would > > > > usually involve a discussion on the dev list about the proposed > project, > > > > resulting in lazy consensus to proceed. > > > > > > > >1. > > > > > > > >And any other questions that you may have! > > > > > > > > > > > > To do so, please, contact us, the Apache coordinators: "Matt Sicker" > < > > > > boa...@gmail.com>,. "Awasum Yannick" ,. > "Katia > > > > Rojas" . > > > > > > > > Providing: > > > > > > > > > > > >1. > > > > > > > >Your questions. > > > >2. > > > > > > > >Availability in case you need one to one conference call. > > > > > > > > > > > > Remember, the deadline to submit your applications is getting closer: > > > > 2019-Sep-17 23:00 UTC. > > > > > > > > Looking forward to hearing from you soon! > > > > > > > > Cheers, > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > -- > > 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 > > -- Matt Sicker
Re: Graph status?
n graph at commons and apache. > > > > FYI I currently need the following libraries in a minimal viable setup > > to > > work with the Jena graph api. > > > > jena-base (215kb), jena-core (1.69mb), jena-shaded-guave (2.73mb), > > log4j > > (479kb), slf4j-log (41kb), slf4j-api (12kb) > > > > Marco > > > > On Sat, Sep 7, 2019 at 10:33 PM Romain Manni-Bucau < > > rmannibu...@gmail.com> > > wrote: > > > > > Hi Marco, > > > > > > Had a look to jena for another project and didnt evaluate it here > > for these > > > reasons (happy to be wrong): > > > > > > - dep stack was huge for only graph part (guava shade, some other > > uneeded > > > commons etc, most being excludable but without guarantees in time) > > > - it is not about DAG and therefore misses navigation methods (which > > is > > > what I need in addition to "mutation" methods for the algo i want to > > impl) > > > - it is not the goal of jena so API and core stack can evolve in an > > > undesired manner > > > > > > To mention alternatives, spark, flink, beam, ignite for the few I > > can think > > > about, have something not crazy but still this stack and API issues > > :(. > > > > > > This is how i ended up looking commons, to try to have something > > stable and > > > dep free. > > > > > > Romain > > > > > > > > > Le sam. 7 sept. 2019 à 23:15, Marco Neumann > > a > > > écrit : > > > > > > > I highly recommend to take a look at the Apache Jena project for > > > > inspiration here. It has a very mature graph representationat this > > point: > > > > > > > > https://jena.apache.org/ > > > > > > > > > > > > > > > > > https://jena.apache.org/documentation/javadoc/jena/org/apache/jena/graph/Graph.html > > > > > > > > Jena use triples in the form of to encode the graph > > > > > > > > give it try and make sure to post to us...@jena.apache.org if you > > have > > > any > > > > questions > > > > > > > > enjoy, > > > > Marco > > > > > > > > On Sat, Sep 7, 2019 at 10:30 AM Romain Manni-Bucau < > > > rmannibu...@gmail.com> > > > > wrote: > > > > > > > > > Hi all > > > > > > > > > > What is the status of graph at commons - or apache if we have > > something > > > > > elsewhere? > > > > > > > > > > I found in sandbox that doc > > > > > > > > > > > > > > > > > > > https://commons.apache.org/sandbox/commons-graph/apidocs/org/apache/commons/graph/DirectedGraph.html > > > > > , > > > > > but wonder if we have something live and if not why it failed. > > > > > > > > > > My rational is I started to write some DAG modelization and > > tooling > > > > > (backward browsing in my case) but I see it could be generic so > > wonder > > > if > > > > > it is worse thinking about commons or incubator of if scope is > > too > > > small > > > > > for that and keeping it specific is saner. > > > > > > > > > > Anyone has some pointers? > > > > > > > > > > > > -- > > > > > > > > > > > > --- > > > > Marco Neumann > > > > KONA > > > > > > > > -- > > > > > > > > > > > > --- > > > > Marco Neumann > > > > KONA > > > > > > > > > > > > > -- > > > > > > --- > > Marco Neumann > > KONA > > > > > > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Graph status?
No, it was more of a personal idea so far. I've been doing work in Log4j lately in my free time, so I have no target yet. On Mon, 9 Sep 2019 at 12:20, Romain Manni-Bucau wrote: > > Sounds like convergent. > > Any targetted deadline? > On my side I need a PoC soon - like last week ;) - so will start included > in the happy but happy to catch up after. > Pushed in my todo to hack in sandbox but from scratch works too for me. > > Le lun. 9 sept. 2019 à 18:10, Matt Sicker a écrit : > > > We have scattered graph logic in Jenkins Core as well as the Pipeline > > plugins. If I wanted to use a graph library in Jenkins, it would be > > best to use minimal dependencies because any dependencies included > > with Jenkins tend to get reused by plugins which can cause upgrade > > problems later, especially with libraries that use a lot of > > dependencies (particularly dependencies that don't have as strict of > > API/ABI compatibility guarantees as typical Commons components). > > > > I bring this up because refactoring the graph APIs in Jenkins are a > > loosely defined goal of mine in order to allow for job dependency > > graphs to be queried and potentially manipulated more easily. As you > > can see here [1], we already have dependency hell going on, so in the > > future, I'd like to avoid introducing more unnecessary or hard to > > upgrade dependencies (like Guava or anything from Google it seems; > > "'we'll just increment the major version for every release and call it > > a day" is not a backward compatibility policy). > > > > [1]: > > https://mvnrepository.com/artifact/org.jenkins-ci.main/jenkins-core/2.194 > > > > On Mon, 9 Sep 2019 at 04:40, Romain Manni-Bucau > > wrote: > > > > > > Le lun. 9 sept. 2019 à 11:06, Rob Vesse a écrit : > > > > > > > Playing Devil's advocate: > > > > > > > > I am always curious when folks complain about a "huge" dependency stack > > > > (for a start the term huge is inherently subjective). This is pretty > > much > > > > the reality of the modern OSS ecosystem, people (yourself included) > > try to > > > > avoid reinventing the wheel and want to focus on solving their problem > > > > rather than all the mundane engineering that goes into enabling that. > > > > > > > > While there are legitimate use cases where keeping the dependency stack > > > > minimal is desirable (e.g. embedded computing) for most use cases the > > size > > > > of your dependency stack isn't a major issue. And if it is there are > > tools > > > > that can aggressively optimise this e.g. ProGuard [1] that are in > > common > > > > usage (e.g. the Android build chain incorporates ProGuard by default) > > > > > > > > Could you expand on why you see this as being such a problem? > > > > > > > > > > Yep, there are multiple aspects converging to this requirement: > > > > > > 1. My whole server is 10M + my app specific stack is 3M so adding 10M > > for a > > > graph navigation support would be a killer for the consistency of the app > > > (and not it is not what OSS is, spring does that, not the whole apache > > > projects ;) > > > 2. More your stack is big, harder it is to follow up with CVE and > > > dependencies upgrades, therefore for pure algorithm/logic it is saner to > > > not depend on anything (and some bad habits like relocations breaks tools > > > which can be a disaster if exposed through a server), > > > 3. In terms of sharing, any element of a stack should at least be > > > understood in a team, here again, more you have, slower you will be or > > you > > > will miss things. > > > 4. This logic part will be something highly transferred in clusters so > > > smaller it is, better it is (and yes transfered as binaries, not only > > > instances). > > > 5. Dependency conflicts can be a mess (not here, but since I'm listing > > the > > > general approach I'm mentionning it) > > > > > > I can hear some people don't care of these points but I have to take care > > > of them to ensure I keep a good velocity and control over time of my > > > deliveries with a good quality (accross security, responsiveness etc) so > > > I'm really concerned about it. > > > > > > > > > > > > > > There's clearly a trade off between size of dependency stack and how >
Re: [report][draft] Board report September 2019
That looks like the highest committer to PMC ratio I've seen so far, but I haven't paid that close attention yet. What a massive list of committers! On Wed, 11 Sep 2019 at 13:42, Gary Gregory wrote: > > Hi All: > Here is the draft for the board report. Any feedback welcome: > -- > ## Description: > The mission of Apache Commons is the creation and maintenance of Java > focused > reusable libraries and components > > ## Issues: > There are no issues requiring board attention. > > ## Membership Data: > Apache Commons was founded 2007-06-19 (12 years ago) > There are currently 148 committers and 39 PMC members in this project. > The Committer-to-PMC ratio is roughly 5:2. > > Community changes, past quarter: > - No new PMC members. Last addition was Alex Herbert on 2019-05-09. > - No new committers. Last addition was Alex Herbert on 2019-01-30. > > ## Project Activity: > The project is healthy and active and released 7 components > in this reporting period: > - BEANUTILS-1.9.4 was released on 2019-08-14. > - BUILD-PLUGIN-1.11 was released on 2019-09 > - COMPRESS 1.19 was released on 2019-08-27. > - DAEMON-1.2.1 was released on 2019-09-09. > - RELEASE-PLUGIN-1.7 was released on 2019-09-02. > - TEXT-1.8 was released on 2019-09-02. > - VFS-2.4.1 was released on 2019-08-14. > > ## Community Health: > We are handling the mailing lists, JIRA tickets, GitHub PRs in a timely > manner. > -- -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [report][draft] Board report September 2019
Yeah, I was kind of expecting the committer-to-PMC ratio to be infinity or close to it. On Wed, 11 Sep 2019 at 14:15, sebb wrote: > > On Wed, 11 Sep 2019 at 19:42, Gary Gregory wrote: > > > > Hi All: > > Here is the draft for the board report. Any feedback welcome: > > -- > > ## Description: > > The mission of Apache Commons is the creation and maintenance of Java > > focused > > reusable libraries and components > > > > ## Issues: > > There are no issues requiring board attention. > > > > ## Membership Data: > > Apache Commons was founded 2007-06-19 (12 years ago) > > There are currently 148 committers and 39 PMC members in this project. > > The Committer-to-PMC ratio is roughly 5:2. > > Not sure the committer information is correct. > > Since Commons uses universal commit, there are in theory many more committers. > Do we always update the LDAP committer group when people commit code? > I don't think we do, unless the karma is needed: > Commons LDAP committer group karma is needed to update the production website > > So I think the figures above are misleading and should be dropped or > at least qualified. > > > Community changes, past quarter: > > - No new PMC members. Last addition was Alex Herbert on 2019-05-09. > > - No new committers. Last addition was Alex Herbert on 2019-01-30. > > > > ## Project Activity: > > The project is healthy and active and released 7 components > > in this reporting period: > > - BEANUTILS-1.9.4 was released on 2019-08-14. > > - BUILD-PLUGIN-1.11 was released on 2019-09 > > - COMPRESS 1.19 was released on 2019-08-27. > > - DAEMON-1.2.1 was released on 2019-09-09. > > - RELEASE-PLUGIN-1.7 was released on 2019-09-02. > > - TEXT-1.8 was released on 2019-09-02. > > - VFS-2.4.1 was released on 2019-08-14. > > > > ## Community Health: > > We are handling the mailing lists, JIRA tickets, GitHub PRs in a timely > > manner. > > -- > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [report][draft] Board report September 2019
I don't think I'm a committer, though I've used the commit bit.
On Wed, 11 Sep 2019 at 14:26, Gary Gregory wrote:
>
> On Wed, Sep 11, 2019 at 3:15 PM sebb wrote:
>
> > On Wed, 11 Sep 2019 at 19:42, Gary Gregory wrote:
> > >
> > > Hi All:
> > > Here is the draft for the board report. Any feedback welcome:
> > > --
> > > ## Description:
> > > The mission of Apache Commons is the creation and maintenance of Java
> > > focused
> > > reusable libraries and components
> > >
> > > ## Issues:
> > > There are no issues requiring board attention.
> > >
> > > ## Membership Data:
> > > Apache Commons was founded 2007-06-19 (12 years ago)
> > > There are currently 148 committers and 39 PMC members in this project.
> > > The Committer-to-PMC ratio is roughly 5:2.
> >
> > Not sure the committer information is correct.
> >
> > Since Commons uses universal commit, there are in theory many more
> > committers.
> > Do we always update the LDAP committer group when people commit code?
> > I don't think we do, unless the karma is needed:
> > Commons LDAP committer group karma is needed to update the production
> > website
> >
> > So I think the figures above are misleading and should be dropped or
> > at least qualified.
> >
>
> Sure, but who outside of Commons has actually used this privilege? I'll
> rephrase anyway as:
>
> {quote}
> ## Membership Data:
> Apache Commons was founded 2007-06-19 (12 years ago)
> The committer count and Committer-to-PMC ratio offered by the Apache
> reporting tool is misleading since Apache Commons is open to all Apache
> Committer.
> {quote}
>
> Gary
>
>
> >
> > > Community changes, past quarter:
> > > - No new PMC members. Last addition was Alex Herbert on 2019-05-09.
> > > - No new committers. Last addition was Alex Herbert on 2019-01-30.
> > >
> > > ## Project Activity:
> > > The project is healthy and active and released 7 components
> > > in this reporting period:
> > > - BEANUTILS-1.9.4 was released on 2019-08-14.
> > > - BUILD-PLUGIN-1.11 was released on 2019-09
> > > - COMPRESS 1.19 was released on 2019-08-27.
> > > - DAEMON-1.2.1 was released on 2019-09-09.
> > > - RELEASE-PLUGIN-1.7 was released on 2019-09-02.
> > > - TEXT-1.8 was released on 2019-09-02.
> > > - VFS-2.4.1 was released on 2019-08-14.
> > >
> > > ## Community Health:
> > > We are handling the mailing lists, JIRA tickets, GitHub PRs in a timely
> > > manner.
> > > --
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
--
Matt Sicker
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: New Sub-project Proposal.
0)
> > > > >
> > > > > and build the BloomFilter
> > > > > BloomFilter filter1 = proto.create( config1 )
> > > > >
> > > > > I can use that filter to determine if the person is in a collection
> > of
> > > > > 1x10^7 items. The implementation of that collection could be
> > multiple
> > > > > buckets of 1x10^4 items with a collision rate of 5x10^3 items. To
> > > check
> > > > > that I create an appropriate FilterConfig
> > > > > FilterConfig config2 = new FilterConfig( 1, 5000 )
> > > > >
> > > > > and then create the proper bloom filter
> > > > > BloomFilter filter2 = proto.create( config2 )
> > > > >
> > > >
> > > > With my above attempt at an alternative API, we'd have (untested):
> > > >
> > > > BloomFilter.Builder proto = BloomFilter
> > > > .with("Claude")
> > > > .with("Warren")
> > > > .with("brown").
> > > > .with("silver");
> > > >
> > > > BloomFilter filter1 = proto.create(config1);
> > > > BloomFilter filter2 = proto.create(config2);
> > > >
> > > >
> > > > IIUC, in your current implementation of "ProtoBloomFilter", there
> > > > is a side-effect of "build()" (i.e. the call to "clear()"); thus
> > calling
> > > > "build()" twice will not yield the same result. I don't think that's
> > > > a desirable feature.
> > > >
> > > > Regards,
> > > > Gilles
> > > >
> > > > > Claude
> > > > >
> > > > >
> > > > > On Fri, Sep 13, 2019 at 2:22 PM Gilles Sadowski <
> > gillese...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > > > [...]
> > > > > > >
> > > > > > > Gilles,
> > > > > > >
> > > > > > > Take a look at the PR, I added comments to allow the PR to have 0
> > > deps.
> > > > > > >
> > > > > > > Gary
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > IMO, the package should be named "bloomfilter" (without "s").
> > > > > > Naming seems inconsistent in [Collections]: Some (package)
> > > > > > names are singular, other plural.
> > > > > >
> > > > > > * Indent must be 4 spaces.
> > > > > > * All fields and methods must be commented.
> > > > > > * "FilterConfig" contains a "main" method.
> > > > > > * Local variables and fields must be declared "final" whenever
> > > constant.
> > > > > > * Some methods are declared "final", others not.
> > > > > > * "BloomFilter" should be made immutable.
> > > > > > * "BloomFilter" could do without a second constructor:
> > "FilterConfig"
> > > > > > should have a method that returns a "BitSet".
> > > > > > * "BloomFilter" must make a defensive copy of its "bitSet"
> > argument.
> > > > > > * What's the difference between "match" and "equals"?
> > > > > > * Why is "STORED_SIZE" public?
> > > > > > * "Utils" classes should be avoided.
> > > > > > * Hash function should be imported/shaded from "Commons Codec"
> > > > > > (and defined there if missing).
> > > > > > * Constructor(s) should be private (instantiation through factory
> > > > > > methods (cf. ValJO).
> > > > > > * "Serializable" should be avoided.
> > > > > > * The "update" methods are missing explanations (or reference)
> > about
> > > > > > their purpose. Also, it seems that "update" and "build" are
> > > redundant.
> > > > > > * Does "getLog" return a standard value? If so, the reference
> > should
> > > > > > appear in the Javadoc (not just as code comment).
> > > > > > * What is the purpose of method "asBitSet()"?
> > > > > > * (IIUC) "ProtoBloomFilter" should be renamed "BloomFilterFactory".
> > > > > > "ProtoBloomFilterBuilder" should be a static inner class of that
> > > > > > factory.
> > > > > >
> > > > > > 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
> > >
> > >
> >
>
>
> --
> I like: Like Like - The likeliest place on the web
> <http://like-like.xenei.com>
> LinkedIn: http://www.linkedin.com/in/claudewarren
--
Matt Sicker
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1
> > Why not create them in a different output directory under target? > > > >>>> The src zip also contains: > > >>>> src/native/unix/configure > > >>>> AIUI this is a generated file; I would expect it to be in the binary > > >>>> artifact, if anywhere > > > > No. The configure script is generated but it *is* meant to be in the > > source distribution. Without it, building from source is more difficult. > > I forgot this for the 1.2.0 release and there were complaints as a > result. > > Is the config file OS and version independent? > If not, then it might be confusing. > > Why is it not in the Git repo? > > > >>>> Also there are some Git files missing from the src zip. > > >>>> Not sure if that is intentional? > > >>>> > > >>>> CONTRIBUTING.md > > >>>> HOWTO-RELEASE.txt > > >>>> README.md > > >>>> > > >>> > > >>> I certainly would expect CONTRIBUTING.md and README.md to be in the > src > > >>> zip, not quite a blocker for me. I am more concerned that we are > including > > >>> all of these OBJ and EXE files. > > > > The .md files are generated but I agree they should be in the source > > distribution. I'll see about getting them added. > > > > The HOWTO_RELEASE.txt is perhaps more debatable but on balance I think > > it should be there too. > > Does no harm, and makes it easier to compare source tag with source bundle. > > > 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 > > -- Matt Sicker
Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1
I’m sort of going off of what GNU projects do (they use autotools for any C projects), but the common ‘./configure && make && sudo make install’ snippet is almost timeless. On Sun, Sep 29, 2019 at 13:01, sebb wrote: > On Sun, 29 Sep 2019 at 17:21, Matt Sicker wrote: > > > > Projects that have a configure script usually include that in the source > > distribution but not in the source repository (at least for autotools > > users). > > But is that correct? > > Surely the source archive should only contain source that is in the source > repo? > > Provenance of source is vital: i.e. each file can be found in SVN/Git. > > > On Sat, Sep 28, 2019 at 17:41, sebb wrote: > > > > > On Sat, 28 Sep 2019 at 17:42, Mark Thomas wrote: > > > > > > > > On 28/09/2019 17:06, Gary Gregory wrote: > > > > > On Sat, Sep 28, 2019 at 12:04 PM Gary Gregory < > garydgreg...@gmail.com> > > > > > wrote: > > > > > > > > > >> I can confirm that if I delete all of: > > > > >> > > > > >> src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE > > > > >> src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE > > > > >> src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE > > > > >> > > > > >> I can build without errors but with warnings: > > > > >> > > > > >> .\..\..\apps\prunsrv\prunsrv.c(323): warning C4996: '_wfopen': > This > > > > >> function or variable may be unsafe. Consider using _wfopen_s > instead. > > > To > > > > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help > for > > > > >> details. > > > > >> C:\Program Files (x86)\Windows > > > > >> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130): note: see > > > > >> declaration of '_wfopen' > > > > >> .\..\..\apps\prunsrv\prunsrv.c(347): warning C4996: '_wfopen': > This > > > > >> function or variable may be unsafe. Consider using _wfopen_s > instead. > > > To > > > > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help > for > > > > >> details. > > > > >> C:\Program Files (x86)\Windows > > > > >> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130): note: see > > > > >> declaration of '_wfopen' > > > > >> .\..\..\apps\prunsrv\prunsrv.c(1339): warning C4996: '_snprintf': > This > > > > >> function or variable may be unsafe. Consider using _snprintf_s > > > instead. To > > > > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help > for > > > > >> details. > > > > >> C:\Program Files (x86)\Windows > > > > >> Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see > > > declaration of > > > > >> '_snprintf' > > > > >> .\..\..\apps\prunsrv\prunsrv.c(1341): warning C4996: '_snprintf': > This > > > > >> function or variable may be unsafe. Consider using _snprintf_s > > > instead. To > > > > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help > for > > > > >> details. > > > > >> C:\Program Files (x86)\Windows > > > > >> Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see > > > declaration of > > > > >> '_snprintf' > > > > >> rc /l 0x409 /d "NDEBUG" /i ".\..\..\include" /fo > > > > >> WINXP_X86_EXE_RELEASE\prunsrv.res .\..\../apps/prunsrv/prunsrv.rc > > > > >> > > > > > > > > > > FWIW, using: > > > > > > > > > > Microsoft (R) C/C++ Optimizing Compiler Version 19.21.27702.2 for > x86 > > > > > Copyright (C) Microsoft Corporation. All rights reserved. > > > > > > > > Since I am going to re-tag for an RC2 (see below) I'll see what I > can do > > > > to clean up those warnings. > > > > > > > > >> On Sat, Sep 28, 2019 at 11:53 AM Gary Gregory < > garydgreg...@gmail.com > > > > > > > > >> wrote: > > > > >>> On Sat, Sep 28, 2019 at 10:03 AM sebb wrote: > > > > >>>> On Sat, 28 Sep 2019 at 13:39, Gary Gregory < > garydgreg...@gmail.
Re: [ALL] Update to commons security page
What we’ve been doing in Jenkins Security about this has been to request demonstrable exploits only. Output from an automated tool is not a security vulnerability report. Plus, these tools generally don’t understand greater context and usage of code, so you’ll get false positives that require someone familiar with the code base to confirm or deny. With a huge report, that can be a huge waste of time. On Tue, Oct 15, 2019 at 05:55, sebb wrote: > On Tue, 15 Oct 2019 at 11:03, Claude Warren wrote: > > > > If the style is to rely on external code to do input validation, then I > > think that should be in the javadocs as well as on the page you mention. > > Perhaps I phrased it wrong. > > What I meant was that the code generally does what it is told to do. > > e.g. a delete_tree(path) method is not going to prevent you from using > path='/' > > Commons cannot in general validate such parameters. > > > Claude > > > > On Tue, Oct 15, 2019 at 10:59 AM sebb wrote: > > > > > It might be useful to add a note to the commons security page about > > > automated vulnerability checkers. > > > > > > These tend to produce a lot of false positives and may report items > > > which could never be a security issue (e.g. poor code style, dead > > > code). > > > > > > Even if the issue is potentially a vulnerability, it often depends on > > > the context. > > > This is particularly true of Commons - the code generally relies on > > > the application to do validation of input parameters. > > > > > > Thoughts? > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > -- > > I like: Like Like - The likeliest place on the web > > <http://like-like.xenei.com> > > LinkedIn: http://www.linkedin.com/in/claudewarren > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [codec] No snapshots built automatically
I believe the PMC Chair can grant Jenkins permissions to people. On Sat, 23 Nov 2019 at 15:42, Gilles Sadowski wrote: > > Hello. > > >> [...] > > >> But I cannot see where to configure it, or if I have permissions to > > >> do so. > > > > > > Are you logged in? > > > > I can log in. But I cannot see any options that would indicate that I have > > admin rights. > > When I log in, what changes is the number of options in the (left) menu. > The first entry there is "New Item". > If you don't see it when logged in, that's probably worth inquiring at INFRA. > > > > > When I click the 'Open Blue Ocean’ link to change the view the top bar has > > a Pipelines tab but not an Administration tab. If I click Pipelines I do > > not see a ’New’ option. This is not what I expect given the documentation > > on how to use the Blue Ocean pages [1]. > > Never used this... > > Best, > Gilles > > > > > If you have these options it seems I do not have privileges. > > > > [1] https://jenkins.io/doc/book/blueocean/creating-pipelines/ > > <https://jenkins.io/doc/book/blueocean/creating-pipelines/> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collection] NPE vs IAE in org.apache.commons.collections4.CollectionUtils
+1 for NPE. New Java versions are supposed to even auto generate useful error messages for them, too. On Thu, Dec 5, 2019 at 10:22 Gary Gregory wrote: > Hi All: > > org.apache.commons.collections4.CollectionUtils contains a mix of checking > for null inputs by throwing NullPointerExceptions in some methods and > IllegalArgumentExceptions in others. > > I propose we standardized to NPE simply because the JRE provides > Objects.requireNonNull() just for this purpose. > > Gary > -- Matt Sicker
Re: [commons-lang] branch master updated: Use Collection#toArray(new T[0]) instead of a presized array as it is faster on modern JVMs.
n/java/org/apache/commons/lang3/reflect/MethodUtils.java
> > >>>>> index bbd5019..491470d 100644
> > >>>>> --- a/src/main/java/org/apache/commons/lang3/reflect/MethodUtils.java
> > >>>>> +++ b/src/main/java/org/apache/commons/lang3/reflect/MethodUtils.java
> > >>>>> @@ -878,7 +878,7 @@ public class MethodUtils {
> > >>>>>final boolean
> > >>>>> searchSupers, final boolean ignoreAccess) {
> > >>>>>final List annotatedMethodsList =
> > >>>>> getMethodsListWithAnnotation(cls, annotationCls, searchSupers,
> > >>>>>ignoreAccess);
> > >>>>> -return annotatedMethodsList.toArray(new
> > >>>>> Method[annotatedMethodsList.size()]);
> > >>>>> +return annotatedMethodsList.toArray(new Method[0]);
> > >>>>>}
> > >>>>>
> > >>>>>/**
> > >>>>> diff --git
> > >>>> a/src/main/java/org/apache/commons/lang3/reflect/TypeUtils.java
> > >>>>> b/src/main/java/org/apache/commons/lang3/reflect/TypeUtils.java
> > >>>>> index 2a6ccd0..f9df8c6 100644
> > >>>>> --- a/src/main/java/org/apache/commons/lang3/reflect/TypeUtils.java
> > >>>>> +++ b/src/main/java/org/apache/commons/lang3/reflect/TypeUtils.java
> > >>>>> @@ -1149,7 +1149,7 @@ public class TypeUtils {
> > >>>>>}
> > >>>>>}
> > >>>>>
> > >>>>> -return types.toArray(new Type[types.size()]);
> > >>>>> +return types.toArray(new Type[0]);
> > >>>>>}
> > >>>>>
> > >>>>>/**
> > >>>>> diff --git
> > >>>> a/src/main/java/org/apache/commons/lang3/text/StrTokenizer.java
> > >>>>> b/src/main/java/org/apache/commons/lang3/text/StrTokenizer.java
> > >>>>> index c9ab666..97fae7d 100644
> > >>>>> --- a/src/main/java/org/apache/commons/lang3/text/StrTokenizer.java
> > >>>>> +++ b/src/main/java/org/apache/commons/lang3/text/StrTokenizer.java
> > >>>>> @@ -604,10 +604,10 @@ public class StrTokenizer implements
> > >>>>> ListIterator, Cloneable {
> > >>>>>if (chars == null) {
> > >>>>>// still call tokenize as subclass may do some
> > work
> > >>>>>final List split = tokenize(null, 0, 0);
> > >>>>> -tokens = split.toArray(new String[split.size()]);
> > >>>>> +tokens = split.toArray(new String[0]);
> > >>>>>} else {
> > >>>>>final List split = tokenize(chars, 0,
> > >>>>> chars.length);
> > >>>>> -tokens = split.toArray(new String[split.size()]);
> > >>>>> +tokens = split.toArray(new String[0]);
> > >>>>>}
> > >>>>>}
> > >>>>>}
> > >>>>> diff --git
> > >>>>>
> > a/src/main/java/org/apache/commons/lang3/time/DurationFormatUtils.java
> > >>>>>
> > b/src/main/java/org/apache/commons/lang3/time/DurationFormatUtils.java
> > >>>>> index 83af2e0..4a75237 100644
> > >>>>> ---
> > >>>> a/src/main/java/org/apache/commons/lang3/time/DurationFormatUtils.java
> > >>>>> +++
> > >>>> b/src/main/java/org/apache/commons/lang3/time/DurationFormatUtils.java
> > >>>>> @@ -564,7 +564,7 @@ public class DurationFormatUtils {
> > >>>>>if (inLiteral) { // i.e. we have not found the end of the
> > >>>> literal
> > >>>>>throw new IllegalArgumentException("Unmatched quote in
> > >>>>> format: " + format);
> > >>>>>}
> > >>>>> -return list.toArray(new Token[list.size()]);
> > >>>>> +return list.toArray(new Token[0]);
> > >>>>>}
> > >>>>>
> > >>>>>
> > >>>>>
> > >>
> > //---
> > >>>>> diff --git
> > >>>>> a/src/main/java/org/apache/commons/lang3/time/FastDatePrinter.java
> > >>>>> b/src/main/java/org/apache/commons/lang3/time/FastDatePrinter.java
> > >>>>> index a5edb28..888d3fb 100644
> > >>>>> ---
> > a/src/main/java/org/apache/commons/lang3/time/FastDatePrinter.java
> > >>>>> +++
> > b/src/main/java/org/apache/commons/lang3/time/FastDatePrinter.java
> > >>>>> @@ -160,7 +160,7 @@ public class FastDatePrinter implements
> > >> DatePrinter,
> > >>>>> Serializable {
> > >>>>> */
> > >>>>>private void init() {
> > >>>>>final List rulesList = parsePattern();
> > >>>>> -mRules = rulesList.toArray(new Rule[rulesList.size()]);
> > >>>>> +mRules = rulesList.toArray(new Rule[0]);
> > >>>>>
> > >>>>>int len = 0;
> > >>>>>for (int i=mRules.length; --i >= 0; ) {
> > >>>>> diff --git
> > >>>>>
> > >>
> > a/src/test/java/org/apache/commons/lang3/concurrent/EventCountCircuitBreakerTest.java
> > >>
> > b/src/test/java/org/apache/commons/lang3/concurrent/EventCountCircuitBreakerTest.java
> > >>>>> index b3fb5cf..2819006 100644
> > >>>>> ---
> > >>>>>
> > >>
> > a/src/test/java/org/apache/commons/lang3/concurrent/EventCountCircuitBreakerTest.java
> > >>>>> +++
> > >>>>>
> > >>
> > b/src/test/java/org/apache/commons/lang3/concurrent/EventCountCircuitBreakerTest.java
> > >>>>> @@ -407,7 +407,7 @@ public class EventCountCircuitBreakerTest {
> > >>>>> */
> > >>>>>public void verify(final Boolean... values) {
> > >>>>>assertArrayEquals(values,
> > >>>>> -changedValues.toArray(new
> > >>>>> Boolean[changedValues.size()]));
> > >>>>> +changedValues.toArray(new Boolean[0]));
> > >>>>>}
> > >>>>>}
> > >>>>>}
> > >>>>>
> > >>>>>
> > >>
> > >> -
> > >> 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
> >
> >
--
Matt Sicker
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-codec] branch master updated: Change AssertionError to IllegalStateException
Aren’t Errors supposed to be fatal exceptions that are generally only
caught by exception handlers rather than by calling code? Think
OutOfMemoryError or StackOverflowError.
On Sat, Dec 28, 2019 at 11:35 Miguel Munoz
wrote:
> I can't look at the code right now, but I would use an
> IllegalStateException if the problem is caused by a user error. I would use
> an AssertionError if the problem is caused by a defect in the
> implementation.
>
> -- Miguel Muñoz
> On Friday, December 27, 2019, 5:45:58 PM PST, Gary Gregory <
> garydgreg...@gmail.com> wrote:
>
> On Fri, Dec 27, 2019 at 8:17 PM wrote:
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > aherbert pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/commons-codec.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> > new 1cf4d19 Change AssertionError to IllegalStateException
> > 1cf4d19 is described below
> >
> > commit 1cf4d19069c64d0493f8b92178ffdb728c0c0ac2
> > Author: Alex Herbert
> > AuthorDate: Sat Dec 28 01:17:17 2019 +
> >
> >Change AssertionError to IllegalStateException
> > ---
> > src/main/java/org/apache/commons/codec/digest/MurmurHash3.java | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git
> > a/src/main/java/org/apache/commons/codec/digest/MurmurHash3.java
> > b/src/main/java/org/apache/commons/codec/digest/MurmurHash3.java
> > index d4a95ea..5d9aa9d 100644
> > --- a/src/main/java/org/apache/commons/codec/digest/MurmurHash3.java
> > +++ b/src/main/java/org/apache/commons/codec/digest/MurmurHash3.java
> > @@ -1054,7 +1054,7 @@ public final class MurmurHash3 {
> > k = orBytes(unprocessed[0], unprocessed[1],
> > unprocessed[2], data[offset]);
> > break;
> > default:
> > -throw new AssertionError("Unprocessed length should
> > be 1, 2, or 3: " + unprocessedLength);
> > +throw new IllegalStateException("Unprocessed length
> > should be 1, 2, or 3: " + unprocessedLength);
> > }
> > hash = mix32(k, hash);
> > // Update the offset and length
> >
>
> That seems clearer, thanks.
>
> This seems like the kind of code we might want fuzz test. It seems
> quite unlikely otherwise we'd hit this case. I also wonder if
>
> Thoughts?
>
> I see in several places:
>
> // Note: This fails to apply masking using 0xL to the seed.
>
> Shouldn't this be in the Javadoc?
>
> Gary
>
--
Matt Sicker
Re: [All] Do we want to apply for "mentored" contributions?
I’d honestly expect that several components here are prime candidates for a more student-heavy audience, particularly the more academic-aligned components like the math ones in particular. The components are also low level enough to not require experience in any specific frameworks which is nice. I think the difficult part is simply curating enough starter tasks for one or more applicants to complete in order to choose an intern. On Tue, Feb 4, 2020 at 05:47 Gilles Sadowski wrote: > Hello. > > Is "Commons" willing to set up itself for welcoming new > people who, in order to contribute to the projects, might > need more support than the usual asynchronous review > of patches? > > The ASF participates in GSoC[1] and Outreachy[2] and > some Apache projects seem well prepared for dealing with > the mentoring requirements and application selection process. > > Last year, we[3] participated in GSoC, with mitigated results. > Maybe it was partly due to the lack of experience with these > programs, especially on how to gauge the candidates (wrt > to the expected benefit for the project). > > Some people start to ask questions about their eventual > application.[4][5] > Is "Commons" too complicated for the target audience of > those initiatives? > > Regards, > Gilles > > [1] https://summerofcode.withgoogle.com/ > [2] https://www.outreachy.org/ > [3] Rob Tompkins, Eric Barnhill, Alex Herbert, and I. > [4] https://markmail.org/message/n5prdwkaukw5ji37 > [5] > https://issues.apache.org/jira/browse/NUMBERS-70?focusedCommentId=17028479&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17028479 > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [all] How PRs could be better
Let's just say if you can manage to generically solve this problem, you should be nominated for the programming equivalent of a Nobel. On Thu, 20 Feb 2020 at 10:36, Xu Jin wrote: > > It is hard for github to detect what code is test... > Not all players follows the rule to puting tests into /test/java... > If you really want this feature maybe we shall write a maven plugin for > loading tests from other version of a same project. > > > 发件人: Gary Gregory > 发送时间: 2020年2月20日 21:52 > 收件人: Commons Developers List > 主题: [all] How PRs could be better > > Hi All: > > I wonder if any of you have an ideas regarding the following. > > When looking at _some_ PRs (that are green on GitHub, build with tests and > other checks passing, able merge OK), I like to apply only the test changes > locally and verify that the main code fails. Then I continue my > evaluation. Obviously if a new or modified test passes, the test or main > change is no good. So yes, a new test for new main code would not even > compile and that's OK. > > It think it would be great if GH could be made to do this two step for us: > - The tests should fail if only the test changes are applied, if not the PR > is red. > - If the tests fail, then GH can evaluate the whole PR. > > How the tests fail and where I'll leave aside for now. > > Thoughts? > > Gary -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-configuration] branch master updated: [CONFIGURATION-784] Javadoc improvements.
Definitely gotta be a line ending issue. This has happened in log4j’s repo before. On Sat, Mar 7, 2020 at 09:21 Oliver Heger wrote: > > > Am 06.03.20 um 23:23 schrieb Gary Gregory: > > What happened here? The _whole_ file was replaced? > No idea. A line-ending issue? I am on Linux. > > Oliver > > > > > Gary > > > > On Fri, Mar 6, 2020 at 3:35 PM wrote: > > > >> This is an automated email from the ASF dual-hosted git repository. > >> > >> oheger pushed a commit to branch master > >> in repository > >> https://gitbox.apache.org/repos/asf/commons-configuration.git > >> > >> > >> The following commit(s) were added to refs/heads/master by this push: > >> new 737c0a7 [CONFIGURATION-784] Javadoc improvements. > >> 737c0a7 is described below > >> > >> commit 737c0a7124ddd96bf1703f7a1d56be5996b4bbb7 > >> Author: oheger > >> AuthorDate: Fri Mar 6 21:34:48 2020 +0100 > >> > >> [CONFIGURATION-784] Javadoc improvements. > >> > >> Adapted description in changes.xml. > >> --- > >> src/changes/changes.xml| 5268 > >> ++-- > >> .../commons/configuration2/YAMLConfiguration.java |2 +- > >> 2 files changed, 2635 insertions(+), 2635 deletions(-) > >> > >> diff --git a/src/changes/changes.xml b/src/changes/changes.xml > >> index 2407e6a..a897329 100644 > >> --- a/src/changes/changes.xml > >> +++ b/src/changes/changes.xml > >> @@ -1,2634 +1,2634 @@ > >> - > >> - > >> - > >> - > >> -Apache Commons Configuration Release Notes > >> -Apache Commons > >> Community > >> - > >> - > >> - > >> - >> - description="Minor release with new features and updated > >> dependencies."> > >> - >> due-to="Gary Gregory"> > >> -Single argument DataConfiguration APIs always create empty > arrays. > >> - > >> - >> due-to="Gary Gregory"> > >> -Use variable arguments. > >> - > >> - > >> -Update ]com.puppycrawl.tools:checkstyle from 8.24 to 8.25. > >> - > >> - >> due-to="Gary Gregory"> > >> -Update com.fasterxml.jackson.core:jackson-databind from 2.9.9 > to > >> 2.10.0. > >> - > >> - >> due-to="Gary Gregory"> > >> -Refactor XMLConfiguration.write(Writer) to add > >> XMLConfiguration.write(Writer, Transformer). > >> - > >> - >> due-to="Gary Gregory"> > >> -NullPointerException in XMLConfiguration#createTransformer() > when > >> no FileLocator is set. > >> - > >> - >> due-to="Gary Gregory"> > >> -XMLConfiguration#write does not indent XML elements. > >> - > >> - >> due-to="Gary Gregory"> > >> -Update com.fasterxml.jackson.core:jackson-databind 2.10.0 -> > >> 2.10.1. > >> - > >> - > >> -[test] org.easymock:easymock 4.0.2 -> 4.1. > >> - > >> - >> due-to="Dan Dragut"> > >> -User's Guide > Properties files > Saving - small > >> documentation bugs #41. > >> - > >> - >> due-to="Gary Gregory"> > >> -Update Apache Commons VFS from 2.4.1 to 2.5.0. > >> - > >> - >> due-to="Gary Gregory"> > >> -Update Apache Commons VFS from 2.5.0 to 2.6.0. > >> - > >> - >> due-to="Gary Gregory"> > >> -Update optional Apache Commons Codec from 1.13 to 1.14. > >> - > >> - > >> -Update tests from JUnit 4.12 to 4.13. > >> - > >> - >> due-to="Gary Gregory"> > >> -Update optional jackson-databind from 2.10.1 to 2.10.2. > >> - > >> - >> due-to="Gary Gregory"> > >> -Update com.fasterxml.jackson.core:jackson-databind from 2.10.2 > to > >> 2.10.3. > >> - > >> - >> due-to="Gary Gregory"> > >> -Update org.yaml:snakeyaml from 1.25 to 1.26. > >> - > >> - >> due-to="Gary Gregory"> > >> -Update org.springframework:spring-* from 4.3.25.RELEASE to > >> 4.3.26.RELEASE. > >> - > >> - > >> - > >> - >> - description="Minor release with new features and updated > >> dependencies."> > >> - >> due-to="Jason Pickens, Gary Gregory, Emmanuel Bourg"> > >> -XMLPropertyListConfiguration cannot set arrays in the correct > >> plist form. > >> - > >> - >> due-to="Gary Gregory"> > >> -Update Apache Commons Text from 1.6 to 1.7. > >> - > >> - >> due-to="Gary Gregory"> > >> -Update Apache Commons VFS from 2.3 to 2.4.1. > >> - > >> - >> due-to="Gary Gregory"> > >> -Update Apache Commons Text from 1.7 to 1.8. > >> - > >> - > >> -Fix Javadoc for > >> > org.apache.commons.configuration2.PropertiesConfiguration.getIncludeOptional(). > >> - > >> - > >> -Document "includeOptional" on the site. > >> - > >> - >> due-to="Gary Gregory"> > >> -[CVE-2014-0114] Update Apache Commons BeanUtils from 1.9.3 to > >> 1.9.4. > >> - > >> - > >> -Fix syntax in user guide documentation #33. > >> - > >> - >> d
Re: [crypto] Help Releasing new Commons Crypto
t; and, > > > > more importantly IMO, > > > > 2) We provide a better and sounder foundation for future changes, > > > allowing > > > > developers to make changes with less worry of introducing regression > > > bugs. > > > > > > > > Cheers, > > > > Gary > > > > > > > > > > > > > > > > > > Still, I've seen this error pop up in Travis multiple times now for > > > > > the > > > > > repo: > > > > > > > > > > 3040[ERROR] > > > > > testGcmTamperedData(org.apache.commons.crypto.cipher.GcmCipherTest) > > > > > Time elapsed: 0.019 s <<< ERROR! > > > > > 3041java.lang.Exception: Unexpected exception, > > > > > expected but > > > > > was > > > > > 3042 at > > > > > > > > org.apache.commons.crypto.cipher.GcmCipherTest.testGcmTamperedData(GcmCipherTest.java:224) > > > > > > > > > > Is that an error in commons-crypto, or something up with the Travis CI > > > > > env? I haven't seen it on my dev environments. > > > > > > > > > > -Geoff > > > > > > > > > > - > > > > > 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 > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LANG] Porting to Kotlin
This sounds similar to our Log4j Kotlin API. It’s an adapter library to integrate with Kotlin-specific features or APIs (they provide a mini standard library on top of Java like how Groovy does). On Sun, May 10, 2020 at 09:54 Gilles Sadowski wrote: > Hi. > > Le dim. 10 mai 2020 à 15:34, Isira Seneviratne a > écrit : > > > > I hope my answer was helpful. If you need any more information, please > let > > me know. > > Please explain, by example, how we would go in order to provide a Kotlin > release? > IIUC, your PR does not cover all of [Lang] (?). > Might be worth posting in a new thread (with the "[ALL]" prefix). > > Thanks, > Gilles > > > > On Sun, May 10, 2020, 7:03 PM Isira Seneviratne > > wrote: > > > > > > > > > > > On Sun, May 10, 2020, 6:55 PM Gilles Sadowski > > > wrote: > > > > > >> Hi. > > >> > > >> In what consists the "porting"? Could you give an example? > > >> > > > > > > Of course. > > > > > > Extension functions and properties are a language feature of Kotlin, > which > > > allow a function/property to be called from a variable as if it was > part of > > > the original class declaration: > > > https://kotlinlang.org/docs/reference/extensions.html > > > > > > > > >> If it's straightforward and can be automated, it might be worth > > >> creating the port for all the Commons components (as part of > > >> the release) in a move that can potentially expand our team of > > >> developers (if Kotlin programmers are willing to participate to > > >> the "upstream" Java project, of course). > > >> > > >> 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 > > -- Matt Sicker
Re: commons-graph still on sandbox ?
I have a vague interest in this library as Jenkins includes a bunch of graph logic for scheduling builds and such. It'd be nice to use a proper graph API someday. :) On Sat, 30 May 2020 at 19:34, Bruno P. Kinoshita wrote: > > Hi Amey! > > > >> 3. Any pending work or jiras available which I can help to graduate commons > >> graph? this is not available https://issues.apache.org/jira/projects/GRAPH > >> ? > > > >Strange; again maybe the reason is in the ML archive. > > > I believe projects in the Sandbox use the common JIRA project "SANDBOX": > https://issues.apache.org/jira/projects/SANDBOX > > > And each component has a component under the SANDBOX project. The graph > issues are under the graph component: > https://issues.apache.org/jira/browse/SANDBOX-460?jql=project%20%3D%20SANDBOX%20AND%20component%20%3D%20Graph > > > Coincidentally, I also am working on a project with graphs, and yesterday > started looking for cyclic graph unfolding algorithms to do some experiments. > Even though my project is in Python, I was going to look at the commons-graph > to see if there was any useful code there. > > > > Also, I **think** someone mentioned something about bringing graph algorithms > to commons-collections. It might be worth checking if there's any overlap > work in collections&graph. > > > > Cheers > > Bruno > > > On Sunday, 31 May 2020, 1:12:56 am NZST, Gilles Sadowski > wrote: > > > > > > Hello. > > Le sam. 30 mai 2020 à 14:12, Amey Jadiye a écrit : > > > > Hi All, > > > > I'm working on an interesting project which uses Graph, I knew there is > > commons-graph available and I'm trying to use it. I have a couple of > > questions. > > > > 1. Why graph in the sandbox? > > Probably because work stopped before a first release. > > It might be worth digging into the ML archive in order to > know why that happened. > > > any plan of releasing it with 1.0 ? > > No. But you may come up with one. :-) > > > 2. I don't see its repo on GitHub thus I cant contribute a > > few improvements/additions I'm thinking? > > You could install and use Subversion, providing patches > through JIRA. > > > any plan of moving from svn to git? > > IMHO not before we know the answer to your first question. > > > 3. Any pending work or jiras available which I can help to graduate commons > > graph? this is not available https://issues.apache.org/jira/projects/GRAPH ? > > Strange; again maybe the reason is in the ML archive. > > Best, > 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 > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [crypto] New Release
Leaving directory '/mnt/c/git/commons-crypto' > [exec] Makefile:105: recipe for target 'linux-armhf' failed > [exec] cc1: fatal error: lib/inc_linux/jni_md.h: No such file or > directory > [exec] compilation terminated. > [exec] make[1]: *** > [target/commons-crypto-1.1.0-SNAPSHOT-Linux-armhf/OpenSslCryptoRandomNative.o] > Error 1 > [exec] make: *** [linux-armhf] Error 2 > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 10.400 s > [INFO] Finished at: 2020-06-13T14:16:53Z > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-antrun-plugin:1.8:run (make) on project > commons-crypto: An Ant BuildException has occured: exec returned: 2 > [ERROR] around Ant part ... dir="/mnt/c/git/commons-crypto" executable="make">... @ 5:78 in > /mnt/c/git/commons-crypto/target/antrun/build-make.xml > > For the linux-aarch64 profile, I need to install the proper package: > > [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto --- > [INFO] Executing tasks > > make: > [exec] make native CROSS_PREFIX=aarch64-linux-gnu- OS_NAME=Linux > OS_ARCH=aarch64 > [exec] make[1]: Entering directory '/mnt/c/git/commons-crypto' > [exec] aarch64-linux-gnu-gcc -Ilib/inc_linux > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include" -Ilib/inc_mac -O2 -fPIC > -fvisibility=hidden -Wall -Werror -Ilib/include -I/usr/include > -I"src/main/native/org/apache/commons/crypto/" > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux" > -I"target/jni-classes/org/apache/commons/crypto/cipher" > -I"target/jni-classes/org/apache/commons/crypto/random" -c > src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c > -o > target/commons-crypto-1.1.0-SNAPSHOT-Linux-aarch64/OpenSslCryptoRandomNative.o > [exec] Makefile:54: recipe for target > 'target/commons-crypto-1.1.0-SNAPSHOT-Linux-aarch64/OpenSslCryptoRandomNative.o' > failed > [exec] make[1]: Leaving directory '/mnt/c/git/commons-crypto' > [exec] Makefile:109: recipe for target 'linux-aarch64' failed > [exec] In file included from > src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:233:0, > [exec] from > src/main/native/org/apache/commons/crypto/random/org_apache_commons_crypto_random.h:22, > [exec] from > src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c:19: > [exec] /usr/include/openssl/aes.h:13:11: fatal error: > openssl/opensslconf.h: No such file or directory > [exec] # include > [exec]^~~ > [exec] compilation terminated. > [exec] make[1]: *** > [target/commons-crypto-1.1.0-SNAPSHOT-Linux-aarch64/OpenSslCryptoRandomNative.o] > Error 1 > [exec] make: *** [linux-aarch64] Error 2 > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 10.943 s > [INFO] Finished at: 2020-06-13T14:19:44Z > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-antrun-plugin:1.8:run (make) on project > commons-crypto: An Ant BuildException has occured: exec returned: 2 > [ERROR] around Ant part ... dir="/mnt/c/git/commons-crypto" executable="make">... @ 5:78 in > /mnt/c/git/commons-crypto/target/antrun/build-make.xml > > Thoughts? > > Gary > > On Fri, Jun 12, 2020 at 8:41 PM Alex Remily wrote: > > > Just checking in on the status of the 1.1 release. > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [crypto] New Release
Use of cmake could be useful for cross platform builds, though I’ve only used some of the basic functionality so far and can’t comment on how big a task it is to convert to use. On Sat, Jun 13, 2020 at 17:26 Marcelo Vanzin wrote: > Pretty sure I remember comments in the code about building with mingw > on Windows (not cygwin). That should have a version of make, too, > IIRC. > > On Sat, Jun 13, 2020 at 3:11 PM Gary Gregory > wrote: > > > > Except that you can't build on plain Windows because the build uses make > > and Microsoft version is called nmake. I might have to cobble up some > > cygwin thing... > > > > Gary > > > > On Sat, Jun 13, 2020, 18:02 Alex Remily wrote: > > > > > I can't speak to how the original developers did the build, but all > > > the Windows builds that I did were on a Windows machine. I always > > > assumed that the original developers just manually packed the release > > > jar with artifacts from each supported environment. I never did any > > > investigation into the process. Is cobbling together a release in > > > that manner really a non-starter here? > > > > > > Alex > > > > > > On Sat, Jun 13, 2020 at 5:44 PM Gary Gregory > > > wrote: > > > > > > > > Hi Matt: > > > > > > > > > I have: > > > > > > > > > > /mnt/c/git/commons-crypto# find /usr -name windows.h > > > > > /usr/i686-w64-mingw32/include/windows.h > > > > > /usr/share/mingw-w64/include/windows.h > > > > > /usr/x86_64-w64-mingw32/include/windows.h > > > > > > > > > > Case matters here, so I wonder if the original others did not cross > > > > compile > > > > > from Linux and instead built a little here, a little there, and so > on. > > > > > > > > > > I can see "-Ilib/inc_win" in the build but I am not sure where > that is > > > > > supposed to be... > > > > > > > > Gary > > > > > > > > On Sat, Jun 13, 2020, 15:41 Matt Sicker wrote: > > > > > > > > > Are the Windows headers even available when using Ming32 or Cygwin? > > > > > That sounds more like a Visual Studio compiler thing. > > > > > > > > > > On Sat, 13 Jun 2020 at 09:29, Gary Gregory > > > > wrote: > > > > > > > > > > > > The challenge is getting everything set up just right for > building > > > the > > > > > > various OS profiles. This component is quite different in this > > > regard, > > > > > > getting help from the original contributors would be helpful. > > > > > > > > > > > > After much fiddling to install the proper packages, this builds > OK: > > > > > > > > > > > > mvn package -DskipTests -P linux64 > > > > > > mvn package -DskipTests -P linux32 > > > > > > > > > > > > But these do not: > > > > > > mvn package -DskipTests -P win64 > > > > > > mvn package -DskipTests -P win32 > > > > > > > > > > > > due to: > > > > > > > > > > > > [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto > --- > > > > > > [INFO] Executing tasks > > > > > > > > > > > > make: > > > > > > [exec] make native CROSS_PREFIX=x86_64-w64-mingw32- > > > OS_NAME=Windows > > > > > > OS_ARCH=x86_64 > > > > > > [exec] make[1]: Entering directory > '/mnt/c/git/commons-crypto' > > > > > > [exec] x86_64-w64-mingw32-gcc > > > > > > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include" -I"/include" > > > > > > -Ilib/inc_win -O2 -fno-inline -Ilib/include -I/usr/include > > > > > > -I"src/main/native/org/apache/commons/crypto/" > > > > > > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux" > > > > > > -I"target/jni-classes/org/apache/commons/crypto/cipher" > > > > > > -I"target/jni-classes/org/apache/commons/crypto/random" -c > > > > > > > > > > > > > > > src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c > > > > > > -o > > > > > > > > > > > >
Re: [lang] org.apache.commons.lang3.concurrent.Locks.Lock
> > > with the framework. > > > > > > > > Now that I've considered the above, the API Locks.lock(O) is really > > > > misnamed, because it does not lock anything, it's a factory method. > > > > > > > > Stepping back even more, since there is only a static inner class in > > > Locks, > > > > and no-hint that alternative implementations for different kind of > > locks > > > > are possible, I would say we do not need Locks, all we need is what is > > > now > > > > called Lock. > > > > > > > > It's not clear why some methods are protected, I would make those > > > private. > > > > It's not like I can use or plugin a Lock, ReentrantReadWriteLock, a > > > > ReentrantLock, or any ReadWriteLock instead of a StampedLock. I would > > > then > > > > make the current Lock class a standalone class which can then be used > > > later > > > > from a factory class (now Locks) where we can then fill in with > > different > > > > implementations. > > > > > > > > The Javadoc talks about a "hidden" object but it is not hidden since it > > > is > > > > passed to all visitors! > > > > > > > > This test assumption is wrong: > > > > > > > > If our threads are running concurrently, then we expect to be > > > > faster > > > > than running one after the other. > > > > > > > > The VM or Java spec makes no such guarantee and the tests have no > > control > > > > over VM scheduling. There are cases where this will fail when under > > heavy > > > > load for example where the cost of additional threads becomes > > > overwhelming. > > > > > > > > Another item I am quite doubtful about is hiding checked exceptions by > > > > rethrowning them as unchecked. I'd consider this an anti-pattern. If I > > am > > > > using one of our "Failing" interfaces it is because I am expecting it > > to > > > > fail. Perhaps this could be made smoother by refactoring to pass in a > > > > lambda for an exception handler. > > > > > > > > I've crystallized my thoughts into code here as WIP (Javadoc needs > > work): > > > > https://github.com/apache/commons-lang/pull/559 > > > > > > > > Not as important as the above: > > > > The example in the Javadoc uses logging as its domain subject, a > > > "logging" > > > > API (PrintStream) which is not a good example IMO. Logging frameworks > > > > today like Log4j handle multi-threaded applications normally without > > > having > > > > developers meddle in it. Yes, I understand it's a simple example but I > > am > > > > hoping we can come up with something more realistic or useful. > > > > > > > > Thank you, > > > > Gary > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] org.apache.commons.lang3.concurrent.Locks.Lock
Are there any academic references for this? Or even something from Java Concurrency in Practice? Those are good sources for names around concurrency. On Tue, 7 Jul 2020 at 12:42, Rob Tompkins wrote: > > Why not make the name “ThreadedLambdaSynchronizer” or something like > that….just something more descriptive here that get’s closer to what the > intended functionality is. > > That said, I’m not particularly tied to the name “ThreadedLambdaSynchronizer” > just spitballing here for something more descriptive than “Lock” > > -Rob > > > On Jun 29, 2020, at 12:58 PM, Matt Sicker wrote: > > > > Now that starts to sound like Apache Groovy or Kotlin. > > > > On Mon, 29 Jun 2020 at 11:58, Xeno Amess wrote: > >> > >> soemtimes I really wish to rewrite/add some functions in jdk directly... > >> especially for reusing some package private static functions... > >> > >> Gary Gregory 于2020年6月30日周二 上午12:01写道： > >> > >>> I'm not sure talking to the JDK folks is helpful IMO. We are still > >>> targeting Java 8. The customers I deal with are migrating from 8 to 11, > >>> and > >>> Java 11 is not everywhere our customers are. So talking about something > >>> that might end up in Java... 25 seems to be not in our user's best or > >>> immediate interest. It might be good for Java in the long oh so long term > >>> of course. > >>> > >>> Gary > >>> > >>> On Mon, Jun 29, 2020 at 8:31 AM Rob Tompkins wrote: > >>> > >>>> At first look, I’m a little surprised we’re trying to take on this > >>>> functionality. Has anyone reached out to the JDK guys to see if they’d be > >>>> interested in having it in the JDK? That said, if we approach it from > >>> that > >>>> path, we would lose the functionality in older versions of java. So > >>> maybe I > >>>> just talked myself out of the idea of putting it in the JDK > >>>> > >>>> Just wanted to stream of consciousness my initial gut vibe. > >>>> > >>>> Cheers, > >>>> -Rob > >>>> > >>>>> On Jun 26, 2020, at 10:07 AM, Gary Gregory > >>>> wrote: > >>>>> > >>>>> Hi All: > >>>>> > >>>>> I know email is a challenging medium for code reviews, so please > >>> consider > >>>>> these comments coming from my best intentions, constructive and caring > >>>> ;-) > >>>>> Also please excuse the meandering nature of this post. > >>>>> > >>>>> The new class org.apache.commons.lang3.concurrent.Locks.Lock needs > >>> better > >>>>> names IMO, not just the class name. There is already a JRE interface > >>>> called > >>>>> Lock so this class name is confusing (to me.) > >>>>> > >>>>> The Javadoc reads in part: > >>>>> > >>>>>* This class implements a wrapper for a locked (hidden) object, and > >>>>>* provides the means to access it. The basic idea, is that the user > >>>>>* code forsakes all references to the locked object, using only the > >>>>>* wrapper object, and the accessor methods > >>>>> > >>>>> But this is not the case, the object itself is not locked in > >>>>> the traditional sense with a monitor through a synchronized block, so > >>> we > >>>>> need to update the Javadoc as well. > >>>>> > >>>>> To me, this is more about executing blocks of code (through lambdas) > >>>> which > >>>>> then get 'safe' (via locking) access to an underlying object. This > >>> tells > >>>> me > >>>>> the class is more about the functional interfaces than about a domain > >>>>> "Object", hence the name "Lock" is not the best. It's really more of a > >>>>> visitor where the visitation pattern is: Lock, Visit, Unlock. > >>>>> Instead, maybe: > >>>>> - StampledLockVisitor (more specific) > >>>>> - LockingVisitor (more general) > >>>>> - SafeObject (vague) > >>>>> - ObjectLocker (vague) > >>>>> - rejected: LockedObject since the object itself is not locked. > >>>>> - ?
Re: [lang] org.apache.commons.lang3.concurrent.Locks.Lock
JCIP seems to call this idea a monitor, but that’s also the general implicit locking mechanism in Java. On Tue, Jul 7, 2020 at 17:56 Gary Gregory wrote: > Typo: LockingVisitors. > > On Tue, Jul 7, 2020 at 6:56 PM Gary Gregory > wrote: > > > In the PR https://github.com/apache/commons-lang/pull/559 I am going > > with "LockingVistors". > > > > Gary > > > > On Tue, Jul 7, 2020 at 2:33 PM Rob Tompkins wrote: > > > >> I’m not all that familiar with that area of academia. Let me see what I > >> can dig up > >> > >> -Rob > >> > >> > On Jul 7, 2020, at 2:19 PM, Matt Sicker wrote: > >> > > >> > Are there any academic references for this? Or even something from > >> > Java Concurrency in Practice? Those are good sources for names around > >> > concurrency. > >> > > >> > On Tue, 7 Jul 2020 at 12:42, Rob Tompkins wrote: > >> >> > >> >> Why not make the name “ThreadedLambdaSynchronizer” or something like > >> that….just something more descriptive here that get’s closer to what the > >> intended functionality is. > >> >> > >> >> That said, I’m not particularly tied to the name > >> “ThreadedLambdaSynchronizer” just spitballing here for something more > >> descriptive than “Lock” > >> >> > >> >> -Rob > >> >> > >> >>> On Jun 29, 2020, at 12:58 PM, Matt Sicker wrote: > >> >>> > >> >>> Now that starts to sound like Apache Groovy or Kotlin. > >> >>> > >> >>> On Mon, 29 Jun 2020 at 11:58, Xeno Amess > wrote: > >> >>>> > >> >>>> soemtimes I really wish to rewrite/add some functions in jdk > >> directly... > >> >>>> especially for reusing some package private static functions... > >> >>>> > >> >>>> Gary Gregory 于2020年6月30日周二 上午12:01写道： > >> >>>> > >> >>>>> I'm not sure talking to the JDK folks is helpful IMO. We are still > >> >>>>> targeting Java 8. The customers I deal with are migrating from 8 > to > >> 11, and > >> >>>>> Java 11 is not everywhere our customers are. So talking about > >> something > >> >>>>> that might end up in Java... 25 seems to be not in our user's best > >> or > >> >>>>> immediate interest. It might be good for Java in the long oh so > >> long term > >> >>>>> of course. > >> >>>>> > >> >>>>> Gary > >> >>>>> > >> >>>>> On Mon, Jun 29, 2020 at 8:31 AM Rob Tompkins > >> wrote: > >> >>>>> > >> >>>>>> At first look, I’m a little surprised we’re trying to take on > this > >> >>>>>> functionality. Has anyone reached out to the JDK guys to see if > >> they’d be > >> >>>>>> interested in having it in the JDK? That said, if we approach it > >> from > >> >>>>> that > >> >>>>>> path, we would lose the functionality in older versions of java. > So > >> >>>>> maybe I > >> >>>>>> just talked myself out of the idea of putting it in the JDK > >> >>>>>> > >> >>>>>> Just wanted to stream of consciousness my initial gut vibe. > >> >>>>>> > >> >>>>>> Cheers, > >> >>>>>> -Rob > >> >>>>>> > >> >>>>>>> On Jun 26, 2020, at 10:07 AM, Gary Gregory < > >> garydgreg...@gmail.com> > >> >>>>>> wrote: > >> >>>>>>> > >> >>>>>>> Hi All: > >> >>>>>>> > >> >>>>>>> I know email is a challenging medium for code reviews, so please > >> >>>>> consider > >> >>>>>>> these comments coming from my best intentions, constructive and > >> caring > >> >>>>>> ;-) > >> >>>>>>> Also please excuse the meandering nature of this post. > >> >>>>>>> > >> >>>>>>> The new class org.apache.commons.lang3.concurrent.Locks.Lock > needs > >
Re: commons-lang3 - new functionality
There’s also the string substitutor classes, but they use a different
syntax. There’s also MessageFormat in the JDK.
On Fri, Jul 10, 2020 at 06:31 Gary Gregory wrote:
> If this is for logging, most logging APIs like Log4j already provide this
> type of functionality.
>
> Gary
>
> On Fri, Jul 10, 2020, 07:19 Enrico Olivelli wrote:
>
> > Sergei,
> > doesn't java.lang.String#format fit your need ?
> >
> > just my 2 cents
> > Enrico
> >
> > Il giorno ven 10 lug 2020 alle ore 13:14 ha
> > scritto:
> >
> > > Hi,
> > >
> > >
> > >
> > > I am a Java Developer and during my development practice I have some
> new
> > > functionality to provide for an Apache Commons Lang3 library -
> > StringUtils
> > > class.
> > >
> > > As is writted in CONTRIBUTING.md I would like to discuss with you
> first.
> > >
> > > The main purpose of a changes I would like to provide is to add an
> > ability
> > > for format any kind of message in the following way.
> > >
> > >
> > >
> > > Example:
> > >
> > > Input:
> > >
> > > We have happened an error {} with some kind of specific interesting
> > thing:
> > > {}, ERROR_1, something
> > >
> > >
> > >
> > > Output:
> > >
> > > We have happened an error ERROR_1 with some kind of specific
> interesting
> > > thing: something
> > >
> > >
> > >
> > > There are some additional new functuionality that I would like to offer
> > to
> > > StringUtils, similar to the following.
> > >
> > > So if it is in scope of Commons I would like to create a Pull Request
> > with
> > > a
> > > changes proposal.
> > >
> > > The main question: Does it need to Commons Lang or not?
> > >
> > >
> > >
> > > Kind regards,
> > >
> > > Sergei Visotsky
> > >
> > >
> > >
> > >
> >
>
--
Matt Sicker
Re: [all] release validation (was: Re: [VOTE] Release Apache Commons Lang 3.11 based on RC2)
e no sooner that 72 hours from now. > > > > [ ] +1 Release these artifacts > > [ ] +0 OK, but... > > [ ] -0 OK, but really should fix... > > [ ] -1 I oppose this release because... > > > > Thank you, > > > > Gary Gregory, > > Release Manager (using key 86fdc7e2a11262cb) > > > > For following is intended as a helper and refresher for reviewers. > > > > Validating a release candidate > > == > > > > These guidelines are NOT complete. > > > > Requirements: Git, Java, Maven. > > > > You can validate a release from a release candidate (RC) tag as follows. > > > > 1) Clone and checkout the RC tag > > > > git clone https://gitbox.apache.org/repos/asf/commons-lang.git --branch > > commons-lang-3.11-RC2 commons-lang-3.11-RC2 > > cd commons-lang-3.11-RC2 > > > > 2) Check Apache licenses > > > > This step is not required if the site includes a RAT report page which you > > then must check. > > > > mvn apache-rat:check > > > > 3) Check binary compatibility > > > > Older components still use Apache Clirr: > > > > This step is not required if the site includes a Clirr report page which > > you then must check. > > > > mvn clirr:check > > > > Newer components use JApiCmp with the japicmp Maven Profile: > > > > This step is not required if the site includes a JApiCmp report page which > > you then must check. > > > > mvn install -DskipTests -P japicmp japicmp:cmp > > > > 4) Build the package > > > > mvn -V clean package > > > > You can record the Maven and Java version produced by -V in your VOTE reply. > > To gather OS information from a command line: > > Windows: ver > > Linux: uname -a > > > > 5) Build the site for a single module project > > > > Note: Some plugins require the components to be installed instead of > > packaged. > > > > mvn site > > Check the site reports in: > > - Windows: target\site\index.html > > - Linux: target/site/index.html > > > > -the end- > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Jenkins a mess? [Re: Build failed in Jenkins: commons-io-windows #361]
ng.UserRequest.perform(UserRequest.java:212) > >>at hudson.remoting.UserRequest.perform(UserRequest.java:54) > >>at hudson.remoting.Request$2.run(Request.java:369) > >>at > >> > hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) > >>at java.util.concurrent.FutureTask.run(Unknown Source) > >>at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown > >> Source) > >>at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown > >> Source) > >>at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:93) > >>at java.lang.Thread.run(Unknown Source) > >> java.nio.file.DirectoryNotEmptyException: < > >> https://builds.apache.org/job/commons-io-windows/ws/target> > >>at sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown > Source) > >>at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(Unknown > >> Source) > >>at java.nio.file.Files.deleteIfExists(Unknown Source) > >>at > >> > jenkins.util.io.PathRemover.removeOrMakeRemovableThenRemove(PathRemover.java:241) > >>at > jenkins.util.io.PathRemover.tryRemoveFile(PathRemover.java:205) > >>at > >> jenkins.util.io.PathRemover.tryRemoveRecursive(PathRemover.java:216) > >>at > >> > jenkins.util.io.PathRemover.tryRemoveDirectoryContents(PathRemover.java:226) > >>at > >> > jenkins.util.io.PathRemover.forceRemoveDirectoryContents(PathRemover.java:87) > >>at hudson.Util.deleteContentsRecursive(Util.java:259) > >>at hudson.Util.deleteContentsRecursive(Util.java:248) > >>at > >> > org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:699) > >>at > >> > org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153) > >>at > >> > org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146) > >>at hudson.remoting.UserRequest.perform(UserRequest.java:212) > >>at hudson.remoting.UserRequest.perform(UserRequest.java:54) > >>at hudson.remoting.Request$2.run(Request.java:369) > >>at > >> > hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) > >>at java.util.concurrent.FutureTask.run(Unknown Source) > >>at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown > >> Source) > >>at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown > >> Source) > >>at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:93) > >>at java.lang.Thread.run(Unknown Source) > >> ERROR: Error cloning remote repo 'origin' > >> hudson.plugins.git.GitException: Failed to delete workspace > >>at > >> > org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:702) > >>at > >> > org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153) > >>at > >> > org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146) > >>at hudson.remoting.UserRequest.perform(UserRequest.java:212) > >>at hudson.remoting.UserRequest.perform(UserRequest.java:54) > >>at hudson.remoting.Request$2.run(Request.java:369) > >>at > >> > hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) > >>at java.util.concurrent.FutureTask.run(Unknown Source) > >>at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown > >> Source) > >>at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown > >> Source) > >>at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:93) > >>at java.lang.Thread.run(Unknown Source) > >>Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote > >> call to JNLP4-connect connection from > >> static.218.113.76.144.clients.your-server.de/144.76.113.218:64663 > >>at > >> hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743) > >>at > >> > hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357) > >>at hudson.remoting.Channel.call(Channel.java:957) > >>at > >> > org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146) > >>at sun.reflect.GeneratedMethodAccessor842.invoke(Unknown > >> Source) > >>at > >> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > >>at java.lang.reflect.Method.invoke(Method.java:498) > >>at > >> > org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132) > >>at com.sun.proxy.$Proxy133.execute(Unknown Source) > >>at > >> hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1152) > >>at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192) > >>at hudson.scm.SCM.checkout(SCM.java:504) > >>at > >> hudson.model.AbstractProject.checkout(AbstractProject.java:1208) > >>at > >> > hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574) > >>at > >> jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) > >>at > >> > hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499) > >>at hudson.model.Run.execute(Run.java:1815) > >>at > >> hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:543) > >>at > >> hudson.model.ResourceController.execute(ResourceController.java:97) > >>at hudson.model.Executor.run(Executor.java:429) > >> Caused by: jenkins.util.io.CompositeIOException: Unable to delete '< > >> https://builds.apache.org/job/commons-io-windows/ws/'.> Tried 3 times > (of > >> a maximum of 3) waiting 0.1 sec between attempts. > >>at > >> > jenkins.util.io.PathRemover.forceRemoveDirectoryContents(PathRemover.java:90) > >>at hudson.Util.deleteContentsRecursive(Util.java:259) > >>at hudson.Util.deleteContentsRecursive(Util.java:248) > >>at > >> > org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:699) > >>... 11 more > >> ERROR: Error cloning remote repo 'origin' > >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [all] Thoughts on build system maven -> gradle??
On a related note, anyone with non-trivial build needs can always develop Maven plugins to fill in any gaps in a more integrated fashion. That’s what we do in Jenkins, for example, and that’s an incredibly complex ecosystem. You get a ton of freebies with Maven which is fantastic for libraries especially. In my experience, Gradle was most useful in building standalone applications, though that’s fairly doable with Maven anyways. It’s mostly useful when you have a critical mass of developers who prefer it; otherwise, you end up with only half a person who understands the resulting build scripts. On Sat, Jul 18, 2020 at 08:37 Xeno Amess wrote: > -1 for me. I have experience of grade about maintaining 5 or 6 gradle > projects, including my graduationg project. > And I think gradle shitty. > > Adam Retter 于 2020年7月18日周六 下午8:18写道： > > > -1 from me. I have only ever found Gradle to be worse than Maven. > > > > On Thu, 16 Jul 2020, 23:30 Rob Tompkins, wrote: > > > > > I think we might be coming towards time to make this move or at least > > > accommodate for gradle builds in commons. Let’s look to the success the > > > Spring Framework has had here with gradle. That said, I’m merely trying > > to > > > gauge opinions here and am entirely content to stay with maven, if > that’s > > > what the community wishes. > > > > > > I’m a +1 on at least letting gradle be a part of our systems (don’t > have > > > to get rid of maven either). > > > > > > Cheers, > > > -Rob > > > ----- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > -- Matt Sicker
Re: [all]should we really allow denpabot upgrade a dependency that changes major version?
I think it depends on the specific dependency. Maven plugins can typically be upgraded. Test dependencies, too. On Wed, Jul 22, 2020 at 10:12 Xeno Amess wrote: > as title. > I see some dependency trying to upgrade from v1 to v2.3.1, and some plugin > from 3.5.1 to 5.1.1 > Just confused. > -- Matt Sicker
Re: [ALL] CI builds
If we request the pipeline template plugin to be installed, that would help reduce the amount of boilerplate needed in the new Jenkins. I could help with that. On Wed, Jul 22, 2020 at 22:00 Gilles Sadowski wrote: > 2020-07-23 3:35 UTC+02:00, Torsten Curdt : > >> > >> > I realize that a local build seems to be your gold standard. > >> > >> Not mine. "Commons". > >> > > > > You are arguing for it. > > No I'm not. It (i.e "maven", "svn" then "git") was there > when I came here. > > It could change but that's another discussion that > will probably never happen as people just assume > that everyone should use GitHub on its own (as > contrasted to through being an Apache committer). > [The latter is the main thing I don't agree with.] > > > I would just call it a current policy or practice. > > > > > > > >> > That's a very debatable point of view. > >> > >> There was no debate. > > > > > > Yet it is a debatable point of view :) > > > > No problem with automating the release process. > [Cf. my comments in other threads on that subject.] > > > > >> I don't see why you are putting those sideways > >> conclusions into the simple issue of maintaining > >> this place comfortable for everyone, not only > >> for GitHub users. > >> > > > > And I don't get why you are making such a big deal about having to delete > > 100(?) emails and maybe setting up an email filter. > > Yesterday 0 > Today 100 > Tomorrow ? > > And for what? Delete. > I don't get the logic. > > >> Deleting the messages should have been 10s max. > >> > I wonder why you choose to be outraged instead. > >> > >> No, today's flood just pushed me to want to have > >> something that's bothering for months, fixed. > >> > > > > The flood was from enabling the bot. > > So what has bothered you before? > > The mails about PRs? > > Yes, all those messages that would go in [TRACE] level > in a logger. > > >> I guess there are many people out there that like it as a tool. > >> > >> Maybe you could explain why it's a burden for you? > >> > >> Sure: No GH account. > >> > > > > OK - why don't you have one? > > Why should I? > Do I need one to contribute here? I so, where is stated? > > > And why does that make things harder? > > It does when changes to the contribution work flow > assumes that everyone has one. > [I mentioned that 2 or 3 times already on "dev@". > Namely that it is factually as if "dev@" and JIRA are > not anymore *the* (only) official places where changes > to the codes are discussed.] > > >> so maybe elaborate on > >> > the inconvenience. > >> > >> Try to do something on GH without being logged in. > >> > > > > So others are using a tool that (I assume) you don't want to use, > > and that is causing inconvenience for you and that is bothering you? > > The inconvenience is the invalid assumption that everyone > should use GH even though that was never discussed. > > > And you want the rest of us to not use the tool because of that? > > Where did you get that conclusion from? > > Is GH more than a convenience tool like Travis, Coveralls or > SonarQube? > Or is it a core part of the work flow like "git"? > If so, when did this happen? Where is the decision recorded? > > Gilles > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [ALL] CI builds
https://github.com/apache/logging-pipelines For more pipelines. On Thu, Jul 23, 2020 at 06:21 Olivier Lamy wrote: > On Thu, 23 Jul 2020 at 20:57, Gilles Sadowski > wrote: > > > Hi. > > > > 2020-07-23 12:38 UTC+02:00, Olivier Lamy : > > > Hi > > > As you know the current Jenkins infra is migrating to another CI > server. > > > The current commons-* builds in the old Jenkins infra have been created > > > manually and this will be a pain to transfer to the new one and to keep > > > maintaining manually. > > > In the Maven project we have plenty of maven-* git repo so we have > > created > > > a dedicated Jenkins plugin (which is used by other TLP such netbeans) > > which > > > scan the gitbox server to get repo based on regular expression or name > > > content and create the build reusing the same build file. > > > And this is done without duplicating the build configuration for every > > > single git repository It's done once and updated for all repos when > > > this configuration change (no need to touch manually every single git > > > repository) > > > Each git repo contains a simple Jenkinsfile saying which jdks to use in > > > case the component has different needs. > > > I'm happy to help to duplicate similar configuration for commons. > > > Just let me know. > > > > +1 > > > > How does it work with projects having several Jenkins builds > > (e.g. one for running SonarQube)? > > > > can be a parameter as well. > look at this file > https://github.com/apache/maven-site-plugin/blob/master/Jenkinsfile > we can imagine having a parameter sonarQube: true/false (default might be > false) > > > > > > Gilles > > > > > > > > cheers > > > Olivier > > > > > > On Thu, 23 Jul 2020 at 16:39, Stefan Bodewig > wrote: > > > > > >> On 2020-07-23, Stefan Bodewig wrote: > > >> > > >> > My preference would be for using less of github rather than more. > But > > >> > I'm probably alone with that. > > >> > > >> Of course I'm not. Sorry Gilles. :-) > > >> > > >> Stefan > > >> > > >> - > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >> For additional commands, e-mail: dev-h...@commons.apache.org > > >> > > >> > > > > > > -- > > > Olivier Lamy > > > http://twitter.com/olamy | http://linkedin.com/in/olamy > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > -- > Olivier Lamy > http://twitter.com/olamy | http://linkedin.com/in/olamy > -- Matt Sicker
Re: [ALL] CI builds
As Olivier mentioned, that GitBox plugin plus some relatively simple pipelines would make it fairly simple to make every Commons component easily buildable in Jenkins just like how Maven set up their projects. Well, hopefully a little more optimized since their setup occasionally figures out how to spawn off a zillion builds, but that might be more so due to builds triggering downstream dependent builds and such. The pipeline templates plugin is something installable in the new ci-builds.apache.org environment which could be used to further reduce the boilerplate of pipelines by creating a template pipeline which the various Commons components can all specify parameters to (similar to the parent pom). On Thu, 23 Jul 2020 at 08:01, Gilles Sadowski wrote: > > Hello. > > Le jeu. 23 juil. 2020 à 13:21, Olivier Lamy a écrit : > > > > On Thu, 23 Jul 2020 at 20:57, Gilles Sadowski wrote: > > > > > Hi. > > > > > > 2020-07-23 12:38 UTC+02:00, Olivier Lamy : > > > > Hi > > > > As you know the current Jenkins infra is migrating to another CI server. > > > > The current commons-* builds in the old Jenkins infra have been created > > > > manually and this will be a pain to transfer to the new one and to keep > > > > maintaining manually. > > > > In the Maven project we have plenty of maven-* git repo so we have > > > created > > > > a dedicated Jenkins plugin (which is used by other TLP such netbeans) > > > which > > > > scan the gitbox server to get repo based on regular expression or name > > > > content and create the build reusing the same build file. > > > > And this is done without duplicating the build configuration for every > > > > single git repository It's done once and updated for all repos when > > > > this configuration change (no need to touch manually every single git > > > > repository) > > > > Each git repo contains a simple Jenkinsfile saying which jdks to use in > > > > case the component has different needs. > > > > I'm happy to help to duplicate similar configuration for commons. > > > > Just let me know. > > > > > > +1 > > > > > > How does it work with projects having several Jenkins builds > > > (e.g. one for running SonarQube)? > > > > > > > can be a parameter as well. > > look at this file > > https://github.com/apache/maven-site-plugin/blob/master/Jenkinsfile > > Wow, it's rather terse: Configuration could hardly seem simpler. :-) > If it just works (TM) for all Commons components, we could (should > IMO) make this a required CI system (as a PMC decision to ensure > a yet to be reached consensus about what is required from a commit > to the "master" branch), letting of course anyone willing to handle > additional CI systems for building GH PRs. > > > we can imagine having a parameter sonarQube: true/false (default might be > > false) > > Fine. > > Thanks, > Gilles > > > > > cheers > > > > Olivier > > > > > > > > On Thu, 23 Jul 2020 at 16:39, Stefan Bodewig wrote: > > > > > > > >> On 2020-07-23, Stefan Bodewig wrote: > > > >> > > > >> > My preference would be for using less of github rather than more. But > > > >> > I'm probably alone with that. > > > >> > > > >> Of course I'm not. Sorry Gilles. :-) > > > >> > > > >> Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-compress] branch master updated: Enable GitHub Dependabot.
Also, how different is a bot proposing a dependency update from a human doing the same? The bot includes far more context about the update in the PR comment, too, which is super useful for determining whether or not the dependency is worth updating. You can even configure it to only notify about security updates if it’s too noisy. On Thu, Jul 23, 2020 at 20:42 Gary Gregory wrote: > I suggest you look at the PRs directly instead the emails. > > Gary > > On Thu, Jul 23, 2020, 21:27 Peter Lee wrote: > > > Got plenty of mails this morning(which surprised me a lot). Seems they > are > > all triggered by github dependency bot. > > Have been too busy these days. Will try to look into them this weekend. > > On 7. 23 2020, at 5:12 , Gilles Sadowski wrote: > > > Hi. > > > > > > 2020-07-22 18:32 UTC+02:00, Stefan Bodewig : > > > > I hope anybody sees this message. > > > > > > I've seen it. Although it could have been easily drowned in the flood. > > ;-) > > > > Can we please discuss this per component? I personally do like the > idea > > > > of dependabot for applications but feel it is completly wrong for > > > > libraries and would prefer to not use it. > > > > > > At least, it seems that I was not completely off-base in asking what > > > was going on. > > > > > > Thanks, > > > Gilles > > > > > > > > > > > Stefan > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > -- Matt Sicker
Re: [ALL] CI builds
Pipelines are the text file method of Jenkins jobs. You can store them in the repo you’re building similar to other CI systems, or you can make a dedicated repo for holding pipelines, or you can even store the pipeline script directly in Jenkins (not the best idea, but can be useful during development). More info here: https://www.jenkins.io/doc/book/pipeline/ On Fri, Jul 24, 2020 at 05:43 Gilles Sadowski wrote: > Hi. > > 2020-07-23 15:59 UTC+02:00, Matt Sicker : > > [...] make every Commons component > > easily buildable in Jenkins [...] > > How to do it practically? > Can we create a text file and drop it somewhere, or has > the configuration to be done in GUI ? > > Gilles > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [all] When to update dependencies?
; > path, the copying/pasting continues and slowly grows the iceberg. > > A recent example is the issue with pseudo-random numbers > > generation where maintaining duplicate functionality in [Lang] > > was preferred even though [RNG] has 100% coverage (and a > > explicit scope that entails it will never have any dependency of > > its own). > > > > Would you be willing to provide a PR that deprecates the relevant APIs and > points to their equivalent in RNG? It will be more cruft we can trim for > 4.0, whenever that happens. > > > > > Shading has its limited use in my view, and I've used it to provide > > > monolithic versions of applications, but beyond that, I've no use for > it; > > > but the pain it can cause is very real indeed. > > > > > > You can imagine all manner of jar-hell created by shading. For > instance: > > > - library L1 shades library ShadedA-1.0 and ShadedB-1.1. > > > - library L2 shades library ShadedA-1.1 and ShadedB-1.0. > > > - An app wants to use L1, L2, ShadedA-1.1, and ShadedB-1.1 but it can't > > no > > > matter what classpath ordering it uses. > > > - An app wants to use L1, L2, ShadedA-1.0, and ShadedB-1.0 but it can't > > no > > > matter what classpath ordering it uses. > > > > I didn't understand how the problem is supposed to arise. > > Fortunately, Torsten already replied to this point. :-) > > > > Unless I'm mistaken, there is one drawback to shading: Since > > it creates new classes, there will be less shared code, hence > > one could imagine a potential hit on performance (?). > > > > > Lastly, there is a special kind of shading jar hell that deserves its > own > > > section: the copied and re-packaged source/jar. In this lovely planned > > > development managed by Hades, an entire jar has been copied then > > repackaged > > > such that instead of being in its original Java package > org.foo.library, > > it > > > is now under org.other.bar.org.foo.library. Residents of this charming > > > cottage have now the proud owners of every bug and CVE for that > specific > > > version of the source jar, without, and this is the kicker, the option > of > > > overriding the jar with a new version (I'll leave aside your option to > > take > > > a new version of the jar and repackaging it yourself to put it in front > > of > > > the shaded jar.) I've seen this in various libraries that shade > > > bytecode manipulation libraries that you can't use on new Java > versions. > > > > I must be missing something: Since shaded classes are supposed > > to be "internal", if there is an impact on the public API, the only sane > > solution is a bug-fix release that shades the fixed version of the > internal > > library. No? > > > > Which is exactly the problem I am pointing out: You have no control over > when this third party will release a new version and whether that new > version contains updated shaded code. > > For example: JaCoCo 0.8.5 (current) and Java 15 yields this gorgeous stack > trace: > > Caused by: java.lang.IllegalArgumentException: Unsupported class file major > version 59 > 14951 > < > https://github.com/apache/commons-bcel/runs/899223983?check_suite_focus=true#step:4:14951 > > > at > > org.jacoco.agent.rt.internal_43f5073.asm.ClassReader.(ClassReader.java:195) > > 14952 > < > https://github.com/apache/commons-bcel/runs/899223983?check_suite_focus=true#step:4:14952 > > > at > > org.jacoco.agent.rt.internal_43f5073.asm.ClassReader.(ClassReader.java:176) > > 14953 > < > https://github.com/apache/commons-bcel/runs/899223983?check_suite_focus=true#step:4:14953 > > > at > > org.jacoco.agent.rt.internal_43f5073.asm.ClassReader.(ClassReader.java:162) > > 14954 > < > https://github.com/apache/commons-bcel/runs/899223983?check_suite_focus=true#step:4:14954 > > > at > > org.jacoco.agent.rt.internal_43f5073.core.internal.instr.InstrSupport.classReaderFor(InstrSupport.java:280) > > 14955 > < > https://github.com/apache/commons-bcel/runs/899223983?check_suite_focus=true#step:4:14955 > > > at > > org.jacoco.agent.rt.internal_43f5073.core.instr.Instrumenter.instrument(Instrumenter.java:75) > > 14956 > < > https://github.com/apache/commons-bcel/runs/899223983?check_suite_focus=true#step:4:14956 > > > at > > org.jacoco.agent.rt.internal_43f5073.core.instr.Instrumenter.instrument(Instrumenter.java:107) > > 14957 > < > https://github.com/apache/commons-bcel/runs/899223983?check_suite_focus=true#step:4:14957 > > > ... 52 more > > Can I add the current version of ASM to my project to cure this ill? Of > course not, that would be too easy. > > Instead I have to wait for 0.8.6 which will be released whenever. I am > assuming that we would not want our POMs to depend on a snapshot... > > Gary > > > > Gilles > > > > > > > > I hope this helps someone... > > > > > > Gary > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > -- Matt Sicker
Re: [all] When to update dependencies?
They’re not the same class and that’s the problem. It’s similar to loading two versions of the same library in OSGi and allowing the two classes to get mixed up somehow (fun errors like Foo is not type Foo), typically a bug. On Fri, Jul 24, 2020 at 11:30 Gilles Sadowski wrote: > Le ven. 24 juil. 2020 à 17:46, Matt Sicker a écrit : > > > > Shading also violates a lot of common ClassLoader assumptions like not > > having multiple copies of the same class in the same visible context > (even > > if different packages) > > How classes in different packages could be the same class? > > Gilles > > > [...] > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [all] github (was Re: [VOTE] Create additional mailing lists for automated posts)
GitHub is basically our interactive pull request interface. If we didn’t have that, I bet we’d be running GitLab ourselves or similar. Also, being that the bar to be a committer here is fairly low, getting access to gitbox directly isn’t too difficult. On Fri, Jul 24, 2020 at 12:17 Xeno Amess wrote: > besides, that is JIRA where we can apply patch, but I think it SHOULD be > done on gutbox. github, gitlab, all of them have a convienent pr system. > so yes our JIRA is good, I like JIRA. > But for gitbox, I think it really lack lots of things. > Or, there be those things, but not open. > > Xeno Amess 于 2020年7月25日周六 上午1:11写道： > > > you know that is really complex and time costing... > > especially when we want some trigger invoked like travis-ci. > > > > Stefan Bodewig 于 2020年7月25日周六 上午1:06写道： > > > >> On 2020-07-24, Xeno Amess wrote: > >> > >> > I will explain why github come to be center, but not apache gitbox. > >> > 1.1 > >> > I have right to register an account on github. > >> > 1.2 > >> > I registered an account at github. > >> > 1.3 > >> > I commit then create pr. > >> > 1.4 > >> > pr get reviewed then merged. > >> > >> I am fully aware of how github works, I use PRs myself. > >> > >> The perceived ease[1] of doing this comes at a price and I'm mourning > >> the loss of community building. > >> > >> Stefan > >> > >> [1] with gitbox you are certainly able to contribute > >> > >> git clone > >> git checkout -b my-work > >> ... > >> git format-patch > >> attach patch to JIRA > >> > >> but you know that. > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > -- Matt Sicker
Re: [all] When to update dependencies?
Exactly. It’s not a general problem, but one specific to various legacy APIs still commonly used. On Sat, Jul 25, 2020 at 14:56 Bernd Eckenfels wrote: > It will only cause problems if this is registered as a service/spi/driver > like XML, Crypto, JDBC, Authentication and so on. For internal libraries > functions which don't have such global state it's fine. > > Gruss > Bernd > > > -- > http://bernd.eckenfels.net > > Von: Torsten Curdt > Gesendet: Saturday, July 25, 2020 8:29:21 PM > An: Commons Developers List > Betreff: Re: [all] When to update dependencies? > > > > > They’re not the same class and that’s the problem. It’s similar to > loading > > two versions of the same library in OSGi > > > Let's say you are dealing with > > org.vafer.Foo > > the library relocates this as > > org.apache.commons.compress.internal.org.vafer.Foo > > The library only deals with > > org.apache.commons.compress.internal.org.vafer.Foo > > They cannot get mixed up. > Please explain how this will cause problems. > -- Matt Sicker
Re: [ALL] CI builds and Java versions
If building on Jenkins, it looks like Infra still supports all the way back to 1.4: https://cwiki.apache.org/confluence/display/INFRA/JDK+Installation+Matrix On Sun, 26 Jul 2020 at 16:46, Gary Gregory wrote: > > Hi All: > > As a guideline I think our CI builds should use the following Java versions: > >- Java 8 since it is LTS >- Java 11 since it is LTS >- Java 14 since it is the latest version >- Java 15-ea since it is upcoming, but should be allowed to fail a build >- Java 16-ea since it is upcoming, but should be allowed to fail a build > > When Java 15 is released in September: > >- Java 15 can take the place of Java 14 in the list above >- Drop Java 15-ea. > > Java 17 looks to be the next LTS version but there is no EA yet. > > For antique builds that still require Java 7 then that build can be added > of course. > > For mythical builds that require Java 6, we should really consider bumping > those up to Java 7 or 8 because newer JDKs do not accept compiling to > targets older than Java 7. That will just make the builds and tooling > simpler to deal with and will avoid telling contributors that they have to > find and install some deep freeze Java version. > > Gary -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Build failed in Jenkins: commons-io-windows #527
at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:93) >> at java.lang.Thread.run(Unknown Source) >> ERROR: Error cloning remote repo 'origin' >> hudson.plugins.git.GitException: Failed to delete workspace >> at >> org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:702) >> at >> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153) >> at >> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146) >> at hudson.remoting.UserRequest.perform(UserRequest.java:212) >> at hudson.remoting.UserRequest.perform(UserRequest.java:54) >> at hudson.remoting.Request$2.run(Request.java:369) >> at >> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) >> at java.util.concurrent.FutureTask.run(Unknown Source) >> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown >> Source) >> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown >> Source) >> at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:93) >> at java.lang.Thread.run(Unknown Source) >> Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote >> call to JNLP4-connect connection from >> jenkins-win-he-de-1.apache.org/144.76.12.43:49684 >> at >> hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743) >> at >> hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357) >> at hudson.remoting.Channel.call(Channel.java:957) >> at >> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146) >> at sun.reflect.GeneratedMethodAccessor842.invoke(Unknown >> Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:498) >> at >> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132) >> at com.sun.proxy.$Proxy133.execute(Unknown Source) >> at >> hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1152) >> at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192) >> at hudson.scm.SCM.checkout(SCM.java:504) >> at >> hudson.model.AbstractProject.checkout(AbstractProject.java:1208) >> at >> hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574) >> at >> jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) >> at >> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499) >> at hudson.model.Run.execute(Run.java:1815) >> at >> hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:543) >> at >> hudson.model.ResourceController.execute(ResourceController.java:97) >> at hudson.model.Executor.run(Executor.java:429) >> Caused by: jenkins.util.io.CompositeIOException: Unable to delete '< >> https://builds.apache.org/job/commons-io-windows/ws/'.> Tried 3 times >> (of a maximum of 3) waiting 0.1 sec between attempts. >> at >> jenkins.util.io.PathRemover.forceRemoveDirectoryContents(PathRemover.java:90) >> at hudson.Util.deleteContentsRecursive(Util.java:259) >> at hudson.Util.deleteContentsRecursive(Util.java:248) >> at >> org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:699) >> ... 11 more >> ERROR: Error cloning remote repo 'origin' >> > -- Matt Sicker
Re: [VOTE] Release Apache Commons Validator 1.7 based on RC2
tor-1.7-test-sources.jar=86fb0021b9ffd048fa28ed67418b78780534988f17da472c62dba758f8a7443a7dfbb00df4fa74e59d951f7e06e5af7fe4e303400e8e9870d6f6d18b65ca5714 > > > > > > > > > > > > > > > > > > > > > > commons-validator-1.7-tests.jar=2f7521b8ccdecb8cc6d93da17bef628a82a3ddcc370c938549d5659de136ef8d39ccb9e5ea430487575d850805a299d895c27e619ed862342765fe191f1ec9f4 > > > > > > > > > > > > > > > > > > > > > I have tested this with ***'mvn clean install site'*** using: > > > > > > > > > > > > > > Maven home: /opt/apache-maven-3.5.4 > > > > > > > Java version: 1.8.0_231, vendor: Oracle Corporation, runtime: > > > > > > > > > /Library/Java/JavaVirtualMachines/jdk1.8.0_231.jdk/Contents/Home/jre > > > > > > > Default locale: en_GB, platform encoding: UTF-8 > > > > > > > OS name: "mac os x", version: "10.15.6", arch: "x86_64", > family: > > "mac" > > > > > > > > > > > > > > Details of changes since 1.6 are in the release notes: > > > > > > > > > > > > > > > > > > > > > > https://dist.apache.org/repos/dist/dev/commons/validator/1.7-RC2/RELEASE-NOTES.txt > > > > > > > > > > > > > > > > > > > > > > https://dist.apache.org/repos/dist/dev/commons/validator/1.7-RC2/site/changes-report.html > > > > > > > > > > > > > > Site: > > > > > > > > > > > > > > > > > > > > > > https://dist.apache.org/repos/dist/dev/commons/validator/1.7-RC2/site/index.html > > > > > > > (note some *relative* links are broken and the 1.7 > > directories are > > > > > > > not yet created - these will be OK once the site is deployed.) > > > > > > > > > > > > > > CLIRR Report (compared to 1.6): > > > > > > > > > > > > > > > > > > > > > > https://dist.apache.org/repos/dist/dev/commons/validator/1.7-RC2/site/clirr-report.html > > > > > > > > > > > > > > JApiCmp Report (compared to 1.6): > > > > > > > > > > > > > > > > > > > > > > https://dist.apache.org/repos/dist/dev/commons/validator/1.7-RC2/site/japicmp.html > > > > > > > > > > > > > > RAT Report: > > > > > > > > > > > > > > > > > > > > > > https://dist.apache.org/repos/dist/dev/commons/validator/1.7-RC2/site/rat-report.html > > > > > > > > > > > > > > KEYS: > > > > > > > https://www.apache.org/dist/commons/KEYS > > > > > > > > > > > > > > Please review the release candidate and vote. > > > > > > > This vote will close no sooner than 72 hours from now. > > > > > > > > > > > > > > [ ] +1 Release these artifacts > > > > > > > [ ] +0 OK, but... > > > > > > > [ ] -0 OK, but really should fix... > > > > > > > [ ] -1 I oppose this release because... > > > > > > > > > > > > > > Thank you, > > > > > > > > > > > > > > Sebb, > > > > > > > Release Manager (using key 4FAD5F62) > > > > > > > > > > > > > > For following is intended as a helper and refresher for > > reviewers. > > > > > > > > > > > > > > Validating a release candidate > > > > > > > == > > > > > > > > > > > > > > These guidelines are NOT complete. > > > > > > > > > > > > > > Requirements: Git, Java, Maven. > > > > > > > > > > > > > > You can validate a release from a release candidate (RC) tag as > > > > > follows. > > > > > > > > > > > > > > 1) Clone and checkout the RC tag > > > > > > > > > > > > > > git clone > > https://gitbox.apache.org/repos/asf/commons-validator.git > > > > > > > --branch > > > > > > > < > > https://gitbox.apache.org/repos/asf/commons-validator.git--branch> > > > > > > > VALIDATOR_1_7_RC2 VALIDATOR_1_7_RC2 > > > > > > > cd VALIDATOR_1_7_RC2 > > > > > > > > > > > > > > 2) Check Apache licenses > > > > > > > > > > > > > > This step is not required if the site includes a RAT report > page > > which > > > > > > > you then must check. > > > > > > > > > > > > > > mvn apache-rat:check > > > > > > > > > > > > > > 3) Check binary compatibility > > > > > > > > > > > > > > Older components still use Apache Clirr: > > > > > > > > > > > > > > This step is not required if the site includes a Clirr report > > page > > > > > > > which you then must check. > > > > > > > > > > > > > > mvn clirr:check > > > > > > > > > > > > > > Newer components use JApiCmp with the japicmp Maven Profile: > > > > > > > > > > > > > > This step is not required if the site includes a JApiCmp report > > page > > > > > > > which you then must check. > > > > > > > > > > > > > > mvn install -DskipTests -P japicmp japicmp:cmp > > > > > > > > > > > > > > 4) Build the package > > > > > > > > > > > > > > mvn -V clean package > > > > > > > > > > > > > > You can record the Maven and Java version produced by -V in > your > > VOTE > > > > > > > reply. > > > > > > > To gather OS information from a command line: > > > > > > > Windows: ver > > > > > > > Linux: uname -a > > > > > > > > > > > > > > 5) Build the site for a single module project > > > > > > > > > > > > > > Note: Some plugins require the components to be installed > > instead of > > > > > > > packaged. > > > > > > > > > > > > > > mvn site > > > > > > > Check the site reports in: > > > > > > > - Windows: target\site\index.html > > > > > > > - Linux: target/site/index.html > > > > > > > > > > > > > > 6) Build the site for a multi-module project > > > > > > > > > > > > > > mvn site > > > > > > > mvn site:stage > > > > > > > Check the site reports in: > > > > > > > - Windows: target\site\index.html > > > > > > > - Linux: target/site/index.html > > > > > > > > > > > > > > Sebb > > > > > > > > > > > > > > > > - > > > > > > > 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 > > > > > -- Matt Sicker
Re: [release-plugin] thoughts on automated validation of releases
At OpenWhisk, they've come up with a more standardized process around this as they have a lot of components, too. https://github.com/apache/openwhisk-release And the related utilities for enforcing releasability and similar things: https://github.com/apache/openwhisk-utilities This began as a release candidate validation script to check all the automatable verifications (like checksums, signatures, RAT checks and other language equivalents, scanning for binaries in sources, etc.), and it's grown into an automated system for helping ensure all the various components of the project are fairly easy to release and verify. There might be some useful stuff here for Commons, too. On Mon, 3 Aug 2020 at 13:19, Gary Gregory wrote: > > Hi Rob, > > I am missing something. Is this something you will provide for each > component? Or, is this a command that is generated in the VOTE.txt? > The latter seems more reasonable since there are so many variables. > > Note that some components have different component names from their > artifact IDs: pool vs pool2 where some folders are called .../commons-pool > or .../pool but the AID is different like commons-pool2 (same for Commons > Lang, DBCP, Configuration, VFS, Collections). > > Maybe put a bunch of env vars at the top that people can edit, at least > that would remove some of the repetition, unless it's generated. > > Gary > > On Mon, Aug 3, 2020 at 1:37 PM Rob Tompkins wrote: > > > Currently I run the following scripts for signature valitaion: > > > > > > https://github.com/chtompki/notes/blob/master/commons-release-validation/commons-text-1.7-downloader.sh > > < > > https://github.com/chtompki/notes/blob/master/commons-release-validation/commons-text-1.7-downloader.sh > > > > > > > and > > > > > > https://github.com/chtompki/notes/blob/master/commons-release-validation/commons-text-1.7-sig-validator.sh > > < > > https://github.com/chtompki/notes/blob/master/commons-release-validation/commons-text-1.7-sig-validator.sh > > > > > > > For the sake of making everything easier for everyone should we put this > > in the release-plugin for automated validation? > > > > -Rob -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: The project website
See also the asf-site and asf-staging branches for an Infra-supported site publishing system: https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features Seems to work fairly similar to a gh-pages branch, though they offer Pelican instead of Jekyll. Though since Commons sites are all statically generated from Maven, it doesn't matter which you use as you can simply commit the output files to one of those special branches. On Tue, 4 Aug 2020 at 08:57, Gary Gregory wrote: > > HI Andrew, > > I think we use both CMS and Buildbot if that makes any sense [1], but > whatever it is, it's no longer working [2][3], so I'm happy to switch. > > I see GitHub pages as an option, so why not go with that. > > Commons its own site obviously but it also has a lot of components each > with their own site. Each component site does not use CMS, it is published > manually as part of a release. > > So this migration should only apply to the Commons site and not component > sites, right? > > Gary > > [1] https://commons.apache.org/site-publish.html > [2] https://ci.apache.org/builders/commons-site-staging > [3] https://issues.apache.org/jira/browse/INFRA-20632 > > > > > > On Tue, Aug 4, 2020 at 9:40 AM Andrew Wetmore wrote: > > > Hi: > > > > I am part of the Infrastructure team, and am writing to ask whether your > > project is still using the Apache CMS for your project website. As you > > know, the CMS is reaching end-of-life, and we need projects to move their > > websites onto a different option within the next few weeks. > > > > There are several alternatives available, including those listed on this > > page [1] on managing project websites. Infra is assembling a Wiki page [2] > > on migrating a website from the CMS, and is looking forward to helping > > projects with this transition. > > > > Please let me know whether your site is still on the Apache CMS and, if so, > > who will be the project point-of-contact with Infra for the migration. > > > > Thank you! > > > > > > > > > > [1] https://infra.apache.org/project-site.html > > > > [2] > > > > https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS > > > > > > -- > > Andrew Wetmore > > Technical Writer-Editor > > Infra > > *Apache Software Foundation* > > andr...@apache.org > > > > < > > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > > > Virus-free. > > www.avast.com > > < > > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: The project website
I meant they support building your site from source automatically via Pelican similar to how GitHub supports Jekyll sources to generate the HTML from. Since we generate the HTML manually from Maven, you can use either service as they both support static contents. It's only a difference if we were using another system for generating the site. On Tue, 4 Aug 2020 at 10:00, Gary Gregory wrote: > > On Tue, Aug 4, 2020 at 10:56 AM Matt Sicker wrote: > > > See also the asf-site and asf-staging branches for an Infra-supported > > site publishing system: > > https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features > > > > Seems to work fairly similar to a gh-pages branch, though they offer > > Pelican instead of Jekyll. Though since Commons sites are all > > statically generated from Maven, it doesn't matter which you use as > > you can simply commit the output files to one of those special > > branches. > > > > Hi Matt, > > I was not planning on changing how we deal with component sites, just the > Commons site itself. Or am I missing something? > > Personally, I also don't want to use Jekyl/Pelican, I'd prefer to go > straight to GitHub. > > Gary > > > > > > On Tue, 4 Aug 2020 at 08:57, Gary Gregory wrote: > > > > > > HI Andrew, > > > > > > I think we use both CMS and Buildbot if that makes any sense [1], but > > > whatever it is, it's no longer working [2][3], so I'm happy to switch. > > > > > > I see GitHub pages as an option, so why not go with that. > > > > > > Commons its own site obviously but it also has a lot of components each > > > with their own site. Each component site does not use CMS, it is > > published > > > manually as part of a release. > > > > > > So this migration should only apply to the Commons site and not component > > > sites, right? > > > > > > Gary > > > > > > [1] https://commons.apache.org/site-publish.html > > > [2] https://ci.apache.org/builders/commons-site-staging > > > [3] https://issues.apache.org/jira/browse/INFRA-20632 > > > > > > > > > > > > > > > > > > On Tue, Aug 4, 2020 at 9:40 AM Andrew Wetmore > > wrote: > > > > > > > Hi: > > > > > > > > I am part of the Infrastructure team, and am writing to ask whether > > your > > > > project is still using the Apache CMS for your project website. As you > > > > know, the CMS is reaching end-of-life, and we need projects to move > > their > > > > websites onto a different option within the next few weeks. > > > > > > > > There are several alternatives available, including those listed on > > this > > > > page [1] on managing project websites. Infra is assembling a Wiki page > > [2] > > > > on migrating a website from the CMS, and is looking forward to helping > > > > projects with this transition. > > > > > > > > Please let me know whether your site is still on the Apache CMS and, > > if so, > > > > who will be the project point-of-contact with Infra for the migration. > > > > > > > > Thank you! > > > > > > > > > > > > > > > > > > > > [1] https://infra.apache.org/project-site.html > > > > > > > > [2] > > > > > > > > > > https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS > > > > > > > > > > > > -- > > > > Andrew Wetmore > > > > Technical Writer-Editor > > > > Infra > > > > *Apache Software Foundation* > > > > andr...@apache.org > > > > > > > > < > > > > > > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > > > > > > > Virus-free. > > > > www.avast.com > > > > < > > > > > > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > > > > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > > > > > > > > > > > -- > > Matt Sicker > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CRYPTO] Random AEADBadTagException in GcmCipherTest?
Now I hope we don't have unit tests depending on non-static state for its random number generator! ;) I'd expect a crypto library's test suites to include several hard-coded known-good and known-bad ciphertexts with static keys/IVs similar to the test cases presented in their RFCs (especially since said tests are typically small enough to copy/paste the binary data fairly easily). On Thu, 6 Aug 2020 at 08:19, Gary Gregory wrote: > > On Thu, Aug 6, 2020 at 8:31 AM Alex Remily wrote: > > > No problem. I'll do it when I get home tonight. > > > > Thanks Alex! > > Gary > > > > > > On Thu, Aug 6, 2020, 8:25 AM Gary Gregory wrote: > > > > > Hi Alex, > > > > > > Would you mind creating that ticket with that info? > > > > > > Thank you, > > > Gary > > > > > > On Thu, Aug 6, 2020, 08:10 Alex Remily wrote: > > > > > > > That is an intermittent issue that I haven't been able to reliably > > > > reproduce. As I recall, the test that's failing is supposed to fail, > > but > > > > in a different way. I think it's supposed to fail because of a short > > > > buffer but occasionally fails because of an internal error, and when > > that > > > > happens this test fails. I don't know when it was introduced. We > > should > > > > probably document it in jira and or realese notes. > > > > > > > > On Wed, Aug 5, 2020, 10:53 PM Gary Gregory > > > wrote: > > > > > > > > > Hi All: > > > > > > > > > > I am seeing what may be a random AEADBadTagException in > > GcmCipherTest? > > > > > > > > > > For example: > > > > > > > > > > [ERROR] > > > > testGcmTamperedData(org.apache.commons.crypto.cipher.GcmCipherTest) > > > > > Time elapsed: 0.015 s <<< ERROR! > > > > > 881java.lang.Exception: Unexpected exception, > > > > > expected but > > > > > was > > > > > 882 at > > > > > > > > > > > > > > org.apache.commons.crypto.cipher.GcmCipherTest.testGcmTamperedData(GcmCipherTest.java:224) > > > > > 883 > > > > > 884 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Any thoughts? > > > > > > > > > > The above is from > > > > > https://travis-ci.org/github/apache/commons-crypto/jobs/715348986 > > > > > > > > > > Gary > > > > > > > > > > > > > > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CRYPTO] Random AEADBadTagException in GcmCipherTest?
Well, for testing RNGs, I can understand using property testing, yes. It would also be useful for testing fuzzing scenarios like making sure the GCM tag is invalid for any random input data (giving a near zero probability of valid data) or that an elliptic curve implementation doesn't leak out information about points outside the curve or respond to invalid inputs improperly or things like that. On Thu, 6 Aug 2020 at 09:37, Rob Tompkins wrote: > > > > > On Aug 6, 2020, at 10:33 AM, Matt Sicker wrote: > > > > Now I hope we don't have unit tests depending on non-static state for > > its random number generator! ;) > > We actually do have a considerable number of those in our projects where we > use probabilistic epsilons on the output. See commons-rng. Note, Gilles is > quite good at writing such tests. > > -Rob > > > I'd expect a crypto library's test > > suites to include several hard-coded known-good and known-bad > > ciphertexts with static keys/IVs similar to the test cases presented > > in their RFCs (especially since said tests are typically small enough > > to copy/paste the binary data fairly easily). > > > > On Thu, 6 Aug 2020 at 08:19, Gary Gregory wrote: > >> > >> On Thu, Aug 6, 2020 at 8:31 AM Alex Remily wrote: > >> > >>> No problem. I'll do it when I get home tonight. > >>> > >> > >> Thanks Alex! > >> > >> Gary > >> > >> > >>> > >>> On Thu, Aug 6, 2020, 8:25 AM Gary Gregory wrote: > >>> > >>>> Hi Alex, > >>>> > >>>> Would you mind creating that ticket with that info? > >>>> > >>>> Thank you, > >>>> Gary > >>>> > >>>> On Thu, Aug 6, 2020, 08:10 Alex Remily wrote: > >>>> > >>>>> That is an intermittent issue that I haven't been able to reliably > >>>>> reproduce. As I recall, the test that's failing is supposed to fail, > >>> but > >>>>> in a different way. I think it's supposed to fail because of a short > >>>>> buffer but occasionally fails because of an internal error, and when > >>> that > >>>>> happens this test fails. I don't know when it was introduced. We > >>> should > >>>>> probably document it in jira and or realese notes. > >>>>> > >>>>> On Wed, Aug 5, 2020, 10:53 PM Gary Gregory > >>>> wrote: > >>>>> > >>>>>> Hi All: > >>>>>> > >>>>>> I am seeing what may be a random AEADBadTagException in > >>> GcmCipherTest? > >>>>>> > >>>>>> For example: > >>>>>> > >>>>>> [ERROR] > >>>>> testGcmTamperedData(org.apache.commons.crypto.cipher.GcmCipherTest) > >>>>>> Time elapsed: 0.015 s <<< ERROR! > >>>>>> 881java.lang.Exception: Unexpected exception, > >>>>>> expected but > >>>>>> was > >>>>>> 882 at > >>>>>> > >>>>> > >>>> > >>> org.apache.commons.crypto.cipher.GcmCipherTest.testGcmTamperedData(GcmCipherTest.java:224) > >>>>>> 883 > >>>>>> 884 > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> Any thoughts? > >>>>>> > >>>>>> The above is from > >>>>>> https://travis-ci.org/github/apache/commons-crypto/jobs/715348986 > >>>>>> > >>>>>> 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 > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CRYPTO] Random AEADBadTagException in GcmCipherTest?
The ECC stuff I mostly learned about from various Bernstein papers like this one: https://cr.yp.to/newelliptic/nistecc-20160106.pdf On Thu, 6 Aug 2020 at 09:50, Rob Tompkins wrote: > > > > > On Aug 6, 2020, at 10:42 AM, Matt Sicker wrote: > > > > Well, for testing RNGs, I can understand using property testing, yes. > > It would also be useful for testing fuzzing scenarios like making sure > > the GCM tag is invalid for any random input data (giving a near zero > > probability of valid data) or that an elliptic curve implementation > > doesn't leak out information about points outside the curve or respond > > to invalid inputs improperly or things like that. > > +1 - the elliptic curve stuff I’ll have to defer to you on as I’m less a > number theorist and more of a logician. > > -Rob > > > > > On Thu, 6 Aug 2020 at 09:37, Rob Tompkins wrote: > >> > >> > >> > >>> On Aug 6, 2020, at 10:33 AM, Matt Sicker wrote: > >>> > >>> Now I hope we don't have unit tests depending on non-static state for > >>> its random number generator! ;) > >> > >> We actually do have a considerable number of those in our projects where > >> we use probabilistic epsilons on the output. See commons-rng. Note, Gilles > >> is quite good at writing such tests. > >> > >> -Rob > >> > >>> I'd expect a crypto library's test > >>> suites to include several hard-coded known-good and known-bad > >>> ciphertexts with static keys/IVs similar to the test cases presented > >>> in their RFCs (especially since said tests are typically small enough > >>> to copy/paste the binary data fairly easily). > >>> > >>> On Thu, 6 Aug 2020 at 08:19, Gary Gregory wrote: > >>>> > >>>> On Thu, Aug 6, 2020 at 8:31 AM Alex Remily wrote: > >>>> > >>>>> No problem. I'll do it when I get home tonight. > >>>>> > >>>> > >>>> Thanks Alex! > >>>> > >>>> Gary > >>>> > >>>> > >>>>> > >>>>> On Thu, Aug 6, 2020, 8:25 AM Gary Gregory > >>>>> wrote: > >>>>> > >>>>>> Hi Alex, > >>>>>> > >>>>>> Would you mind creating that ticket with that info? > >>>>>> > >>>>>> Thank you, > >>>>>> Gary > >>>>>> > >>>>>> On Thu, Aug 6, 2020, 08:10 Alex Remily wrote: > >>>>>> > >>>>>>> That is an intermittent issue that I haven't been able to reliably > >>>>>>> reproduce. As I recall, the test that's failing is supposed to fail, > >>>>> but > >>>>>>> in a different way. I think it's supposed to fail because of a short > >>>>>>> buffer but occasionally fails because of an internal error, and when > >>>>> that > >>>>>>> happens this test fails. I don't know when it was introduced. We > >>>>> should > >>>>>>> probably document it in jira and or realese notes. > >>>>>>> > >>>>>>> On Wed, Aug 5, 2020, 10:53 PM Gary Gregory > >>>>>> wrote: > >>>>>>> > >>>>>>>> Hi All: > >>>>>>>> > >>>>>>>> I am seeing what may be a random AEADBadTagException in > >>>>> GcmCipherTest? > >>>>>>>> > >>>>>>>> For example: > >>>>>>>> > >>>>>>>> [ERROR] > >>>>>>> testGcmTamperedData(org.apache.commons.crypto.cipher.GcmCipherTest) > >>>>>>>> Time elapsed: 0.015 s <<< ERROR! > >>>>>>>> 881java.lang.Exception: Unexpected exception, > >>>>>>>> expected but > >>>>>>>> was > >>>>>>>> 882 at > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> org.apache.commons.crypto.cipher.GcmCipherTest.testGcmTamperedData(GcmCipherTest.java:224) > >>>>>>>> 883 > >>>>>>>> 884 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Any thoughts? > >>>>>>>> > >>>>>>>> The above is from > >>>>>>>> https://travis-ci.org/github/apache/commons-crypto/jobs/715348986 > >>>>>>>> > >>>>>>>> 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 > >> > > > > > > -- > > 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 > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CRYPTO] Random AEADBadTagException in GcmCipherTest?
Choose a seed value for the `new Random()` constructor and the tests will be deterministic. On Thu, 6 Aug 2020 at 09:57, Rob Tompkins wrote: > > > > > On Aug 6, 2020, at 10:56 AM, Gary Gregory wrote: > > > > This is all fine and good but how would you fix the test such that it does > > not fail randomly. PR anyone? > > Either static inputs for determinism, or putting a probabilistic boundary in > which the solution can fall. > > -Rob > > > > > Gary > > > > On Thu, Aug 6, 2020 at 10:54 AM Matt Sicker wrote: > > > >> The ECC stuff I mostly learned about from various Bernstein papers > >> like this one: https://cr.yp.to/newelliptic/nistecc-20160106.pdf > >> > >> On Thu, 6 Aug 2020 at 09:50, Rob Tompkins wrote: > >>> > >>> > >>> > >>>> On Aug 6, 2020, at 10:42 AM, Matt Sicker wrote: > >>>> > >>>> Well, for testing RNGs, I can understand using property testing, yes. > >>>> It would also be useful for testing fuzzing scenarios like making sure > >>>> the GCM tag is invalid for any random input data (giving a near zero > >>>> probability of valid data) or that an elliptic curve implementation > >>>> doesn't leak out information about points outside the curve or respond > >>>> to invalid inputs improperly or things like that. > >>> > >>> +1 - the elliptic curve stuff I’ll have to defer to you on as I’m less a > >> number theorist and more of a logician. > >>> > >>> -Rob > >>> > >>>> > >>>> On Thu, 6 Aug 2020 at 09:37, Rob Tompkins wrote: > >>>>> > >>>>> > >>>>> > >>>>>> On Aug 6, 2020, at 10:33 AM, Matt Sicker wrote: > >>>>>> > >>>>>> Now I hope we don't have unit tests depending on non-static state for > >>>>>> its random number generator! ;) > >>>>> > >>>>> We actually do have a considerable number of those in our projects > >> where we use probabilistic epsilons on the output. See commons-rng. Note, > >> Gilles is quite good at writing such tests. > >>>>> > >>>>> -Rob > >>>>> > >>>>>> I'd expect a crypto library's test > >>>>>> suites to include several hard-coded known-good and known-bad > >>>>>> ciphertexts with static keys/IVs similar to the test cases presented > >>>>>> in their RFCs (especially since said tests are typically small enough > >>>>>> to copy/paste the binary data fairly easily). > >>>>>> > >>>>>> On Thu, 6 Aug 2020 at 08:19, Gary Gregory > >> wrote: > >>>>>>> > >>>>>>> On Thu, Aug 6, 2020 at 8:31 AM Alex Remily > >> wrote: > >>>>>>> > >>>>>>>> No problem. I'll do it when I get home tonight. > >>>>>>>> > >>>>>>> > >>>>>>> Thanks Alex! > >>>>>>> > >>>>>>> Gary > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> On Thu, Aug 6, 2020, 8:25 AM Gary Gregory > >> wrote: > >>>>>>>> > >>>>>>>>> Hi Alex, > >>>>>>>>> > >>>>>>>>> Would you mind creating that ticket with that info? > >>>>>>>>> > >>>>>>>>> Thank you, > >>>>>>>>> Gary > >>>>>>>>> > >>>>>>>>> On Thu, Aug 6, 2020, 08:10 Alex Remily > >> wrote: > >>>>>>>>> > >>>>>>>>>> That is an intermittent issue that I haven't been able to > >> reliably > >>>>>>>>>> reproduce. As I recall, the test that's failing is supposed to > >> fail, > >>>>>>>> but > >>>>>>>>>> in a different way. I think it's supposed to fail because of a > >> short > >>>>>>>>>> buffer but occasionally fails because of an internal error, and > >> when > >>>>>>>> that > >>>>>>>>>> happens this t
Re: [CRYPTO] Random AEADBadTagException in GcmCipherTest?
Or alternatively, if using random values each time, have it retry the test with a different value. It's typically better to use an actual property testing library for these types of tests anyways. One example library I found is https://jqwik.net/ (these types of testing libraries are more common in functional programming like in Scala). On Thu, 6 Aug 2020 at 09:59, Matt Sicker wrote: > > Choose a seed value for the `new Random()` constructor and the tests > will be deterministic. > > On Thu, 6 Aug 2020 at 09:57, Rob Tompkins wrote: > > > > > > > > > On Aug 6, 2020, at 10:56 AM, Gary Gregory wrote: > > > > > > This is all fine and good but how would you fix the test such that it does > > > not fail randomly. PR anyone? > > > > Either static inputs for determinism, or putting a probabilistic boundary > > in which the solution can fall. > > > > -Rob > > > > > > > > Gary > > > > > > On Thu, Aug 6, 2020 at 10:54 AM Matt Sicker wrote: > > > > > >> The ECC stuff I mostly learned about from various Bernstein papers > > >> like this one: https://cr.yp.to/newelliptic/nistecc-20160106.pdf > > >> > > >> On Thu, 6 Aug 2020 at 09:50, Rob Tompkins wrote: > > >>> > > >>> > > >>> > > >>>> On Aug 6, 2020, at 10:42 AM, Matt Sicker wrote: > > >>>> > > >>>> Well, for testing RNGs, I can understand using property testing, yes. > > >>>> It would also be useful for testing fuzzing scenarios like making sure > > >>>> the GCM tag is invalid for any random input data (giving a near zero > > >>>> probability of valid data) or that an elliptic curve implementation > > >>>> doesn't leak out information about points outside the curve or respond > > >>>> to invalid inputs improperly or things like that. > > >>> > > >>> +1 - the elliptic curve stuff I’ll have to defer to you on as I’m less a > > >> number theorist and more of a logician. > > >>> > > >>> -Rob > > >>> > > >>>> > > >>>> On Thu, 6 Aug 2020 at 09:37, Rob Tompkins wrote: > > >>>>> > > >>>>> > > >>>>> > > >>>>>> On Aug 6, 2020, at 10:33 AM, Matt Sicker wrote: > > >>>>>> > > >>>>>> Now I hope we don't have unit tests depending on non-static state for > > >>>>>> its random number generator! ;) > > >>>>> > > >>>>> We actually do have a considerable number of those in our projects > > >> where we use probabilistic epsilons on the output. See commons-rng. Note, > > >> Gilles is quite good at writing such tests. > > >>>>> > > >>>>> -Rob > > >>>>> > > >>>>>> I'd expect a crypto library's test > > >>>>>> suites to include several hard-coded known-good and known-bad > > >>>>>> ciphertexts with static keys/IVs similar to the test cases presented > > >>>>>> in their RFCs (especially since said tests are typically small enough > > >>>>>> to copy/paste the binary data fairly easily). > > >>>>>> > > >>>>>> On Thu, 6 Aug 2020 at 08:19, Gary Gregory > > >> wrote: > > >>>>>>> > > >>>>>>> On Thu, Aug 6, 2020 at 8:31 AM Alex Remily > > >> wrote: > > >>>>>>> > > >>>>>>>> No problem. I'll do it when I get home tonight. > > >>>>>>>> > > >>>>>>> > > >>>>>>> Thanks Alex! > > >>>>>>> > > >>>>>>> Gary > > >>>>>>> > > >>>>>>> > > >>>>>>>> > > >>>>>>>> On Thu, Aug 6, 2020, 8:25 AM Gary Gregory > > >> wrote: > > >>>>>>>> > > >>>>>>>>> Hi Alex, > > >>>>>>>>> > > >>>>>>>>> Would you mind creating that ticket with that info? > > >>>>>>>>> > > >>>>>>>>> Thank you, > > >>>>>>>>>
Re: [IO] Test failures on Windows
That sounds like a file modification time granularity issue. Does Windows not support milliseconds or finer for file modification times? It could be that the test executed too fast! On Fri, Aug 7, 2020 at 09:01 Gary Gregory wrote: > As of recently, I am seing: > > [INFO] Running org.apache.commons.io.FileUtilsTestCase > [ERROR] Tests run: 142, Failures: 2, Errors: 0, Skipped: 1, Time elapsed: > 5.613 s <<< FAILURE! - in org.apache.commons.io.FileUtilsTestCase > [ERROR] testCopyFile2WithoutFileDatePreservation Time elapsed: 0.038 s > <<< FAILURE! > org.opentest4j.AssertionFailedError: Check last modified date not same as > input ==> expected: not equal but was: <1596807101505> > at > org.apache.commons.io > .FileUtilsTestCase.testCopyFile2WithoutFileDatePreservation(FileUtilsTestCase.java:1229) > > [ERROR] testCopyDirectoryPreserveDates Time elapsed: 0.027 s <<< FAILURE! > org.opentest4j.AssertionFailedError: expected: but was: > at > org.apache.commons.io > .FileUtilsTestCase.testCopyDirectoryPreserveDates(FileUtilsTestCase.java:1403) > > I am wondering if GitHub/Travis can also be set up to run at least one > build on Windows so we can catch issues like these? > > Gary > -- Matt Sicker
Re: [IO] Test failures on Windows
You can basically copy the GitHub Actions setup we have in log4j2 minus the toolchains stuff (unless you need that too). GHA looks to support macOS runners as well. On Fri, Aug 7, 2020 at 09:07 Xeno Amess wrote: > there be document on travis-ci about windows environment but I havn't seen > any java repo using it > https://docs.travis-ci.com/user/reference/windows/ > > besides if my memory be correct, there be another site who have free > windows environment. > https://www.appveyor.com/ > > Gary Gregory 于2020年8月7日周五 下午10:01写道： > > > As of recently, I am seing: > > > > [INFO] Running org.apache.commons.io.FileUtilsTestCase > > [ERROR] Tests run: 142, Failures: 2, Errors: 0, Skipped: 1, Time elapsed: > > 5.613 s <<< FAILURE! - in org.apache.commons.io.FileUtilsTestCase > > [ERROR] testCopyFile2WithoutFileDatePreservation Time elapsed: 0.038 s > > <<< FAILURE! > > org.opentest4j.AssertionFailedError: Check last modified date not same as > > input ==> expected: not equal but was: <1596807101505> > > at > > org.apache.commons.io > > > .FileUtilsTestCase.testCopyFile2WithoutFileDatePreservation(FileUtilsTestCase.java:1229) > > > > [ERROR] testCopyDirectoryPreserveDates Time elapsed: 0.027 s <<< > FAILURE! > > org.opentest4j.AssertionFailedError: expected: but was: > > at > > org.apache.commons.io > > > .FileUtilsTestCase.testCopyDirectoryPreserveDates(FileUtilsTestCase.java:1403) > > > > I am wondering if GitHub/Travis can also be set up to run at least one > > build on Windows so we can catch issues like these? > > > > Gary > > > -- Matt Sicker
Re: [IO] Test failures on Windows
Even if it’s fixed upstream, it’ll never get backported most likely. Even compiler bugs aren’t backported (see for example a bug related to reflection on intersection types that was fixed in Java 9; I can’t find an exact reference, but multiple bugs related to this were all address in 9). On Fri, Aug 7, 2020 at 12:03 sebb wrote: > If so, then it is not sufficient to run tests on Windows, it looks > like we need to run tests on Windows with the appropriate version of > Java. > > Presumably that is why Jenkins did not show the error. > > However, fixing the test won't fix the code - there may be instances > of lastModified elsewhere. > > The Java bug needs to be fixed. > > > On Fri, 7 Aug 2020 at 17:12, Gary Gregory wrote: > > > > On Fri, Aug 7, 2020 at 10:04 AM Matt Sicker wrote: > > > > > That sounds like a file modification time granularity issue. Does > Windows > > > not support milliseconds or finer for file modification times? It > could be > > > that the test executed too fast! > > > > > > > This might be a classic bug I've run into at work: > > https://bugs.openjdk.java.net/browse/JDK-8177809 > > > > Basically, never use File.lastModified(), use > Files.getLastModifiedTime(). > > > > Gary > > > > > > > > > > On Fri, Aug 7, 2020 at 09:01 Gary Gregory > wrote: > > > > > > > As of recently, I am seing: > > > > > > > > [INFO] Running org.apache.commons.io.FileUtilsTestCase > > > > [ERROR] Tests run: 142, Failures: 2, Errors: 0, Skipped: 1, Time > elapsed: > > > > 5.613 s <<< FAILURE! - in org.apache.commons.io.FileUtilsTestCase > > > > [ERROR] testCopyFile2WithoutFileDatePreservation Time elapsed: > 0.038 s > > > > <<< FAILURE! > > > > org.opentest4j.AssertionFailedError: Check last modified date not > same as > > > > input ==> expected: not equal but was: <1596807101505> > > > > at > > > > org.apache.commons.io > > > > > > > > .FileUtilsTestCase.testCopyFile2WithoutFileDatePreservation(FileUtilsTestCase.java:1229) > > > > > > > > [ERROR] testCopyDirectoryPreserveDates Time elapsed: 0.027 s <<< > > > FAILURE! > > > > org.opentest4j.AssertionFailedError: expected: but was: > > > > > at > > > > org.apache.commons.io > > > > > > > > .FileUtilsTestCase.testCopyDirectoryPreserveDates(FileUtilsTestCase.java:1403) > > > > > > > > I am wondering if GitHub/Travis can also be set up to run at least > one > > > > build on Windows so we can catch issues like these? > > > > > > > > Gary > > > > > > > -- > > > Matt Sicker > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [IO] Test failures on Windows
That's what I meant; bug fixes will be included in normal releases. It's actually fairly similar to how the Jenkins LTS process works in that LTS releases are basically just points chosen in time to maintain as branches for backporting security fixes (slight difference being that in Jenkins, we "upmerge" security fixes instead of backporting for maximum compatibility) while everything else continues to be released early and often (though Jenkins does weekly releases instead of every 26 weeks like Java, and our LTS releases are more in line with Java's regular release schedule). As to what to do about broken code from upstream? We can make a shim utility class for detecting if the bug is present and selecting the appropriate behavior at runtime, or perhaps the production code should be updated to use the NIO2 APIs which work properly unlike the old File API. On Sat, 8 Aug 2020 at 10:50, Gary Gregory wrote: > > FWIW, there recently was a bug found by Commons Lang in Java 15 and 16. > Java 16 has now fixed the bug but it will not be fixed in Java 15, at > least not before GA. > > > Gary > > On Sat, Aug 8, 2020, 11:45 Matt Sicker wrote: > > > Even if it’s fixed upstream, it’ll never get backported most likely. Even > > compiler bugs aren’t backported (see for example a bug related to > > reflection on intersection types that was fixed in Java 9; I can’t find an > > exact reference, but multiple bugs related to this were all address in 9). > > > > On Fri, Aug 7, 2020 at 12:03 sebb wrote: > > > > > If so, then it is not sufficient to run tests on Windows, it looks > > > like we need to run tests on Windows with the appropriate version of > > > Java. > > > > > > Presumably that is why Jenkins did not show the error. > > > > > > However, fixing the test won't fix the code - there may be instances > > > of lastModified elsewhere. > > > > > > The Java bug needs to be fixed. > > > > > > > > > On Fri, 7 Aug 2020 at 17:12, Gary Gregory > > wrote: > > > > > > > > On Fri, Aug 7, 2020 at 10:04 AM Matt Sicker wrote: > > > > > > > > > That sounds like a file modification time granularity issue. Does > > > Windows > > > > > not support milliseconds or finer for file modification times? It > > > could be > > > > > that the test executed too fast! > > > > > > > > > > > > > This might be a classic bug I've run into at work: > > > > https://bugs.openjdk.java.net/browse/JDK-8177809 > > > > > > > > Basically, never use File.lastModified(), use > > > Files.getLastModifiedTime(). > > > > > > > > Gary > > > > > > > > > > > > > > > > > > On Fri, Aug 7, 2020 at 09:01 Gary Gregory > > > wrote: > > > > > > > > > > > As of recently, I am seing: > > > > > > > > > > > > [INFO] Running org.apache.commons.io.FileUtilsTestCase > > > > > > [ERROR] Tests run: 142, Failures: 2, Errors: 0, Skipped: 1, Time > > > elapsed: > > > > > > 5.613 s <<< FAILURE! - in org.apache.commons.io.FileUtilsTestCase > > > > > > [ERROR] testCopyFile2WithoutFileDatePreservation Time elapsed: > > > 0.038 s > > > > > > <<< FAILURE! > > > > > > org.opentest4j.AssertionFailedError: Check last modified date not > > > same as > > > > > > input ==> expected: not equal but was: <1596807101505> > > > > > > at > > > > > > org.apache.commons.io > > > > > > > > > > > > > > > > .FileUtilsTestCase.testCopyFile2WithoutFileDatePreservation(FileUtilsTestCase.java:1229) > > > > > > > > > > > > [ERROR] testCopyDirectoryPreserveDates Time elapsed: 0.027 s <<< > > > > > FAILURE! > > > > > > org.opentest4j.AssertionFailedError: expected: but was: > > > > > > > > > at > > > > > > org.apache.commons.io > > > > > > > > > > > > > > > > .FileUtilsTestCase.testCopyDirectoryPreserveDates(FileUtilsTestCase.java:1403) > > > > > > > > > > > > I am wondering if GitHub/Travis can also be set up to run at least > > > one > > > > > > build on Windows so we can catch issues like these? > > > > > > > > > > > > Gary > > > > > > > > > > > -- > > > > > Matt Sicker > > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > -- > > Matt Sicker > > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [crypto] Releasing 1.1.0 with Mac64 support
Can convenience binaries be voted on separately from the regular source release? If so, it might be easier to get the source out first along with release binaries as they're created. On Sun, 9 Aug 2020 at 06:13, sebb wrote: > > It occurs to me that we don't *have* to release binaries. > > We could just release the source, as is done by several other ASF > projects (including httpd). > > Sebb. > > On Mon, 3 Aug 2020 at 15:15, Geoffrey Blake > wrote: > > > > Hi Gary, has a solution for the Mac build been reached? Do you > > require some assistance here? As Bindul suggested, Travis has support > > for uploading artifacts to AWS S3: > > > > https://docs.travis-ci.com/user/uploading-artifacts/ > > > > This may alleviate the issue with accepting an unknown artifact, and > > with Travis, you have more confidence the artifact not only built but > > passed unit-tests as well. > > > > -Geoff > > > > On Mon, Jul 27, 2020 at 2:26 PM Bindul Bhowmik > > wrote: > > > > > > Hi Gary, > > > > > > (Please ignore if it has been discussed already) > > > > > > On Mon, Jul 27, 2020 at 12:07 PM Gary Gregory > > > wrote: > > > > > > > > Hi All, > > > > > > > > Thanks to Geoffrey Blake's help setting up a Docker Ubuntu Trusty > > > > (14.04) > > > > environment, I am working toward creating an RC for 1.1.0, but in order > > > > to > > > > get Mac64 support we are quite sure I need to build that binary on a > > > > Mac, > > > > which I do not own or have simple access to. > > > > > > > > Is there an acceptable workflow for me, the Release Manager, to procure > > > > said binary from another person? Does that person need to be on the > > > > Commons > > > > PMC, a Commons Committer, an Apache Commons, an Apache Member, or can > > > > it be > > > > Anyone? > > > > > > > > There is an obvious trust issue here since I would not be the one > > > > building > > > > the Mac64 binary but would be delivering it through our dist area and > > > > Maven > > > > Central. > > > > > > commons-crypto is built on OSX on travis. So, a thought on getting the > > > binaries out of that: > > > If you had a place for travis to upload the artifacts: you could fork > > > the repo, alter the .travis.yml to add a deployment step to upload the > > > built OSX binaries to your location. I think this gets you, the > > > release manager, a known good binary. You can add whatever 'on' > > > conditions for the deploy to only upload binaries from the tag, etc. I > > > am suggesting forking the repo, so the altered .travis.yml is not in > > > the release source tag and the secrets to upload the binary are only > > > in your github/travis org. > > > > > > > > > > > Yes, I know that in theory, Apache only delivers source code and that > > > > our > > > > binary distributions are only a convenience, so there might be nothing > > > > to > > > > talk about, still, I want to make sure to check on expectations and > > > > processes. > > > > > > > > Gary > > > > > > Bindul > > > > - > > 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 > -- Matt Sicker - 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
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
Re: [all] cicd philosophy (was: Re: Introducing Maven Wrapper)
I'll note that at least from a Jenkins point of view (probably similar with GitHub Actions), it's easier to set up your CI config to use the Maven wrapper script instead of configuring a Maven tool (Jenkins) or using a specific Docker image or similar extra config. We've had a wrapper script in Log4j for a while which is used in our GitHub Actions workflow: https://github.com/apache/logging-log4j2/blob/master/.github/workflows/maven.yml Compare to the more complicated configuration for Maven without the wrapper (I hard-coded known paths here instead of using the "tool" DSL, but it's the same idea): https://github.com/apache/logging-pipelines/blob/master/vars/mvn.groovy On Sat, 15 Aug 2020 at 12:22, Rob Tompkins wrote: > > Hello all, > > I first want to thank John for bringing these points to light as I think we > can have quite a healthy discussion about the CI/CD philosophy employed by > the project (Apache Commons) generally. Furthermore, I hope to set precedent > with intent and direction with the following comments. Note, these are merely > ideas yet to be set in stone. I would propose that we draft the ideas using > this thread and potentially have a PMC level/committer/user level [POLL] (to > be handled on the dev@ list) on direction following debate and drafting. I > quite enjoy suggestions and ideas from all areas and take quite seriously the > suggestions of any user of the project. :-) > > Having worked with ./mvnw extensively during $work over the last 5 years, I’m > quite hesitant to use it in CI. Note, we intentionally have NO continuous > deployment as we GPG sign all of our artifacts locally, and we intentionally > do not publish snapshots as we don’t want people actively consuming our > inflight development work. We use beta releases instead for this purpose. > Furthermore, all of our CI processes have explicit declarations for a various > array of different java versions (open to varying across maven versions > here). But do note that they are indeed all quite hard coded in our github > actions files, towards which we are migrating. > > All that said, I do indeed see quite a good argument for including ./mvnw in > the project and that is to expedite developer productivity by helping to > install the latest version of Apache Maven, and I want to be clear here that > we only want to install the latest version of Apache Maven as we very much do > not want to be prescriptive with our java versioning. We, in fact, work quite > hard to maintain backwards compatibility to the oldest freely available > supported (long-term-support) version of java. > > I also wonder, but am unsure of the potential here with either GitHub’s > actions or GitHubs dependabot, if we can automate upversioning maven to it’s > latest version in said .properties files. > > Thoughts? > > Cheers, > -Rob > > > On Aug 15, 2020, at 9:45 AM, 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 > > > > 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 > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Matt Sicker - 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
Travis isn't donated; the ASF pays for a subscription of some sort. It's likely discounted, but it's still ASF infra in that sense. On Sat, 15 Aug 2020 at 16: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 > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] so what should we do for the failing test on jdk15?
I like the test strategy they’re using at Mina: 8, latest LTS, and latest release. Those are the main supported lines of OpenJDK (from their distributors at least; I don’t think the project has official support), and since other versions won’t receive updates, there’s not much point in continued use. On Mon, Aug 24, 2020 at 04:51 Xeno Amess wrote: > Hi. > > There exist a bug on jdk15, and which results a test failed on jdk15 for > > commons-lang. > > JDK guys said they will fix it on jdk16 but no plan for migrating the fix > > to jdk15. > > So maybe we should shut that test on jdk15, or we filter out some buggy > > parts in that test and do not do it on jdk15? > > Any ideas? > > -- Matt Sicker
Re: [Crypto] requesting help testing native binaries
ersions: > > > > > > > > > > > > openssl version > > > > > > OpenSSL 1.1.1g 21 Apr 2020 > > > > > > > > > > > > mvn -version > > > > > > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) > > > > > > Maven home: /opt/apache-maven-3.6.3 > > > > > > Java version: 1.8.0_265, vendor: AdoptOpenJDK, runtime: > > > > > > > > > /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre > > > > > > Default locale: en_US, platform encoding: UTF-8 > > > > > > OS name: "mac os x", version: "10.15.6", arch: "x86_64", family: > > > "mac" > > > > > > > > > > > > Thank you, > > > > > > Gary > > > > > > > > > > > > > > > > > > On Sat, Aug 22, 2020 at 7:48 PM Gary Gregory < > > garydgreg...@gmail.com > > > > > > > > > wrote: > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > I intent on creating a release candidate for Commons Crypto soon. > > > > > > > > > > > > > > I pushed a snapshot today which contains native binaries for > > > Windows 32 > > > > > > > and 64, Linux 32 and 64, Mac 64, and ARM and ARM HF. > > > > > > > > > > > > > > Please help testing these on whatever platforms you may have > > > access to. > > > > > > > > > > > > > > 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 > > > > > > > > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: opinions about @NotNull and @Nullable ?
We use the findbugs annotations fairly extensively in Jenkins, and with the proper plugins, it’s helped a lot for nullability checking. On Mon, Aug 24, 2020 at 23:54 Xeno Amess wrote: > Hi. > > Today I see a pr have similar ideas with this, so I will suggest we > > consider it again. > > at [LANG-1598 <https://issues.apache.org/jira/browse/LANG-1598>] > > He suggest a google annotations repo, and I'd prefer the one from > > jetbrains, but that is not key point. > > Key point is, should we consider about adding such Annotations? > > Adding such annotations can help: > > 1. make people who want to modify the function sure whether each > > param/return value can be null, and make sure do not change it. > > It has better readability than any other ways. > > 2. make people who invoke these functions have a clear idea whether this > > function can return null. > > And more importantly maybe, let the ide also knows whether this function > > can return null. > > That will simplify a lot of human time to check. > > > > Any ideas? > > > > Xeno Amess 于2020年4月24日周五 下午6:50写道： > > > > > I want to know about your opinions about @NotNull and @Nullable. > > > > > > Should we use it in every function? > > > Or we use it only at some misleading places? > > > Or simply not use them at all? > > > > > > thx. > > > > > > > > -- Matt Sicker
Re: opinions about @NotNull and @Nullable ?
Annotations like this don't need to be present at runtime. They can exist only in the source code like that. On Tue, 25 Aug 2020 at 14:08, sebb wrote: > > On Tue, 25 Aug 2020 at 19:48, Xeno Amess wrote: > > > > in maven, dependency can be provided > > AFAIK that means Maven won't download the dependency. > Surely that makes it harder for the developer? > > > sebb 于2020年8月26日周三 上午2:45写道： > > > > > Won't this mean that every component has to have a dependency on the > > > tag library? > > > > > > > > > On Tue, 25 Aug 2020 at 14:45, Matt Sicker wrote: > > > > > > > > We use the findbugs annotations fairly extensively in Jenkins, and with > > > the > > > > proper plugins, it’s helped a lot for nullability checking. > > > > > > > > On Mon, Aug 24, 2020 at 23:54 Xeno Amess wrote: > > > > > > > > > Hi. > > > > > > > > > > Today I see a pr have similar ideas with this, so I will suggest we > > > > > > > > > > consider it again. > > > > > > > > > > at [LANG-1598 <https://issues.apache.org/jira/browse/LANG-1598>] > > > > > > > > > > He suggest a google annotations repo, and I'd prefer the one from > > > > > > > > > > jetbrains, but that is not key point. > > > > > > > > > > Key point is, should we consider about adding such Annotations? > > > > > > > > > > Adding such annotations can help: > > > > > > > > > > 1. make people who want to modify the function sure whether each > > > > > > > > > > param/return value can be null, and make sure do not change it. > > > > > > > > > > It has better readability than any other ways. > > > > > > > > > > 2. make people who invoke these functions have a clear idea whether > > > this > > > > > > > > > > function can return null. > > > > > > > > > > And more importantly maybe, let the ide also knows whether this > > > function > > > > > > > > > > can return null. > > > > > > > > > > That will simplify a lot of human time to check. > > > > > > > > > > > > > > > > > > > > Any ideas? > > > > > > > > > > > > > > > > > > > > Xeno Amess 于2020年4月24日周五 下午6:50写道： > > > > > > > > > > > > > > > > > > > > > I want to know about your opinions about @NotNull and @Nullable. > > > > > > > > > > > > > > > > > > > > > > Should we use it in every function? > > > > > > > > > > > Or we use it only at some misleading places? > > > > > > > > > > > Or simply not use them at all? > > > > > > > > > > > > > > > > > > > > > > thx. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > 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 > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: opinions about @NotNull and @Nullable ?
Runtime retention still doesn’t require the annotations to be present on the classpath unless you perform reflection on them (I forget the specifics). It’s a feature specific to annotations. On Tue, Aug 25, 2020 at 14:36 Jochen Wiedmann wrote: > On Tue, Aug 25, 2020 at 9:08 PM sebb wrote: > > > > > AFAIK that means Maven won't download the dependency. > > > Surely that makes it harder for the developer? > > > > No, it means that Maven won't add the dependency to a distribution. > > > > However, I've got a question: These annotations have > > @Retention(Runtime). (See > > > https://www.javadoc.io/doc/com.google.code.findbugs/jsr305/latest/javax/annotation/Nullable.html > .) > > Aren't we enforcing the presence of the respective jar at runtime? > > > > > > Jochen > > > > -- > > > > Look, that's why there's rules, understand? So that you think before > > you break 'em. > > > > -- (Terry Pratchett, Thief of Time) > > > > --------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > -- Matt Sicker
Re: opinions about @NotNull and @Nullable ?
FindBugs and SpotBugs support the annotations. I mentioned that instead of the javax package version of the annotations for the JPMS reason mentioned by someone else earlier. That’s what we’re using in Jenkins (along with a mix of which annotation sets are used, but that’s the nature of a plugin ecosystem), and it works for downstream users, too. On Wed, Aug 26, 2020 at 08:40 Gary Gregory wrote: > Does SpotBugs use these annotations? If not, can SB make use of any > > annotations? > > > > Gary > > > > On Wed, Aug 26, 2020 at 2:30 AM Romain Manni-Bucau > > wrote: > > > > > For what it is worth: > > > > > > 1. Generally speaking - and IMHO - these annotations only make sense in a > > > particular tooling setup(s) - like considering values which can be null > by > > > code analysis and not by spec (@NotNull) - which I'm not sure we have so > it > > > is mainly about making it consumer friendly but how do we guarantee our > > > meta are right and don't create false positives? Until we can guarantee > it, > > > it sounds like we can only bring drawbacks by adding it and users can > > > trivially solve it since if he already uses @NotNull he puts it in his > code > > > at a higher level anyway. > > > 2. Please don't use javax.annotation.* since, thanks JPMS, it can make > the > > > code not compilable on java >= 9 - a package must be owned by a single > > > module. (Not)Nullable static check is generally about the annotation > > > simple name and not the package so you can just duplicate the 1-2 > > > annotations you want in [lang], it is a saner compromise in today's > > > ecosystem. > > > > > > Romain Manni-Bucau > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > <https://rmannibucau.metawerx.net/> | Old Blog > > > <http://rmannibucau.wordpress.com> | Github < > > > https://github.com/rmannibucau> | > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > > < > > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > > > > > > Le mer. 26 août 2020 à 01:30, Matt Sicker a écrit : > > > > > > > Runtime retention still doesn’t require the annotations to be present > on > > > > the classpath unless you perform reflection on them (I forget the > > > > specifics). It’s a feature specific to annotations. > > > > > > > > On Tue, Aug 25, 2020 at 14:36 Jochen Wiedmann < > jochen.wiedm...@gmail.com > > > > > > > > wrote: > > > > > > > > > On Tue, Aug 25, 2020 at 9:08 PM sebb wrote: > > > > > > > > > > > > > > > > > > > > > AFAIK that means Maven won't download the dependency. > > > > > > > > > > > Surely that makes it harder for the developer? > > > > > > > > > > > > > > > > > > > > No, it means that Maven won't add the dependency to a distribution. > > > > > > > > > > > > > > > > > > > > However, I've got a question: These annotations have > > > > > > > > > > @Retention(Runtime). (See > > > > > > > > > > > > > > > > > > > > > > > https://www.javadoc.io/doc/com.google.code.findbugs/jsr305/latest/javax/annotation/Nullable.html > > > > > .) > > > > > > > > > > Aren't we enforcing the presence of the respective jar at runtime? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jochen > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > Look, that's why there's rules, understand? So that you think before > > > > > > > > > > you break 'em. > > > > > > > > > > > > > > > > > > > > -- (Terry Pratchett, Thief of Time) > > > > > > > > > > > > > > > > > > > > - > > > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > > -- > > > > Matt Sicker > > > > > > > > > -- Matt Sicker
