Ed,
Looking at this:
https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.15-I-builds/http___download.eclipse.org_eclipse_updates_4.15-I-builds_I20200124-1800.html
The platform does include that in it's repo:
https://download.eclipse.org/oomph/archive/repor
Hi
Indeed, and java.util.logging and logback.
My attempts to use SLF4J in OCL have foundered. Migrating the plugins
was easy, although RSI-inducing. Test harnesses which represent an
'overall application' must continue to use their log4j proprietary
tweaks, but making this work enters a hotch
On Sat, Jan 25, 2020 at 10:56 AM Ed Willink wrote:
> Hi
>
> I've started to action this for OCL;
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=559532
>
> and hit a silly problem; who redistributes SLF4J?
>
> If it's standard, surely the platform should redistribute so that a copy
> can be found
AFAIK the policy is projects should be adding such bundles to their p2
repos. That is certainly what CDT does.
However, I don't know if that is written down or really just convention.
End users should not be pointing at orbit p2 repos.
HTH
Jonah
On Sat., Jan. 25, 2020, 03:56 Ed Willink, wrot
Hi
I've started to action this for OCL;
https://bugs.eclipse.org/bugs/show_bug.cgi?id=559532
and hit a silly problem; who redistributes SLF4J?
If it's standard, surely the platform should redistribute so that a copy
can be found in e.g. eclipse-SDK-4.14-win32-x86_64.zip ?
There is no SLF4J
Roland told me that for adding new content to Orbit (which is most often
required for new versions of already approved third party libraries)
we should still file CQs until the new process and tools are sorted out.
On Fri, Jan 24, 2020 at 5:25 PM Wayne Beaton <
wayne.bea...@eclipse-foundation.org>
> On Jan 24, 2020, at 17:43, Christian Dietrich
> wrote:
>
> so this means for new versions we still need CQs?
> e.g. the current slf4j 1.7.30
As 1.7.x is approved and has a CQ this falls under the "service release"
exception as mentioned! No CQ required.
-Gunnar
--
Gunnar Wagenknecht
gun
so this means for new versions we still need CQs?
e.g. the current slf4j 1.7.30
Am 24.01.20 um 17:36 schrieb Wayne Beaton:
> Almost.
>
> So we can use any libary in any version if the license is in the approved
>> list
>
> The library and version needs to have been vetted either by the Eclipse IP
Almost.
So we can use any libary in any version if the license is in the approved
> list
The 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
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
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
On Fri, Jan 24, 2020 at 5:58 PM Wayne Beaton <
wayne.bea...@eclipse-foundation.org> 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
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 ap
>
> - 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 o
Hi Christian
After reading some of the SLF4J documentation, it appears that SLF4J is
not a replacement for Log4J rather it is a Facade that hides Log4j or
whatever other conformant logger an application configures.
At the source code level it appears to be just necessary to change
Logger
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 ther
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 year
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
18 matches
Mail list logo
