I am starting this work. I have pushed a copy of current maven core master to maven-studies.
Then I have added my "maven-metrics" module. This module contains only the API to be implemented by Metrics Providers and a No-op implementation. You can find the draft API here. https://github.com/apache/maven-studies/tree/maven-metrics/maven-metrics It is not final it is just the first import to git, I have to see some real world Maven cases before designing the final one. Now I am going to instrument some Maven core subsystem and implement a simple Metrics Provider in order to see some data. My very first problem is to boot the MetricsProvider and to give access to it from any Java class and module. Maven uses Dependency Injection and this is cool, but with this approach you will not be able to instrument non-component classes, like internal Caches or Network facilities. I am leaning towards using some kind of "global static reference" (like a pure Java Singleton) to hold a reference to the Metrics subsystem. By default the Metrics Provider will be the No-op implementation, so third party tools won't see NULLs. in MavenCli I will "boot" (and manage the whole lifecycle) the Metrics Provider and set this "global reference". The Metrics Provider API will be in the main Maven classloader and the Metrics Provider will have to be loaded in the same context/classloader. Plugins and internal classes will use the API and not directly the provider implementation. I don't know how classloading works very well in the case of Maven/Plexus. Any suggestion is very appreciated. I have very very limited time for this work, but I see value and I will move forward when I have cycles Cheers Enrico Il giorno ven 31 gen 2020 alle ore 00:27 <[email protected]> ha scritto: > > maven-studies looks like the right location: > https://github.com/apache/maven-studies > > Regards, > > Hervé > > ----- Mail original ----- > De: "Enrico Olivelli" <[email protected]> > À: "Maven Developers List" <[email protected]> > Envoyé: Jeudi 30 Janvier 2020 04:31:14 > Objet: Re: Maven Runtime Metrics > > 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 > > > > +==============================+ > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
