Hi Maven Team
Want to bring to your attention new feature I’m see as beneficial for the
cache. The reason to bring into attention is core level questions - ability to
not rerun tests for unchanged project which in turn needs ability to mark
source code and plugins as private (ie not consuming an
Hi Paul
this is a fork which is recommended to use with mvnw.
Thank you
Aleks
On 2021/02/22 11:00:44, Falko Modler wrote:
> This is very interesting and exciting news!
>
> > this is a fork of Maven somehow? Or additional
> > plugins that are configurable into standard Maven?
>
> I second th
Hi Paul
this is fork which is required to use with mvnw. It is fully compatible with
usual maven so no special modifications to project are required except config
file.
Thank you
Aleks
On 2021/02/22 10:40:23, Paul Hammant wrote:
> Sounds great. Quick check - this is a fork of Maven somehow?
cally. So again, at least
tactically this feature closed gap between maven and gradle to such an extent
that future build system could be evaluated and planned without pressure.
Thank you
Aleks
On 2021/02/22 10:57:29, Michael Osipov wrote:
> Am 2021-02-22 um 05:37 schrieb Alexander Ashitkin
Hi Maven Dev
We would like to resume topic of incremental builds on Maven -
https://www.mail-archive.com/dev@maven.apache.org/msg119816.html
We’ve come a long way on Deutsche Bank side and currently few steps away from
contribution. At this point Deutsche Bank Open Source council asked for suppo
Totally disagree on the point. Writing java7 code after 8 makes you feel
suffering - because instead of expressive stream based operations and lambdas
you write pointless iterators and copy collections.
It is purely subjective opinion that lambdas make code less readable - at least
there is an
Totally support java 8. There is nothing to discuss here. Not sure everyone
realizes that, but it's 2019 already.
Regarding the new features:
1) as you mentioned the new model, i think it will be good to introduce simple
build graph balancing hints in the model. It is possible to examine critic
28:48, Martijn Dashorst wrote:
> 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 (cau
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
>
> 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 what's the
>
d be deployed, then
> > there is a strong reason to separate them in separate SCM repos.
> >
> > Then this separation concept will guide you to isolate the middle layers
> > into isolated services as JAR files. And then you endup with Microservices,
> > SOA services and
ase 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 what
09/14 08:48:00, Romain Manni-Bucau wrote:
> 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 r
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
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
27;t get me wrong, I admire your will to improve Maven ecosystem with this
> cool feature! Thank you for contribution your work. We will try to get the
> best
>
> Enrico
>
> Il sab 14 set 2019, 08:29 Laird Nelson ha scritto:
>
> > On Fri, Sep 13, 2019 at 11:0
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 tr
...@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
22 matches
Mail list logo
