Hi Enrico, These could all be solved by firing events.
And there's another benefit: since there won't be an API, we don't need to maintain it,or be afraid of mistakes. To me this is the wrong approach to embed metrics. thanks, Robert On 10-5-2020 16:58:59, Enrico Olivelli <eolive...@gmail.com> wrote: Il giorno dom 10 mag 2020 alle ore 13:42 Robert Scholte <> rfscho...@apache.org> ha scritto: > sometimes code says more than a thousand words: can you share the changes > in Maven Core you had in mind? > Maven Metrics Extensions API: https://github.com/apache/maven-metric/blob/master/maven-metrics-api/src/main/java/org/apache/maven/metrics/MetricsSystem.java An Extension is expected to implement that Named component Example implementation: https://github.com/eolivelli/simplemavenmetrics/blob/master/src/main/java/org/apache/maven/metrics/SimpleMetricsSystem.java This is mostly what Romain said, if you add this extension to your project (and use Maven 3.7. from my branch on maven studies) mvn -Dmetrics.dumpAtEnd=true verify You will see the "final" values of every metric, it does not track any time series This is a sample instrumentation of Maven Core https://github.com/apache/maven/pull/344/files I am not sure that those are the most interesting points but it is enough to see interesting data on some project: - time to resolve the pom - time to resolve dependencies of plugins - time to "install" an artifact locally - time to perform the execution of each mojo I wanted to instrument more components but I have to tweak Wagon and other lower level external components Enrico On 10-5-2020 12:07:33, Enrico Olivelli wrote: > Il giorno dom 10 mag 2020 alle ore 11:53 Robert Scholte > rfscho...@apache.org> ha scritto: > > > Maybe I'm still missing a detail, but this is what I had in mind: > > Maven already fires events. > > > > Metrics are for a distinct use case. > Metrics are like Logs, the developer instruments its own code to have > important information available during the execution. > For instance you want to see the evolution of a cache, see how much it is > useful, > or you can instrument the HTTP client inside wagon to see how well the > network is performing. > Usually they are for fine grained instrumentation of hot points in code. > For instance you do not want to fire an event every time an entry of a > cache is evicted and expect some code to intercept that event. > > Metrics are not extension points like current "events" mechanism. > The MetricsProvider will be an extension, in a way that it is separate from > Maven Core, it only provides the way to gather the information, > usually in form of time series and make it available to the tools (like > Dashboards, reports...). > > Metrics will be useful for: > - Maven developers (core and plugins): see how well code behaves and where > it is better to put enhancements/optimizations > - Maven users: some of the metrics could be useful for users, especially > about the system in which Maven is executing (network, disk speed, usage of > memory during peaks....) > - Automatics tools, like Jenkins, to display information about the > execution of long running builds > > > Enrico > > > > > > > The extension listens to these events and can do its metrics. > > I see no need for a hard coupling between these two. > > > > Robert > > > > On 10-5-2020 10:28:42, Enrico Olivelli wrote: > > Il Dom 10 Mag 2020, 09:21 Romain Manni-Bucau ha > > scritto: > > > > > Le dim. 10 mai 2020 à 07:43, Enrico Olivelli a > > > écrit : > > > > > > > Robert > > > > Maybe I was misunderstood. > > > > We need a new repo only for the Metrics API. > > > > > > > > Maven core (3.7?) provides the noop implementation. > > > > > > > > Implementations of MetricsProvider will be extensions. I feel it is > > > better > > > > that we don't deal with implementations as a first step. > > > > I will leave a couple of implementations in my personal repo. > > > > > > > > > > Think we need at least a trivial memory impl with maybe a "log at > > > shutdown" feature otherwise it will not bring anything to end users > > > > > > > > > Yep > > > > I have already implemented it :) > > > > > > Robert, > > I saw the github notification about the new two repositories > > > > Thank you all > > > > > > Enrico > > > > > > > > > > > > > > > > > Enrico > > > > > > > > > > > > Il Sab 9 Mag 2020, 22:51 Robert Scholte ha > > > scritto: > > > > > > > > > > > > > > On 9-5-2020 17:58:47, Enrico Olivelli wrote: > > > > > Robert > > > > > > > > > > Il Sab 9 Mag 2020, 10:54 Robert Scholte ha scritto: > > > > > > > > > > > Although I'm disappointed there's no spec group for this, having > > our > > > > own > > > > > > seems indeed the best choice, but here we will likely face > similar > > > > issues > > > > > > where the API needs adjustments. > > > > > > So lets create the maven-metrics git repository > > > > > > > > > > > > > > > > > > > > > Shall I do it by myself or do I need help from a PMC? > > > > > > > > > > For JIRA I think we can keep using Maven core project > > > > > Robert Scholte: > > > > > No, I'll create a separate project for it too. This extension will > > have > > > > > its own lifecycle, unrelated to the Maven lifecycle (and it won't > be > > > > > bundled) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > There are a few things I want to address: > > > > > > - Consider returning Optional when methods might return null. > > > > > > > > > > > Okay > > > > > > > > > > > - Specify how to handle Collections and Maps, I think we should > > > assume > > > > > > these are never null > > > > > > > > > > > Okay > > > > > > > > > > > - Abstract classes versus default methods. Default methods were > > > > > introduced > > > > > > to extend existing interfaces without breaking the contract. I > > > already > > > > > > expected patterns to appear where default methods would replace > > > > abstract > > > > > > classes. I'm not saying it is a bad thing, but just to have > > consensus > > > > > that > > > > > > we can do this. > > > > > > > > > > > > > > > > I will think more about this > > > > > > > > > > Thanks > > > > > Enrico > > > > > > > > > > > > > > > > thanks, > > > > > > Robert > > > > > > > > > > > > On 4-5-2020 17:00:39, Romain Manni-Bucau wrote: > > > > > > Le lun. 4 mai 2020 à 16:55, Slawomir Jaranowski a > > > > > > écrit : > > > > > > > > > > > > > Hi, > > > > > > > In my humble opinion it is not the best way to implement own > api > > > when > > > > > > > similar api is already ready and maintained. > > > > > > > > > > > > > > There is another project used for metrics: micrometer, as we > can > > > see > > > > it > > > > > > is > > > > > > > a quite popular 2.3K stars, 500 forks on github > > > > > > > https://github.com/micrometer-metrics/micrometer > > > > > > > > > > > > > > Please consider similar situation with logging api used in > maven, > > > we > > > > > have > > > > > > > different logging in plexus component, maven plugin api, maven > > > core, > > > > > ... > > > > > > > and now slf4j is try to replace old > > > > > > > > > > > > > > Why it is so important to you to be independent in this case? > > > > > > > > > > > > > > > > > > > Cause none is stable and it will be user facing (mojo dev) so it > is > > > key > > > > > to > > > > > > create an API we - maven - can assume in time and not depend on > > > > vendors. > > > > > > Microprofile just proved it would have been a bad choice cause > they > > > > broke > > > > > > the API quite drastically (I'm not blaming them, it is the > > > microprofile > > > > > > contract for now but at maven stage it would have been a bad > > choice). > > > > > > This is not a ton of API and impl can rely on anything you want > > while > > > > > fully > > > > > > isolated (proxy on API?) from the mojo/extensions classloader > > > > (otherwise > > > > > it > > > > > > will conflict for sure). > > > > > > > > > > > > > > > > > > > > > > > > > > sob., 2 maj 2020 o 15:20 Enrico Olivelli napisał(a): > > > > > > > > > > > > > > > Robert > > > > > > > > > > > > > > > > Il Sab 2 Mag 2020, 15:11 Robert Scholte ha > > > > > > > scritto: > > > > > > > > > > > > > > > > > If I take a look at the pom of maven-metrics, I see no > > > dependency > > > > > on > > > > > > > > Maven. > > > > > > > > > And looking at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/maven-studies/tree/maven-metrics/maven-metrics/src/main/java/org/apache/maven/metrics > > > > > > > > > [ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/maven-studies/tree/maven-metrics/maven-metrics/src/main/java/org/apache/maven/metrics > > > > > > > > > ] > > > > > > > > > This looks a lot like > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/eclipse/microprofile-metrics/tree/master/api/src/main/java/org/eclipse/microprofile/metrics > > > > > > > > > [ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/eclipse/microprofile-metrics/tree/master/api/src/main/java/org/eclipse/microprofile/metrics > > > > > > > > > ] > > > > > > > > > > > > > > > > > > So do we need to maintain our own Metrics API? > > > > > > > > > > > > > > > > > > > > > > > > > Yes it is really better. > > > > > > > > > > > > > > > > We will be in charge for this API, it will be a new API on > > which > > > we > > > > > > will > > > > > > > > depend in many part of Maven core and in plugins. > > > > > > > > It is better to not depend on third party. > > > > > > > > > > > > > > > > There are other initiatives like microprofile metrics. > > > > > > > > > > > > > > > > The API itself is very small and we could add an > implementation > > > > that > > > > > > uses > > > > > > > > micro profile. But we must be independent. > > > > > > > > > > > > > > > > Enrico > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > thanks, > > > > > > > > > Robert > > > > > > > > > On 2-5-2020 10:26:19, Enrico Olivelli wrote: > > > > > > > > > Hello community, > > > > > > > > > I am now ready to move forward with concrete steps for the > > > > > > > implementation > > > > > > > > > of Maven Runtime Metrics. > > > > > > > > > > > > > > > > > > This is the JIRA > > > > > > > > > https://issues.apache.org/jira/browse/MNG-6899 > > > > > > > > > > > > > > > > > > It links to my proof-of-concept branch on maven studies. > > > > > > > > > https://github.com/apache/maven-studies/tree/maven-metrics > > > > > > > > > > > > > > > > > > In order to move forward I have to create an independent > > > > module/git > > > > > > > > > repository for the Maven Metrics Runtime API. > > > > > > > > > Currently I have it on maven-studies inside Maven Core but > > this > > > > is > > > > > > not > > > > > > > > > good, because I would like to use it in Plugins > independently > > > > from > > > > > > the > > > > > > > > > version of Maven Core. > > > > > > > > > When you run the plugin on an old version of Maven all of > the > > > > data > > > > > > will > > > > > > > > be > > > > > > > > > simply ignored. > > > > > > > > > > > > > > > > > > My plan: > > > > > > > > > - create a git repository > > > > > > > > > - put there the first version of the API (maybe we can put > > > there > > > > a > > > > > > > simple > > > > > > > > > implementation of the API, but I could leave it off for the > > > first > > > > > > > > release) > > > > > > > > > - release it to the public > > > > > > > > > - use it in Maven 3.7 > > > > > > > > > - use it in Wagon and in Resolver and in other > "interesting" > > > > > > > modules/core > > > > > > > > > plugins > > > > > > > > > > > > > > > > > > Best regards > > > > > > > > > Enrico > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Sławomir Jaranowski > > > > > > > > > > > > > > > > > > > > > > > > > > > >
