Re: [LOGGING] 2.0

> On Feb 13, 2024, at 3:39 AM, Piotr P. Karwasz wrote: > > If such a thing is even possible, it would be nice if we can get > `jakarta.logging` as the package prefix. Creating a Jakarta logging would certainly be possible. I am not certain if that follows the JCP process though since

Re: [ALL] Eventually, soon, Java 11

The primary reason for moving to Java 11 is to fully support JPMS. Most libraries have added an automatic module name to the Manifest but that doesn’t really make it fully JPMS enabled. To be honest, the number of people I’ve seen asking for full JPMS support is quite small though. Ralph >

Re: New component proposal: commons-plugins

> On Apr 12, 2022, at 6:56 PM, Thomas wrote: > > > On 11.04.2022 00:00, Ralph Goers wrote: >> See below >> >>> On Apr 8, 2022, at 9:23 AM, Peter Verhas wrote: >>> >>> Thanks Ralph for the detailed explanation. I appreciate it and now I s

Re: New component proposal: commons-plugins

See below > On Apr 8, 2022, at 9:23 AM, Peter Verhas wrote: > > Thanks Ralph for the detailed explanation. I appreciate it and now I see > the points. I’ve removed the parts that I don’t think need any more discussion. > - How will it be a “plugin" project and not another dependency injection

Re: New component proposal: commons-foo or better commons-text

The Log4j variation used StrSubstitutor straight from Commons (wherever it was located at the time) but then had to modify some of the methods to accept LogEvents. To do this StringSubstitutor would have to be modified to be StringSubstitutor and allow an object of type T to be passed to the

Re: New component proposal: commons-plugins

> On Apr 7, 2022, at 2:52 AM, Peter Verhas wrote: > > >> I would suggest that before responding to this email that >> you go look at how log4j-plugins is implemented in the master branch. >> > > Sure, if you propose to create a commons-plugin library that is an extract > of the plugin

Re: New component proposal: commons-plugins

If I had known this was going to turn into a debate I wouldn’t have responded to the question. But it seems either my response wasn’t clear, you did not understand what I wrote, or you have some preconceived notion as to why anything beyond ServiceLoader is needed. I would suggest that before

Re: New component proposal: commons-plugins

; >> Gary Gregory 于2022年4月4日周一 21:11写道： >> >>> I am trying to figure out the input and output of a Commons Plugins >>> that Log4j would use. >>> >>> Gary >>> >>> On Sun, Apr 3, 2022 at 10:51 PM Ralph Goers >>> wrote:

Re: New component proposal: commons-plugins

of a Commons Plugins >> that Log4j would use. >> >> Gary >> >> On Sun, Apr 3, 2022 at 10:51 PM Ralph Goers >> wrote: >>> >>> It has been too long since I looked at Commons Configuration for me to >>> answer that. >>> &

Re: New component proposal: commons-plugins

It has been too long since I looked at Commons Configuration for me to answer that. Ralph > On Apr 3, 2022, at 7:25 PM, Gary Gregory wrote: > > So in a Commons centric fantasy, Log4j Nodes could be Commons Configuration > objects? > > G > > On Sun, Apr 3, 2022,

Re: New component proposal: commons-plugins

ote: > > Nice thread :-) > > Where does the parsing of configuration files mix in such a stack? > > Where does variable interpolation come into play? > > Gary > > On Sun, Apr 3, 2022, 20:50 Ralph Goers wrote: > >> Matt J, >> >> I fully expect th

Re: New component proposal: commons-plugins

Matt J, I fully expect that if commons-plugins came into fruition it would bear a resemblance to the Log4j plugin system but there would be differences. For example, while Log4j integrates with Spring we don’t currently support having the logging configuration in application.yml. I also

Re: New component proposal: commons-plugins

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

Re: New component proposal: commons-plugins

