Maybe I'm still missing a detail, but this is what I had in mind: Maven already fires events. 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 > > > > > > > > > > > > > > >
