Le lun. 1 juin 2020 à 10:31, Robert Scholte a écrit :
> My main concerns are:
> - Performance: adding metrics should have (close to) no impact on current
> performance. For short builds metrics might not add enough value, and our
> aim should be fast and short builds. Metrics is a tool to analyze
My main concerns are:
- Performance: adding metrics should have (close to) no impact on current
performance. For short builds metrics might not add enough value, and our aim
should be fast and short builds. Metrics is a tool to analyze in case you seek
improvements of your builds
- Portability:C
Il Lun 1 Giu 2020, 07:08 Romain Manni-Bucau ha
scritto:
> Hi Enrico,
>
> As mentionned I think 5 would be an error, we should provide an in memory
> flavor with a dump at exist (-Dmaven.metrics.dumpOnExit=/tmp/metrics.csv or
> so?) otherwise it will be a noop for user so not sure it is worth havi
Hi Enrico,
As mentionned I think 5 would be an error, we should provide an in memory
flavor with a dump at exist (-Dmaven.metrics.dumpOnExit=/tmp/metrics.csv or
so?) otherwise it will be a noop for user so not sure it is worth having it
at all.
In other words, if you want it as a vendor you put a
Hey guys,
I feel this Metrics Runtime API will be very useful to Maven and Maven
plugins.
But I am not sure we are reaching consensus.
Main points:
1) We will introduce a Metrics Provider API, maintained by Maven project.
2) Metrics are not "extension points", they are not "events",
implementation
Hmm, it shouldn't be:
metricsSystem
.getMetricsContext()
.getSummary( "resolvePluginDependency", "Time to resolve dependencies of a
plugin (ms)" )
.add( MetricsUtils.elapsedMillis( startResolve ) );
but
counter.add(duration).
Resolution of the counter can be either (just in terms of inputs, the
Il giorno dom 10 mag 2020 alle ore 22:10 Robert Scholte <
rfscho...@apache.org> ha scritto:
> This looks more like a bug, so this should be analyzed.
> It sounds to me, that if this information was accurate, there wouldn't be
> a need for the a separate MetricSystem.
>
Sorry, I have added that me
This looks more like a bug, so this should be analyzed.
It sounds to me, that if this information was accurate, there wouldn't be a
need for the a separate MetricSystem.
Robert
On 10-5-2020 20:38:39, Romain Manni-Bucau wrote:
Le dim. 10 mai 2020 à 20:11, Karl Heinz Marbaise a
écrit :
>
> On 1
; > > > > broke
> > > > > > > the API quite drastically (I'm not blaming them, it is the
> > > > microprofile
> > > > > > > contract for now but at maven stage it would have been a bad
> > > choice).
> > > &g
Le dim. 10 mai 2020 à 20:11, Karl Heinz Marbaise a
écrit :
>
> On 10.05.20 19:59, Romain Manni-Bucau wrote:
> > Events vs metrics is an old topic.
> > The choice between both is not only design but also about perf. In terms
> of
> > design it brings the ability to export data without exposing it
On 10.05.20 19:59, Romain Manni-Bucau wrote:
Events vs metrics is an old topic.
The choice between both is not only design but also about perf. In terms of
design it brings the ability to export data without exposing it in code
(events are public). It also avoid to expose a stable api of events
; > > >
> > > > > > > > > Why it is so important to you to be independent in this
> case?
> > > > > > > > >
> > > > > > > >
> > > > > > > > Cause none is stable and i
gt; > > > Microprofile just proved it would have been a bad choice cause
> > they
> > > > > broke
> > > > > > > the API quite drastically (I'm not blaming them, it is the
> > > > microprofile
> > > > > > > contract for now but at m
it
> > > > > > will conflict for sure).
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > sob., 2 maj 2020 o 15:20 Enrico Olivelli napisał(a):
> > > > > > >
> > > > &g
it
> > > > > > will conflict for sure).
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > sob., 2 maj 2020 o 15:20 Enrico Olivelli napisał(a):
> > > > > > >
> > > > >
:
> > > > > > >
> > > > > > > > If I take a look at the pom of maven-metrics, I see no
> > dependency
> > > > on
> > > > > > > Maven.
> > > > > > > > And looking at
> > > > > >
t; > > > > > Robert
> > > > > > >
> > > > > > > Il Sab 2 Mag 2020, 15:11 Robert Scholte ha
> > > > > > scritto:
> > > > > > >
> > > > > > > > If I take a look at the pom of maven-metrics, I see no
> >
t; >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven-studies/tree/maven-metrics/maven-metrics/src/main/java/org/apache/maven/metrics
> > > > > > > [
> > > > > > >
> > And looking at
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven-studies/tree/maven-metrics/maven-metrics/src/main/java/org/apache/maven/metrics
> > > > > >
gt; >
> > > >
> > >
> >
> https://github.com/apache/maven-studies/tree/maven-metrics/maven-metrics/src/main/java/org/apache/maven/metrics
> > > > > > ]
> > > > > > This looks a lot like
> > > > > >
&
s/tree/master/api/src/main/java/org/eclipse/microprofile/metrics
> > > > > ]
> > > > >
> > > > > So do we need to maintain our own Metrics API?
> > > > >
> > > >
> > > > Yes it is really better.
> > > >
> >
gt; > > > So do we need to maintain our own Metrics API?
> > > >
> > >
> > > Yes it is really better.
> > >
> > > We will be in charge for this API, it will be a new API on which we
> will
> > > depend in many part of Maven c
API on which we
> will
> > > depend in many part of Maven core and in plugins.
> > > It is better to not depend on third party.
> > >
> > > There are other initiatives like microprofile metrics.
> > >
> > > The API itself is very small and we cou
>
> > > > So do we need to maintain our own Metrics API?
> > > >
> > >
> > > Yes it is really better.
> > >
> > > We will be in charge for this API, it will be a new API on which we
> will
> > > depend in many part of Maven core and in pl
ns.
> > It is better to not depend on third party.
> >
> > There are other initiatives like microprofile metrics.
> >
> > The API itself is very small and we could add an implementation that uses
> > micro profile. But we must be independent.
> >
> >
be a new API on which we will
> > depend in many part of Maven core and in plugins.
> > It is better to not depend on third party.
> >
> > There are other initiatives like microprofile metrics.
> >
> > The API itself is very small and we could add an im
add an implementation that uses
> micro profile. But we must be independent.
>
> Enrico
>
>
>
> > thanks,
> > Robert
> > On 2-5-2020 10:26:19, Enrico Olivelli wrote:
> > Hello community,
> > I am now ready to move forward with concrete steps for
wrote:
> Hello community,
> I am now ready to move forward with concrete steps for the implementation
> of Maven Runtime Metrics.
>
> This is the JIRA
> https://issues.apache.org/jira/browse/MNG-6899
>
> It links to my proof-of-concept branch on maven studies.
> https://git
our own Metrics API?
thanks,
Robert
On 2-5-2020 10:26:19, Enrico Olivelli wrote:
Hello community,
I am now ready to move forward with concrete steps for the implementation
of Maven Runtime Metrics.
This is the JIRA
https://issues.apache.org/jira/browse/MNG-6899
It links to my proof-of-concept
Hello community,
I am now ready to move forward with concrete steps for the implementation
of Maven Runtime Metrics.
This is the JIRA
https://issues.apache.org/jira/browse/MNG-6899
It links to my proof-of-concept branch on maven studies.
https://github.com/apache/maven-studies/tree/maven-metrics
Looks very interesting (and good work btw!), very impatient to see what the
end dump looks like with wagon and potentially local (disk) I/O!
Next step is likely to try to use as an extension a shade of a "common"
impl (I'm thinking to microprofile metrics but could be codehale one) to
have exporter
Hi,
news about the status of my POC:
1) I have created a demo Metrics Provider [1]
2) I have updated my branch on Maven Studies [2]
It works everything as expected.
In order to setup an appealing "demo" I have to add "interesting" metrics...
Every suggestion is welcome, as my next step I will try
I have managed to use @Inject and the extensions mechanism.
Thank you for your advices.
I am now implementing some useful "simple" metrics providers (two
"extensions") in order to see this stuff working.
My idea is to have two interesting implementations:
- Dump stats at the end of the CLI session
It depends how it is done.
@Inject MetricsSystem ms; will likely fail but if you inject the container
and do the lookup you can handle the absence of the metrics, less elegant
but working as well.
Alternative is to inject a custom compiler component and have 2 components
impl (hints being differe
Self answer: I had written the DefaultMetricsSystem file in the wrong
directory ! (in maven core tests!)
Sorry fo the noise
I have just one problem.
Currently I am using Jsr300 to plug the MetricsSystem to Maven Core
and this would be the expected way for Plugins.
Say now that I want to use my Me
Hi,
I have pushed a new version of my prof-of-concept
https://github.com/apache/maven-studies/compare/maven-metrics?expand=1
I am introducing a MetricsSystem interface and a DefaultMetricsSystem CDI bean.
I am new to sisu/plexsus container.
It looks like that DefaultMetricsSystem is getting instan
Le samedi 14 mars 2020, 15:14:17 CET Enrico Olivelli a écrit :
> I am starting this work.
> I have pushed a copy of current maven core master to maven-studies.
nice
[...]
> I don't know how classloading works very well in the case of Maven/Plexus.
your approach looks reasonable: you're adding exte
ols won't see NULLs.
> > > > >
> > > > > in MavenCli I will "boot" (and manage the whole lifecycle) the
> > Metrics
> > > > > Provider and set this "global reference".
> > > > >
> > >
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 cas
assloading 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 cycl
ll 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
> >
> >
> >
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 ha
> scritto:
> >
> > maven-studies looks like the right location:
> > https://github.com/apache/mav
lle ore 00:27 ha scritto:
>
> maven-studies looks like the right location:
> https://github.com/apache/maven-studies
>
> Regards,
>
> Hervé
>
> - Mail original -
> De: "Enrico Olivelli"
> À: "Maven Developers List"
> Envoyé: Jeudi
maven-studies looks like the right location:
https://github.com/apache/maven-studies
Regards,
Hervé
- Mail original -
De: "Enrico Olivelli"
À: "Maven Developers List"
Envoyé: Jeudi 30 Janvier 2020 04:31:14
Objet: Re: Maven Runtime Metrics
I sound like to dra
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 ha
scritto:
> technically we can shade microprofile, metrics/dropwizard or even sirona
> but maven requires quite a different model
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 issu
Il Mar 28 Gen 2020, 13:30 Lennart Jörelid 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
Would it be possible to use an existing standard for the specification of
such a metrics API?
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 footp
Il giorno mar 28 gen 2020 alle ore 09:15 Romain Manni-Bucau <
rmannibu...@gmail.com> 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" wi
+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.
Side note being: we can start we just counters so no lib is fine imho.
Le mar. 28 janv. 2020 à 08:56, Enrico Olivelli a
écrit :
> Hi,
> I would
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.
51 matches
Mail list logo