ServliceLoader is used to locate plugins but what is loaded by ServiceLoader are not plugins. Log4j Plugins are categorized into different groupings, primarily by where and how the plugins are used. For example, PatternConverters used by the PatternLayout are separate from Appenders, Filters

Re: [EXTERNAL] [Numbers][All] Separate Java target version for "src/test"

I don’t understand this. Log4j2 was one of the first adopters of multi-release jars. There were problems in the beginning but those have virtually all been resolved. We haven’t had any complaints in ages. Log4j 2 2.14.1 supports Java 8. Fully supporting JPMS (i.e. - adding a module-info.java

Re: [REPORT][DRAFT] Apache Commons Board report for June 2021

> On Jun 6, 2021, at 11:44 AM, Gilles Sadowski wrote: > > Le dim. 6 juin 2021 à 14:54, Gary Gregory a écrit : >> >> Here is the draft I plan on submitting: >> >> ## Description: >> The mission of Apache Commons is the creation and maintenance of Java focused >> reusable libraries and

Re: The case for a Commons component

t; >>> >>> There is no need for a Sandbox component to use SVN, and it's easy to >>> create a new Commons git repo. >>> >>> A non-ASF code repo would require code to be checked for license >>> compliance etc before it could become a Com

Re: [math] working on increasing performance for Math3

> On May 8, 2021, at 5:14 AM, Gilles Sadowski wrote: > > Hello. > > Le sam. 8 mai 2021 à 08:42, Benjamin Marwell > a écrit : >> >> Instead of using byte buddy, why not just maven multi release jars? *1 > > Thanks for the suggestion. > Again, I don't know how to

Re: The case for a Commons component

> On May 6, 2021, at 3:04 AM, Gilles Sadowski wrote: >> >> It looks like you didn’t read the page. > > I did, of course. And my interpretation differs. > >> For clarity I am copying it here >> >> "Votes on procedural issues follow the common format of majority rule unless >> >> otherwise

Re: The case for a Commons component

> On May 6, 2021, at 8:06 AM, Gary Gregory wrote: > > What about the Commons Sandox? Would that be a good place to start? > Emmanuel just sort of proposed doing away with it. As he put it, anyone can create a GitHub repo so why does it need to be under the apache user. He hasn’t

Re: The case for a Commons component

> On May 5, 2021, at 11:13 AM, Gilles Sadowski wrote: > > Le mer. 5 mai 2021 à 17:44, Ralph Goers a écrit : >> >> >> >>> On May 5, 2021, at 6:38 AM, Gilles Sadowski wrote: >>> >>> Le mar. 4 mai 2021 à 02:49, Ralph Goers a >&g

Re: The case for a Commons component

> On May 5, 2021, at 6:38 AM, Gilles Sadowski wrote: > > Le mar. 4 mai 2021 à 02:49, Ralph Goers a écrit : >> >> I apologize. I started another thread regarding the vote before seeing this. > > No problem. > >> Maybe that will get more attention? &g

Re: The case for a Commons component

he [Vote] before getting into the > details... > > Currently, there have been votes by: > Emmanuel Bourg (-1) > Sebastian Bazley (-0) > Ralph Goers (+0) > Paul King (+1) > > So currently, the discussion should be focused on settling to the > issues put forward by th

[Discuss][Vote] Create repository for "machine learning" algorithms.

How long is this vote going to stay open? This vote has already been open for 12 days. To this point we have Sebb - no actual vote but somewhere between 0 and -1. (Binding) Ralph - +0 (Binding) Emmanuel: -1 (Binding) Paul King: +1 (Non-Binding) Gilles: + 1 (Binding) Arijit: +1 (Non-Binding) So

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

> On Apr 29, 2021, at 4:49 AM, sebb wrote: > > On Thu, 29 Apr 2021 at 12:00, Gilles Sadowski wrote: >> >> Le jeu. 29 avr. 2021 à 01:45, sebb a écrit : >>> >>> On Thu, 29 Apr 2021 at 00:10, Gilles Sadowski wrote: It occurs to me that we *should* create a specific "git"

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

> On Apr 29, 2021, at 3:58 AM, Gilles Sadowski wrote: > > >> There's no point converting to Git if that process is more involved >> than the existing process. > > I'm not sure that we mean the same with "the existing process". > Earlier in the thread, I've described what I do: > > $ mvn

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

> On Apr 27, 2021, at 6:57 AM, Gilles Sadowski wrote: > > Le mar. 27 avr. 2021 à 12:32, sebb > a écrit : >> >> On Tue, 27 Apr 2021 at 02:10, Gilles Sadowski wrote: >>> >> [...] > > OK to create the >commons-site > "git" repository?

Re: The case for a Commons component

How many committers will be active for this component? Ralph > On Apr 26, 2021, at 7:17 AM, Avijit Basak wrote: > > Hi > >As per previous discussions, I have created a temporary repository > in GitHub under my personal GitHub Id(avijitbasak). The artifacts have been > copied from

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

e easier to use? >>> There's no point changing the publication strategy if it is not an >>> improvement. >> >> Quoting Ralph Goers: >> ---CUT--- >> When I release Log4j I rum mvn site followed by "mvn site:stage >> -DstagingDi

Re: [Vote] Create repository for "machine learning" algorithms.

+0 I am fine with the proposal but I won’t be contributing to it or helping to maintain it so I am hesitant to vote +1. Ralph > On Apr 21, 2021, at 10:05 AM, Gilles Sadowski wrote: > > Hi. > > [This a reboot of the proposal for which the preceding vote > has just been cancelled.] > > Name

Re: [Vote] Create a "machine learning" component

> On Apr 21, 2021, at 2:25 AM, Gilles Sadowski wrote: > > Le mer. 21 avr. 2021 à 08:56, Paul King a écrit : >> >> On Wed, Apr 21, 2021 at 4:12 PM Ralph Goers >> wrote: >>> >>> Why are y’all having a long discussion on Vote thread? > &

Re: [Vote] Create a "machine learning" component

d to think >>> (unfortunately) >>> that it isn't. He should first explore whether the Spark community >>> is >>> interested, that the GA functionality be moved over there. >>> >>> Gilles >>> >>> [1] https://issues.apache.org/ji

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

> On Apr 18, 2021, at 6:38 AM, sebb wrote: > > On Sun, 18 Apr 2021 at 13:40, Gary Gregory wrote: >> >> Note that git also has its gitlink and sub modules features that we could >> use here. > > Are they easy to use? Submodules are documented at

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

> On Apr 17, 2021, at 3:32 PM, sebb wrote: > > On Sat, 17 Apr 2021 at 22:57, Ralph Goers <mailto:ralph.go...@dslextreme.com>> wrote: >> >> >> When I release Log4j I rum mvn site followed by "mvn site:stage >> -DstagingDirectory=$HOME/l

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

One other think I should add. Although Infra’s pages mention tools that you can use those are just suggestions. As long as you use the .asf.yaml files and place the files in the correct locations in the repos you can use any tooling you want to create the sites. I used JBake because I felt it

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

You should see my other message but I will reply to your questions also. > On Apr 16, 2021, at 1:37 PM, Gilles Sadowski wrote: > > Hello. > > Le ven. 16 avr. 2021 à 20:39, Ralph Goers a > écrit : >> >> FYI - I did the work of moving Logging Services site from

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

tures > On Apr 17, 2021, at 6:48 AM, sebb wrote: > > On Fri, 16 Apr 2021 at 19:39, Ralph Goers wrote: >> >> FYI - I did the work of moving Logging Services site from the CMS to git. It >> really wasn’t that hard. The main web site is at >> https://git

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

FYI - I did the work of moving Logging Services site from the CMS to git. It really wasn’t that hard. The main web site is at https://github.com/apache/logging-site . Each of the subproject has their own site such as

Re: [exec][email] Java 7 to 8

We just concluded this same discussion for Log4j. I looked at the JRebel 2021 report [1] to gauge the number of people using a particular Java version. Respondents were able to select multiple versions so the numbers don’t add up to 100%. Java 7 or older.15% Java 8 69%

Re: [Vote] Create a "machine learning" component

-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

Re: Unapproved license

To get even more specific, That message is usually generated by the Maven RAT plugin. RAT is an Apache tool to verify that our projects have an appropriate license header. A file should have been generated in the “target” directory named rat.txt that lists the files without an appropriate

Re: No more dependabot

I am not sure that is possible since Dependabot is actually creating PRs and GitHub sends those to the mailing list. What I heard was that they would like to have Dependabot just send reports from time to time about what dependencies could be changed rather than create PRs. Matt also mentioned

Re: [All] New repo for all proper components as submodules?

Why? > On Sep 1, 2020, at 8:39 PM, Matt Sicker wrote: > > It could be useful for grouping inter-dependent modules like pool/dbcp. > > On Tue, Sep 1, 2020 at 21:46 Ralph Goers wrote: > >> As I said previously, I would avoid using either one. I really don’t kn

Re: [All] New repo for all proper components as submodules?

As I said previously, I would avoid using either one. I really don’t know why you would want to with Java. I can understand it with applications written in C where you might want to compile all the dependencies along with the main application. But that isn’t the case in Java. Introducing

Re: [All] New repo for all proper components as submodules?

> On Aug 31, 2020, at 8:24 AM, Ralph Goers wrote: > > > >> On Aug 31, 2020, at 7:01 AM, Gary Gregory wrote: >> >> My target use case here is: I want an easy way to work on all of Commons in >> a new VM or a new machine, so I'd like to be able to check

Re: [All] New repo for all proper components as submodules?

> On Aug 31, 2020, at 7:01 AM, Gary Gregory wrote: > > My target use case here is: I want an easy way to work on all of Commons in > a new VM or a new machine, so I'd like to be able to check out all of > Commons in one go from any level for example here is an imaginary git > submodule tree: >

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

Why are you singling out Corretto? What about AdoptOpenJDK or RedHat’s OpenJDK support? The ASF is supposed to be vendor neutral. Ralph > On Mar 21, 2019, at 11:05 AM, Rob Tompkins wrote: > > Hello all, > > I would think that with the Amazon Corretto play at long term support for > java 8

Re: [log4j] Please release 2.11.1 from Nexus

Wrong mailing list? Ralph > On Jul 27, 2018, at 6:58 AM, Gary Gregory wrote: > > Hi Ralph, > > May you please release 2.11.1 from Nexus? I want to pick up the release > ASAP from our builds. > > Thank you, > Gary - To

Re: [VOTE] Migrate existing Git repos to GitBox

+1 Although I really would like to see documentation somewhere on how the process differs. For example, with GitBox can we now merge pull requests directly at GitHub? That would be a nice benefit. Can we still commit to the ASF git repo or only at GitHub? Ralph > On Apr 22, 2018, at 10:07

Discuss [VOTE] Migrate Commons Weaver to Git

Is this vote for Git or Gitbox or is there any difference these days? Ralph > On Apr 19, 2018, at 8:46 AM, Matt Benson wrote: > > Hello, > After having received some support from a "feeler" email, I would like to > propose the formal vote to migrate this Commons component

Re: Prepare commons to JDK 9

> On Mar 12, 2018, at 9:27 AM, Jörg Schaible <joerg.schai...@gmx.de> wrote: > > Hi Ralph, > > On Wed, 07 Mar 2018 11:56:32 -0700 Ralph Goers wrote: > >>> On Mar 7, 2018, at 2:47 AM, Stephen Colebourne <scolebou...@joda.org> >>> wrote: >>&g

Re: Prepare commons RDF to JDK 9

> On Mar 8, 2018, at 5:47 PM, Bernd Eckenfels wrote: > > Hello, > > any experience with compiling a JAR with old Java and only adding the > module-info.jar with a new class Version? Would that allow to avoid the Need > for Multi-Release JARs? (of Course it makes a

Re: Prepare commons RDF to JDK 9

> On Mar 8, 2018, at 5:17 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > > >> On Mar 8, 2018, at 4:08 PM, Gilles <gil...@harfang.homelinux.org> wrote: >> >> On Thu, 8 Mar 2018 15:09:18 -0700, Ralph Goers wrote: >>>> On Mar 8, 2

Re: Prepare commons RDF to JDK 9

> On Mar 8, 2018, at 4:08 PM, Gilles <gil...@harfang.homelinux.org> wrote: > > On Thu, 8 Mar 2018 15:09:18 -0700, Ralph Goers wrote: >>> On Mar 8, 2018, at 11:06 AM, Gilles <gil...@harfang.homelinux.org> wrote: >>> >>> On Thu, 8 Mar 2018 11:01:

Re: Prepare commons RDF to JDK 9

> On Mar 8, 2018, at 11:06 AM, Gilles wrote: > > On Thu, 8 Mar 2018 11:01:08 -0700, Gary Gregory wrote: >> On Thu, Mar 8, 2018 at 10:58 AM, Gilles >> wrote: >> >>> On Thu, 8 Mar 2018 10:48:28 -0700, Gary Gregory wrote: >>> On

Re: Prepare commons to JDK 9

lt;gil...@harfang.homelinux.org> wrote: > > Hello. > > On Wed, 7 Mar 2018 22:21:44 +, Stephen Colebourne wrote: >> On 7 March 2018 at 18:56, Ralph Goers <ralph.go...@dslextreme.com> wrote: >>> Actually, you really do need to use a multi-release jar to includ

Re: Prepare commons to JDK 9

> On Mar 7, 2018, at 2:47 AM, Stephen Colebourne wrote: > > 1) Moving to Java 9 as a base would be a terrible choice. Java 9 is a > six-month release which is about to be replaced by Java 10, which will > then be replaced by Java 11. Thus, Java 8 is the only sensible >

Re: Discussion: New commons module/project

If this was a project to create specs AND provide reference implementations I think it would make sense. I don’t see how a project that just creates specs fits with Commons personally. Ralph > On Feb 13, 2018, at 1:46 PM, Matt Sicker wrote: > > A sort of commons-algorithms

Re: [draft] Board report is due Dec 20.

LGTM Ralph > On Dec 14, 2017, at 9:48 AM, Gary Gregory wrote: > > I will send this report to the board later tonight. Let me know if you > think it needs to be amended. > > Gary > > On Wed, Dec 13, 2017 at 1:38 PM, Gary Gregory > wrote: > >>

Re: [text] Adapt the Log4j 2 Interpolator to [text]

Yes, the Interpolator was borrowed from Commons Configuration. Ralph > On Dec 14, 2017, at 5:20 AM, Jörg Schaible > wrote: > > Hi Gary, > > Am Wed, 13 Dec 2017 15:17:56 -0700 schrieb Gary Gregory: > >> Hi All, >> >> Log4j 2 provides it's own copy of our

Re: [All][Math] New component: "Commons Geometry"?

I don’t know why you are ignoring option 3, which is what many have suggested many times. 3) Modify CM to be a multi-module project that contains only the modules you want to support. Ralph > On Dec 3, 2017, at 4:51 AM, Gilles wrote: > > On Sun, 3 Dec 2017

