copy-dependencies goal as stated in the docs:
"Goal that copies the project dependencies from the repository to a
defined location."
it copies as stated...
The question is what you expect to be copied and furthermore the the
more important question: Why do you need to copy those parts?
explanation -- it is much appreciated. (as well as
the suggestion to bump up the logging on Maven to find the details on what
is being fetched).
>
> On Wed, Jun 26, 2024 at 11:11 AM Karl Heinz Marbaise
> wrote:
>
> > Hi,
> >
> > On 26.06.24 03:51, Robert Turner wro
On Wed, Jun 26, 2024 at 5:12 AM Karl Heinz Marbaise
wrote:
> Hi,
>
> On 26.06.24 03:51, Robert Turner wrote:
> > On Tue, Jun 25, 2024 at 8:36 PM Karl Heinz Marbaise
> > wrote:
> >
> >> Hi,
> >>
> >> I'm not sure if I understand your p
On Wed, Jun 26, 2024 at 1:36 AM Nils Breunese wrote:
> Robert Turner wrote:
>
> > The "problem" is not that the old log4j gets copied to the output folder,
> > it's that it is fetched into the local Maven cache / repository, which is
> > then picked up by security tooling (which of course compla
arl Heinz Marbaise
wrote:
> Hi,
>
> On 26.06.24 03:51, Robert Turner wrote:
> > On Tue, Jun 25, 2024 at 8:36 PM Karl Heinz Marbaise
> > wrote:
> >
> >> Hi,
> >>
> >> I'm not sure if I understand your problem correct, because based on the
>
Hi,
On 26.06.24 03:51, Robert Turner wrote:
On Tue, Jun 25, 2024 at 8:36 PM Karl Heinz Marbaise
wrote:
Hi,
I'm not sure if I understand your problem correct, because based on the
copy-dependencies goal as stated in the docs:
"Goal that copies the project dependencies from the rep
Robert Turner wrote:
> The "problem" is not that the old log4j gets copied to the output folder,
> it's that it is fetched into the local Maven cache / repository, which is
> then picked up by security tooling (which of course complains that it is
> ancient and has vulnerabilities).
There is no
On Tue, Jun 25, 2024 at 9:51 PM Robert Turner wrote:
>
> On Tue, Jun 25, 2024 at 8:36 PM Karl Heinz Marbaise
> wrote:
>
>> Hi,
>>
>> I'm not sure if I understand your problem correct, because based on the
>> copy-dependencies goal as stated in the
On Tue, Jun 25, 2024 at 8:36 PM Karl Heinz Marbaise
wrote:
> Hi,
>
> I'm not sure if I understand your problem correct, because based on the
> copy-dependencies goal as stated in the docs:
>
> "Goal that copies the project dependencies from the repository to a
> d
Hi,
I'm not sure if I understand your problem correct, because based on the
copy-dependencies goal as stated in the docs:
"Goal that copies the project dependencies from the repository to a
defined location."
it copies as stated...
The question is what you expect to be copied
e [1] is
"maven-javadoc-plugin" (which likely needs some updates of dependencies,
etc, in particular maven-reporting- which seem to be the ones that are
older).
During our build process, "maven-dependency-plugin" is used with the goal
"copy-dependencies" to copy runt
a shaded artifact, then the metadata should said that the
> dependencies have been transformed that way. For modular dependencies,
> shading the artifact has major impacts: it breaks modules encapsulation,
> potentially creating security holes that did not existed in the original
> librar
adata should said that the
dependencies have been transformed that way. For modular dependencies,
shading the artifact has major impacts: it breaks modules encapsulation,
potentially creating security holes that did not existed in the original
libraries. For non-modular dependencies, the impact
Hi Lars,
On Mon, 13 May 2024 at 17:46, Lars Francke wrote:
> The problem is that SBOM tools have no realistic chance to gather that
> information if all they have is a final artifact and the POMs that
> were published as is the case here.
An increasing number of Maven artifacts publish CycloneDX
;
> Hello Lars,
>
> ignoring your second email, I felt like it is normal for the pom to ignore
> the shaded dependencies. This is how Maven works.
> For me, it should be the job of a SBOM (CycloneDX format or SPDX for
> exemple) to keep the information of what the shaded jar contain
Hello Lars,
ignoring your second email, I felt like it is normal for the pom to ignore
the shaded dependencies. This is how Maven works.
For me, it should be the job of a SBOM (CycloneDX format or SPDX for
exemple) to keep the information of what the shaded jar contains.
This is the role of SBOMs
>
>
> org.apache.htrace
> htrace-core4
>
>
> HTrace in version 4.2.0-incubating has a dependency on
> jackson-databind 2.4.0[1, 2] but it also uses the shade plugin to
> relocate all of its dependencies[3].
> The published POM of HTrace contains n
in version 4.2.0-incubating has a dependency on
jackson-databind 2.4.0[1, 2] but it also uses the shade plugin to
relocate all of its dependencies[3].
The published POM of HTrace contains no trace of these dependencies[4].
A vulnerability scanner like Trivy[5] does find the code via the
META-INF/maven/
Thank you very much, Alexander! It solved the issue!
Toshiya
On Thu, Mar 28, 2024 at 4:53 PM Alexander Kriegisch <
alexan...@kriegisch.name> wrote:
> Shade needs an original sources JAR as input for 'createSourcesJar'. Make
> sure to add Maven Source Plugin to your build and put it above Shade i
Shade needs an original sources JAR as input for 'createSourcesJar'. Make sure
to add Maven Source Plugin to your build and put it above Shade in the
'plugins' section to ensure that both of them are exeuted in the correct order
during the 'package' phase.
org.apache.maven.plugins
maven-so
Hello,
I use maven-shade-plugin to create an uber jar and its source jar with
.
https://github.com/tkobayas/shade-test/blob/main/pom.xml
```
org.apache.maven.plugins
maven-shade-plugin
3.5.2
source-jar
shade
The documentation for publishing to Central is very comprehensive. I
suggest you take a closer look. Specifically
https://central.sonatype.org/register/central-portal/
https://central.sonatype.org/publish/producer-terms/
https://repo1.maven.org/terms.html
And maybe contact a lawyer and Sonaty
Fri, 1 Mar 2024, /Olivier Lamy/:
users will not be able to rebuild from sources.
is it a requirement? No real idea as already said in this thread, you
need to ask Sonatype.
But it breaks the concept of opensource as you cannot build from the sources :)
The sources uploaded to Maven Central a
gin
> > > plugin-dep
> > > 42.4.2
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Feb 29, 2024 at 1:33 PM Tamás Cservenák
> > > wrote:
> > >
> > > > Howdy,
t; On Thu, Feb 29, 2024 at 1:33 PM Tamás Cservenák
> > wrote:
> >
> > > Howdy,
> > >
> > > You would need to ask Sonatype about that, and check here:
> > > https://central.sonatype.org/publish/requirements/
> > >
> > > IMHO best to ask them about
that, and check here:
> > https://central.sonatype.org/publish/requirements/
> >
> > IMHO best to ask them about it: IIUC you want to deploy artifacts to
> > central that has dependencies not available from Central
> > (nor any other public repository?)
> >
> > Thank
o ask Sonatype about that, and check here:
> > https://central.sonatype.org/publish/requirements/
> >
> > IMHO best to ask them about it: IIUC you want to deploy artifacts to
> > central that has dependencies not available from Central
> > (nor any other public repositor
ed to ask Sonatype about that, and check here:
> https://central.sonatype.org/publish/requirements/
>
> IMHO best to ask them about it: IIUC you want to deploy artifacts to
> central that has dependencies not available from Central
> (nor any other public repository?)
>
> Thanks
> T
Howdy,
You would need to ask Sonatype about that, and check here:
https://central.sonatype.org/publish/requirements/
IMHO best to ask them about it: IIUC you want to deploy artifacts to
central that has dependencies not available from Central
(nor any other public repository?)
Thanks
T
On
e for regular dependencies and plugins, but
I'm not 100% sure about plugin dependencies in particular (although I would
guess it's the same).
Any input would be appreciated,
Best regards,
Florent
odule build - and therefore module A will not be in the reactor. This
> is
> > > why the m2 repo will always be used for module A in this scenario.
> > >
> > > Joe
> > >
> > > -Original Message-
> > > From: Siddharth Jain
> >
; > why the m2 repo will always be used for module A in this scenario.
> >
> > Joe
> >
> > -Original Message-
> > From: Siddharth Jain
> > Sent: Thursday, February 15, 2024 7:50 PM
> > To: Maven Users List
> > Subject: Re: How does maven resol
Maven Users List
> Subject: Re: How does maven resolve inter-module dependencies in a
> multi-module build?
>
> External Email: Please be vigilant and check the contents and source for
> signs of malicious activity.
>
> thanks Joe. but then if classes are available both in the tar
reactor. This is why
the m2 repo will always be used for module A in this scenario.
Joe
-Original Message-
From: Siddharth Jain
Sent: Thursday, February 15, 2024 7:50 PM
To: Maven Users List
Subject: Re: How does maven resolve inter-module dependencies in a multi-module
build
otice that I can run mvn compile from the root directory
> and
> > it will build the 3 projects. The projects may have inter-dependencies
> > e.g., B depends on A and let's say C depends on both A and B.
> >
> > My question is while building B how does maven locat
ning 3 sub-projects A, B, C and a parent pom defined in the root
> directory. I notice that I can run mvn compile from the root directory and
> it will build the 3 projects. The projects may have inter-dependencies
> e.g., B depends on A and let's say C depends on both A and B.
>
>
Hello,
I am working on a multi-module Maven build. e.g., I have a root directory
containing 3 sub-projects A, B, C and a parent pom defined in the root
directory. I notice that I can run mvn compile from the root directory and
it will build the 3 projects. The projects may have inter-dependencies
On Wednesday, 31. January 2024, 16:34:22 CET Mansour Al Akeel wrote:
> We have a large number of legacy dependencies that we need to sign. I am
> trying to cache those that are not signed into an internal repository to
> reduce build time.
>
> So I created another project to sig
We have a large number of legacy dependencies that we need to sign. I am
trying to cache those that are not signed into an internal repository to
reduce build time.
So I created another project to sign them and load them into our private
repository. I am using a classifier to indicate the signed
On 15.12.23 18:01, David Hoffer wrote:
Is it possible to configure maven-checkstyle-plugin to use one of the
project's modules as the source of the checkstyle XML file?
E.g. I have the plugin configured like this:
org.apache.maven.plugins
maven-checkstyle-plugin
${maven-checksty
Op 15-12-2023 om 18:01 schreef David Hoffer:
Is it possible to configure maven-checkstyle-plugin to use one of the
project's modules as the source of the checkstyle XML file?
E.g. I have the plugin configured like this:
org.apache.maven.plugins
maven-checkstyle-plugin
${maven-ch
Is it possible to configure maven-checkstyle-plugin to use one of the
project's modules as the source of the checkstyle XML file?
E.g. I have the plugin configured like this:
org.apache.maven.plugins
maven-checkstyle-plugin
${maven-checkstyle-plugin.version}
dependency management, along with the POM it comes from—even
with line numbers. Nice!
And (drumroll …) it looks like
`biz.aQute.bnd:biz.aQute.bnd.annotation:6.4.1` is coming from
`org.apache.logging:logging-parent:10.1.1`.
And `org.mockito:mockito-inline:4.8.1` was getting in because one of my
own de
In my Maven project (an aggregate project with child projects) I issue
> the following command for the Versions Maven Plugin:
>
> mvn versions:display-dependency-updates
>
> There are a couple of outdated dependencies I'm not sure where are
> coming from:
>
> [
ntegrated?
>
> Garret
>
> > On Thu, Nov 9, 2023 at 9:04 PM Garret Wilson
> > wrote:
> >
> >> In my Maven project (an aggregate project with child projects) I issue
> >> the following command for the Versions Maven Plugin:
> >>
> >
ov 9, 2023 at 9:04 PM Garret Wilson
wrote:
In my Maven project (an aggregate project with child projects) I issue
the following command for the Versions Maven Plugin:
mvn versions:display-dependency-updates
There are a couple of outdated dependencies I'm not sure where are
comi
Plugin:
>
> mvn versions:display-dependency-updates
>
> There are a couple of outdated dependencies I'm not sure where are
> coming from:
>
> [INFO] The following dependencies in Dependency Management have newer
> versions:
> [INFO] biz.aQute.bnd:biz.aQute
In my Maven project (an aggregate project with child projects) I issue
the following command for the Versions Maven Plugin:
mvn versions:display-dependency-updates
There are a couple of outdated dependencies I'm not sure where are
coming from:
[INFO] The following dependenci
Hello Siddharth
Le 2023-10-13 à 00 h 02, Siddharth Jain a écrit :
IIUC, this is a separate issue. At minimum we need to make the
behavior of compile vs. testCompile consistent. Currently it is not.
Understood, but what I think is the common point is that Maven currently
uses heuristic rules
s put in its
own module and namespace (package name) with dependencies on the main
module and junit etc.
>
>
> > I see during the test-compile phase the plugin is putting all the
> > dependencies on the module-path whereas during the main compilation it
> > only puts those
is to
duplicate the module-info.java file in the test directory [1], but this
is not the only way.
I see during the test-compile phase the plugin is putting all the
dependencies on the module-path whereas during the main compilation it
only puts those dependencies on the module-path that are
the plugin is putting all the dependencies on the
module-path whereas during the main compilation it only puts those
dependencies on the module-path that are declared in module-info.java; the
rest are on the classpath (which is the correct behavior). I am using
latest version of the plugin 3.11.0
I have a legacy project that requires many third party dependencies. Those
dependencies need to be signed. The resulting dependencies along with the
swing project, are to be served through a JNLP file. The fact that we need
to resign all these dependencies with every build, adds a lot of overhead
Wed, 4 Oct 2023 15:52:14 +, /Joseph Kesselman/:
My only other real gripe with Maven at the moment is that I haven't
yet found a way to tell the javadoc plugin "Yes, I know there's lots
that can be improved, but for now please consider that a Warning
rather than an Error."
If I'm not mist
Oh. Duh.
com.sun
tools
1.6.0
system
${toolsjar}
On 10/3/2023 10:04 PM, Alexander Kriegisch wrote:
Hi Joseph.
I think you uncovered a bug in Maven Javadoc Plugin. I just created
https://issues.apache.org/jira/browse/MJAVADOC-775 on your be
657/
() Plaintext Ribbon Campaign
/\ Stamp out HTML mail!
From: Alexander Kriegisch
Sent: Tuesday, October 3, 2023 10:04:33 PM
To: users@maven.apache.org
Subject: Re: "First time caller..." javadoc taglet dependencies?
Hi Joseph.
I think you uncover
Hi Joseph.
I think you uncovered a bug in Maven Javadoc Plugin. I just created
https://issues.apache.org/jira/browse/MJAVADOC-775 on your behalf.
As a workaround for the non-functioning 'tagletpath' option, I recommend
to separately publish the taglet library as a Maven artifact, which then
you c
Hi, folks. I'm in the process of trying to port the Apache Xalan build
from Ant to Maven. It's close to usable, but I'm still struggling with a
few odd corners.
One of the odder corners: The Xalan documentation uses a javadoc taglet,
@xsl.usage, to indicate whether a method is intended only fo
t-wins, exclusions, scope filtering, etc)
> * artifacts are resolved ("resolve" step), basically each artifact at the
> end points to one File in local repo
> * the graph is being transformed into List (or directly into
> List)
>
> So far we can see that the graph is somewh
est-wins, exclusions, scope filtering, etc)
* artifacts are resolved ("resolve" step), basically each artifact at the
end points to one File in local repo
* the graph is being transformed into List (or directly into
List)
So far we can see that the graph is somewhat affected by ordering i
e of our transient dependencies has a conflict
> with another transient dependency, as it has several FQCNs that are
> identical to ones in the second artifact, but with different content. In
> most of those services, the first artifact ended up in the classpath after
> the second artifact,
I support a large number of SpringBoot services built with Maven.
I recently noticed that one of our transient dependencies has a conflict
with another transient dependency, as it has several FQCNs that are
identical to ones in the second artifact, but with different content. In
most of those
cü a écrit :
> Hello,
>
> Is it considered good practice to reference optional dependencies in BOM
> files?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
I would say yes.
My reasoning: BOM is bill of materials, ANY materials potentially needed
for a library.
Otoh, optional dependencies have to be explicitly listed by consumers (POM
consuming your library).
Hence, you will help your consumer by giving them predefined version to
use, IF they
Hi, Ceki.
My understanding is that, yes, if they are part of the main library
(i.e. not transitive dependencies from some other library), then they
should also be included in the BOM.
The BOM is usually imported under the `` section,
which is simply the place where you are managing which
On 6/17/2023 9:32 PM, Ceki Gülcü wrote:
>
> Hello,
>
> Is it considered good practice to reference optional dependencies in BOM
> files?
My question is probably silly as BOM files are reserved for declaring
artifacts a project builds itself and not for dependencies, option
Hello,
Is it considered good practice to reference optional dependencies in BOM
files?
--
Ceki Gülcü
Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
-
To unsubscribe, e-mail: users-unsubscr
ou
want the Maven version without running a build.
> (1) IntelliJ is caching the JARs it uses for a project somewhere. And giving
> it the commands to reload dependencies or the POM fail if the version number
> has not changed... since I am seeing a file from January. Also, the Intelli
g and deleted everything
> > from there.
> >
> > - Then I rebuilt in order. This included app1 and app2 (that has app1
> > as one of its dependencies) which showed up in the local repository
> > folder. Obviously, both generated snapshot jars had a timestamp of
> &
l maven repository of every single one of my
> projects, literally went in the folder net/myorg and deleted everything
> from there.
>
> - Then I rebuilt in order. This included app1 and app2 (that has app1
> as one of its dependencies) which showed up in the local repository
>
e of its dependencies) which showed up in the local repository
folder. Obviously, both generated snapshot jars had a timestamp of
yesterday.
- Finally I opened app2-0.0.1-SNAPSHOT.jar and looked for the included
app1-0.0.1-SNAPSHOT.jar file. I expected to see yesterday's timestamp
on the JAR fil
the current latest release [0].
To avoid having to manually update dependencies my team has a scheduled task to
run Renovate [1] in our applications' CI pipelines to check for dependency
updates. Renovate automatically creates a branch and a merge request whenever a
dependency update is
I apologize for the length of this email, I could not think of a shorter
way to present the issue/questions that is clear enough.
---
My environment involves the usual many open source dependencies (which I
control by specifying the versions to use in a master POM), but also a
large number
> The aim is not to include Jackson and other classes from transitive
> dependencies of Avro but that the pom file for the new jar would include
> the transitive dependencies from Avro.
>
> My PR is at https://github.com/apache/hadoop-thirdparty/pull/21
>
> Neither the pom.xml nor t
x27;m looking to shade Apache Avro jar, relocating the
> avro classes to a new package name.
> This new jar would be published to Maven Central and used by Hadoop.
> The aim is not to include Jackson and other classes from transitive
> dependencies of Avro but that the pom file f
The aim is not to include Jackson and other classes from transitive
dependencies of Avro but that the pom file for the new jar would include the
transitive dependencies from Avro.
My PR is at https://github.com/apache/hadoop-thirdparty/pull/21
Neither the pom.xml nor the dependency-reduced-pom.xm
Hello,
*Here's the background to my problem: *
Ive created an open source library for automating salesforce tests (
www.testzeus.com) and packaged it as a maven jar (
https://ossindex.sonatype.org/component/pkg:maven/com.testzeus/Test_Zeus@1.0.1)
.
*Here's the problem statement : *
When a user tr
> I do not understand what you are trying to explain here.
Sorry I was not clear at all ! I was trying to say that in a multimodule
build, if you have a module shaded with the shade plugin, my rule of thumb
is to NEVER have another module listing this shaded module in its
dependencies.
S
Hi,
On Fri, Jul 8, 2022 at 5:43 PM Francois Marot
wrote:
> I believe you used the shade maven plugin or equivalent.
Yes
> I faced this
> problem multiple times and to my knowledge, there is no "good" solution.
>
I was afraid of that.
> The problem is that Maven computes the dependency gra
t; > code) and add-reads (essentially replacing the additional
> > "requires")
> >
> >
> > On 7/2/22, 4:46 PM, "Stanimir Stamenkov"
> wrote:
> >
> > I can'
Hi,
If I set these dependencies to 'provided' I have not been able to ensure
they are actually inserted (and relocated) into the final shaded jar file.
Niels
On Fri, Jul 8, 2022 at 6:36 PM Jörg Schaible wrote:
> Hi,
>
> simply declare the dependency with scope "provi
module MUST NOT depend onto a
> shaded module. They must be considered as 'final' modules.
>
> I hope this may help
> François
>
>
> *- - - - -François Marot06 50 91 96 38*
>
> Le ven. 8 juil. 2022 à 16:51, Niels Basjes a écrit :
> > Hi,
> >
> > I
> I have a library project that uses dependencies that are prone to cause
> conflicts when another project wants to use my software.
> Antlr4 is a common example because it enforces the versions of the
> generated code and the runtime to be an exact match.
>
> In my maven project
Hi,
I have a library project that uses dependencies that are prone to cause
conflicts when another project wants to use my software.
Antlr4 is a common example because it enforces the versions of the
generated code and the runtime to be an exact match.
In my maven project I have a main library
y replacing the additional
"requires")
On 7/2/22, 4:46 PM, "Stanimir Stamenkov" wrote:
I can't figure out what's the best practice or just proper way for
setting up a JPMS Maven project with test sources that have additional
Java SE mod
7/2/22, 4:46 PM, "Stanimir Stamenkov" wrote:
I can't figure out what's the best practice or just proper way for
setting up a JPMS Maven project with test sources that have additional
Java SE module dependencies to those of the main sources.
I have th
I can't figure out what's the best practice or just proper way for
setting up a JPMS Maven project with test sources that have additional
Java SE module dependencies to those of the main sources.
I have the following basic project structure:
pom.xml
src/
├─ main/
On Sun, Jun 26, 2022 at 9:49 AM Alexander Kriegisch <
alexan...@kriegisch.name> wrote:
>
> Firstly, you are not crerating a test JAR but a regular JAR with
> application classes, so of course test-scoped dependencies like JUnit
> are not going to be contained in the uber
> I get a build success, but when I inspect the generated jar, I don’t
> see the junit classes
Firstly, you are not crerating a test JAR but a regular JAR with
application classes, so of course test-scoped dependencies like JUnit
are not going to be contained in the uber JAR.
Secondly, y
I am trying to use maven-shade-plugin for the first time to create an uber-jar
and I can’t even get the simplest example to work.
For example, I created a simple pom based on the example at the top of this
page:
https://maven.apache.org/plugins/maven-shade-plugin/examples/includes-excludes.
ould be done"
with Maven, I just told you what my own practice is.
And my suggestion was more about logically separating things, for
extensions is a must (technical reasons), while for "annotation case" is as
you correctly see: dependencies from plugin configurations are "no
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
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
"project".
You're suggesting that I should manage those "helpers" as a separate
project with its own release cycle, and deploy the artifacts to a repo for
consumption by the "real" project.
What about cases where you want to test-drive a change with a "real"
pr
me before 'whatever') *and* you'll have to explicitly include
>> 'processor' in your project list: 'mvn -pl whatever -am verify' won't
>> build
>> 'processor', you have to use 'mvn -pl processor,whatever -am verify'. I
&g
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
gt; declaration order by default, when there's no dependency between modules,
> and then the maven-compiler-plugin happens to be able to resolve
> 'processor' from the reactor build; change the order are declared
> and *kaboom*; in the end it does work only "by accide
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
from the reactor build; change the order are declared
and *kaboom*; in the end it does work only "by accident" (or "by chance" if
you prefer).
I wouldn't say the maven-compiler-plugin is "broken", it's just another
Maven limitation: it has no way of knowing t
cific
> > > module.
> > > Maven CLI will basically complain that it cannot resolve the module
> > needed
> > > by the plugin and fail, even if I explicitly list that module in the
> > > project list.
> > >
> > > That occurs both
1 - 100 of 6225 matches
Mail list logo
