Hi Maven Team
Want to bring to your attention new feature I’m see as beneficial for the
cache. The reason to bring into attention is core level questions - ability to
not rerun tests for unchanged project which in turn needs ability to mark
source code and plugins as private (ie not consuming an
+1
On Thu, Oct 27, 2022, 13:11 Guillaume Nodet wrote:
> Hi,
>
> I've staged a release of Maven Build Cache Extension 1.0.0.
> This is the first release of this component.
>
> Solved issues:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12324820&version=12351243
>
> JIRA
Not sure why it would be any different from testing anything else with external
dependencies. You can see some examples at
https://github.com/oracle/weblogic-monitoring-exporter/tree/main/build-helper-mojo/src
> On Nov 5, 2022, at 7:07 AM, Mark Raynsford
> wrote:
>
> Hello!
>
> As the subj
+1
release confirmed reproducible: reference was done with JDK 11 on *nix
I had to rebuild without tests, as Slawek reported: "Could not find artifact
org.apache.maven.extensions:maven-build-cache-extension:jar:1.0.0-SNAPSHOT",
and created jira issue:
https://issues.apache.org/jira/browse/MBUIL
>From all the responses, where I had the impression that they went into
>different directions, it is not clear to me what the general conclusion of the
>discussion is?
Do you eventually plan to consider some of the concepts of the
'BuildContext/IncrementalBuild'-API for the new Maven-API in Mave
Ok, think the thread starts to fork (;)).
On the "is JUL a bad API" point: to day it is close to concurrent and
likely equivalent on a pure technical point of view - keep in mind we now
have supplier which makes {} legacy and worse than concatenation most of
the times. Only thing it misses is prob
On 6/11/2022 at 8:48:28 PM, Ralph Goers wrote:
> But the biggest problems with JUL include requiring everything being
> wrapped with isEnabled type methods to avoid logging overhead
I believe that was one of things addressed in the Flogger benefits - with
their API using LOG.atDebug()... or LO
Yes, I am aware of Flogger. Both the Log4j and SLF4J APIs now also have
fluent methods for those that prefer them. But the biggest problems with JUL
include requiring everything being wrapped with isEnabled type methods to
avoid logging overhead, an extremely limited set of Handlers, extremely
On 6/11/2022 at 8:31:45 PM, Ralph Goers wrote:
> I can absolutely guarantee you that if Google is actually using JUL that
> they
> have written plenty of their own code on top of it since JUL is woefully
> incomplete.
Google came up with Flogger - their fluent logging API that wraps JUL ( and
> On Nov 5, 2022, at 6:08 AM, Elliotte Rusty Harold wrote:
>
> After log4shell last year, I no longer have any patience for third
> party logging libraries, full stop.
>
> IMO logging should be done through java.util.logging, nothing else.
> This is fully functional since Java 1.4 twenty year
10 matches
Mail list logo