Re: [LOGGING] Logging is Java 1.2 but required Java 1.4 code

critical fixes/updates. >> Upgrading to Java 6 seems to contradict this plan. So where do we want to >> go with Logging? >> >> Regards, >> Benedikt >> >>> Am 28.10.2017 um 18:20 schrieb Ralph Goers <ralph.go...@dslextreme.com>: >>> &

Re: [LOGGING] Logging is Java 1.2 but required Java 1.4 code

That isn’t strictly true Gary, There are ways to build the module-info without upgrading the main code to Java 9. That said, it is a bit of a hack to do it. Ralph > On Oct 28, 2017, at 8:19 AM, Gary Gregory wrote: > > Let's update to at least a minimum of Java 6 such

Re: [LANG] Add module-info.java?

10.2017 um 01:30 schrieb Matt Sicker <boa...@gmail.com>: >>> >>> Which is mainly because the version of Java in Android is intentionally >>> lacking about half of the standard library. Perhaps this will improve in >>> the future now that they're adop

Re: [LANG] Add module-info.java?

I need to point out that even after removing that there would be a lot of stuff in log4j-core that doesn’t work in Android. Ralph > On Oct 14, 2017, at 12:02 PM, Gary Gregory wrote: > > I am wondering if this is a little too early. A lot of tooling our there > does not

