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
elharo opened a new pull request #164:
URL: https://github.com/apache/maven-site/pull/164
@khmarbaise
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
U
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
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 event.
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
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 only
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:
https://github.com/apache/maven-metric/blob/master/maven-metrics
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 hav
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 M
"pip install maven" will apparently install https://pypi.org/project/maven/
which is https://github.com/john-sandall/maven
nothing related to the well known Apache Maven build tool
https://maven.apache.org/
Regards,
Hervé
- Mail original -
De: "Vikas Mishra"
À: "Maven Developers List"
Hi,
Hope you are doing well!
I want to use maven (pom.xml) in python. I am having python 3.6.3 and
visual studio code as an IDE in my laptop. I also installed serenity with
"pip install maven" command where I got msven 0.1.0 version.
I am unable to create maven project there. May you please he
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 w
18 matches
Mail list logo
