> Sent: Saturday, September 21, 2019 9:50 AM
> To: Maven Developers List
> Subject: Re: [VOTE] Maven incremental build for BIG-sized projects with
> local and remote caching
>
> Hi Maximilian,
> is there anyway to see this work ? is it already open source? (I am sorry
Developers List
Subject: Re: [VOTE] Maven incremental build for BIG-sized projects with local
and remote caching
Hi Maximilian,
is there anyway to see this work ? is it already open source? (I am sorry,
maybe I missed some email with links)
Enrico
Il giorno ven 20 set 2019 alle ore 19:30 Ale
Hi Alexander and Maximilian. As a former Deutsche Bank RTC employee, I
cannot bypass this topic.
First of all, I'm not speaking for community, neither Jetbrains.
I know how painfull is to get all approvals for open-source contribution in
Deutsche Bank, but may be you can share you solution as a ma
Hi Maximilian,
is there anyway to see this work ? is it already open source? (I am sorry,
maybe I missed some email with links)
Enrico
Il giorno ven 20 set 2019 alle ore 19:30 Alexander Ashitkin <
ashitkin.a...@gmail.com> ha scritto:
> Hi Martijn
> thanks for positive feedback.
>
> Regarding IDE
Hi Martijn
thanks for positive feedback.
Regarding IDE part, yes you're right on integration part, but still there
important cases when cache helps:
1) you need to navigate less in project as top level targets fast enough to not
drill down
2) if you need to build a part of project (say only res
On Thu, Sep 19, 2019 at 7:48 AM Alexander Ashitkin
wrote:
> Configuration:
> * verify -T4 -P default,all-shapshots-repos
> * my project config (might be suboptimal for wicket)
> * scala tests disabled in 2 modules (caused bytecode version conflict on my
> machine)
>
> Results
> Clean state (cache
Sorry if duplicated, looks like my yesterday reply didn't come through.
Sharing results.
Configuration:
* verify -T4 -P default,all-shapshots-repos
* my project config (might be suboptimal for wicket)
* scala tests disabled in 2 modules (caused bytecode version conflict on my
machine)
Results
vanced optimizations don't look possible
> >
> >Our idea was to move from workaround solutions(as Tibor classified
> >this) to native solution.
> >
> >Thanks for sharing this.
> >
> >Kind regards,
> >Max
> >
> >
> >-Origina
sible
>
>Our idea was to move from workaround solutions(as Tibor classified
>this) to native solution.
>
>Thanks for sharing this.
>
>Kind regards,
>Max
>
>
>-Original Message-
>From: Falko Modler [mailto:f.mod...@gmx.net]
>Sent: Wednesday, September 18,
ks for sharing this.
>
> Kind regards,
> Max
>
>
> -Original Message-
> From: Falko Modler [mailto:f.mod...@gmx.net]
> Sent: Wednesday, September 18, 2019 1:15 AM
> To: dev@maven.apache.org
> Subject: Re: [VOTE] Maven incremental build for BIG-sized projects wi
Sent: Wednesday, September 18, 2019 1:15 AM
To: dev@maven.apache.org
Subject: Re: [VOTE] Maven incremental build for BIG-sized projects with local
and remote caching
Hi there,
I must admit that I did not read everything but in case you are using Git this
extension might help:
https://githu
Hi there,
I must admit that I did not read everything but in case you are using
Git this extension might help:
https://github.com/vackosar/gitflow-incremental-builder
It is a Maven extension and it is _not_ limited to Gitflow setups!
Disclaimer: I am not the owner of this project but I am a "C
This seems like it would benefit a lot of projects (at least it would ours).
How would this work in coordination with IDE's? m2e has (afaict, but
haven't looked closely) its own lifecycle management to bridge eclipse and
maven. AFIAK only Netbeans uses maven directly?
If you want to benchmark a p
lease
> > > of some apps and etc...
> > >
> > > Now we releasing 20+ clients apps and 50+ backend components every
> week or
> > > even often. With multiple SCM we will need to hire a team of release
> > > managers and build engineers to coordinate and
Hi Robert
sounds like right direction, but just categorizing parameters is not enough.
1) You need to connect plugins into a chain, so you need to match outputs of
multiple plugins as input for downstream plugins.
2) Input output is not enough. You need to know which parameters affect plugin
b
are don’t selling our approach. We implemented the missing for
> > us feature.
> >
> > PS. Just thing why commercial products like Gradle Maven Extensions
> > appeared.
> >
> >
> > From: Tibor Digana mailto:tibordig...@apache.org>>
> > Date: Satu
Hi
Let's please stop discussing this subject as it goes off-top and pollutes
thread. Our case exists, it has own reasons and we discuss it is not in the
scope of this thread. Lets please return to the feature itself
Thank you
On 2019/09/14 16:41:43, Romain Manni-Bucau wrote:
> Hope I didnt m
eared.
>
>
> From: Tibor Digana mailto:tibordig...@apache.org>>
> Date: Saturday, 14 Sep 2019, 9:43 PM
> To: Maven Developers List dev@maven.apache.org>>
> Subject: Re: [VOTE] Maven incremental build for BIG-sized projects with
> local and remote caching
>
> Alex
Le sam. 14 sept. 2019 à 22:17, Alexander Ashitkin
a écrit :
> Let us evaluate this approach. But if we go extension way, it will be not
> so big motivation to make it part of maven. and i'm not sure what are long
> term strategy for maven, but without incremental builld it becomes less and
> less
Let us evaluate this approach. But if we go extension way, it will be not so
big motivation to make it part of maven. and i'm not sure what are long term
strategy for maven, but without incremental builld it becomes less and less
attractive in our multi-branched world
Thank you
On 2019/09/14 0
HI Robert
seems to your thinking matches to our own one. Indeed, the question is - should
be executed this goal or not? But in current plugin-api limitations not a
plugin-developer but only project developer can understand should this goal run
or not because of side effects each plugin might hav
t clear).
> -Original Message-
> From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
> Sent: Saturday, September 14, 2019 7:42 PM
> To: Maven Developers List
> Subject: Re: [VOTE] Maven incremental build for BIG-sized projects with
> local and remote caching
>
> Ho
19 11:48 AM
> To: Maven Developers List
> Subject: Re: [VOTE] Maven incremental build for BIG-sized projects with
> local and remote caching
>
> Le sam. 14 sept. 2019 à 08:00, Alexander Ashitkin
> a écrit :
>
> > Indeed we have a kind of the option 2 with variations.
.
PS. Just thing why commercial products like Gradle Maven Extensions appeared.
From: Tibor Digana mailto:tibordig...@apache.org>>
Date: Saturday, 14 Sep 2019, 9:43 PM
To: Maven Developers List mailto:dev@maven.apache.org>>
Subject: Re: [VOTE] Maven incremental build for BIG-sized project
Alexander,
Enrico is really right. Today it is Microservices and there every
microservice is in a separate SCM repo.
It was just only an example with Microservices but in my experiences you
can always find the lower bound modules in the hierary which do not change
so much and segragate them in ano
Robert, I understand the discussion. There is the requirement (1) to cache
the targets and second discussion is to (2) switch on/off unchanged modules
in multi-module project.
I had used the (1) in the company Software AG and it was really
unpredictable build with hunders POMs in project. I would
nnibu...@gmail.com]
Sent: Saturday, September 14, 2019 11:48 AM
To: Maven Developers List
Subject: Re: [VOTE] Maven incremental build for BIG-sized projects with local
and remote caching
Le sam. 14 sept. 2019 à 08:00, Alexander Ashitkin a
écrit :
> Indeed we have a kind of the option
poly-repo.
-Original Message-
From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Sent: Saturday, September 14, 2019 7:42 PM
To: Maven Developers List
Subject: Re: [VOTE] Maven incremental build for BIG-sized projects with local
and remote caching
Hope I didnt miss it but how monorepo=single
Hope I didnt miss it but how monorepo=single build?
It is working well to not have a common parent too and is unlinked to
monorepo which uses local relative paths in general (at least in the
references you quoted which are also not about java ;)).
Unrelated to making maven better at incremental b
https://issues.apache.org/jira/browse/MPLUGIN-350 is the issue to start
with.
Please read all the comments, because my original thought won't work.
thanks,
Robert
On Sat, 14 Sep 2019 17:10:13 +0200, Alexander Ashitkin
wrote:
We checked and price of 550$ per user makes us think twice of w
We checked and price of 550$ per user makes us think twice of what's the best
way to proceed here :-)
Regarding plugin api - yes, changes are desirable to make maven model
cache-friendly. Both in plugin invocation model and Mojo#execute input/output
apis. But it is possible to work with current
Sorry, i think Jenkins is irrelevant here at all. we need solution which works
everythere - on workstations, from commandline, on other build servers, in
intellij, etc. Any solution which is worth to discuss must be Jenkins agnostic
honestly. Also, FYI we don't rely on target directory state at
HI Enrico
Thanks for feedback. that's a side discussion for best approach for projects
layouts. Monorepo has own own advocates and it is easy to find posts describing
why google, microsoft or facebook go monorepo.
Unlike of way of thought, we are ready to go globally in case of emergency
scenar
Hi Laird
yes, in this case B will be rebuilt - that's on of the basic requirements.
Thanks in advance
On 2019/09/14 06:29:00, Laird Nelson wrote:
> 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
Tibor, it seems like you're missing the bigger picture.
The question is similar to what we've discussed in the past: can we define
if surefire should be executed or not?
We should define incremental builds as "should a goal be executed or
not?", e.g. based on the results of the previous buil
oh yeah, exactly opposite.
Jenkins has several ways to create Maven build configuration and it knows
where the repo and workspace is, it knows where to store the archive, it
knows when the build failed.
We cannot take the responsibility because the build may fail for whatever
reason and we do not k
Tibor, maven is the only one with the logic to give any cache the data it
needs. Jenkins alone can't since it does not own the reactor nor plugin I/O
values.
Le sam. 14 sept. 2019 à 12:45, Tibor Digana a
écrit :
> But I do not understand why the Maven should be responsible for the project
> cahe
But I do not understand why the Maven should be responsible for the project
cahe control/management of "/target" directories.
It is a responsibility of the build manager which is the Jenkins.
The Jenkins has the ability to archive files and such property already
exists in the Jenkins.
So the Jenki
On Fri, 13 Sep 2019 23:37:15 +0200, Romain Manni-Bucau
wrote:
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
Le sam. 14 sept. 2019 à 08:00, Alexander Ashitkin
a écrit :
> 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
I feel that in general having an huge monolithic project is kind of a
project-smell.
Btw I have some big project with 100+ modules so I can see your pain.
In the daywork experience a single developer doesn't work on all of the
modules but usually you touch 1-2 modules and maybe some integration/sys
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
...@cservenak.net]
Sent: Friday, September 13, 2019 4:54 PM
To: Maven Developers List
Cc: Alexander Ashitkin
Subject: Re: [VOTE] Maven incremental build for BIG-sized projects with local
and remote caching
Hi there,
just a shot in a dark: Have you tried any of the existing stuff, like Takari
Cc: Alexander Ashitkin
Subject: Re: [VOTE] Maven incremental build for BIG-sized projects with local
and remote caching
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
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
51 matches
Mail list logo
