On Fri, Sep 13, 2019 at 11:01 PM Alexander Ashitkin <
alexander.ashit...@db.com> wrote:
> This feature is true incremental build – you don’t build modules which
> were not changed at all and build only modified/changed ones.
>
Suppose module B depends on module A and I change A. Does B get rebui
Hi
Yes we tried, but Takari is a bit different story – it’s a smarter scheduler
which gives you some boost over default lifecycle scheduler, but still require
you to build your modules.
This feature is true incremental build – you don’t build modules which were not
changed at all and build only
This feature caches Tests results too, but granularity is per-project. In our
case we even cache result of long-running integration tests as well so
developers rerun unit/integration tests only for changed projects and
dependents from them. That’s significant time win.
In our multi module projec
Indeed we have a kind of the option 2 with variations. Current implementation
is opt-in feature driven by configuration with some metadata of required cache
behavior and hints.
Maven extensions is the option, but we would love to have it in maven itself
which is in interest of maven community i
The feature doesn't do per Test/Classes analysis. Granularity of incremental
build is per project - if project is invalidated by changes in
dependencies/source code/plugins it will be rebuilt fully. So, single module of
multi-module build doesn't receive any increment, but for multi module proje
Disabling a Surefire/Failsafe in a particular module is easy but it won't
gain the performance so much if you do not analyse the relations between
classes and the test.
If you analyse the relations then you can easily fetch the list of the
tests in -Dtests or in the included/excludedTests. So ever
There are multiple possible incremental support:
1. Scm related: do a status and rebuild downstream reactor
2. Full and module build graph: seems it is the one you target, ie bypass
modules without change. Note that it only works if upstream graph is taken
into account.
3. Full build: each mojo ha
In theory, the incremental compiler would make it faster.
But this can be told only if you present a demo project with has trivial
tests taking much less time to complete than the compiler.
In reality the tests in huge projects take significantly longer time than
the compiler.
Some developers say
Hi there,
just a shot in a dark: Have you tried any of the existing stuff, like
Takari Lifecycle before modding Maven itself? (
http://takari.io/book/40-lifecycle.html)
Thanks,
T
On Fri, Sep 13, 2019 at 10:46 PM Maximilian Novikov <
maximilian.novi...@db.com> wrote:
> Hi All,
>
>
>
> *We want t
Hi All,
We want to create upstream change to Maven to support true incremental build
for big-sized projects.
To raise a pull request we have to pass long chain of Deutsche Bank's internal
procedures. So, before starting the process we would like to get your feedback
regarding this feature.
Mot
I'll be offline for about 2 weeks, but I guess nobody else has enough
knowledge to verify this...
Robert
On Fri, 13 Sep 2019 21:39:49 +0200, Gabriel Belingueres
wrote:
Hi!
Is there any chance to merge PR for MSHARED-817 [1]?
I would need that change in place as base to make a final comm
Hi!
Is there any chance to merge PR for MSHARED-817 [1]?
I would need that change in place as base to make a final commit for
MSHARED-801 [2].
[1] https://github.com/apache/maven-artifact-transfer/pull/2
[2] https://github.com/apache/maven-artifact-transfer/pull/1
Kind regards,
Gabriel
@Dan Tran use 'deployAtEnd':
org.apache.maven.plugins
maven-deploy-plugin
someVersion
true
https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html
Re
Maybe you'd want to deployAtEnd?
https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#deployAtEnd
On Fri, Sep 13, 2019 at 12:03 PM Dan Tran wrote:
> Looks like I need to clear thing a little bit
>
> Assume I have a reactor of few hundreds of maven modules and my CI
> build deplo
Looks like I need to clear thing a little bit
Assume I have a reactor of few hundreds of maven modules and my CI
build deploys snapshots, first few good builds, each module deployed to
maven repository have same snapshot number
Once we encounter a build failure at a module, the snapshot number b
15 matches
Mail list logo
