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
There are a few things I want to address: - Consider returning Optional when methods might return null. - Specify how to handle Collections and Maps, I think we should assume these are never null - 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. thanks, Robert On 4-5-2020 17:00:39, Romain Manni-Bucau <rmannibu...@gmail.com> 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 >
