Maven Runtime Metrics

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Maven Runtime Metrics

Enrico Olivelli
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
Reply | Threaded
Open this post in threaded view
|

Re: Maven Runtime Metrics

Romain Manni-Bucau
+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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Maven Runtime Metrics

Enrico Olivelli
Il giorno mar 28 gen 2020 alle ore 09:15 Romain Manni-Bucau <
[hidden email]> 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 <[hidden email]> 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
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Maven Runtime Metrics

Enrico Olivelli
Il Mar 28 Gen 2020, 13:30 Lennart Jörelid <[hidden email]> 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 <[hidden email]>
> wrote:
>
> > Il giorno mar 28 gen 2020 alle ore 09:15 Romain Manni-Bucau <
> > [hidden email]> 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 <[hidden email]> 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: [hidden email]
> | URL:   www.jguru.se
> | Phone
> | (skype):    jgurueurope
> | (intl):     +46 708 507 603
> | (domestic): 0708 - 507 603
> +==============================+
>
Reply | Threaded
Open this post in threaded view
|

Re: Maven Runtime Metrics

Romain Manni-Bucau
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 <[hidden email]> a
écrit :

> Il Mar 28 Gen 2020, 13:30 Lennart Jörelid <[hidden email]> 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 <[hidden email]>
> > wrote:
> >
> > > Il giorno mar 28 gen 2020 alle ore 09:15 Romain Manni-Bucau <
> > > [hidden email]> 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 <[hidden email]>
> 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: [hidden email]
> > | URL:   www.jguru.se
> > | Phone
> > | (skype):    jgurueurope
> > | (intl):     +46 708 507 603
> > | (domestic): 0708 - 507 603
> > +==============================+
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Maven Runtime Metrics

Hervé BOUTEMY
In reply to this post by Enrico Olivelli
maven-studies looks like the right location:
https://github.com/apache/maven-studies

Regards,

Hervé

----- Mail original -----
De: "Enrico Olivelli" <[hidden email]>
À: "Maven Developers List" <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> a
> écrit :
>
> > Il Mar 28 Gen 2020, 13:30 Lennart Jörelid <[hidden email]> 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 <[hidden email]>
> > > wrote:
> > >
> > > > Il giorno mar 28 gen 2020 alle ore 09:15 Romain Manni-Bucau <
> > > > [hidden email]> 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 <
> [hidden email]>
> > 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: [hidden email]
> > > | URL:   www.jguru.se
> > > | Phone
> > > | (skype):    jgurueurope
> > > | (intl):     +46 708 507 603
> > > | (domestic): 0708 - 507 603
> > > +==============================+
> > >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]