Il Sab 14 Mar 2020, 19:27 Romain Manni-Bucau <[email protected]> ha scritto:
> Hmm, not sure it is a good example, plugins do play IoC game already and is > the cleanest way to move forward otherwise you will leak the counter or > need to play with thread locals which is worse for plugins using this > pattern (will forbid plugins to use threads). > > That said you can still replace all this code by anything you want, even an > IoC lookup and call using a classfiletransformer in ClassRealm plugin > classloader. It is just a way to rewrite original code to something else. > I am not used to IoC. I have to spend more time in playing with it. If you have some spare cycles to help me maybe I could start quicker. Maybe we can switch to slack for these stuff. If we give the flexibility of a Logger and we are able to respect Maven IoC container I feel we will do the best so I am totally +1 on it Enrico > Le sam. 14 mars 2020 à 17:59, Enrico Olivelli <[email protected]> a > écrit : > > > Il giorno sab 14 mar 2020 alle ore 17:53 Romain Manni-Bucau > > <[email protected]> ha scritto: > > > > > > 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. > > > > Romain, > > can please you elaborate more ? > > > > I am thinking this this case: > > > > class MyCoolCache { > > private static final Counter counter = > > MetricsSystem.getCounter("cacheHits"); > > public T get(K key) { > > .... counter.increment(); > > } > > } > > > > I am a developer of a plugin and I want to set some metric to see the > > runtime behaviour of my component, I don't want my class to play the > > IoC game > > > > You can see it like a "Logger". Loggers are not subject to IoC because > > usually you may want a Logger absolutely everywhere and without > > changing/refactoring your code. > > If I want to add a "temporary" metric I don't want to need to change > > constructors, add getters/setters.... > > > > > > Enrico > > > > > > > > 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] > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
