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
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
-
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
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",
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,
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
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
Just as an example:
metricsSystem
.getMetricsContext()
.getSummary( "resolvePluginDependency", "Time to resolve dependencies of a
plugin (ms)" )
.add( MetricsUtils.elapsedMillis( startResolve ) );
Here you are adding something to the Metric System, but you could also but this
in a single
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 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 and
create coupling between plugin/exts and
Il Dom 10 Mag 2020, 17:49 Robert Scholte ha scritto:
> Hi Enrico,
>
> These could all be solved by firing events.
>
Yes
I see your point.
Unfortunately those are the first points that I have instrumented in order
to see some data.
> And there's another benefit: since there won't be an API, we
Hi Enrico,
These could all be solved by firing events.
And there's another benefit: since there won't be an API, we don't need to
maintain it,or be afraid of mistakes.
To me this is the wrong approach to embed metrics.
thanks,
Robert
On 10-5-2020 16:58:59, Enrico Olivelli wrote:
Il giorno dom
Il giorno dom 10 mag 2020 alle ore 13:42 Robert Scholte <
rfscho...@apache.org> ha scritto:
> sometimes code says more than a thousand words: can you share the changes
> in Maven Core you had in mind?
>
Maven Metrics Extensions API:
sometimes code says more than a thousand words: can you share the changes in
Maven Core you had in mind?
On 10-5-2020 12:07:33, Enrico Olivelli wrote:
Il giorno dom 10 mag 2020 alle ore 11:53 Robert Scholte
rfscho...@apache.org> ha scritto:
> Maybe I'm still missing a detail, but this is what I
Il giorno dom 10 mag 2020 alle ore 11:53 Robert Scholte <
rfscho...@apache.org> ha scritto:
> Maybe I'm still missing a detail, but this is what I had in mind:
> Maven already fires events.
>
Metrics are for a distinct use case.
Metrics are like Logs, the developer instruments its own code to
Maybe I'm still missing a detail, but this is what I had in mind:
Maven already fires events.
The extension listens to these events and can do its metrics.
I see no need for a hard coupling between these two.
Robert
On 10-5-2020 10:28:42, Enrico Olivelli wrote:
Il Dom 10 Mag 2020, 09:21 Romain
Il Dom 10 Mag 2020, 09:21 Romain Manni-Bucau ha
scritto:
> Le dim. 10 mai 2020 à 07:43, Enrico Olivelli a
> écrit :
>
> > Robert
> > Maybe I was misunderstood.
> > We need a new repo only for the Metrics API.
> >
> > Maven core (3.7?) provides the noop implementation.
> >
> > Implementations of
Le dim. 10 mai 2020 à 07:43, Enrico Olivelli a écrit :
> Robert
> Maybe I was misunderstood.
> We need a new repo only for the Metrics API.
>
> Maven core (3.7?) provides the noop implementation.
>
> Implementations of MetricsProvider will be extensions. I feel it is better
> that we don't deal
Robert
Maybe I was misunderstood.
We need a new repo only for the Metrics API.
Maven core (3.7?) provides the noop implementation.
Implementations of MetricsProvider will be extensions. I feel it is better
that we don't deal with implementations as a first step.
I will leave a couple of
On 9-5-2020 17:58:47, Enrico Olivelli wrote:
Robert
Il Sab 9 Mag 2020, 10:54 Robert Scholte ha scritto:
> Although I'm disappointed there's no spec group for this, having our own
> seems indeed the best choice, but here we will likely face similar issues
> where the API needs adjustments.
> So
Robert
Il Sab 9 Mag 2020, 10:54 Robert Scholte ha scritto:
> Although I'm disappointed there's no spec group for this, having our own
> seems indeed the best choice, but here we will likely face similar issues
> where the API needs adjustments.
> So lets create the maven-metrics git repository
Le sam. 9 mai 2020 à 10:54, Robert Scholte a écrit :
> Although I'm disappointed there's no spec group for this, having our own
> seems indeed the best choice, but here we will likely face similar issues
> where the API needs adjustments.
> So lets create the maven-metrics git repository
>
>
+1
Although I'm disappointed there's no spec group for this, having our own seems
indeed the best choice, but here we will likely face similar issues where the
API needs adjustments.
So lets create the maven-metrics git repository
There are a few things I want to address:
- Consider returning
Le lun. 4 mai 2020 à 16:55, Slawomir Jaranowski a
écrit :
> Hi,
> In my humble opinion it is not the best way to implement own api when
> similar api is already ready and maintained.
>
> There is another project used for metrics: micrometer, as we can see it is
> a quite popular 2.3K stars, 500
Hi,
In my humble opinion it is not the best way to implement own api when
similar api is already ready and maintained.
There is another project used for metrics: micrometer, as we can see it is
a quite popular 2.3K stars, 500 forks on github
https://github.com/micrometer-metrics/micrometer
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 dependency on Maven.
> And looking at
> https://github.com/apache/maven-studies/tree/maven-metrics/maven-metrics/src/main/java/org/apache/maven/metrics
> [
>
If I take a look at the pom of maven-metrics, I see no dependency on Maven.
And looking at
https://github.com/apache/maven-studies/tree/maven-metrics/maven-metrics/src/main/java/org/apache/maven/metrics
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
30 matches
Mail list logo