Re: [LOGGING] Release with Java 9 Module support

> On Oct 1, 2017, at 2:48 AM, sebb wrote: > > On 1 October 2017 at 10:08, Pascal Schumacher > wrote: >> Looks like commons-logging-api is used by some popular projects (Hibernate, >> Hadoop, Camel): >> >>

Re: [LOGGING] Release with Java 9 Module support

hat is the case, I think we are ready to release this. > > Benedikt > > Gary Gregory <garydgreg...@gmail.com> schrieb am So. 1. Okt. 2017 um 03:39: > >> On Sep 30, 2017 11:24, "Ralph Goers" <ralph.go...@dslextreme.com> wrote: >> >> Looking

Re: [LOGGING] Release with Java 9 Module support

Looking at the build script it appears that both the api and adapters modules contain a subset of what is in commons-logging.jar. I have no idea why this is but all three of them cannot be modularized. I would suggest only modularizing commons-logging.jar and ignoring the other two. Ralph >

Re: [All][RNG] Generate signatures and checksums (Was: [COLLECTIONS] Time for 4.2)

> On Sep 20, 2017, at 8:27 AM, Gilles wrote: > > On Wed, 20 Sep 2017 09:19:35 -0600, Gary Gregory wrote: [...] >>> >>> Is there a solution to this issue: >>> https://issues.apache.org/jira/browse/RNG-31 >>> >>> IOW how do other modular components

