I'm very glad you get some use out of reproducible builds. Especially given
the amount of work it seems to take (seems like ~1 out of every 3 emails is
about this). And you are right about my co-workers (pity me). But perhaps you
are not appreciating the scale of the problem. Maven is
Spoken just like someone who deals with people from high school in 2005.
I certainly care about reproducible builds - maybe not to the level of
some, but when working on projects that span multiple years, have multiple
deployments in different data centres for different customers, with
different
Sorry if my tone was too much. I tried to edit that out but apparently
failed. But perhaps you can appreciate the level of frustration people have
with Maven and its enthrallment with XML at this point.
Build systems should be declarative but the only real option for that is Maven
(in the
Hello,
Having includes in a format might be handy, but it does not fit the philosophy
of maven of having a repeatable declarative style. If you need such modularity
and imperative style you might be better off using gradle or simple pipeline
scripts.
(With derived published POMs and changes
Hi Robert ,
*Per the JDK 16 schedule , we are in Rampdown Phase One* *[1] .
*
*Please advise if you find any issues while testing the latest Early
Access builds.*
* Schedule for JDK 16
o *2020/12/10 Rampdown Phase One*
o 2021/01/14 Rampdown Phase Two
o 2021/02/04 Initial
JIRA issue (please kindly review):
https://issues.apache.org/jira/browse/MCOMPILER-445
Am So., 13. Dez. 2020 um 14:07 Uhr schrieb Benjamin Marwell <
bmarw...@apache.org>:
> > If is has proven itself for jlink, then we know we can do the same for
> all other tools.
>
> I tested my PR with a
> If is has proven itself for jlink, then we know we can do the same for
all other tools.
I tested my PR with a JavaFX app and it did work. But there's no release
yet, only the ITs and my test project. But adding a parameter to disable
the ToolProvider as a fallback should not be a problem.
A
Hi Markus
i agree surefire dependency upgrade to 2.22.0 was necessary
i generally steer clear of untested snapshot(s) so your refactor of aether to
non-snapshot makes sense
the last person to touch AbstractDependencyMojoTestCase.java for 3.1.3 was
elliot ..at least that is what github reports
Yes, that makes a lot of sense. If is has proven itself for jlink, then we know
we can do the same for all other tools.
If we have a good feeling about the implementation, we could use it at
reference for other plugins as some kind of pattern.
Robert
On 13-12-2020 11:39:02, Benjamin Marwell
Il Dom 13 Dic 2020, 11:38 Benjamin Marwell ha scritto:
> Robert already suggested to use ToolProvider for the JDK9+ builds. I
> created such a patch for jlink and I could create s similar one for the
> compiler and javadoc plugin. This would solve the underlying problem from
> my understanding.
sure, give me sign when you're ready
On 13-12-2020 10:52:16, Michael Osipov wrote:
Can your hold off for few more days? I'd like to run all ITs on my BSD
box, maybe it will uncover something. I am currently overloaded with the
likely upcoming hard lockdown here.
M
Am 2020-12-12 um 16:22 schrieb
Robert already suggested to use ToolProvider for the JDK9+ builds. I
created such a patch for jlink and I could create s similar one for the
compiler and javadoc plugin. This would solve the underlying problem from
my understanding.
As fork mode and fork count would not apply, I would suggest
Can your hold off for few more days? I'd like to run all ITs on my BSD
box, maybe it will uncover something. I am currently overloaded with the
likely upcoming hard lockdown here.
M
Am 2020-12-12 um 16:22 schrieb Robert Scholte:
If there are no objections, I'll merge this probably Monday
Martin,
you are awesone! Thanks a lot for your kind help! While I have decades of
experience with Java, I have no clue what that legacy maven source code all
is about.
Unfortunately your POM
(https://github.com/apache/maven-dependency-plugin/pull/109/commits/7ad683ec
14 matches
Mail list logo
