| Re: [cross-project-issues-dev] Can SLF4J be made the official logging API for Eclipse projects? |
so this means for new versions we still need CQs?
e.g. the current slf4j 1.7.30
Almost. So we can use any libary in any version if the license is in the approvedlistThe library and version needs to have been vetted either by the Eclipse IP Team (i.e., a CQ exists for that library and version) or in the Clearly Defined dataset with a high confidence score (we're thinking 80% at this point). I'm going to assume that most of you don't know what Clearly Defined is (I talk a bit about it here <https://waynebeaton.wordpress.com/2019/10/09/revising-the-eclipse-ip-policy-third-party-content/> ). We've had a "service release" exception for a while now; a service release of a third party library based on a major or minor version that we've already approved may be used without creating a CQ. HTH, Wayne On Fri, Jan 24, 2020 at 11:30 AM Christian Dietrich < christian.dietrich@xxxxxxxxx> wrote:Hello Wayne, thanks for that explanation. So we can use any libary in any version if the license is in the approved list and there is no tracking of which libary in which version is used by which projects? ~Christian Am 24.01.20 um 17:24 schrieb Wayne Beaton: I'm working on some updates to the handbook and we're rolling out some (relatively minor) updates to the "Create a CQ" functionality on the PMI. My apologies to all that this is taking longer than I'd hoped. The short version is that you don't need any tools to not create a CQ. In this particular case, we know that the libraries in question have been approved by the IP due diligence process, so just don't create any new CQs. The challenging bit is how we make it easier for committers to know that they don't need to create a CQ; I'm working on a solution to that problem that I've committed to rolling out this quarter (at least part of which will be contributed to Eclipse Dash, so you all can help maintain it). I need you to be patient for a little while longer for this. The slightly longer version is that I've spent a lot of effort to get our existing IP data into a state where we can do more in an automated manner. Over the years we've collected a lot of data, but--as you likely already know--it's not been collected in a form that makes it consistently queryable. I've got that (mostly) sorted out. We're also starting to leverage license data from Clearly Defined, a project which crowd sources license data from open source projects. My expectation is that we will still need to create CQs for third party content, we'll just have to create a lot fewer of them. Those that we do create will follow the same process that we do today. Again, I owe a longer explanation. Regarding IP Logs, I've been experimenting using build tools to fill in the gaps. This works pretty well for Maven-, Gradle- and NPM-based builds, where you can build an accurate dependency list right out of the tool (e.g., "mvn dependency:list"). FWIW, the tools that I referred to have evolved from scripts that I've been using for a few months to map the results from that dependency list to license and CQ information. I'll start attaching the output from the scripts to IP Log CQs as a stop gap. HTH, Wayne On Fri, Jan 24, 2020 at 11:02 AM Christian Dietrich <christian.dietrich@xxxxxxxxx> wrote: but where is then new tooling for that ? the portal still creates cqs Am 24.01.20 um 16:58 schrieb Wayne Beaton: - 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<https://waynebeaton.wordpress.com/2019/11/13/reviewing-third-party-content/> <https://waynebeaton.wordpress.com/2019/11/13/reviewing-third-party-content/> <https://waynebeaton.wordpress.com/2019/11/13/reviewing-third-party-content/> <https://waynebeaton.wordpress.com/2019/11/13/reviewing-third-party-content/> . 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). 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> <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 listcross-project-issues-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing listcross-project-issues-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing listcross-project-issues-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing listcross-project-issues-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing listcross-project-issues-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing listcross-project-issues-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://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