Re: Retirement of HelpWanted.apache.org
Comdev have decided that the HelpWanted app should be retired as it is not worth the maintenance effort -- it is barely used. I imagine it's barely used because no one knows it exists? Perhaps it can be promoted a bit instead? It sounds like a useful tool. How much maintenance effort are we talking about? - Elric - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [beanutils] Java plaform for 2.0
On 12/09/2024 19:21, Gary D. Gregory wrote: Hi All, Any thoughts on the minimum Java platform requirement for 2.0? Options are (IMO): 8, 11, 17, or 21. I have no vote, but I would go for 21. This will likely be a decision that will have an impact for a long time. 21 is 1 year old, 17 is 3 years old, 11 is already already 6 years old, and 8 is over 10 years old. People can continue to use 1.x if they are stuck on ancient Java versions, but there should be no need to for any major release of any commons project to stick to older versions. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DRAFT] June Report to the Board
On 12/06/2024 15:45, Gary D. Gregory wrote: ## Community Health: Regarding community health: please don't take this the wrong way, but it feels like Gary is doing A LOT of the heavy lifting on all of the commons projects. What happens if Gary is hit by a bus? Would the commons community still be able to function? The XZ Utils backdoor incident was a consequence of the main maintainer burning out, hopefully a healthy community can help prevent such issues here. Is there anything the community can do to pitch in a bit more? Aside from the obvious things like contributing bugfixes and tests etc. - Elric - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Modularization of components
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, It's a multi-module project, sure, but the modules are split along technical boundaries rather than functional. I didn't explain this well enough in my original message, so let me try that again. I thought VFS was an appropriate example because it contains *a lot* of functionality. This is by design, of course, and it's a useful thing. But most people who use VFS don't use all of the file system types (called Providers in VFS). There's FTP, SFTP, HTTP, and a bunch of others. My hypothetical suggestion was that if each of those providers were their own module, the dependency footprint would go down for many projects which use some but not all VFS Providers. IMO this would be a good thing for a variety of reasons. I don't know whether VFS is an appropriate example from a technical/feasibility perspective, and sure, backwards compatibility is a concern. But this was intended as an example to start a discussion about modularization within commons. (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". Is this a fundamental maven issue which is hard to solve? I haven't had too many issues with multi-module maven projects in the past, but I admit that my builds are a lot less complex than commons projects. (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). I imagine that some (many?) projects aren't designed with modularization or pluginification in mind, and they end up doing something like Providers.register(FTP.class, HTTP.class, SFTP.class) to register all known implementations. Inverting that relationship isn't always easy to do after the fact. So I understand that this isn't necessarily a quick and easy project. Supporting JPMS is orthogonal to a modular (Maven) project (see [RNG], for example). True. I think in the long term both are desirable. One to reduce size & dependencies & build times; the other to better isolate components & implementation details. But if I had to choose one or the other, maven modularization would certainly be first on the list. 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. Thanks for the +1 on that, Gilles. I'm certainly not expecting any overnight changes on this. My goal was merely to start a discussion and see whether there's any interest for this in the community. Commons components are used incredibly widely. Which is obviously a great thing. But I see WARs getting fatter and fatter with transitive dependencies, and lots of classes remaining unused at runtime. In the age of continuous deployments and fast container startup times, making it easier to keep things slim seems like a useful goal. Best, Elric - 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
[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: Is there a blog for commons?
On 16/04/2024 13:08, Gary Gregory wrote: There is an Apache wide blog here: https://news.apache.org/ There used to be a planet.apache.org which aggregated committer/project blogs, but that seems to be broken. Would there be any interets in an aggregated ASF-project wide blog? Where contributors from all projects could submit posts? Would be a great way to keep up to do date, as well as learn about other ASF projects. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Net] JUnit 5 migration discussion
Following Rob's suggestion, I migrated FTPSClientTest from @Parameterized to @Nested The result so far can be found here: https://github.com/apache/commons-net/pull/227/commits/b14ee39cca486bda106758a48d31c91ad52d0d83 Basically the test methods were moved from FTPSClientTest.java [1] to AbstractFtpsTest.java [2]. The two @Parameterized values are then injected using @Nested. The behaviour in maven is exactly the same as before. The behaviour in Eclipse bugs me a little, instead of asking both nested tests by default, it asks which one should be executed. But that seems to be the case with @Nested tests in general. [1] https://github.com/apache/commons-net/blob/b14ee39cca486bda106758a48d31c91ad52d0d83/src/test/java/org/apache/commons/net/ftp/FTPSClientTest.java [2] https://github.com/apache/commons-net/blob/b14ee39cca486bda106758a48d31c91ad52d0d83/src/test/java/org/apache/commons/net/ftp/AbstractFtpsTest.java Any feedback is welcome. I personally feel like this test case is a bit too complex to be easily grokked, and perhaps it can be improved a bit more after the JUnit migration. I'll try to tackle some more tests at some point this week. Best, Elric - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Net] JUnit 5 migration discussion
On 01/03/2024 16:53, Rob Spoor wrote: You can turn the current parameterized test into an abstract base class; you can even nest it in another class. Then for each set of parameters you use an @Nested sub class that fills in the parameters in the call to its super constructor. Thanks Rob & Alex for some great tips. I hadn't considered @Nested, this does sound like the least invasive approach. I'll try to explore that over the weekend. Best, Elric - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Net] JUnit 5 migration discussion
Hi folks, I recently made some changes to commons-cli to move it from JUnit 4 to JUnit 5. This was mostly straightforward, and I think it went pretty well. Currently looking into doing the same for commons-net, but there are a couple of tricky tests that probably require some up front discussion, mostly JUnit 3 style tests, and one tricky JUnit 4 Parameterized Test. In previous versions, test classes could be extended and their test methods would be executed as part of the child class' execution. This was true for testt methods annotated with JUnit 4's @Test, or JUnit 3's test-prefix naming convention. Unfortunately, this is no longer the case in JUnit 5. I think this is a poor design decision on their part, as it makes it significantly harder to move to JUnit 5, and it makes certain types of tests just plain difficult. There is some discussion about this in the JUnit community [1], but I can't predict whether this will ever be resolved in a way to makes commons-net's upgrade any easier. One of those cases is AbstractFTPParseTest and its children. This abstract base class has 11 concrete test classes. I'm struggling to see a minimally invasive way to migrate these to JUnit 5. I'm loath to use a heavy handed approach there. A second tricky case is FTPSClientTest, which is a Parameterized test of a form that no longer exists in JUnit 5. It basically creates two instances of a test class with a boolean flag (once true, once false). JUnit 5's @ParameterizedTest annotation operates on the **test method** level, not on the class level, which I think would make the test case slower and harded to read. An alternative approach would be to use Dynamic Tests, which basically generate test cases programmatically, but again, that makes grokking the test a lot more difficult as it requires a greater understanding of JUnit's features. Any insights into this would be greatly appreciated. Best, Elric [1] https://github.com/junit-team/junit5/issues/960 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[CLI] Patch - JUnit 5 upgrade
Hi folks, I couldn't sleep, so I created a merge request to switch Commons CLI to JUnit 5. Before the patch, a mixture of 4 and 5 was used. https://github.com/apache/commons-cli/pull/238 This is a pretty "simple" change, if a bit verbose. It merely converts the JUnit 4 constructs to their JUnit 5 equivalents. What makes the patch a bit larger is that the optional "message" argument in assertions was moved; it was the first argument in old assertions, but it's the last argument in the new style. This is a stupid change, but what can you do ... Enjoy, Elric - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VALIDATOR] - Release of newer version of validator without OWASP vulnerabilities
On 23/11/2023 17:19, Elliotte Rusty Harold wrote: It is possible for a client project to override transitive dependencies, but you need to be careful. Using a BOM is one of the easier ways to manage these problems: https://jlbp.dev/JLBP-15 This is exactly why it's a good idea for commonly used projects (such as all of Apache Commons) to use the latest stable dependencies themselves. If everyone is on the latest stable version, dependency hell is mitigated, more security issues get mitigated, and developers spend less time fighting with BOMs or dependency overrides. Dependabot (and its ilk) makes this fairly straightforward in many cases. But as Gary just mentioned, incompatibilities (e.g. JUnit upgrades) do arise. Addressing those is tedious and thankless work. If no one volunteers, nothing gets done. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ANNOUNCE] Apache Commons IO 2.15.0
On 26/10/2023 13:48, Gary Gregory wrote: Java 8 is required. This phrasing is somewhat confusing. "Java 8 or newer is required" would help clarify things. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Dbutil] Java 8 -> 11
On 15/10/2023 16:31, Gary Gregory wrote: A major version bump is rather heavy handed when no one is asking for a "real" 2.0 with breaking changes. Agreed. My 2 cents: a minor version and a clear release note is plenty. Critical bug fixes can still be made by bumping the patch version, though given that Java 8 is nearly ten years old, it's really time for folks to upgrade. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Volunteering
On 10/04/2023 22:31, Miguel Muñoz wrote: Elric, Did you take up Gary's "thankless" task of updating the tests for Commons VFS? Because I'm looking for a volunteer task, and an opportunity to improve my JUnit 5 skills, so I'd be happy to pitch in. I've had a quick look at it but ran into some build issues. While investigating the possible test upgrade, I stumbled upon openrewrite, which seems to be a tool which could help automate the process, so I'm slowly tinkering with that. There's plenty to be done, so don't feel bad if you beat me to it :D Best, Elric - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Volunteering
Greetings, I've got some time on my hands the next couple of weeks, and I figured I could spend some of that time on the commons. In particular, I've noticed that commons-cli, commons-lang, and commons-io have a lot of jira issues and pull requests that have been open for a long time. Is there anything I can do to help out there? Triage, comment, test, whatever? Thanks, Elric - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