Re: [JCS] update to Log4j 2 facade API

ry-rmannibucau.rhcloud.com> > > 2017-09-05 20:13 GMT+02:00 Gary Gregory <garydgreg...@gmail.com>: > >> On Tue, Sep 5, 2017 at 11:03 AM, Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >> >>> >>>> On Sep 5, 2017, at

Re: [JCS] update to Log4j 2 facade API

> On Sep 5, 2017, at 9:19 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > Le 5 sept. 2017 17:35, "Ralph Goers" <ralph.go...@dslextreme.com > <mailto:ralph.go...@dslextreme.com>> a écrit : > > >> On Sep 5, 2017, at 6:45 AM

Re: [JCS] update to Log4j 2 facade API

> On Sep 5, 2017, at 6:45 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > 2017-09-05 15:33 GMT+02:00 Ralph Goers <ralph.go...@dslextreme.com>: >> >> I see your point. I guess we never built a bridge from the Log4j 2 API to >> JUL simply becaus

Re: [JCS] update to Log4j 2 facade API

>> On Sep 4, 2017, at 10:03 PM, Romain Manni-Bucau <rmannibu...@gmail.com> >> wrote: >>> >>> Le 5 sept. 2017 05:40, "Ralph Goers" <ralph.go...@dslextreme.com> a >> écrit : >>> >>> >>>> On Sep 4, 2017, at 2:24 PM, Rom

