I sound like to draft a prototype. Any suggestion about which repository should contain this new Metrics API?
Enrico Il Mar 28 Gen 2020, 13:54 Romain Manni-Bucau <[email protected]> ha scritto: > technically we can shade microprofile, metrics/dropwizard or even sirona > but maven requires quite a different model. A typical example is the expiry > or weighted model will not fit the reporting maven needs (very long running > instances vs "batch" like executions) and the weighted impl can be an issue > but is spec-ed by MP (so the shaded impl would also have this unexpected > impl) > > What about by just adding counters, enabling to inject them in mojos - > maybe with a qualifier? - and then see if we need to move to something more > widely used or not (but my past experiences kind of tend to show it is not > needed). > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > Le mar. 28 janv. 2020 à 13:42, Enrico Olivelli <[email protected]> a > écrit : > > > Il Mar 28 Gen 2020, 13:30 Lennart Jörelid <[email protected]> ha > > scritto: > > > > > Would it be possible to use an existing standard for the specification > of > > > such a metrics API? > > > > > > > In my opinion we should have our own model, Maven will impose this new > API > > to plugins and we cannot depend on third party tools as Romain also said > > > > Okay for annotations > > > > Enrico > > > > Something like a shaded version of Microprofile Metrics, where the API > can > > > consist entirely of Annotations. > > > (There are programmatic approaches as well, but I suppose we are > > interested > > > in limiting the footprint of metrics within the Maven codebase as much > as > > > possible). > > > > > > ... implying, of course, that we would need to make a Maven-specific > > > implementation as discussed above. > > > > > > On Tue, Jan 28, 2020 at 10:17 AM Enrico Olivelli <[email protected]> > > > wrote: > > > > > > > Il giorno mar 28 gen 2020 alle ore 09:15 Romain Manni-Bucau < > > > > [email protected]> ha scritto: > > > > > > > > > +1 generally since all extensions doing that report wrong data > > > > > -1 to use a mainstream impl if not shaded - it would just bring us > > new > > > > > conflicts i think. > > > > > > > > > > > > > Totally agree. > > > > In my view any "impl" will be plugged with an "extension". > > > > We will provide only a default no-op implementation > > > > > > > > Enrico > > > > > > > > > > > > > > > > > Side note being: we can start we just counters so no lib is fine > > imho. > > > > > > > > > > Le mar. 28 janv. 2020 à 08:56, Enrico Olivelli < > [email protected]> > > a > > > > > écrit : > > > > > > > > > > > Hi, > > > > > > I would like to work on introducing an explicit support in Maven > > Core > > > > for > > > > > > recording "metrics". > > > > > > As far as I know (and I have still limited knowledge about the > > > > internals) > > > > > > you can write an "extension" and you can intercept main lifecycle > > > > events, > > > > > > and using these hooks you can try to record metrics. > > > > > > But my proposal is from another point of view and I want to go > > > deeper. > > > > > > > > > > > > We are adding caches, making refactors....all good things, but we > > > > should > > > > > > have a way to track how Maven is behaving in a measurable manner. > > > > > > > > > > > > Usually in order to capture realtime metrics you are using some > > > Metrics > > > > > > framework, like Prometheus, Dropwizards....and you attach your > > > process > > > > > to a > > > > > > metrics database and capture all of the values. > > > > > > Then you can process all of the data, realtime and/or offline, > you > > > can > > > > > > create dashboards, you can also fine tune your configuration or > > > change > > > > > your > > > > > > code. > > > > > > > > > > > > These frameworks deal with time series created by capturing > > > Counters, > > > > > > Summaries, Gauges. > > > > > > > > > > > > I would like to introduce an API to be used by Maven Core and by > > > Plugin > > > > > to > > > > > > expose internal metrics, like: > > > > > > - internal caches size > > > > > > - memory usage > > > > > > - disk reads/writes > > > > > > - network traffic > > > > > > - any kind of specific metric for plugins (like "number of tests > > > > > executed", > > > > > > "number of files sent to javac...") > > > > > > - .... all of the usual stuff you track in order to understand > > wha's > > > > > going > > > > > > on > > > > > > > > > > > > I am saying a Maven Metrics API because we must not stick to a > > single > > > > > > "provider" (say "DropWizard"), it will be a bad choice in the > long > > > > term. > > > > > > > > > > > > The API will expose to Maven Core and to plugins a way to get > > access > > > to > > > > > > Metrics and report useful values. > > > > > > > > > > > > @InjectMe > > > > > > MetricsProvider metrics; > > > > > > > > > > > > metrics.getCounter("javacFiles").add(....) > > > > > > metrics.getSummary("downloadTime").add(....) > > > > > > > > > > > > I don't want to go down into details as this is only a > preliminary > > > > email > > > > > > but in my view we could let the user attach an "implementation" > > just > > > by > > > > > > dropping in an "extension", in order not to ship with Maven Core > a > > > lot > > > > of > > > > > > third party dependencies. > > > > > > > > > > > > I have some "production" experience with this topic (actually I > did > > > > > > something like that in my company and in ZooKeeper project) so I > > will > > > > be > > > > > > happy to prepare and share a design document. > > > > > > > > > > > > With this work we will open up the way to knowing how a Maven > build > > > > > works, > > > > > > with the 'time dimension', on the local machine of the developer > > but > > > > even > > > > > > on CI servers. > > > > > > > > > > > > Any comment is very welcome > > > > > > > > > > > > Regards > > > > > > Enrico > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > -- > > > +==============================+ > > > | Bästa hälsningar, > > > | [sw. "Best regards"] > > > | > > > | Lennart Jörelid > > > | EAI Architect & Integrator > > > | > > > | jGuru Europe AB > > > | Mölnlycke - Kista > > > | > > > | Email: [email protected] > > > | URL: www.jguru.se > > > | Phone > > > | (skype): jgurueurope > > > | (intl): +46 708 507 603 > > > | (domestic): 0708 - 507 603 > > > +==============================+ > > > > > >
