Hi Karl,
Thank you for the suggestion to use maven-shade/maven-assembly-plugin(s).
I was planning to use them, but haven't gotten around to them yet. I was hung
up on the checkout/build thing. :- Maybe on Tuesday.
The libraries are in 7 modules to manage the development cycle, specifically
Hi Gary,
On 24.03.19 17:55, ga...@oedata.com wrote:
Hi Nick,
Thanks for the questions, I'll try to explain.
The parent pom aggregates a library (jar) from different and sometimes
interdependent modules. The parent pom checks out the module sources with the
poms and compiles them into a
Hi Thomas,
thanks for that info ... I had totally forgotten the prepare-package phase ...
of course using this would reduce a lot of problems.
I changed our build accordingly. I guess if someone does a "mvn
prepare-package" ... well I guess then he's just looking for trouble ;-)
Chris
Am
Rule of thumb: in a react build, don't ever use any lifecycle phase prior
to package, and if you want to skip tests, use -DskipTests or
-Dmaven.test.skip. Corollary: stick with "package" and "verify" (I consider
"mvn install" is an anti-pattern).
BTW, as another rule of thumb, use "processClasses"
Hi Nick,
Thanks for the questions, I'll try to explain.
The parent pom aggregates a library (jar) from different and sometimes
interdependent modules. The parent pom checks out the module sources with the
poms and compiles them into a single jar.
I was using the modules pattern in in the
You can arbitrarily switch to other tags and branches with submodules.
It is just a simple `git checkout X` from the submodule's directory.
-Kyle
On 3/24/19 9:51 AM, ga...@oedata.com wrote:
> Hi Nick,
>
> Thank you for that suggestion. That was also suggested on stackoverflow by
> Karl. That
Hi Nick,
Thank you for that suggestion. That was also suggested on stackoverflow by
Karl. That method is better suited for static-ish configurations. I need a
BOM type system where I can dynamically switch between tags and branches for
different modules, much like clear case. I'll be moving
Gary,
Having modules residing in other repositories is not a problem...
...but why do they not have a pom.xml ?
...Is the POM on a different branch ?
...Are the modules using ANT or gradle instead ?
...Are you auto-generating POMs ?
Like, I'm really scratching my head trying to figure out what
Hi Maxim,
unfortunately that doesn't help.
The problem is that if we do a "mvn compile" no archiving (jar/war building) is
done at all ...
Guess what we would need, would be profiles based on the last maven phase being
built.
So if:
- "last phase < package" --> Copy the content without