Re: [JCS] update to Log4j 2 facade API

> On Sep 4, 2017, at 2:24 PM, Romain Manni-Bucau wrote: > > Le 4 sept. 2017 20:44, "Matt Sicker" a écrit : > > You don't duplicate any logging config. You can use both slf4j-api and > log4j-api with either logback or log4j2. > > > Except you dont

Re: [JCS] update to Log4j 2 facade API

Although I am a big fan of Log4j 2, there are use cases where more thought needs to be given then just adopting it, SLF4J, JUL, etc. The problem comes into play in in frameworks like Tomcat, TomEE or JBoss AS. These frameworks need to perform logging but whatever they use has to be able to

Re: [All][Math] New component: "Commons Geometry"?

has proven he is right. >> >> Given he is trying his best to keep code going, and actually the one doing >> the work, perhaps we should be a little bit less offensive about trying to >> shut him down. >> >> --dave >> >> On 08/21/2017 01:52 PM, Ralph Goe

Re: [All][Math] New component: "Commons Geometry"?

> On Aug 21, 2017, at 4:39 AM, Gilles <gil...@harfang.homelinux.org> wrote: > > On Mon, 21 Aug 2017 08:31:55 +0200, Benedikt Ritter wrote: >>> Am 20.08.2017 um 23:11 schrieb Ralph Goers <ralph.go...@dslextreme.com>: >>> >>> I have to agree with

