Re: [VOTE] Release Apache Commons JCS 3.2.1 based on rc2
Hi folks, > Am 20.04.2024 um 12:25 schrieb Thomas Vandahl : > > Hi folks, > > We have fixed a few bugs since Apache Commons JCS 3.2 was released, so I > would like to release Apache Commons JCS 3.2.1. > > Apache Commons JCS 3.2.1 rc2 is available for review here: >https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2 (svn revision > 68673) > Could I please ask for one more vote? TIA Bye, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[VFS] VFS patch release?
Hi folks, Any chance of getting a new VFS release soonish? There have been a lot of dependency updates, which would make vulnerability scanners a lot less trigger happy. 2.9.0 was released in 2021, so a 2.9.1 might not be a bad idea. Am willing to help out with this if possible. Best, Elric - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] VFS patch release?
I have a release candidate out but some files are missing, so there is something off in the build process. It's been on my to-do list, so within a week or two I hope. Gary On Mon, Apr 29, 2024 at 7:19 AM Elric V wrote: > > Hi folks, > > Any chance of getting a new VFS release soonish? There have been a lot > of dependency updates, which would make vulnerability scanners a lot > less trigger happy. 2.9.0 was released in 2021, so a 2.9.1 might not be > a bad idea. > > Am willing to help out with this if possible. > > Best, > > Elric > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] GitHub is done with Java 8
To resolve this issue in the least disruptive manner, I updated builds that need Java 8 AND macOS from "macos-lateset" to "macos-13". This is likely only a medium-term solution until GH "macos-13" support goes bye-bye. Gary On Wed, Apr 24, 2024 at 1:43 PM Slawomir Jaranowski wrote: > > Rob your project use > > Operating System > macOS > 12.7.4 > 21H1123 > > switching to macos 14 is waiting for your project. > GitHub does not switch all project in the same time. > > > śr., 24 kwi 2024 o 19:15 Rob Spoor napisał(a): > > > I've just tested one of my own projects that has a matrix setup that's > > almost the same (I haven't included Java 22), and it was successful: > > https://github.com/robtimus/application-path/actions/runs/8820506010 > > > > The main difference is that I use @v4 instead of a specific commit, but > > those should be the same right now. > > > > > > On 24/04/2024 16:27, Arnout Engelen wrote: > > > Really? https://adoptium.net/temurin/releases/?version=8 seems to have > > > recent versions. > > > > > > setup-java seems to be treating it as a bug at this time: > > > https://github.com/actions/setup-java/issues/625 > > > > > > On Wed, Apr 24, 2024 at 4:12 PM Slawomir Jaranowski < > > s.jaranow...@gmail.com> > > > wrote: > > > > > >> Hi, > > >> > > >> Temurin jdk distribution doesn't support JDK 8. You can try with zulu. > > >> > > >> śr., 24 kwi 2024 o 15:57 Gary D. Gregory > > napisał(a): > > >> > > >>> Hi All, > > >>> > > >>> I just saw this on GitHub for our Lang component: > > >>> > > >>> Error: Could not find satisfied version for SemVer '8'. > > >>> > > >>> Available versions: 22.0.1+8, 22.0.0+36, 21.0.3+9.0.LTS, > > 21.0.2+13.0.LTS, > > >>> 21.0.1+12.0.LTS, 21.0.0+35.0.LTS, 20.0.2+9, 20.0.1+9, 20.0.0+36, > > >> 19.0.2+7, > > >>> 19.0.1+10, 19.0.0+36, 18.0.2+101, 18.0.2+9, 18.0.1+10, 18.0.0+36, > > >>> 17.0.11+9, 17.0.10+7, 17.0.9+9, 17.0.8+101, 17.0.8+7, 17.0.7+7, > > >> 17.0.6+10, > > >>> 17.0.5+8, 17.0.4+101, 17.0.4+8, 17.0.3+7, 17.0.2+8, 17.0.1+12, > > 17.0.0+35, > > >>> 11.0.23+9, 11.0.22+7.1, 11.0.22+7, 11.0.21+9, 11.0.20+101, 11.0.20+8, > > >>> 11.0.19+7, 11.0.18+10, 11.0.17+8, 11.0.16+101, 11.0.16+8, 11.0.15+10 > > >>> > > >>> So it looks like goodbye Java 8 on GitHub. > > >>> > > >>> Gary > > >>> > > >>> - > > >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >>> For additional commands, e-mail: dev-h...@commons.apache.org > > >>> > > >>> > > >> > > >> -- > > >> Sławomir Jaranowski > > >> > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > -- > Sławomir Jaranowski - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Modularization of components
Hi folks, This is a generic question, but I'll be using VFS as an example. There are a lot of commons components which have many functionalities, e.g. VFS can be used for FTP, HDFS, WebDAV, etc. Many times codebases only use a subset of those. But there's only one VFS module, which includes all of these functionalities, and thus all of their dependencies. This increases build times and sizes (e.g. of WAR files). It seems to me that it might be useful to split such components into multiple modules. Is there any particular reason why this couldn't be done? Best, Elric - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Modularization of components
Eric, Apache Commons VFS is already broken up into a multi-module project, so I don't know what you're talking about; see https://search.maven.org/search?q=g:org.apache.commons%20AND%20a:commons-vfs2* The next release will be further modularized; see git master, Modularization depends on: (1) It's painful to build Apache Commons releases with Maven multi-module projects. It's NOT just building a jar file or set of jars. In comparison, building a mono-module is "simple". This is why I tripped over building Commons Email, FileUpload, and VFS recently. I hope to get back to those ASAP. (2) Always, always, always keep compatibility in mind (3) Keep users in mind with ease of migration and compatibility (see above) (4) JPMS is a giant PITA and we rely on the Moditect plugin for metadata generation. That works today, but there has been some growing pains. and also keep in mind the KISS and YAGNI principle. Gary On Mon, Apr 29, 2024 at 7:58 AM Elric V wrote: > > Hi folks, > > This is a generic question, but I'll be using VFS as an example. There > are a lot of commons components which have many functionalities, e.g. > VFS can be used for FTP, HDFS, WebDAV, etc. Many times codebases only > use a subset of those. But there's only one VFS module, which includes > all of these functionalities, and thus all of their dependencies. This > increases build times and sizes (e.g. of WAR files). > > It seems to me that it might be useful to split such components into > multiple modules. Is there any particular reason why this couldn't be > done? > > Best, > > Elric > > - > 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
[IO] IO-855 PeekableInputStream?
RE https://issues.apache.org/jira/browse/IO-855 There are zero tests or usage in IO for PeekableInputStream. Could the original author add some? Why does PeekableInputStream extend CircularBufferInputStream instead of BufferedInputStream? TY! Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] GitHub is done with Java 8
Hi Gary, On Mon, 29 Apr 2024 at 13:58, Gary Gregory wrote: > To resolve this issue in the least disruptive manner, I updated builds > that need Java 8 AND macOS from "macos-lateset" to "macos-13". In Log4j I updated all builds that require Java 8 + another JDK to use `zulu` as distribution if `runner.os == 'macOS'`. Another solution that might work is to use `x64` as architecture for `macos-latest`, but the runners we be slower and might throw an OOM. Piotr - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Modularization of components
Hello. Le lun. 29 avr. 2024 à 14:07, Gary Gregory a écrit : > > Eric, > > Apache Commons VFS is already broken up into a multi-module project, > so I don't know what you're talking about; see > https://search.maven.org/search?q=g:org.apache.commons%20AND%20a:commons-vfs2* > The next release will be further modularized; see git master, The OP's question makes sense, even if the example was not appropriate (I didn't look at [VFS]). > > Modularization depends on: > > (1) It's painful to build Apache Commons releases with Maven > multi-module projects. It's NOT just building a jar file or set of > jars. In comparison, building a mono-module is "simple". In my experience it was never "simple", as per the long list of things that had to be done manually. Then when steps were automated, the multi-module nature of some components was not taken into account, which led to the issues (AFAICT). > This is why I > tripped over building Commons Email, FileUpload, and VFS recently. I > hope to get back to those ASAP. [RNG], [Numbers], [Geometry], [Math] have been modular for a long time without any more issues than in other components, except for some specialized profiles in order to work around the (too) "simple" way. > (2) Always, always, always keep compatibility in mind How is this related? Any set of functionalities should be amenable to a modular design, unless there are cyclic dependencies (that signal bad design). > (3) Keep users in mind with ease of migration and compatibility (see above) Is this just a matter of a few lines specifying the new dependencies? [Just like with any upgrade.] > (4) JPMS is a giant PITA and we rely on the Moditect plugin for > metadata generation. That works today, but there has been some growing > pains. Supporting JPMS is orthogonal to a modular (Maven) project (see [RNG], for example). > and also keep in mind the KISS and YAGNI principle. Sure, but the request (for an application to have a minimal set of dependencies) is valid for several reasons: Size (as noted by the OP) but also security (the more so that legal requirements seem on the way in that area). In summary, IMO modularization should be a feature (and a default goal) of any new major release. I know that it is a lot of work (of course, cf. [Math] history) , but we should encourage contributions towards that goal. Regards, Gilles > > Gary > > On Mon, Apr 29, 2024 at 7:58 AM Elric V wrote: > > > > Hi folks, > > > > This is a generic question, but I'll be using VFS as an example. There > > are a lot of commons components which have many functionalities, e.g. > > VFS can be used for FTP, HDFS, WebDAV, etc. Many times codebases only > > use a subset of those. But there's only one VFS module, which includes > > all of these functionalities, and thus all of their dependencies. This > > increases build times and sizes (e.g. of WAR files). > > > > It seems to me that it might be useful to split such components into > > multiple modules. Is there any particular reason why this couldn't be > > done? > > > > Best, > > > > Elric - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] GitHub is done with Java 8
Thanks for the tip Piotr. For now it works so I don't plan on changing anything until it breaks. Garu On Mon, Apr 29, 2024, 8:46 AM Piotr P. Karwasz wrote: > Hi Gary, > > On Mon, 29 Apr 2024 at 13:58, Gary Gregory wrote: > > To resolve this issue in the least disruptive manner, I updated builds > > that need Java 8 AND macOS from "macos-lateset" to "macos-13". > > In Log4j I updated all builds that require Java 8 + another JDK to use > `zulu` as distribution if `runner.os == 'macOS'`. > > Another solution that might work is to use `x64` as architecture for > `macos-latest`, but the runners we be slower and might throw an OOM. > > Piotr > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [Collections] Suppliers, Iterables, and Producers
I will see if I can clarify the javadocs and make things clearer. What I think I specifically heard is: - Be clear that producers are fast fail iterators with predicate tests. - Rename CellConsumer to CellPredicate (?) - The semantic nomenclature: - Bitmaps are arrays of bits not a BitMap object. - Indexes are ints and not an instance of a Collection object. - Cells are pairs of ints representing an index and a value. They are not Pair<> objects. - Producers iterate over collections of the object (Bitmap, Index, Cell) applying a predicate to do work and stop the iteration early if necessary. They are carriers/transporters of Bloom filter enabled bits. They allow us to query the contents of the Bloom filter in an implementation agnostic way. Does that basically cover the confusion? If there are better terms, let's hash them out now before I update the javadocs. As an aside, Cells and Bitmaps are referenced in the literature. For the most part the rest is made up out of whole cloth. So we could change "Producer" to something else but we would need a good name. Semantically: - As Hasher generates an IndexProducer once it knows what the range of the values are and how many values it should produce (as defined in the Shape). That index producer can be used multiple times and will produce the same set of values in the same order. - A Bloom filter generates an IndexProducer that enumerates the enabled bits in the filter. - A CellProducer generates an IndexProducer that reports all the index values that it contains. In implementing stable Bloom filters I had to create a RandomHasher that generates an IndexProducer that will generate values in the range and number specified by the Shape but that does not produce the same values every time (obviously). We could change Producer to a term that means a representation: Ideogram, but then we have to introduce the term and explain what it means. Producer starts at a common point. All of this just goes to show that "Naming things is hard". But then we all knew that anyway. Claude On Sun, Apr 28, 2024 at 11:00 PM Gary Gregory wrote: > Thank you for your thoughtful reply. See my comments below. > > On Sun, Apr 28, 2024 at 11:10 AM Alex Herbert > wrote: > > > > Hi Gary, > > > > I am in favour of using nomenclature and patterns that will be familiar > to > > a Java developer. But only if they match the familiar JDK use patterns. > The > > Bloom filter package has some atypical use patterns that have driven the > > current API to where it is. I'll try and describe these below. > > > > On Sun, 28 Apr 2024 at 14:16, Gary Gregory > wrote: > > > > > Hi Clause, Albert, and all, > > > > > > Since the introduction of lambdas in Java 8, Java has a well-defined > > > terminology around the classic producer-consumer paradigm but (for > > > reasons unknown to me) realized in the functional interfaces *Supplier > > > and *Consumer. In addition, as of Java 5, we have the Iterable > > > interface. > > > > > > In our new Bloom filter package we have new interfaces called > > > *Producer (as opposed to *Supplier), where some of these new > > > interfaces are formally annotated with @FunctionalInterface and some > > > not (for example, BloomFilterProducer). > > > > > > My question is: Why call these "Producers" instead of "Suppliers"? Is > > > the formal Bloom filter literature tied to the "Producer" terminology > > > in a way that would make adapting to the Java term confusing? I know I > > > brought up a similar topic recently, but I would like to revisit it > > > now that I've started to read Claude's blog drafts. Even without > > > making the current "Producers" formal suppliers by extending Supplier, > > > would it be worth using the Java terminology? > > > > > > > Claude is familiar with the literature and can comment on that. I would > > defer to the literature if it is a common term. > > > > There is one notable distinction to JDK suppliers. Suppliers only supply > 1 > > element and must be repeatedly called to generate more. The Producers in > > the BloomFilter package will supply multiple values. They are invoked > using > > a forEach pattern with the intention of supplying all the elements to a > > predicate, not a consumer. If any of those elements is rejected by the > > predicate then the rest of the elements are not supplied. So this is a > > fail-fast bulk supplier. > > Ah, this sounds like a special Iterator, fail-fast as you mention, and > Java does not have that in Java 8 at least. > The Producer class suffix still confuses me since this is neither a > factory nor a traditional supplier. If the classes were called > *Iterator and not extend iterator, then it would also be confusing. > The question is whether it would be useful to extend Iterator or if > the class would never be used as a traditional Iterator. I'll that to > an SME ;-) > > > > > > > > > > > My second
