Fwiw, i did a lot of work on the build a while ago, but my main goal was to
optimize subsequent  `mvnd -DskipTests` run.
Ideall, in such cases, no jars should be changed at all, but that's not the
case completely, especially for maven plugins (try running `ls -ltr
**/*.jar` after a build). There are pending changes in maven to fix that
and I plan to push some changes in camel (mostly plugins updates) once
those are released.

In case you don't know the option, you can use the `mvnd -Dmvnd.buildTime`
option to gather statistics on the mojo execution time.

In addition, I've been working a few weeks ago on the
maven-build-cache-extension [1], which is a powerful extension that
provides a full per-module build cache.  The cache can be configured
locally and remotely (where the output of a module will be downloaded from
the remote cache instead of being built locally).  It currently requires
some changes in maven-core that will only be released in maven 3.9.0.
However, I can try to set up an experimental mvnd branch that would embed
this extension if that's of any interest.

Guillaume

[1] https://github.com/apache/maven-build-cache-extension

Le jeu. 10 févr. 2022 à 09:25, Otavio Rodolfo Piske <angusyo...@gmail.com>
a écrit :

> Thanks for looking into this.
>
> On a related note, I think one area where we could investigate potential
> improvements to the compilation is by looking at the performance of our
> maven plugins and code generators.
>
> For example the camel-endpointdsl module takes a long time to generate
> sources and build (that one takes almost 2 minutes to run on GH). The
> camel-componentdsl one takes about 1 minute. I suspect that if we could
> trace why they are so slow, there may be a route for optimizing the build
> time (and if we are lucky, that could happen across the whole build).
>
> A secondary branch of investigation could be looking at whether we can
> adjust our build so that we can have it running with "process-classes"
> target, to avoid the costly process of compressing and installing the jars.
>
> Kind regards
>
> On Wed, Feb 9, 2022 at 2:41 PM Nicolas Filotto <nfilo...@talend.com>
> wrote:
>
> > Hi again,
> >
> > Just to let you know that it appears that there are only 2 cores on the
> > target server which is obviously not enough to have an impact on the
> build
> > time.
> >
> > Regards,
> > Nicolas
> > ________________________________
> > From: Nicolas Filotto <nfilo...@talend.com>
> > Sent: Wednesday, February 9, 2022 11:33
> > To: dev@camel.apache.org <dev@camel.apache.org>
> > Subject: Re: Parallel Build in Camel
> >
> > !-------------------------------------------------------------------|
> >   This Message Is From an External Sender
> >   This message came from outside your organization.
> >   Exercise caution when opening attachments or clicking any
> >   links.
> > |-------------------------------------------------------------------!
> >
> > Hi,
> >
> > Thank you very much for your feedbacks. Here is the related PR
> >
> https://urldefense.com/v3/__https://github.com/apache/camel/pull/6907__;!!CiXD_PY!C-yfZjEVUOAkwpdj1K9URzQDT9hlsdcr4PMcsL2byb6MCaomvtqUJvVUoIKNkHE$
> > .
> >
> > Regards,
> > Nicolas
> >
> > ________________________________
> > From: Otavio Rodolfo Piske <angusyo...@gmail.com>
> > Sent: Wednesday, February 9, 2022 10:26
> > To: dev@camel.apache.org <dev@camel.apache.org>
> > Subject: Re: Parallel Build in Camel
> >
> > !-------------------------------------------------------------------|
> >   This Message Is From an External Sender
> >   This message came from outside your organization.
> >   Exercise caution when opening attachments or clicking any
> >   links.
> > |-------------------------------------------------------------------!
> >
> > Hi,
> >
> > I think it would be OK to give it a try. Please, feel free to open a PR
> > with this suggestion.
> >
> > Kind regards
> >
> > On Wed, Feb 9, 2022 at 10:22 AM Nicolas Filotto <nfilo...@talend.com>
> > wrote:
> >
> > > Hi,
> > >
> > > If the parallel build is something that can be used in the build
> > pipeline,
> > > why not simply starting by adding the -T option of maven to the
> commands
> > > launched by the build (
> > >
> >
> https://urldefense.com/v3/__https://github.com/apache/camel/blob/main/.github/workflows/master-pr-build.yml*L39__;Iw!!CiXD_PY!EMmp3maGNIUrNLCyD1a__sEjX6IOh6rg2uTID5to5gtnpo19lPAOuN33k5dXjH0$
> > )
> > > as short/middle term solution before eventually considering the maven
> > > daemon? What do you think of it?
> > >
> > > Regards,
> > > Nicolas
> > >
> > > ________________________________
> > > From: Otavio Rodolfo Piske <angusyo...@gmail.com>
> > > Sent: Wednesday, February 9, 2022 10:03
> > > To: dev@camel.apache.org <dev@camel.apache.org>
> > > Subject: Re: Parallel Build in Camel
> > >
> > > !-------------------------------------------------------------------|
> > >   This Message Is From an External Sender
> > >   This message came from outside your organization.
> > >   Exercise caution when opening attachments or clicking any
> > >   links.
> > > |-------------------------------------------------------------------!
> > >
> > > Hi,
> > >
> > > Yeah, that helps a bit, although it's still quite a lot. One day I'd
> like
> > > to take a closer look at some of the plugins we have on the build to
> see
> > if
> > > there's some easy speed up we could do.
> > >
> > > As for the Github, I think we depend on 2 things:
> > > 1. I believe we need a Github action that contains and runs maven
> daemon
> > > 2. I believe this action needs to be approved somehow by the ASF. I am
> > not
> > > sure about this, though ... maybe others in the community know more
> about
> > > it.
> > >
> > > Kind regards
> > >
> > >
> > >
> > > As a recipient of an email from Talend, your contact personal data will
> > be
> > > on our systems. Please see our privacy notice (updated August 2020) at
> > > Talend, Inc. <https://www.talend.com/contacts-privacy-policy/>
> > >
> > >
> > >
> >
> > --
> > Otavio R. Piske
> >
> >
> https://urldefense.com/v3/__http://orpiske.net__;!!CiXD_PY!EMmp3maGNIUrNLCyD1a__sEjX6IOh6rg2uTID5to5gtnpo19lPAOuN33LLnzx4c$
> >
> > As a recipient of an email from Talend, your contact personal data will
> be
> > on our systems. Please see our privacy notice (updated August 2020) at
> > Talend, Inc. <https://www.talend.com/contacts-privacy-policy/>
> >
> >
> >
> > As a recipient of an email from Talend, your contact personal data will
> be
> > on our systems. Please see our privacy notice (updated August 2020) at
> > Talend, Inc. <https://www.talend.com/contacts-privacy-policy/>
> >
> >
> >
>
> --
> Otavio R. Piske
> http://orpiske.net
>


-- 
------------------------
Guillaume Nodet

Reply via email to