So, the primary reason I'd like to keep the fastinstall profile is because I bisect Camel often to find which commit introduced a certain bug, test failure or behavior. If we remove this profile, then I would have to adjust my bisect script so that in newer versions it uses "mvn -Dquickly" and in versions before this patch it would use "mvn -Pfastinstall" ... and I would have to, somehow, detect from when to start using one or the other (I think it would be difficult).
I haven't thought about adding the profile to my user's settings.xml file, but maybe that would do the trick ... I'll give it a try. Regardless of that, the lack of fastinstall profile is not a blocker from my end. I think this is a good improvement. Kind regards On Fri, Jun 23, 2023 at 11:30 AM Peter Palaga <ppal...@redhat.com> wrote: > On 23/06/2023 09:38, Otavio Rodolfo Piske wrote: > > +1 from me. > > > > All in all I think this is a good thing. Our build takes _way_ too long, > so > > any effort that can reduce this time is welcome. Also, I like that this > > would make the build similar to CEQ. Ideally, in the future, we could > also > > apply the same pattern to both CSB and CKC, so that we have an uniform > > build process across the board. > > > > That said, I have one (hopefully) simple request* in all of this: for us > to > > retain the fastinstall profile. The reason for me asking this is because > it > > makes my bisect scripts much easier. > > > > * Obs.: as far as I can tell, the PR does not remove the fastinstall > > profile, so this is more like "just to be sure". > > Thanks for the feedback, Otavio! I actually wanted to remove the > fastinstall profile altogether but now I see there are some leftovers. > You mean you want to keep the fastinstall profile as it was with all > those skip properties? I am open to that, but still, I wonder whether > defining fastinstall in your settings.xml would not be a good enough > solution too? > > -- P > > > Great work, Peter ... I'm hoping to see these changes merged. > > > > Kind regards > > > > On Fri, Jun 23, 2023 at 1:00 AM Peter Palaga <ppal...@redhat.com> wrote: > > > >> Hi, > >> > >> In PR https://github.com/apache/camel/pull/10476 I tried to make some > >> changes to improve ergonomics and reproducibility. > >> > >> The first idea is to auto-fix formatting issues instead of outputting > >> error messages. I.e. rather than using Checkstyle plugin that is not > >> able to fix even basic violations of its policies, maven-license-plugin, > >> maven-formatter-plugin and maven-impsort-plugin are enabled by default > >> to format the sources in the desired way without contributors having to > >> configure their IDEs or anything else manually. There are some more > >> details in https://issues.apache.org/jira/browse/CAMEL-19461 > >> > >> My second goal was to make the fast build (done from a state that passed > >> the CI) as fast as possible by removing the unessential Maven mojos from > >> the Maven execution plan altogether. We use this since longer in Camel > >> Quarkus and it is explained in detail in this blog: > >> https://peter.palaga.org/2020/10/29/skipping-maven-mojos-properly.html > >> The new mechanism is slightly different from how our original > >> `fastinstall` profile worked. `fastinstall` was disabling mojos by > >> defining their skip properties and it was activated simply by passing > >> `-Pfastinstall`. The new fast build does something different: it > >> disables the default `full` profile by passing a property. Because the > >> invocation had to change from -P to -D I dared to use the same property > >> name as we use in Camel Quarkus: `-Dquickly` I hope that's fine for > >> everybody. See also https://issues.apache.org/jira/browse/CAMEL-19466 > >> > >> On my machine with 32 virtual threads, invoking `mvnd clean install > >> -Dquickly` takes > >> > >> * 1st build: 1m 21s > >> * 2nd build: 1m 10s > >> > >> The subsequent builds are slower. I have not investigated why, it is > >> perhaps because of garbage collection or some plugin might be leaking > >> memory. > >> > >> The third thing is not having the Apache Snapshots Maven repository > >> enabled by default for the sake of reproducibility locally and on CI. > >> It is still present in the `apache-snapshots` profile. > >> There are more details in > >> https://issues.apache.org/jira/browse/CAMEL-19465 > >> > >> Any feedback is welcome. > >> > >> Thanks, > >> > >> -- Peter > >> > >> > > > > -- Otavio R. Piske http://orpiske.net