Re: [All][Math] New component: "Commons Geometry"?

oops. My bad. I just noticed this is NOT a vote there. I just saw what looked like votes. Ralph > On Aug 20, 2017, at 2:12 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > This is a vote thread - not a discussion thread. If you want to discuss > people’s votes please

Re: [VOTE] Move Apache Commons Launcher to dormant?

+1 Ralph > On Aug 20, 2017, at 3:11 AM, Pascal Schumacher > wrote: > > Hi all, > > as discussed, I'd like to propose to move Apache Commons Launcher to dormant. > > Reasons: > - The last release is from 2007. > - No bugfix or feature addition commits since 2007. >

Re: [All][Math] New component: "Commons Geometry"?

This is a vote thread - not a discussion thread. If you want to discuss people’s votes please move it to another thread. Ralph > On Aug 20, 2017, at 11:29 AM, Gilles wrote: > > On Sun, 20 Aug 2017 23:16:17 +0530, Amey Jadiye wrote: >> I'm +1 to this change, I

Re: [All][Math] New component: "Commons Geometry"?

I have to agree with Jochen and am -1 to this proposal. I have stated before that I don’t want to see Commons become the placeholder for all the Math related components. If Math has stuff that can’t be maintained then create a MathLegacy project in the sandbox and move the stuff there. Ralph

Re: Ready for JDK 9 ?

I have my doubts about the module system but I am not sure why you would think multi-release jars will cause problems. Ralph > On Aug 9, 2017, at 8:28 AM, Gary Gregory wrote: > > On Wed, Aug 9, 2017 at 1:09 AM, Jörg Schaible < > joerg.schai...@bpm-inspire.com

Re: Things in a POM file that are not probably incorrect

It seems so, although it sounds like there is a solution to do it with Java 7 and 8 as well. http://events.linuxfoundation.org/sites/events/files/slides/Java9%20and%20the%20impact%20on%20Maven%20projects.pdf

Re: [LOGGING] Logging and Java 9 (Was: Re: Compiler targets and Java 9)

The latest discussions I read indicated that adding the automatic module entry to the manifest is NOT recommended unless the component is ready to be modularized except that it has downstream dependencies that are not modules. Ralph > On Jun 6, 2017, at 5:18 AM, Jörg Schaible

Re: Compiler targets and Java 9

> On Jun 5, 2017, at 2:58 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > >> On Jun 5, 2017, at 1:00 PM, Amey Jadiye <ameyjad...@gmail.com> wrote: >> >> correct, moving to Java9 might be restricting 1.5 to run on higher >> versions

Re: Compiler targets and Java 9

> On Jun 5, 2017, at 1:00 PM, Amey Jadiye wrote: > > correct, moving to Java9 might be restricting 1.5 to run on higher > versions, that said they may not run on java 9 so all this discussion came > in picture, I wish we can have java 9 target well at the same time we >

