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 <eolive...@gmail.com> 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 > > > > > > > > > > > > > > > > > > > > >
