Re: [all] stopping dependabot and security analyses on dormant components
Le 03/10/2023 à 20:18, Bruno Kinoshita a écrit : Same for me, I prefer to know ahead of time if there are any issues with dependencies. But the Commons components are mostly dependency-less, we are flooded by dependabot requests to update non code related dependencies (Maven plugins, GitHub actions) for non critical purposes. It would be better to have such notifications for CVEs only. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] stopping dependabot and security analyses on dormant components
Le 01/10/2023 à 14:09, sebb a écrit : As the subject says: how does one stop dependabot and other analyses from running on dormant components? +1 And even on all components, updating the dependencies is a release time task. Updating 3 times the same Maven plugins between releases is a waste of time. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-fileupload2-jakarta
On 11/07/2023 12:57, Eugene Grybinnyk wrote: We tried to get rid of commons-fileupload in favour of Servlet API for our project where we disable multipart and use streaming (not to store files on the disk). And it looks like Servlet API doesn’t provide a convenient way of streaming the attachments (like commons-fileupload does) so in the end we concluded that we need to implement something similar to what we get from commons-fileupload OR to wait for version commons-fileupload:2.0. streaming is a good use case for commons-fileupload, thank you for mentioning it. I think we should highlight the differences between the Servlet API and commons-fileupload on the website, and encourage using the standard API if neither streaming nor upload progression is required. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-fileupload2-jakarta
On 12/07/2023 13:27, Martin Tzvetanov Grigorov wrote: Last time when I tried to replace Commons Fileupload with pure Servlet API I faced these issues: 1) The Servlet API does not provide hooks to follow the upload progress To display a progress bar on the client side? 2) The Servlet API does not provide a way to cleanup after processing the uploaded files, i.e. the commons-fileupload Cleaner Isn't the temp file cleaning automatically handled by the Servlet container? The API user shouldn't have to care about that. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-fileupload2-jakarta
On 09/07/2023 18:01, Gary Gregory wrote: I think it might be helpful to think about this in terms of existing and legacy code bases that need to migrate to the Jakarta namespace in a simple manner, as opposed to green-field development. Here the sensible migration path is to switch to the Servlet API, not creating a new API that puts a maintenance burden on us for the years to come. I plan on cutting a release candidate for 2 .0.0-M1 this weekend or next Some people have been asking for it as well. But why are they asking for that? We don't do things just because we are asked to. We do things because it makes sense technically, and it doesn't look so in this case. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-fileupload2-jakarta
Dumb question: what's the benefit of using commons-fileupload in 2023 instead of the equivalent file upload feature of the Servlet API? The use case I had in mind was to support file upload in very old Servlet containers still in production (Tomcat 6 or Jetty 7 for example, both EOL), but servers supporting the Jakarta API are recent and have the file upload feature integrated. I'd expect commons-fileupload to go to dormant in the near future rather than adapted for the jakarta namespace. What did I miss? Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Jakarta namespace in commons like dbcp - thoughts / ideas?
On 26/05/2023 12:20, Romain Manni-Bucau wrote: TomEE can drop managed package legacy dependency now, was kept while the replacement was in test in 1.x version but makes years it is no more relevant and no more the default (since we switched to tomcat-jdbc). So no big deal if dbcp wants to drop it on TomEE side IMHO. Ok but tomcat-jdbc contains a modified copy of DBCP. Does TomEE use the managed package from tomcat-jdbc? If so we can't simply drop this package from DBCP. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Jakarta namespace in commons like dbcp - thoughts / ideas?
Le 11/05/2023 à 15:56, Richard Zowalla a écrit : Hi, do we have any updates? How can I help to get a dbcp version supporting Jakarta namespace? Emmanuel outlined a possible appraoch. How can we move forward with it? I'm tempted to merge the dual-javax-jakarta branch, but Romain's comment about TomEE no longer using the managed package made me wonder if we really need to bother at all. Are we trying to fix a theoretical issue or are there actual users of these classes expecting a fix? Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Eventually, soon, Java 11
Le 23/04/2023 à 19:40, Glavo a écrit : If only for JPMS, we can compile module-info.java separately, which is still compatible with Java 8. If we really need to give up compatibility with Java 8, then I still recommend skipping Java 11 and using Java 17. +1 This should be decided component by component if there is a good technical reason to switch (and I don't think JPMS support is a good one). Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Jakarta namespace in commons like dbcp - thoughts / ideas?
I've experimented with another approach, a single version supporting both javax.transaction and jakarta.transaction: https://github.com/ebourg/commons-dbcp/tree/dual-javax-jakarta The only classes using javax.transaction are in the org.apache.commons.dbcp2.managed package. This package is copied at build time to org.apache.commons.dbcp2.managed.jakarta with the javax imports replaced. This solution is easier than maintaining two versions is parallel. What do you think? Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Jakarta namespace in commons like dbcp - thoughts / ideas?
Thank you, it works perfectly now. I've pushed the changes to: https://github.com/ebourg/commons-dbcp/tree/jakarta Comments are welcome before I create a dbcp3 branch on the ASF repository. I think the API should be kept identical to dbcp2 to ease porting changes and facilitate migrations. So no removal of deprecated methods before dbcp4. Emmanuel Bourg On 28/12/2022 19:22, Romain Manni-Bucau wrote: Hi Emmanuel, You have https://repo1.maven.org/maven2/org/apache/geronimo/components/geronimo-transaction/3.1.5/geronimo-transaction-3.1.5-jakarta.jar which is usable if you exclude transitive deps. 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> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Jakarta namespace in commons like dbcp - thoughts / ideas?
Thank you for the pointers, the Narayana and JBoss artifacts look good, but I haven't found a replacement for geronimo-transaction. I tried replacing the Geronimo Transaction implementation with the one from Narayana but got 4 test failures. I'll try to process the geronimo-transaction jar at build time and see how it works. Emmanuel Bourg Le 28/12/2022 à 07:24, Richard Zowalla a écrit : There is a Jakarta artifact available for Narayana: narayana-jta-jakarta For the SPI: jboss-transaction-spi-jakarta (because JBoss plays the namespace game with their app server ;-) ) Geronimo most likely also provides a Jakarta version or (if it is only API) can be replaced by the Jakarta artifact. Gruß Richard - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Jakarta namespace in commons like dbcp - thoughts / ideas?
I tried to replace javax with jakarta in DBCP, the less trivial part is to find a replacement for the test dependencies: - org.apache.geronimo.modules:geronimo-transaction - org.jboss.narayana.jta:narayana-jta - and maybe org.jboss:jboss-transaction-spi Or we disable the transaction tests temporarily to publish quickly a Jakarta variant. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [rng][lang] Shuffling arrays
I would rather keep the ArrayUtils.shuffle() methods not deprecated, and mention RNG in the Javadoc for more advanced usages. Adding a 100KB dependency just to shuffle an array isn't optimal. Emmanuel Bourg Le 06/12/2022 à 21:40, Gary Gregory a écrit : I am ok with both LANG and TEXT deprecating to RNG. Gary On Tue, Dec 6, 2022, 13:21 Alex Herbert wrote: On Tue, 6 Dec 2022 at 17:22, Gary Gregory wrote: I agree this should be in rng. Does rng duplicate all of the lang APIs such that we can deprecate the lang methods? In short, yes. (cd src/main && git grep -c Random) - ArrayUtils - RandomStringUtils - RandomUtils The proposed ArraySampler with shuffle methods for all array types would deprecate ArrayUtils.shuffle. You would have to provide a UniformRandomProvider in place of a java.util.Random. RandomStringUtils is not explicitly deprecated. However the class javadoc states that Commons Text's RandomStringGenerator and, generically, Commons RNG are more suitable for random generation. RandomUtils is already deprecated. It mentions RNG in the header but the functionality is for static thread-safe calls for random numbers. The RandomUtils class is partly deprecated by changing calls from RandomUtils.xxx to ThreadLocalRandom.current().xxx. The class uses ThreadLocalRandom under the hood, but does not act as a pass-through for all methods. It looks like these could be updated to directly use ThreadLocalRandom's implementation: nextLong(long upper) Note: This method in RandomUtils does not check upper > 0 which is a bug. However the bounds for some methods are different, some have extra conditions and some are missing from ThreadLocalRandom. method : lang : ThreadLocalRandom nextBytes(int) : present : NA nextDouble() : [0, MAX_VALUE) : [0, 1) nextDouble(lower, upper) : [lower, upper) | upper > lower >= 0 : upper > lower nextFloat() : [0, MAX_VALUE) : [0, 1) nextFloat(lower, upper) : [lower, upper) | upper > lower >= 0 : NA nextInt() : [0, MAX_VALUE) : [MIN_VALUE, MAX_VALUE] nextInt(upper) : NA : [0, upper) nextInt(lower, upper) : [lower, upper) | upper > lower >= 0 : [lower, upper) | upper > lower nextLong() : [0, MAX_VALUE) : [MIN_VALUE, MAX_VALUE] nextLong(upper) : [0, upper) [no check upper > 0] : [0, upper) nextLong(lower upper) : [lower, upper) | upper > lower >= 0 : [lower, upper) | upper > lower All these methods are in the UniformRandomProvider interface from [rng], including the nextFloat with ranges but with the exception of nextBytes(int count). The generators provide nextBytes(byte[]) and you must supply the array. In this case it may be helpful to document each method with an equivalent from ThreadLocalRandom that provides a thread-safe static call to generate the same output (with the exception that lower bounds can be negative in ThreadLocalRandom). Alex - 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] GH workflow change details don't belong in changes.xml
Le 08/10/2022 à 17:56, sebb a écrit : I don't think we should be cluttering the changes file with irrelevant and potentially confusing information. +1, changes.xml should be for user visible changes only (API changes, bug fixes, updated language level, etc). Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [configuration] Jakarta mailapi 2.0.1
On 10/06/2022 22:16, Rob Spoor wrote: Since reflection is used to create the instances, isn't it possible to support both? +1, we should support both Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: New component proposal: commons-plugins
Le 04/04/2022 à 02:27, Ralph Goers a écrit : I don’t think so. Commons Configuration (which I was working actively on when I started writing Log4j 2) is designed to provide access to the configuration data. The plugin system is design to convert configuration data into instantiated objects. I could easily see Commons Configuration being used as the input to the plugin system, but I think it would be a mistake to tightly couple them. +1 I agree, the goal of Commons Configuration is to parse dumb configuration files in various formats and with some extra convenient features. Building complex object structures is out of its scope. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: The case for a Commons component
Le 2021-05-06 13:06, Gilles Sadowski a écrit : It is not nice to decide for others what they may need. It is not nice to suggest I shouldn't voice my opinions. It would have been courteous to acknowledge the answers to your argument against having a dedicated component I've little appetite for lengthy debate with you again. My rationale, for whether a specific component is needed, has always been the same: Define a scope (and stick to it). You seem to find this acceptable for any Commons project except those which you tagged as "math-related". The machine learning scope is too wide, it doesn't belong here. So I'm asking: Will it make any difference if the "machine learning" codes are further developed within [Math]? Concretely: * Would you vote to release CM v4.0? * Would you help (more than if the ML codes were in a specific component) to review/merge the PRs? I'd would vote favorably for a modularized CM 4.0 release, but I still think that the math related components would be best served in their own TLP with a dedicated community free of the Apache Commons rules and constraints. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: The case for a Commons component
Le 2021-05-05 20:31, Oliver Heger a écrit : What about the sandbox? IIUC, every committer can start a new component there. If then a community forms around this component, it can move to proper (which would then require a vote). With the various source hosting solutions available today we no longer need the sandbox, and I think we should discontinue this practice. The machine learning library could as well start its life on GitHub, it doesn't need Apache Commons. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Move Proxy to dormant?
Le 23/04/2021 à 01:04, sebb a écrit : > There has been no substantial development for several years, and only > two open JIRA feature requests. > > The website is outdated, and needs regeneration. > > Is it worth spending any time on this component? > > I suspect it should go dormant. +1 Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Vote] Create repository for "machine learning" algorithms.
Le 22/04/2021 à 00:41, sebb a écrit : >> ---CUT--- >> >> You might want to read the discussion that proceeded from the >> previous vote request. [10] >> >> Please vote: >> [ ] Yes. >> [X] No, because ... > > I think it belongs elsewhere. > However if there are enough Commons developers who are able and > willing to support the component, I won't veto it. -1, I agree with sebb. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] OSS Fuzz
Le 17/04/2021 à 18:33, Gary Gregory a écrit : > I'll go with the consensus here but I feel that the security list should be > for humans and posts there deserve human attention on an ASAP basis. I've > just seen too many false positives and noise from automated tools over the > years. Let's just give it a try with compress and reevaluate in a couple of month ? Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: GitHub license display confused by LICENSE-header.txt
+1 for moving these files elsewhere. The project root should just contain the pom.xml, license, notice, readme and CI files. Emmanuel Bourg Le 09/03/2021 à 02:15, Melloware Inc a écrit : > In commons beanutils we recommend using /src/conf for these type of files. > > Sent from my iPhone > >> On Mar 8, 2021, at 8:13 PM, sebb wrote: >> >> On Tue, 9 Mar 2021 at 01:08, Bernd Eckenfels wrote: >>> >>> Checkstyle-header.txt sounds good and maybe also moving it to a subdir like >>> src/build/ or src/test/? >> >> There are other checkstyle files at the top-level; best to keep them >> together. >> >>> Gruss >>> Bernd - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Vote] Create a "machine learning" component
-1 for commons-ml for the same reasons. What about commons-machine-learning or commons-math-learning? The latter is as long as commons-configuration. Emmanuel Bourg Le 2021-02-10 03:27, Ralph Goers a écrit : -1 on commons-ml as the name. My first thought is such a repo would hold stuff related to mailing lists. Then again maybe it contains stuff relating to markup languages. Maybe it is Apache’s version of the ML Programming Language [1]. However, I wouldn’t be -1 on commons-math-ml, although at best I would be +0 since it is still not obvious what it would contain. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Introduce @NonNull, and @Nullable
Le 01/02/2021 à 11:58, Jochen Wiedmann a écrit : > So, assuming that my proposal should be accepted: How do we proceed? I > see two alternatives: > > a) We had com.google.code.findbugs:jsr305:3.0.2 with a scope > "provided" to our dependencies. The scope will guarantee, that users > aren't affected at all. +1, that's the dependency commonly used to provide these annotations. > b) We create our own annotations, say > org.apache.commons.lang3.annotations.NonNull, etc. When using > Spotbugs, or the respective IDE's, we need to adjust the namespace, > but that should be doable. -1, we don't need more JSR305-like annotations in the Java ecosystem. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Thoughts on build system maven -> gradle??
-1, I'd rather return to Ant than switching to Gradle. Gradle builds quickly become messy as hell, if you compare several Gradle based projects like Hibernate, Spring and OpenJFX they hardly look similar. Maven POM files may look verbose but at least the declarative syntax enforces a normalized project structure and build process. Emmanuel Bourg Le 16/07/2020 à 23:30, Rob Tompkins a écrit : > 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 > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] CI builds and Java versions
Le 26/07/2020 à 23:39, Gary Gregory a écrit : > 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. Technically it's possible to build with Java 11 and use the --release 6 flag. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: About binary compatibility
Le 14/06/2020 à 15:41, Gary Gregory a écrit : > In order to avoid posting the same answer here and on GitHib over and over, > I tried to explain BC here: > https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/ > > Feedback is most welcome. Excellent post, thank you Gary. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] What to do with Pack200?
Le 04/01/2020 à 12:19, Stefan Bodewig a écrit : >> FYI I plan to fork the JDK pack200 implementation into a standalone >> project. I've reserved the 'pack200' group on GitHub for this. The code >> isn't published yet > > https://github.com/pack200/pack200 looks pretty public to me :-) I've published my work in progress at the aforementioned URL. It consists in the Pack200 code with full history extracted from OpenJDK before the removal, the project has been mavenized and the jtreg tests were converted to JUnit. The API is the same but the package was changed from java.util.jar to io.pack200. It's still missing the native library to speed up unpacking. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] What to do with Pack200?
Le 05/01/2020 à 14:09, Gary Gregory a écrit : > Is Pack200 100% Java? In OpenJDK the pack200 encoder is 100% Java, and there are two decoder implementations in Java and in C. The native decoder is 5 times faster than the Java one. > I think it would be neat to bring it in from Apache Harmony The pack200 implementation in Harmony is a bit old now, it doesn't support the new bytecode instructions introduced since Java 7. > I think we should consider converting > compress into a multi-module project and avoid hard dependencies. As compress grows and supports more formats by using external dependencies, I also think some form of modularization will be needed. Otherwise it'll become a behemoth like Tika. > For the test, the simplest might be to use a JUnit Assume to skip running > that test on Java > 14. Is it possible to build with Java 8 and test with Java 14 in the same CI run? Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] What to do with Pack200?
Le 04/01/2020 à 12:19, Stefan Bodewig a écrit : > This won't work as CompressorStreamFactory depends on the package. Maybe some reflection could address that? > https://github.com/pack200/pack200 looks pretty public to me :-) I've just pushed a raw extraction of the OpenJDK code with its history. I'll have to redo it to include all the C files required to compile the native library. > I'd say it is fair to call pack200 support an optional feature of > Commons Compress https://apache.org/legal/resolved.html#optional Good point, I wasn't aware of this rule. Alternatively I'm considering adding an independent Apache-2.0 licensed interface, and having the GPLed code provide an implementation, maybe using a META-INF service mechanism. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] What to do with Pack200?
Le 02/01/2020 à 11:06, Stefan Bodewig a écrit : > Any other ideas? The removal of pack200 isn't an issue for the upcoming release yet since we still target Java 7. For now this is just an issue with the CI using Java 14+. Maybe we can deal with this by using a Maven profile excluding the pack200 classes from the compilation when Java 14+ is used. This leaves some time to find an alternative implementation, I don't think Commons Compress will require Java 14+ in the next 5 years. FYI I plan to fork the JDK pack200 implementation into a standalone project. I've reserved the 'pack200' group on GitHub for this. The code isn't published yet but I've already Mavenized the project and converted the tests to JUnit. I'm struggling a bit to get the native code to build. The fork will inherit the GPL2 with classpath exception license from OpenJDK. I'm not sure Apache projects are allowed to depend on such libraries, but that would be odd not to be able to use it since it's exactly the same code that we used in the JDK. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Git status update
Le 24/10/2019 à 12:54, sebb a écrit : > Without a fixed tag pointing to a commit, AIUI the commit can be > eliminated through a force push. Force pushing a branch doesn't erase the tags along it nor its parent commits. The commit and the tag still exist in the repository. > That is deliberate, to avoid the lost commit issue. Git commits aren't easily lost. They can be recovered from ASF backups, GitHub, developers working repositories and from the affected repository itself until it's garbage collected. > It's standard within the ASF now. It's a feature provided by the ASF infrastructure if we are interested in using it, not a mandatory policy. I'm not interested in more complexity. >> * it doesn't solve any actual issue > > Yes, it does solve an issue - see above. Sorry but no, it never happened in Commons, this is purely theoretical. And should it happen anyway it's trivial to restore the original branch from a developer repository. >> * we want fewer steps to our release process, not more > > No, we want as few as possible, but no fewer. It's possible to work without read-only tags, so let's not overload our processes even more please. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Git status update
Le 09/09/2019 à 17:29, Gary Gregory a écrit : > What I meant is that, when we successfully create a release, then the > release tag should go under 'rel/' instead of ''. Sorry for the > misunderstanding. If the vote mail mentions the tag name and the commit hash I don't see the need to use read-only tags. The mail is archived all around the net and the commit isn't going away. The risk of losing a release is zero. I can see the downsides of using rel/ tags though: * it can't be reverted and errors can't be corrected (without bugging the infra team I guess, but they've more important things to do) * it's inconsistent with past releases and we probably don't want to retag all our repositories * it doesn't look great, shorter tags look nicer * it's longer to type when checking out tags from the command line * it's non standard (never seen that anywhere) * it doesn't solve any actual issue * we want fewer steps to our release process, not more Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [beanutils] Towards 2.0?
Le 17/10/2019 à 19:45, Gary Gregory a écrit : > It seems like org.apache.commons.collections4.Predicate can/should be > replaced by java.util.function.Function Did we consider modifying collections4 such that Predicate extends Function? That would ease the transition to the Java 8 types. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All] Using "SemVer"?
Le 18/10/2019 à 12:46, Gilles Sadowski a écrit : > Why not state it explicitly (and make it a formal requirement for > a release)? -1, it restricts our freedom for no real gain, we have enough constraints already. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: strange change to src/main/java/org/apache/bcel/generic/FieldGenOrMethodGen.java
Le 18/10/2019 à 11:10, Xeno Amess a écrit : > Do commons follow semver? No but we care about backward compatibility. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: strange change to src/main/java/org/apache/bcel/generic/FieldGenOrMethodGen.java
Le 18/10/2019 à 10:52, sebb a écrit : > As noted in the OP, the change was part of changing the package name. If the visibility change triggered a regression I think it should be reverted. Emmanuel bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Restoring something like the svn browser
Le 11/10/2019 à 02:39, Phil Steitz a écrit : > Today I tried to find where a bug reported against what I suspect is > DBCP 1.4 (I think that is likely what tomcat 7 pulls in) was fixed. It > appears to be fixed in the 1.5 branch, but it is impossible now to > actually see history via the browser. Hi Phil, You can try these URLs: https://svn.apache.org/viewvc/commons/proper/dbcp/branches/DBCP_1_5_x_BRANCH/?pathrev=1755453 https://svn.apache.org/viewvc/commons/proper/dbcp/branches/DBCP_1_5_x_BRANCH/?view=log=1755453 Alternatively, you could also look at the 1.5 branch on GitHub: https://github.com/apache/commons-dbcp/commits/DBCP_1_5_x_BRANCH Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [configuration] review for PR 30
Le 02/07/2019 à 01:59, Gary Gregory a écrit : > What would you call the method? I don't know, setPropertyDirectInternal? It's private anyway, the name isn't important. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [configuration] review for PR 30
Le 01/07/2019 à 16:26, Gary Gregory a écrit : > May anyone that knows enough of the internals of [configuration] please > comment on https://github.com/apache/commons-configuration/pull/30 I got a quick look, besides the setArrayProperty method that doesn't seem to have the right name (there is nothing specific to arrays in the implementation, it just sets the value as is) the PR looks good. Emmanuel Bourg - 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.
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
Re: Lost SVN updates following conversion to Git
Le 24/05/2019 à 22:59, sebb a écrit : > The simplest way to stop further updates is probably to rename the SVN > directory from /proper to /_moved_to_git. This will still allow > updates by PMC members, but it's much more obvious that the SVN repo > should no longer be updated. Couldn't we set the ACL on the /proper path to read-only instead? At least it doesn't break the URLs pointing to the current path. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Using email addresses in exception messages
Le 12/05/2019 à 14:25, Gary Gregory a écrit : > +1 to removing email addresses from exception messages. We should do a pass > over all of Commons. +1, makes sense. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Message files encoding
Oops wrong list, sorry. Le 01/08/2018 à 13:00, Emmanuel Bourg a écrit : > Hi all, > > The LocalString*.properties files are ASCII encoded which renders the > modification of the non-english messages rather inconvenient. > Contributors either need a specialized resource editor or go through a > native2ascii roundtrip. > > How do feel about converting the message files to UTF-8 to facilitate > the modifications and transform them with native2ascii at build time? > > Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Message files encoding
Hi all, The LocalString*.properties files are ASCII encoded which renders the modification of the non-english messages rather inconvenient. Contributors either need a specialized resource editor or go through a native2ascii roundtrip. How do feel about converting the message files to UTF-8 to facilitate the modifications and transform them with native2ascii at build time? Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons DBCP 2.4.0 based on RC1
Le 13/06/2018 à 21:51, Gary Gregory a écrit : > #Release SHA-1s > commons-dbcp2-2.4.0-null-pom.asc=df3fbc3dc6460cba003b16f8eba13ed3ffd8beef > commons-dbcp2-2.4.0-null-jar.asc=3352f1b1ab04452445709d19272449bc5238d735 Are these "null" files excepted? Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] - git: prevent unnecessary merge commits?
+1, I prefer linear commit histories too. Emmanuel Bourg Le 09/06/2018 à 10:53, Pascal Schumacher a écrit : > Hello everybody, > > in my opinion it is a good practice to always use the "--rebase" option > when using "git pull". This keeps the history free of unnecessary merge > commits like "Merge branch 'master' of > https://git-wip-us.apache.org/repo...;. > > You can also tell git to automatically rebase when pulling: > > git config --global pull.rebase true > > What do you think? > > Cheers, > > Pascal > > > - > 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] SHA-1 vs. SHA-256
On 18/05/2018 17:30, Gary Gregory wrote: > Thoughts? I wouldn't bother. The checksum is just there to ensure the download worked properly, and for this even md5 is fine. The authenticity of the artifacts is ensured by the GPG signatures. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Discuss [VOTE] Migrate Commons Weaver to Git
Le 20/04/2018 à 00:12, sebb a écrit : > I suggest asking Infra whether they are both going to be supported longer > term. FWIW when I migrated JEXL I had no other choice than using Gitbox. I'm not sure Infra still accepts new git-wip repositories. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jexl] Migration to Git
Le 04/02/2018 à 00:49, sebb a écrit : > That should be: > > https://gitbox.apache.org/repos/asf?p=commons-jexl.git Yes sorry, but note that this URL can't be used with "git clone", the clone URL is: https://gitbox.apache.org/repos/asf/commons-jexl.git > Won't that break old references? Which ones? This is a new repository, there is no reference to it yet. The old references to SVN will keep working. > What about history? The history is fully preserved. I even resurrected tags that were missing from SVN (2.0-RC1 and 2.0-RC2). Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jexl] Migration to Git
Le 04/02/2018 à 00:46, Gilles a écrit : > Link returns: > ---CUT--- > XML Parsing Error: junk after document element Location: > https://gitbox.apache.org/repos/commons-jexl.git Line Number 33, Column 8: > > ---^ > ---CUT--- Oops it's https://gitbox.apache.org/repos/asf/commons-jexl.git - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[jexl] Migration to Git
Hi all, I'm pleased to announce that JEXL has moved to Git. This is the first Commons component using the new gitbox.apache.org service, so the URL is slightly different from the others : https://gitbox.apache.org/repos/commons-jexl.git The migration was also the opportunity to rename the old CVS style tags (COMMONS_JEXL_3_1) to a shorter form (3.1). The mail notifications don't work yet and the GitHub isn't fully up to date (only the master branch). These issues are being tracked by INFRA-15965. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Create new component commons-signing
+1 Emmanuel Bourg Le 02/02/2018 à 18:54, Mark Thomas a écrit : > Hello all, > > I propose that we create a new component [commons-signing]. > > The scope of the component is code signing utilities including, but not > limited to, Ant and Maven plugins for the Symantec code signing service > that a number of ASF projects use. > > We'll work most things out as we go along but the rough plan at this > stage is: > > * git repo > * start with the Symantec Ant task in Tomcat > * add the Maven plugin from Sling > * refactor out the duplicate code > * first release > > I'm leaning towards using GitHub issues rather than Jira. > > Please review the proposal and vote. This vote will close no sooner that > 72 hours from now. > > [ ] +1 Create the component > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this component because… > > Cheers, > > 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
Re: [Signing] New component for code signing
Le 23/01/2018 à 07:33, Mark Thomas a écrit : > Thoughts? Comments? +1 I might even be able to contribute some elements I developed for my jsign project [1]. jsign is able to sign Windows executables but using a local signing certificate or a PKCS#11 token. It comes with an Ant task, a Maven plugin, a Gradle plugin and also a command line tool. Will the scope be limited to the Symantec signing service? Emmanuel Bourg [1] https://ebourg.github.io/jsign/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Tagging Daemon 1.1
On 11/02/2017 03:42 PM, Mark Thomas wrote: > I'm happy to go with the majority preference (mine being for 1.1.0). I'm more concerned about consistency between releases than the actual version format. commons-daemon has always used 3 digits, so 1.1.0 is fine. But releasing lang 3.7.0 after 3.6 would look odd. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] version labels
On 11/02/2017 02:41 PM, Gary Gregory wrote: > I propose that all releases we do use the three part version format like > major.minor.maintenance, for example 1.1.0 for the next daemon. Why not simply 1.1 as we usually do? Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LANG] Add module-info.java?
Le 14/10/2017 à 14:43, Benedikt Ritter a écrit : > I’d like to hear opinions on this change. I wonder if we could somehow write a module-info.java compiler that works with older version of Java. The syntax doesn't look terribly complicated after all. It could be invoked from a plugin hooked to the compile phase. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Commons Lang 2.x release for Java 9
Le 9/10/2017 à 18:32, Gary Gregory a écrit : > Can you please update the Javadocs on the various methods that show Java > versions with examples up to Java 9 to make it clear that the Java 9 use > case is handled? Good idea, I added some examples to the public methods. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Commons Lang 2.x release for Java 9
Le 9/10/2017 à 22:15, Emmanuel Bourg a écrit : > ...by maven-javadoc-plugin 2.10.4 which depends on commons-lang 2.5. Actually it depends on commons-lang 2.4, not 2.5. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Commons Lang 2.x release for Java 9
Thank you for the trace. This error is actually triggered by maven-javadoc-plugin 2.10.4 which depends on commons-lang 2.5. It should be fixed in the version 3.0.0. maven-site-plugin 3.6 already uses commons-lang3. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Commons Lang 2.x release for Java 9
Le 9/10/2017 à 18:29, Gary Gregory a écrit : > One way to test isJavaVersionAtLeast for sure would be to install lang 2.7 > locally and, for example, take the current [configuration] 2.2 RC and > update the POM to use [lang] 2.7 with the Maven Site plugin. The Maven Site > plugin 3.6 currently blows up on isJavaVersionAtLeast. Interesting, what exception do you get with maven-site-plugin? Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Commons Lang 2.x release for Java 9
Le 29/09/2017 à 10:08, Emmanuel Bourg a écrit : > I'd like to prepare a new release of Commons Lang 2 that addresses the > Java 9 compatibility. I have two items in mind for this update, the > automatic module name in the manifest of course, but also the > SystemUtils.isJavaVersionAtLeast() method that is broken with Java 9 and > throws an Exception. This would be a minimal update branched off the > latest 2.6 release. I prepared the changes on GitHub: https://github.com/ebourg/commons-lang/tree/LANG_2_X I started from the 2.x branch since it contained a few fixes worth keeping. The exception I was seeing with SystemUtils isJavaVersionAtLeast() was actually fixed in 2.6, so I just added the automatic module name to the manifest (I used org.apache.commons.lang as name assuming commons-lang3 would use org.apache.commons.lang3). I updated the release notes but not the site since it's published from the master branch. Please review, I intend to merge the changes and roll the release next week. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[lang] Commons Lang 2.x release for Java 9
Hi all, I'd like to prepare a new release of Commons Lang 2 that addresses the Java 9 compatibility. I have two items in mind for this update, the automatic module name in the manifest of course, but also the SystemUtils.isJavaVersionAtLeast() method that is broken with Java 9 and throws an Exception. This would be a minimal update branched off the latest 2.6 release. Do you see anything else that should be addressed in this update? Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LOGGING] Release with Java 9 Module support
Le 26/09/2017 à 23:34, Stephen Colebourne a écrit : > I would suggest being extra cautious when releasing, as a newer > version of maven may have changed some of the config, and you don't > want to release the two extra jars to maven central. (In fact, why not > just delete their creation in pom.xml ?) Or maybe even safer: branch from the last release tag and just add the manifest entry for the new release. I wonder if we should do the same for commons-lang 2.x, it's still commonly used. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Moving component to dormant - Make JIRA read-only?
Le 24/09/2017 à 14:28, sebb a écrit : > I would be inclined to leave it open. > Might be useful to collect reports against the component, even if > nothing is planned to be done with them at present. +1 Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
Le 4/09/2017 à 15:30, Gilles a écrit : > I see it as a fundamental one: Why should codes unrelated > by scope be artificially tied together by management rules > (such as design, supported language version, release schedule, > etc.)?[1] Because they share the same general scope of being math related. The design and the supported language version can be different for each module. > Why do you "prefer" multi-module, independently of the subject > matters being talked about? I already explained twice in this thread. > Please comment on my suggestion to create a single maven project > for the whole of "Commons". I'd agree that this suggestion is > ridiculous; yet some of you do the same proposal for "everything > math-related". If you want to use an absurd proposal to prove your point let me try that game too: Please comment on my suggestion to create multiple components out of every Java package defined in the Commons components. > If you had been contributing to the math codes (plural), you > perhaps would have understood that it creates more management > problems than it solves.[4] Please use foot references for external links only, your messages are unreadable if we have to go back and forth to understand them. > Again, I have to stress on what happened that led me to propose > a new "Commons RNG": obvious improvements to the CM code base > were outrightly rejected based on demonstrably false statements; > i.e. the objections were not technical but for the convenience > of one user. I still think that splitting RNG into its own component was a good move. I'm less happy with Numbers, I'd have preferred a module from a renovated "CM5" project started from scratch as I'm suggesting now for Geometry. > Do you think that I enjoy contradicting you on these matters? I'm starting to think that you enjoy rhetoric, probably more than seeking compromise unfortunately. > Do they want to implement another plan? What plan? Here is my counter-proposal: 1. Refactor Commons Math as a multi-module project, bump to version 5 2. Create two modules: geometry and legacy 3. Release Commons Math 5, without the legacy module 4. Spin-off new modules from the legacy module when needed And I'm willing to help at least for the steps 1 and 2. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
Le 2/09/2017 à 00:50, Gilles a écrit : > Because of "Commons" rules, it is not "equivalent": There was > a long thread concluding that all modules must be released > _together_, and with the same top-level package name and version > number. True, but I don't see this as an issue. > I think that the unspecified problem(s) which you refer to > here are mostly alleviated with tools such as git and maven. I mentioned the problems in a previous message in this thread. Managing the releases, the JIRA configurations, maintaining the sites... many tasks can't be automated with tools, that's why I referred to the multi-modules solution as "lightweight" compared to multiple components. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
Le 1/09/2017 à 04:54, Dave Brosius a écrit : > So volunteers? Gary, Emmanuel, others?? are you up to doing this? I can setup the initial branch, but I need at least Gilles' consent and an indication about the first modules he'd like to integrate. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
Le 31/08/2017 à 23:33, Gilles a écrit : > it's a pity we cannot meet in person to sort all those issues Hum, maybe with a few beers you'll be easier to convince ;) > I'm not against you modularizing CM, I'm against me doing it > just because you "think" it's a better approach to the > (management) problems which I've been describing for at least > two years (and some more). I understand your point of view, you don't want to spent a lot of time modularizing CM, dealing with parts of the code you are not comfortable with and delaying the release of code you really care about. That's fair and I agree this shouldn't be forced upon you. The good news is you don't actually have to refactor *all* of CM as a multi-module project right now. Start with a mostly empty branch containing just a couple of modules you like and release them. And you progressively bring more modules after each release from the old CM branch. That's equivalent to the creation of multiple components (you cherry-pick the code that you want, and release it when ready), and you keep the lightweight management of a single component. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons CSV 1.5 based on RC1
Le 27/08/2017 à 12:10, Bruno P. Kinoshita a écrit : > [X] +1 Release it. Emmanuel Bourg signature.asc Description: OpenPGP digital signature
Re: [All][Math] New component: "Commons Geometry"?
Le 30/08/2017 à 22:14, Gilles a écrit : > -1 to asking others to do one's work.[1] So whatever the others think you don't care? If the quantity of work is important to you then you should be happy with a multi-module project since it induces significantly less work than multiple components: - one source repository - one JIRA setup - one site to manage - less release votes - less hair-pulling about defining component scopes - more flexibility to rearrange code between modules I thought you already realized that when you eventually agreed to pick this strategy for RNG instead of creating more components. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
Le 21/08/2017 à 21:41, Gary Gregory a écrit : > What about this for a compromise: create Commons Math 5 as a multi-module > project and bring in as submodules only the newly minted components and > whatever gets spun out of Math 3/4. +1 for multiple modules instead of multiple components. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Things in a POM file that are not probably incorrect
Le 27/06/2017 à 00:02, Simon Spero a écrit : > JDK 9 cannot generate or parse class files compiled with -target 1.5 [1]. AFAIK Java 9 can still parse 1.5 (and lower) class files. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: TEXT-77 | String palindrome API
Le 22/06/2017 à 06:28, Bruno P. Kinoshita a écrit : > But would be good to find someone, maybe a bioinformatician, that could > confirm if it would be useful, and give a few use cases, for that. What about waiting for someone with an actual and sensible use case to request the inclusion of palindrome functions in [text] instead? If we try to include whatever text processing function we can imagine in [text], even if they aren't used, we'll end up with an oversized and bloated API. I think the development should be driven by actual needs and not by hypothetical usage. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: TEXT-77 | String palindrome API
Le 21/06/2017 à 19:17, Amey Jadiye a écrit : > Though its very trivial to build, by any chance we should have palindrome > method in Apache Commons API ? there is nothing bad having this tool in > our arsenal, preferably in StringUtils ? Like sebb I fail to see the use case for this. Checking palindromes looks more like an academic exercise to me than a useful feature of a text oriented library. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] dev@ traffic
Le 19/06/2017 à 15:41, Stefan Bodewig a écrit : > those two should go to the same list even if its "issues"? Yes, sorry for the ambiguity. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] dev@ traffic
Le 19/06/2017 à 12:32, Stefan Bodewig a écrit : > IMHO neither should go to dev@ and using notifications@ seems more > logical to me. I'm going to change this for Compress and would likt to > ask other components to check their settings as well so we can raise the > signal ratio for dev@ again. +1 for redirecting Jenkins to notifications@ GitHub PRs and JIRA should target the same list. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request
Le 11/06/2017 à 21:16, Gary Gregory a écrit : > Can you show us a real problem that this would have solved? +1, I don't understand what actual issue it would solve with commons-compress. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: OSGi Version at Package Level
Le 7/06/2017 à 09:23, Bertrand Delacretaz a écrit : > With the right tools as mentioned in my previous message it's quite easy. Easier but not easy. > Implementing semantic versioning at the java package level as opposed > to bundle level. That's the theory, I'm actually curious to see what real issue it solves with commons-compress. What incompatibility in commons-compress caused an issue with an OSGi application? And was there no other alternative to solve this issue? Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: OSGi Version at Package Level
Le 7/06/2017 à 02:10, Jörg Schaible a écrit : > Your opinions? Do I understand well that we would have to micro manage versions at the package level different from the version at the component level, and sometimes significantly different versions (like foo 1.2.3 and org.apache.commons.foo.bar 2.3.4)? That sounds like a nightmare. What is the real gain? What existing problem would that solve exactly? Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Compiler targets and Java 9
Le 5/06/2017 à 16:41, Jochen Wiedmann a écrit : > All commons proper components are expected within one year from now on > to bump their compiler target to 1.6, or beyond, and have a release > published with that target. That way, we know, that it works fine with > the Java 9 compiler. +1 for using 1.6 as the baseline, but I don't see the need to publish new releases with that target if nothing else changed. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1792641 - /commons/proper/jexl/trunk/pom.xml
Le 25/04/2017 à 21:20, sebb a écrit : > Problem is that the short form does not generate the correct relative > links from component pages to the Commons parent site. > Such links need an extra ../ segment. Where are these links generated? We should switch them to absolute URLs. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1792641 - /commons/proper/jexl/trunk/pom.xml
Le 25/04/2017 à 20:36, s...@apache.org a écrit : > --- commons/proper/jexl/trunk/pom.xml (original) > +++ commons/proper/jexl/trunk/pom.xml Tue Apr 25 18:36:28 2017 > @@ -28,7 +28,7 @@ > Apache Commons JEXL > 2001 > The Apache Commons JEXL library is an implementation of the > JSTL Expression Language with extensions. > -http://commons.apache.org/jexl/ > +http://commons.apache.org/proper/commons-jexl/ I'd prefer keeping the short form. I still hope we'll be able to get rid of these horribly long URLs and return to the ones we had originally. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Java 9 module names
Le 22/04/2017 à 01:02, Stephen Colebourne a écrit : > I've started a page here: > https://github.com/jodastephen/jpms-module-names/blob/master/README.md > Feel free to raise a PR with more projects at commons or elsewhere in > Apache - I'm just checking the Javadoc and releases to ensure there > are no problems. Seeing Commons Lang 2 in the list I realize we'll have to dust off the old branches and publish new releases (lang 2.x, configuration 1.x, jexl 2.x, math 3.x, pool 1.x, etc). Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] explicit Maven groupId in component POMs
Le 21/04/2017 à 18:39, sebb a écrit : > But the problem is that it would be very easy to change the parent gid > and assume that everything is still OK. But why would we change the parent groupId? It hasn't changed since its first release 10 years ago and I don't see the need for a new name. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] explicit Maven groupId in component POMs
Le 21/04/2017 à 15:12, sebb a écrit : > Agreed? I don't mind, but IntelliJ will highlight the groupId and suggest to remove it :) Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Java 9 module names
Le 21/04/2017 à 14:00, Stephen Colebourne a écrit : > Comments? Questions? Hi Stephen, Thank you for stopping by and enlightening us about JPMS. The new module system looks like a huge mess. I understand the need for modularization at the JRE level, but I haven't figured out yet how this extra complexity will improve my applications. I know you've followed the development of this feature thoroughly and I trust your judgment. You still have commit access to the Commons components, so I'd encourage you to go ahead and implement your suggestion directly. Commons Lang 3.6 is about to be released, we could start with this one and use it as an example for the other components. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] - Close java.util.Date related enhancement requests as won't fix?
Le 19/04/2017 à 18:00, Pascal Schumacher a écrit : > What do you think? I agree for LANG-1065, this case is covered by the Java 8 API. The improvements suggested in the other issues could be designed to work with the java.time API, maybe in a dedicated commons-time component. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] new concurrency annotations
Le 19/04/2017 à 00:23, Gary Gregory a écrit :
> I'd like to see a real example before we talk about abstract arguments and
> counter-arguments, which will never end ;-)
Ok, here is a slightly more substantial example. The following class is
immutable but not thread-safe:
public class FileAppender {
private final File file;
public FileAppender(File file) {
this.file = file;
}
public void append(String message) throws IOException {
try (OutputStream out = new FileOutputStream(file)) {
out.write(message.getBytes());
}
}
}
The point is, if the class operates on resources outside the JVM, the
immutability doesn't ensure the thread safety. Immutability is only a
thread safety guarantee for data structures, and not for classes with
operations causing side effects (like writing to files, drawing on the
screen, playing sounds, calling remote services, accessing off-heap
memory, etc).
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] new concurrency annotations
Le 18/04/2017 à 23:06, Gary Gregory a écrit : > This use case does not make sense to me. If an object is immutable, then it > is thread safe. If you want to include an asynchronous external resource as > part of your object, then the object might not be in fact, immutable. > Speaking of a specific use case would be better. What about something like a FileOutputStream? The object fields could be final (the file descriptor never changes), but the write methods can't be safely called concurrently. Another example would be an interface to a remote service. The stub could be immutable and contain the URL of the remote service, but the operations couldn't be called by multiple threads. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] new concurrency annotations
Le 18/04/2017 à 08:36, Gary Gregory a écrit : > Thoughts? I think I tend to prefer the JCIP style. ThreadingBehavior conflates the notions of thread safety and immutability and intuitively I'd keep them separate, even if they are often closely related. An object could be immutable and not thread safe because it operates on an external resource that doesn't work concurrently. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] The Commons Math issue
Le 18/04/2017 à 15:42, Gilles a écrit : > And that's why "do-ocracy" should really matter more than > "opinion". And how do you reach consensus if you aren't open to others opinions? Doing and not listening is just a variant of dictatorship, that's not my vision of an open community. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[RESULT][VOTE][LAZY] Migrate Apache Commons JEXL to Git
No objection was raised, the vote therefore passes. I'll proceed with the migration. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] The Commons Math issue
On 04/14/2017 06:12 PM, Gilles wrote: > [I can be clearer: I had this issue with Emmanuel, about the > design and scope of "Commons RNG" (cf. ML archive), and it was > acknowledged that "do-ocracy" must prevail over "opinion".] Well, I had much more than mere "opinions" to offer to RNG, but you rushed and imposed your design. So be it, I gave up, I didn't have enough free time to keep up and argue with you, and there are other areas where I can be useful. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[VOTE][LAZY] Migrate Apache Commons JEXL to Git
Hi all, Now that JEXL 3.1 is out I think it's a good time to move the repository to Git. I'd like to start a vote by lazy consensus about the migration, the vote will be considered as passed after 72 hours if nobody objects. Thank you, Emmanuel Bourg signature.asc Description: OpenPGP digital signature
[ANNOUNCE] Apache Commons JEXL 3.1 Released
The Apache Commons Team is pleased to announce the availability of: Apache Commons JEXL 3.1 Apache Commons JEXL is a library intended to facilitate the implementation of dynamic and scripting features in applications and frameworks written in Java. The release notes can be reviewed at: http://www.apache.org/dist/commons/jexl/RELEASE-NOTES.txt Distribution packages can be downloaded from: https://commons.apache.org/proper/commons-jexl/download_jexl.cgi When downloading, please verify signatures using the KEYS file available at: http://www.apache.org/dist/commons More information and comprehensive documentation is available at: https://commons.apache.org/jexl/ Maven artifacts are also available in the central Maven repository: http://repo1.maven.org/maven2/org/apache/commons/commons-jexl3/3.1/ The Apache Commons Team signature.asc Description: OpenPGP digital signature
[RESULT][VOTE] Release JEXL 3.1 based on RC1
On 04/07/2017 11:59 PM, Emmanuel Bourg wrote: > JEXL is ready for a new release, please review the artifacts and cast > your votes. > > Changes since 3.0: > > https://dist.apache.org/repos/dist/dev/commons/jexl/3.1_RC1/RELEASE-NOTES.txt > http://people.apache.org/~ebourg/jexl/site/changes-report.html > > SVN tag: > > http://svn.apache.org/repos/asf/commons/proper/jexl/tags/COMMONS_JEXL_3_1-RC1 > (r1790565) Here is the result of the vote: Oliver Heger:+1 Jörg Schaible: +1 Bruno Kinoshita: +1 Emmanuel Bourg: +1 Henri Biestro: +1 (non binding) With at 4 +1 binding votes and no objections the vote passes. Thanks a lot for the reviews! I'll proceed with the release in the next days. Emmanuel Bourg signature.asc Description: OpenPGP digital signature
Re: [ALL] The Commons Math issue
On 04/12/2017 05:29 PM, Gilles wrote: > Do you actually prefer advertizing a non-Apache project rather than > having the PMC support its own developers in any which way it could? If nobody is able to maintain commons-math I have no objection recommending an alternative, especially one that is derived from commons-math, has the same license and an open development process. The minimal support you can expect from the PMC members is people voting on the releases, and if there is no show stopper like binary incompatibilities, awful regressions or improperly licensed code, the vote will be a non-issue. > How can you be so sure? The last releases did not elicit an awful lot > of votes; and that is for components that do not raise objections about > their mere existence. Give it a try? Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] The Commons Math issue
On 04/12/2017 02:56 PM, Gilles wrote: > Yes; and it is good per se, of course. Unforunately, it didn't change > the Commons Math issue: it's still unmaintained, and from what I observe > on JIRA, it's not going to improve with time (I said that much one year > ago and I was right, in hindsight). Ok, then let's move commons-math to dormant and redirect the users to Hipparchus. > Last time I acted (to request a "git" repository from INFRA), you (IIRC, > pardon me if I'm wrong) complained ;-) that it had not been agreed upon... Wasn't this because you wanted to create a new component before considering other options like creating a submodule of an existing component? > Moreover, the lack of interest shown by the PMC > is a worrying indication that any further work can be doomed to not get the > minimal support for an official release, even if there would be no > "technical reason"[4] to prevent such release. I wouldn't worry about that, even if few members are actively contributing to the code there are enough people ready to review and vote on the releases. > [1] It's the right size and scope: I now agree with the PMC members who > did not see it useful to have its current modules as separate > components. Good, and it could be the same with CM for the parts that may not fit well in a separate component. > [5] As usual, sorry for the long email, but trying to keep messages > short does not seem to help either in conveying correctly what I > perceive as a need for PMC action... Thanks! Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
