Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Can SLF4J be made the official logging API for Eclipse projects?


On Fri, Jan 24, 2020 at 5:58 PM Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> wrote:
- the bureaucracy

I assume that you mean IP due diligence. There should be no Eclipse Foundation bureaucracy required. All of the libraries in question have already been approved, so the project team can just start using them.

Following the Eclipse Foundation's Board of Directors approval of our new IP Policy in October, Piggyback CQs are no longer required. I owe the community a much longer discussion about all of the changes. There is some discussion on by blog.

You will still have to submit your IP Log for review, but only the next time that you actually have to do a release review. Note that changes made to the EDP in December 2018 make it so that you can do releases for an entire year following a successful release review (i.e., we no longer require a review for every single release).

Wayne, how does one maintain the IP log if not doing PB CQs ? It's an honest question as not filing PB CQs will save me so much time.
 

I hope that this knocks at least one thing off of the list (I understand that the other things on the list are harder

HTH,

Wayne

On Fri, Jan 24, 2020 at 3:07 AM Christian Dietrich <christian.dietrich@xxxxxxxxx> wrote:

Hi,

we (Xtext) currently have no capacity to do

- the bureaucracy
- analyze impacts on logging customization points in Xtext
- analyze who else uses what logging and how that change would affect them and indirectly us

Regards
Christian

Am 23.01.20 um 15:05 schrieb Ed Willink:

Hi

If there is a conflict hazard then it already exists. Examining one of my workspaces...

Good (SLF4J) - jgit, m2e
Bad (LOG4J) - mwe, ocl, qvtd, xtend, xtext

This is complete news to me. I continue to use log4j since it avoids changing code styles that have been unchanged for many many years. Other projects probably just copy prevailing practice.

I presume changing is rather easy, and of no consequence to the exported API, since the use of log4j is by import package.

However without a commitment to change by Xtext, I would be reluctant to change any Xtext-based project.

    Regards

        Ed Willink

On 23/01/2020 13:09, Hickman, Steve (AdvTech) wrote:

Log4j 1.x reached end of life in 2015. The documentation for it now appears to have gone offline. There are some Eclipse projects (call them L1 projects) that currently use Log4j 1.x directly rather than SLF4J. That means that any projects that depend on L1 projects cannot use Log4J 2.x without risking dependency collisions from attempting to load multiple versions of Log4J.

 

SLF4J was created precisely to eliminate dependencies on specific logging implementations.

 

It is important that libraries like those that plug into Eclipse not unintentionally force a specific logging implementation on their users. Those library developers have no way of knowing – and probably no way of satisfying – all the requirements of their various sets of users.

 

Given that, it seems that Eclipse should make SLF4J the ‘official’ logging API for all Eclipse libraries.

 

 

 

 

 

Steve Hickman

Software Architect

Honeywell | Aerospace

Office: 480-236-8367

 

steve.hickman@xxxxxxxxxxxxx

https://in.honeywell.com/sites/aero/ENG/advance-tech/crew-intf/Pages/crewhome.aspx

 


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev


--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev


--
Alexander Kurtakov
Red Hat Eclipse Team

Back to the top