Assuming maven core/boot is components, a component registry can instrument plugins and subclassloaders with classfiletransformers so maybe ok to keep it in the IoC.
Le sam. 14 mars 2020 à 15:14, Enrico Olivelli <[email protected]> a écrit : > 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] > >
