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 > > >