Re: Compiler targets and Java 9

> On Jun 5, 2017, at 1:35 PM, sebb <seb...@gmail.com> wrote: > > On 5 June 2017 at 21:06, Ralph Goers <ralph.go...@dslextreme.com > <mailto:ralph.go...@dslextreme.com>> wrote: >> OK. Who cares if their last release was Java 1.5? They will never relea

Re: Compiler targets and Java 9

>> so yeah, why are we discussing support for Java 1.5 when not even the >> vendors who ship it support it ? just move our modules for >=1.6. > > This thread is *not* about support for 1.5. > > It's about supporting Java 9, and what to do about components whose > last r

Re: Compiler targets and Java 9

This whole discussion has me really confused. According to https://en.wikipedia.org/wiki/Java_version_history the free version of Java 5 reached end-of-life in 2009 and Oracle's supported version reached end-of-life in 2015.

Re: [all] Java 9 module names

In the case of Commons Logging, Log4j 2 works that way - Commons Logging uses log4j-jcl as its implementation. But SLF4J replaces Commons Logging with slf4j-over-jcl, so you must make sure the commons-logging jar is not present. What Stephen is saying is that in that case commons-logging and

Re: [all] Java 9 module names

> platform. > Stephen > > >> On 23 April 2017 at 08:57, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> How does the module system support Maven’s runtime scope? >> >> Ralph >> >>> On Apr 21, 2017, at 10:48 PM, Stephen Colebourne <scolebou.

Re: [all] Java 9 module names

e! > > This is why I started this thread. By saying _now_what the module name > will be, you greatly reduce the chance of people guessing wrongly. > Getting everyone to usesuper-package reverse DNS naming helps too. > > Stephen > > > On 22 April 2017 at 02:11, Ralph Goer

Re: [all] Java 9 module names

Gary, if you are transitioning to use Java 9 modules I think it is appropriate that it be expected that only the latest versions will support them. Upgrading to Java 9 is not going to be as simple as just replacing the java runtime and running. They have removed lots of deprecated classes. See

Re: [all] Java 9 module names

requires directives. Ralph > On Apr 21, 2017, at 6:04 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > Thanks for taking a look Stephen. I appreciate the guidance. I will be sure > to submit a PR when I get something going with Log4j 2. > > Ralph > >> On

Re: [all] Java 9 module names

e point about the need to export all packages > individually, allowing the modules above. > > Stephen > > On 21 April 2017 at 21:34, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> I am having a hard time figuring out how Log4j is going to be able to >&g

Re: [all] Java 9 module names

I think I finally found it at http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html <http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html>. Ralph > On Apr 21, 2017, at 1:58 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > Ok - it seems I missed t

Re: [all] Java 9 module names

Ok - it seems I missed that every package has to be individually specified. Where is the link to the spec for the module-info file. All I seem to be able to find with google are examples and descriptions. Ralph > On Apr 21, 2017, at 1:40 PM, Ralph Goers <ralph.go...@dslextreme.com&

Re: [all] Java 9 module names

or code > signing so nobody should really use that anyway) > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ____ > From: Ralph Goers <ralph.go...@dslextreme.com> > Sent: Friday, April 21, 2017 10:34:36 PM > To: Commons Developer

Re: [all] Java 9 module names

I am having a hard time figuring out how Log4j is going to be able to support this. The API itself is in org.apache.logging.log4j and some packages under that. All the main implementation is under org.apache.logging.log4j.core. These obviously overlap. Most of our other jars have packages

Re: [ALL] The Commons Math issue

Gilles, What is your vision on where things should end up? Can you identify what new commons sub-projects we will have? If it is just 3 or 4 I have no problem with that. But if we are going to have 10 sub-projects then I really feel like it should be done as: A: Commons Math with Commons

  1   2   3   4   5   6   7   >