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. Enrico Il Sab 9 Mag 2020, 22:51 Robert Scholte <rfscho...@apache.org> ha scritto: > > On 9-5-2020 17:58:47, Enrico Olivelli <eolive...@gmail.com> 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 > > > > > >
