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