[DISCUSS] Improve efficiency of build cache with plugin and source type aware processing
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 and not contributing any dependencies in reactor). More details are in the ticket - https://issues.apache.org/jira/plugins/servlet/mobile#issue/MBUILDCACHE-27. Your feedback is greatly appreciated. Thank you. Alex - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven Build Cache Extension 1.0.0
+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=12351243 > > JIRA issues left: > > > https://issues.apache.org/jira/browse/MBUILDCACHE?jql=project%20%3D%20MBUILDCACHE%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC > > Staging repo: > https://repository.apache.org/content/repositories/maven-1817 > > > https://repository.apache.org/content/repositories/maven-1817/org/apache/maven/extensions/maven-build-cache-extension/1.0.0/maven-build-cache-extension-1.0.0-source-release.zip > > Source release checksum: > maven-build-cache-extension-1.0.0-source-release.zip - SHA-512: > > 2379d68b15a47d47bcb836e2f0e543adce49c430b8bfe63de98c603e9a75c48450e56e9aab439a7437bf22b83e79bbf51d3ab7da97b53257f8e86cdc887105c7 > > Staging site: > > > https://maven.apache.org/extensions-archives/maven-build-cache-extension-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > -- > > Guillaume Nodet >
Re: Testing plugins in JUnit 5
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 subject says: Is there a documented way to write tests for > plugins under JUnit 5? The only thing I've been able to find is the > takari testing project: > > https://github.com/takari/takari-plugin-testing-project > > There seems to be some preliminary support there, but it's not in any > of the available releases and nobody seems to have touched the project > for almost a year. > > -- > Mark Raynsford | https://www.io7m.com > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven Build Cache Extension 1.0.0
+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/MBUILDCACHE-34 Regards, Hervé Le jeudi 27 octobre 2022, 13:11:31 CET Guillaume Nodet a écrit : > 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 > rsion=12351243 > > JIRA issues left: > > https://issues.apache.org/jira/browse/MBUILDCACHE?jql=project%20%3D%20MBUILD > CACHE%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2 > C%20updated%20DESC > > Staging repo: > https://repository.apache.org/content/repositories/maven-1817 > > https://repository.apache.org/content/repositories/maven-1817/org/apache/mav > en/extensions/maven-build-cache-extension/1.0.0/maven-build-cache-extension- > 1.0.0-source-release.zip > > Source release checksum: > maven-build-cache-extension-1.0.0-source-release.zip - SHA-512: > 2379d68b15a47d47bcb836e2f0e543adce49c430b8bfe63de98c603e9a75c48450e56e9aab43 > 9a7437bf22b83e79bbf51d3ab7da97b53257f8e86cdc887105c7 > > Staging site: > > https://maven.apache.org/extensions-archives/maven-build-cache-extension-LAT > EST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Aw: Improve connection between Maven and IDE?
>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 Maven 4, 4.1 (or later)? If yes, please let us know when discussions happen where interested IDE maintainer can provide feedback/input. Regards, Hannes Gesendet: Sonntag, 25. September 2022 um 19:26 Uhr Von: "Hannes Wellmann" An: dev@maven.apache.org Betreff: Improve connection between Maven and IDE? Hello Maven developers, for the Maven integration for Eclipse IDE (called M2Eclipse or M2E) there is a mechanism of so called "connector plugins" or "connectors" which connect Maven plug-ins with the IDE. Their job is to tell the IDE what to do during a workspace-build within the IDE, if the connected plug-in is encountered when building a Maven-project. They decide if the maven-plugin is executed or not and can perform necessary extra configuration. But one important and often the only actual relevant task of such connector is to tell the Eclipse IDE which files have been updated so that it can refresh the internal data about those files and react to the changes if necessary. Therefore the need for a connector often vanishes if the plug-in would notify the IDE about the files it just changed. In order to deliver such notifications to the IDE the 'sisu-build-api' [1] project incubated the concept of a 'BuildContext' [2] that can be used by mojos to perform file-system operations like create new files or refresh the state of a file. Additionally it provides information about deltas since the last (incremental) build and therefore acts as cache. Maven Plugins then use the BuildContext to perform their file-system operations instead of using corresponding Java APIs directly. The default implementation, which is used in a standalone Maven build is rather straight forward and just performs the corresponding operation respectively always answers that a file has changed. [3] But within the IDE an enhanced BuildContext can be injected into the Maven session that notifies the IDE when a file-system operation happened and properly maintains the cache/delta data. Plug-ins that would for example benefit from that are the maven-clean-plugin and the maven-dependency-plugin. They only delete or copy/unpack files and the IDE only has to be notified about that. While the 'sisu-build-api'-project never left the prototype status and the repository has been archived in the meantime, the general idea still seems to be suitable. Therefore we, the Maven2Eclipse team, want to ask if there is a general interest from the Maven dev team to improve the connection between maven and IDEs by using such an approach? You can find the discussion at M2E with some more details under. [4] A corresponding API with default implementation for standalone Maven builds could be maintained as part of Maven so that not only Eclipse can use it. Of course the API could be reworked to better fit the most common usage patterns. Suggestions for other approaches to improve the connection without the need to maintain 'connectors' would of course be welcome as well. Regards Hannes [1] - https://github.com/sonatype/sisu-build-api [2] - https://github.com/sonatype/sisu-build-api/blob/master/src/main/java/org/sonatype/plexus/build/incremental/BuildContext.java[https://github.com/sonatype/sisu-build-api/blob/master/src/main/java/org/sonatype/plexus/build/incremental/BuildContext.java] [3] - https://github.com/sonatype/sisu-build-api/blob/master/src/main/java/org/sonatype/plexus/build/incremental/DefaultBuildContext.java[https://github.com/sonatype/sisu-build-api/blob/master/src/main/java/org/sonatype/plexus/build/incremental/DefaultBuildContext.java] [4] - https://github.com/eclipse-m2e/m2e-core/discussions/876[https://github.com/eclipse-m2e/m2e-core/discussions/876] - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logging in Maven Plugins - Bridging
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 probably NDC/MDC but in current
ascyn/reactive world it sounds like a good thing - it is too often broken
IMHO. Rest is biaised opinion - for both sides - since API are strictly
equivalent *technically* as of today.
Back to the original topic: as discussed multiple times in other thread, as
soon as maven leaks any 3rd party library we get troubles so even for
logging the rule of thumb should probably be to not leak anything else than
a controlled or JRE api which means for logging org.apache.maven.api.log.*
or JUL.
Once again for internals we can get debates but seems there had been a
local consensus about slf4j years ago so let's keep it but try to drop the
export from core/extensions.xml for maven 4 to stick to previous rule since
we can't do it for v3.
Romain Manni-Bucau
@rmannibucau | Blog
| Github |
LinkedIn | Book
Le dim. 6 nov. 2022 à 09:12, Mark Derricutt a écrit :
> 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 LOG.atInfo()...
> that when not at the appropriate level, they can return a NoOpLogger which
> just does nothing, which avoids any over head formatting when logging (
> unless you do nasty string concatenation I guess ).
>
> Still flawed slightly IMHO tho.
>
> --
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> Porcupine Tree
>
Re: Logging in Maven Plugins - Bridging
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 LOG.atInfo()... that when not at the appropriate level, they can return a NoOpLogger which just does nothing, which avoids any over head formatting when logging ( unless you do nasty string concatenation I guess ). Still flawed slightly IMHO tho. -- "Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree
Re: Logging in Maven Plugins - Bridging
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 limited filtering capabilities and finally, the terrible way it binds the logging implementation to the API. Although Log4j provides the documented way of bridging from JUL to it most people can’t use it because JUL typically initializes and binds to the JDK implementation before log4j can set the system property and they do not want to rely on having to manually set it. The alternative approach of having a handler that routes to another logging framework is a hack and almost inevitably results in some performance loss. Ralph > On Nov 6, 2022, at 12:36 AM, Mark Derricutt wrote: > > 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 > now has pluggable backends ) but doesn’t seem to have any any updates for > awhile: https://google.github.io/flogger/ > > The benefits page ( https://google.github.io/flogger/benefits ) is quite > compelling, tho I find the API a bit cumbersome. > > Mark > > -- > "Great artists are extremely selfish and arrogant things" — Steven Wilson, > Porcupine Tree - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logging in Maven Plugins - Bridging
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 now has pluggable backends ) but doesn’t seem to have any any updates for awhile: https://google.github.io/flogger/ The benefits page ( https://google.github.io/flogger/benefits ) is quite compelling, tho I find the API a bit cumbersome. Mark -- "Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree
Re: Logging in Maven Plugins - Bridging
> 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 years ago. Log4j, > slf4j, plexus-logging, etc. are all efforts to solve a problem we > don't have any more. They are not needed and they introduce dependency > problems and security issues. Wow. I sure hope you mean this in the context of Maven only. JUL is the absolute worst API and implementation the JDK developers could have come up with. I have it on good authority that Ceki (the original author of Log4j 1 and SLF4J) was consulted before JUL was added to JDK 1.4 but they pretty much ignored everything he told them. They have never enhanced it - other than to implement platform logging to avoid problems using JUL internally. > > For one example, Google has used java.util.logging exclusively in all > its internal Java code since at least 2008 and never needed anything > more. This is a matter of policy inside Google, and as a result of > this log4shell was close to a non-event for one of the largest Java > shops on the planet. It wasn't a complete non-event only because of > third party libraries that depended on log4j and open source projects > that weren't quite as strict about following Google rules. 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. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
