Hello Florent,
I have had this problem a few years ago, and from what I can remember it is
the expected behavior. Or at least this is the way it is right now.
Sorry, It is from memory and I do not have any link to share nor
explanation about it, but at least you know you are not alone !
Regards
Florent,
Not directly related to your question, but reading your mail caught
my attention one sentence.
Can you shed some light on why "... but I'm trying to get rid of the need
for `mvn install` entirely."?
Thanks
Tamas
On Thu, May 5, 2022 at 3:11 PM Florent Biville
wrote:
> Hello everyone,
>
Because it is an antipattern?
https://www.cloudbees.com/blog/maven-and-install-hack
If you do rely on "mvn install", which one of your commit is your snapshot
in your local repository from? How can you tell? And it gets worse if you
deploy snapshots to a repository, as now it could also be from so
Florent,
created response on reproducer
https://github.com/fbiville/mvn-plugin-dependency-reactor-issue/issues/1
HTH
T
On Thu, May 5, 2022 at 3:11 PM Florent Biville
wrote:
> Hello everyone,
>
> TL;DR? https://github.com/fbiville/mvn-plugin-dependency-reactor-issue
>
> I recently noticed that,
Hm,
By reading this blog entry from 2012 (!), I see it summarizes nicely at the
end:
* You may be using some broken plugins that you will need to fix, or
replace.
* You may be battling a circular dependency hell (which was why you used
dependency:copy in the first place) which indicates a bad buil
IMHO the antipattern here is the idea that "mvn install" is bad.
But let's take it step by step. For simplicity sake, let's ignore remote
deploys/downloads for now.
Also, let's assume a developer workstation for the same reason (simplicity).
Q: which one of your commit is your snapshot in your lo
On Thu, May 5, 2022 at 10:16 PM Tamás Cservenák wrote:
> Hm,
>
> By reading this blog entry from 2012 (!), I see it summarizes nicely at the
> end:
> * You may be using some broken plugins that you will need to fix, or
> replace.
> * You may be battling a circular dependency hell (which was why y
On Thu, May 5, 2022 at 10:22 PM Tamás Cservenák wrote:
> IMHO the antipattern here is the idea that "mvn install" is bad.
>
> But let's take it step by step. For simplicity sake, let's ignore remote
> deploys/downloads for now.
> Also, let's assume a developer workstation for the same reason
> (s
Howdy,
a lot to unravel here...
But let me start first with the obvious: I believe you are quite
experienced, and I'd bet you did not start with Maven3, but most probably
Maven2 or even Maven1 :) The reason why I mention this, is that you use
terms from the "Maven2 era", like "reactor". Maven2 ha
Howdy,
no, not my memory, I rely on my "daily routine": I use Maven Repository
Manager, I regularly nuke my local repo, regularly execute `git clean -fdx`
on my checkout, and on checkout/branch change regularly do "quick-build"
`mvn clean install` (usually `mvn clean install -Dtest=void`) as very
Hm, I need to look more into MCOMPILER-496, as I found a m-compiler-p IT
that does exactly what Thomas described:
https://github.com/apache/maven-compiler-plugin/tree/master/src/it/MCOMPILER-203-processorpath
3 module multi module build:
- an annotation processor
- a verifier plugin
- a "user" mod
On Fri, May 6, 2022 at 12:06 PM Tamás Cservenák wrote:
> Howdy,
>
> a lot to unravel here...
>
> But let me start first with the obvious: I believe you are quite
> experienced, and I'd bet you did not start with Maven3, but most probably
> Maven2 or even Maven1 :) The reason why I mention this, i
On Fri, May 6, 2022 at 1:24 PM Tamás Cservenák wrote:
> Hm, I need to look more into MCOMPILER-496, as I found a m-compiler-p IT
> that does exactly what Thomas described:
>
> https://github.com/apache/maven-compiler-plugin/tree/master/src/it/MCOMPILER-203-processorpath
>
> 3 module multi module
On Fri, May 6, 2022 at 12:29 PM Tamás Cservenák wrote:
> Howdy,
>
> no, not my memory, I rely on my "daily routine": I use Maven Repository
> Manager, I regularly nuke my local repo, regularly execute `git clean -fdx`
> on my checkout, and on checkout/branch change regularly do "quick-build"
> `m
Howdy,
On Fri, May 6, 2022 at 4:01 PM Thomas Broyer wrote:
> Fwiw, my "daily routine" with That Other Build Tool is to just ask it to
> build and let it handle everything for me: never need to clean (through git
> clean or the clean task), never need to nuke my local cache because it
> really on
15 matches
Mail list logo
