Re: Releasing a multi-module project to Maven Central?

[Thomas Broyer]

Shouldn't you use the jar-no-fork *goal* of the maven-source-plugin? Using
that value as execution id does nothing special.

BTW, did you read https://central.sonatype.org/publish/publish-maven/ ?

(No idea if any of this would solve your problem though)

Le jeu. 21 déc. 2023, 03:15, Laird Nelson  a écrit :

> On Wed, Dec 20, 2023 at 5:45 PM Laird Nelson  wrote:
>
> > That is, when I tell the maven-release-plugin to activate the
> "deployment"
> > profile (via the releaseProfiles user property), I am told that the
> source
> > plugin has been invoked twice, and the build fails.
> >
>
> I think this is because the maven-javadoc-plugin's jar goal invokes the
> lifecycle, which of course contains the maven-source-plugin's jar-no-fork
> goal, which attaches the source jar. How would I make this work?
>
> Best,
> Laird
>
> >
>

Re: maven debugging frustrations

[Thomas Broyer]

In `mvn -X` you should find the arguments to javac (beware that empty
arguments are not displayed there, rather than being shown as "" for
instance), which would allow you to run javac on your own, taking Maven out
of the equation.

Le mar. 19 déc. 2023, 23:28,  a
écrit :

> Indeed, if there were ACTUAL error messages from the java compiler, this
> would be far less mysterious :)
> The trouble is that there are NOT any error messages coming from the Java
> compiler.
> There are a few warnings (from javac), followed soon after by "Compilation
> failure" (from maven, NOT from javac)
> I do not recommend feeling my maven-based pain :)
> But if you happen to know where to get some pain relief, I'd love to know
>
> -Original Message-
> From: Tomo Suzuki 
> Sent: Tuesday, December 19, 2023 5:18 PM
> To: Maven Users List 
> Subject: Re: maven debugging frustrations
>
>
> CAUTION: This email originated from outside our organisation -
> suzt...@google.com.INVALID Do not click on links, open attachments, or
> respond unless you recognize the sender and can validate the content is
> safe.
> What’s the exact error messages?
>
> (Maybe I’m too old to feel your pain)  If you use Java, you need to know
> what compilation means (converting Java code to Java bytecode). Your Maven
> invocation was telling it was failing due to some error messages.
>
> On Tue, Dec 19, 2023 at 16:57 
> wrote:
>
> > When my Java code does something I didn't expect, I can run it under a
> > debugger and step through it line by line until things make sense again.
> > When maven does something I didn't expect, my debugging strategy is
> > usually more like "try to think of something in my bag of tricks".
> > Sometimes I suddenly have an epiphany and I realize "oh, it must have
> > broken because of that thing I changed".
> > But in the absence of epiphanies, I don't have any good ways to ask
> > maven to tell me what on earth is going on.
> >
> > Example from today: some is failing on our build server with
> > "Compilation failure".
> > Looking at the build log, there are no compiler errors in sight.
> > There are a few compiler warnings, and those seem to logged twice:
> > once at warning level, and then again at error level.
> > It only fails on SOME (not all) of our build configs, even though our
> > configs are pretty darn similar to each other.
> >
> > So I'm left flailing around more or less at random (try compiling on a
> > different server!  Try copying the command line flags from the one
> > that work!  Etc.) What I actually want is for maven to give me some
> > CRUMB of visibility into what on earth is going wrong.
> >
> > I don't even know what "Compilation failure" actually means.
> > Did some process exit with non-zero status?
> > Did the process fail to launch in the first place?
> > Maybe there is no extra process, and the compilation is taking place
> > in the same JVM that's running maven?
> > If so, what went wrong?  Did an exception get thrown?  Something else?
> >
> > You get the idea.
> >
> >
> > This message is for information purposes only. It is not a
> > recommendation, advice, offer or solicitation to buy or sell a product
> > or service, nor an official confirmation of any transaction. It is
> > directed at persons who are professionals and is intended for the
> > recipient(s) only. It is not directed at retail customers. This message
> is subject to the terms at:
> >
> https://clicktime.symantec.com/15sifLYAwPjLHCtCgybKg?h=ANvnaYG630AR0f2GLplpUfGbAsle9xaoL2f-FF_ESsU==https://www.cib.barclays/disclosures/web-and-email-disclaimer.html
> .
> >
> > For important disclosures, please see:
> > https://clicktime.symantec.com/15siaWLtUn3jsG4H9RCB4?h=M6FIGRVBH8G_LIh
> > m9t5V7SPthNcb5IVYLL7498zEnzg==https://www.cib.barclays/disclosures/s
> > ales-and-trading-disclaimer.html regarding marketing commentary from
> > Barclays Sales and/or Trading desks, who are active market
> > participants;
> > https://clicktime.symantec.com/15siL1m36vzxdRaWWjzjC?h=G7ajSU4AyuCbxlw
> > vIlksn83RCALP2_zHmu0XbnqwDpE==https://www.cib.barclays/disclosures/b
> > arclays-global-markets-disclosures.html
> > regarding our standard terms for Barclays Corporate and Investment
> > Bank where we trade with you in principal-to-principal wholesale
> > markets transactions; and in respect to Barclays Research, including
> > disclosures relating to specific issuers, see:
> https://clicktime.symantec.com/15siFBZkeKKNDUkayBbaa?h=G2aTqP2GUKb-ZJb3VDe2qGDqjn4glmlwiYEU-U9Qp08==http://publicresearch.barclays.com
> .
> > __
> > 
> >
> > If you are incorporated or operating in Australia, read these
> > important
> > disclosures:
> > https://clicktime.symantec.com/15siQqxKZYgZ3NQS4JPsp?h=_wyBE5fSRVnrjCX
> > _RdiyqX2Tzqlr_fF2jEBUkk9zsjg==https://www.cib.barclays/disclosures/i
> > mportant-disclosures-asia-pacific.html
> > .
> >
> > 

Re: what javac is actually used?

[Thomas Broyer]

Afaict, running with debug logs (mvn -X) will print the arguments passed to
the compiler, such that they can be passed to javac with Maven pushed out
if the equation.
They can then be inspected and tweaked, and then maven-compiler-plugin
configuration (hopefully) adjusted to what's expected.

Le lun. 4 déc. 2023, 03:58, Alexander Kriegisch 
a écrit :

> Interesting problem. I think, it would make sense to get a minimal
> reproducer project showcasing the differences in the generated byte
> code. Probably there is some way for javax.tools.JavaCompiler to create
> identical byte code by setting the right combination of options. If
> something is missing in the Maven Compiler options or mishandled in
> Plexus, that could then be added or fixed. Otherwise, someone could
> instruct the OP how to use the existing options to achieve what he
> wants. WDYT?
>
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Olivier Lamy schrieb am 04.12.2023 04:39 (GMT +07:00):
>
> > Hi,
> > If by javac you mean the cli, per default m-compiler-p is not using
> > exactly this but in the process javax.tools.JavaCompiler.
> > If you want to really use javac (and so forking the compilation) you
> > must configure it via the fork option
> > (
> https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#fork
> )
> >
> >
> > On Mon, 4 Dec 2023 at 07:07, Dave Dyer  wrote:
> >>
> >>
> >> >
> >> >Maven, by default uses maven-compiler-plugin, but that plugin itself is
> >> >pluggable (can use javac, which is default, but also eclipse compiler,
> etc).
> >> >The plugin by default uses javac.
> >>
> >> The build I'm using seems to not be using javac - where is guidance
> >> to configuring it?
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: [ANN] Maven Surefire 3.2.1 released

[Thomas Broyer]

This is using plexus-xml 4.0.0 (from Parent 40). Shouldn't that be
downgraded to 3.0.0?
(
https://github.com/apache/maven-parent/commit/096de2d1f79a1b692a112db16675ecc2ac013597
says 4.0.0 is not compatible with Maven 3; maybe a Parent 41 should have
been released after that commit?)

Fwiw, I have a plugin that depends on surefire-common (maybe it shouldn't
but that's another story) and this brings maven-xml-impl et al. that are
flagged as not being in the correct scope (brought in as "compile", should
be "provided"). My tests pass with that version, but I've explicitly
downgraded to 3.0.0 (upgraded plexus-utils to 4.0.0 and added dependency on
plexus-xml 3.0.0) and tests still pass, so I think I'm going to go with
that.

On Mon, Oct 23, 2023 at 10:00 PM Michael Osipov  wrote:

> The Apache Maven team is pleased to announce the release of the Maven
> Surefire version 3.2.1.
>
> https://maven.apache.org/surefire/
>
>
> Release Notes - Maven Surefire - Version 3.2.1
>
> ** Bug
>  * [SUREFIRE-2190] - optional dependencies and JPMS modules confuse
> surefire
>  * [SUREFIRE-2196] -
> maven-surefire-report-plugin:failsafe-report-only failed: Unmatched
> braces in the pattern
>  * [SUREFIRE-2202] - NullPointerException if super class meets
> specific condition
>
> ** New Feature
>  * [SUREFIRE-1124] - Let ${surefire.forkNumber} deliver unique
> environmentVariables when used in parallel mvn builds
>
> ** Improvement
>  * [SUREFIRE-2177] - Use junit-bom instead of single JUnit 5 versions
>  * [SUREFIRE-2178] - classpathDependencyExcludes should support
> classifiers
>  * [SUREFIRE-2179] - additionalClasspathElements should support
> Maven coordinates
>  * [SUREFIRE-2182] - Log starter implementation on DEBUG level
>
> ** Dependency upgrade
>  * [SUREFIRE-2188] - Upgrade to Parent 40
>
>
> Enjoy,
>
> -The Apache Maven team
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: passing compiler args via a properties file

[Thomas Broyer]

On Sun, Sep 24, 2023 at 7:49 PM Stanimir Stamenkov
 wrote:

> I've just noticed you're providing multiple arguments in a single 
> element – I'm not sure if this is supposed to work like that.


It is; this is how -Xplugin: works; those are arguments to the ErrorProne
plugins, not to javac itself:
https://docs.oracle.com/en/java/javase/21/docs/specs/man/javac.html#option-Xplugin

This also means that using @file wouldn't really solve the problem, as the
whole -Xplugin:ErrorProne and its arguments would still have to be on a
single line.

ErrorProne itself doesn't support @file arguments, so I think the question
remains unanswered: can Maven load a property's value from a file?
(possibly through a plugin; I have looked at build-helper-maven-plugin and
apparently it doesn't support it)

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: elegant way to disable Nexus staging/deployment in child POMs

[Thomas Broyer]

Le dim. 30 juil. 2023, 21:36, Garret Wilson  a
écrit :

> On 7/30/2023 3:45 PM, Thomas Broyer wrote:
> > The easiest way to opt-in is to configure the plugin in
> 
> > of the parent POM, and then only "apply" to chosen projects by declaring
> > the plugin in the  (only needs the groupId and artifactId
> > then)
>
> Let me make sure I'm understanding what you're suggesting:
>
> 1. Configure the plugin in `` in the root POM.
>
> 2. Do _not_ add the plugin to the `` section in the root
> POM.
>
> Is that what you are proposing?
>
> So then how do I publish the root POM itself to Maven Central? (That was
> the "catch-22" part in the description.)
>

That's what I was proposing, yes (and I did miss the catch-22). But you can
add the plugin to the  in the root POM with
false as suggested by Delany.
The configuration will be inherited by all projects through the
pluginManagement as soon as you add the plugin to  of that
project (or a parent project).

Re: elegant way to disable Nexus staging/deployment in child POMs

[Thomas Broyer]

The easiest way to opt-in is to configure the plugin in 
of the parent POM, and then only "apply" to chosen projects by declaring
the plugin in the  (only needs the groupId and artifactId
then)

That only works if you're calling Maven with lifecycle phases though, I
think it'll error out if you try to directly invoke the plugin's goals.
(I don't know that plugin —or not enough— so can't tell if you're impacted)

Le dim. 30 juil. 2023, 20:29, Garret Wilson  a
écrit :

> I have a "root" POM which I use as the inheritance ancestor of all my
> projects: https://github.com/globalmentor/globalmentor-root
>
> By default it's configured to use the [Nexus Staging Maven
> Plugin](
> https://github.com/sonatype/nexus-maven-plugins/blob/main/staging/maven-plugin/README.md).
>
> It even has a handy `nexus.host` property to define the Nexus server
> (because Sonatype actually puts accounts on separate old-school hosts,
> but I digress).
>
> The catch-22 here is that I need this configuration to be turned on for
> me to publish this POM to Maven Central, yet there are descendant
> projects that use it that I never want to publish to Maven Central. I
> don't want this publishing feature turned on by default in child
> projects. I would prefer to have a flag that I simply turn on in child
> projects (i.e. opt-in) that are to be made public. Any way to have the
> Nexus Staging Maven Plugin enabled in the POM itself for publishing to
> Maven Central, but have it disabled by default for inherited problems?
>
> I'm guessing the answer is "no", so let's instead find an easy way to
> turn it off. I don't see in the documentation (see link above) that
> there's even a "skip" property. Is there? I see that the Maven Deploy
> Plugin has such a feature. I also see that there is a
> `skipNexusStagingDeployMojo`, but that appears to be neither a
> configuration property nor a user property, but only a "plugin flag"
> which is "passed in from the CLI" using `-D`. Is there a "skip"
> configuration property for the Nexus Staging Maven Plugin ?
>
> Does anybody know of a better approach for easily disabling publishing
> to Maven Central in an inheriting project?
>
> Garret
>
> P.S. I'm debating whether this question would be better published on
> Stack Overflow, but in my experience it seems that the Maven experts
> seem to respond here more than on Stack Overflow.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: improving the Maven BOM pattern

[Thomas Broyer]

I must say I haven't seen any project using the approach described in the
Maven doc.

Most projects I've seen use the root POM as both the aggregator POM and the
parent POM, and have their BOM in a submodule. Sometimes the root POM is
only the aggregator and the parent POM is a submodule as well.

Actually the biggest problem with BOMs is that you want them to have a
parent to share all deployment plugins configuration, but without the
dependency management of the project, so other submodules would have a
different parent with those same plugins, possibly other plugins, and
dependency management (importing the BOM and, in your example, Guava).
This can quickly lead to many POM/submodules just to split plugin
configuration and dependency mangement and the BOM and the parent and…

Le jeu. 15 juin 2023 à 01:05, Garret Wilson  a
écrit :

> Hi, everyone. I understand this list to be a general forum for Apache
> Maven users, so as such I'm sharing some ideas I've had related to BOMs.
>
> Over the years I've changed how I define "Bill of Material" POMs for my
> large, aggregated projects. Recently I've settled on a pattern which I
> feel is a refinement of the official Maven approach
> <
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms>
>
> for putting together a BOM. I've described the technique in my blog post
> I published today: /Improving the Maven Bill of Materials (BOM) Pattern/
> .
> Here's a summary.
>
> Assuming we have a project `com.example:…` with aggregated subprojects
> `com.example:foo` and `com.example:bar`, my technique uses the following
> directory structure:
>
> |pom.xml (BOM) parent-pom.xml ├── foo/ │ └── pom.xml └── bar/ └── pom.xml|
>
> Interestingly the top-level BOM aggregates all three POMs: the two
> submodule POMs as well as `parent-pom.xml` in the project root
> directory. The two submodules `foo` and `bar` use `parent-pom.xml` as
> their parent.
>
> I see this bringing a couple of benefits over the official approach in
> the documentation:
>
>   * Aggregated modules are easy to find—in the top-level POM where they
> logically should be.
>   * Other project dependencies and configurations are located nearby, in
> the `parent-pom.xml` file in the same project root directory as the
> BOM, not relegated to a separate subdirectory.
>
> The post goes into much more detail explaining the differences, with
> example of the POM contents.
>
> I'd be interested in feedback on this technique if you have any
> comments—especially if you find a flaw in this approach.
>
> Best,
>
> Garret
>

Re: MavenCLI failing in Jenkins

[Thomas Broyer]

On Thu, Apr 20, 2023 at 4:16 PM Javier Ortiz Bultron <
javier.ortiz...@gmail.com> wrote:

> So this is not official? It certainly looks that way.
>
> https://hub.docker.com/_/maven


"docker official" != "official from the Maven project"

That being said, the Maven project doesn't itself provide Docker images
AFAICT so at least there cannot be any confusion between two "official"
images.

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: What could cause a missing JAR in WEB-INF?

[Thomas Broyer]

If the versions of Maven (hence of the dependency resolution lib) and
maven-dependency-plugin (might interpret trees differently, but given
maven-war-plugin also behaves differently I'd rather blame Maven) are the
same, and you have no differing extension neither, then I have no idea
sorry.

Le sam. 15 avr. 2023 à 17:24, Thad Humphries  a
écrit :

> Except for the times, the effective poms are identical between the two Mac
> Minis.
>
> From the dependency trees, I see what I see in the debug output. The build
> without the  xml-apis-1.0.b2.jar shows (condensing)
>
> [INFO] +- com.google.gwt:gwt-dev:jar:2.8.2:provided
> [INFO] |  +- net.sourceforge.htmlunit:htmlunit:jar:2.19:provided
> [INFO] |  |  +- xerces:xercesImpl:jar:2.11.0:provided
> [INFO] |  |  |  \- xml-apis:xml-apis:jar:1.4.01:provided
> [INFO] |  |  +- net.sourceforge.nekohtml:nekohtml:jar:1.9.22:provided
> ...
> [INFO] +- com.megginson.sax:xml-writer:jar:0.2:compile
>
> while the other shows
>
> [INFO] +- com.google.gwt:gwt-dev:jar:2.8.2:provided
> [INFO] |  +- net.sourceforge.htmlunit:htmlunit:jar:2.19:provided
> [INFO] |  |  +- xerces:xercesImpl:jar:2.11.0:provided
> [INFO] |  |  +- net.sourceforge.nekohtml:nekohtml:jar:1.9.22:provided
> ...
> [INFO] +- com.megginson.sax:xml-writer:jar:0.2:compile
> [INFO] |  \- xml-apis:xml-apis:jar:1.0.b2:compile
>
> So for some reason the machines see a different requirement for
> xml-apis-*.jar
>
>
> On Fri, Apr 14, 2023 at 4:12 PM Thomas Broyer  wrote:
>
> > Have you tried diffing the effective-pom on the various machines?
> > How about running with debug logs? Does the waven-war-plugin maybe
> outputs
> > why it picks or excludes dependencies from the war?
> >
> > Le ven. 14 avr. 2023 à 21:34, Thad Humphries 
> a
> > écrit :
> >
> > > I have *war that I've built on 3 different Macs (maven-war-plugin
> 3.3.2).
> > > The code is pulled from my local git repo, and the supporting jars are
> > from
> > > a local Nexus repository. All Macs use the same setup--Amazon Corretto
> > Java
> > > 11 and Maven 3.9.1. The ~/.m2/settings.xml are identical. Two of the
> Macs
> > > produce the same *war (a Mini with 10.15.7 and a MacBook with 12.6.5).
> > The
> > > third Mac--also a Mini with 10.15.7--is missing one JAR file in
> > > WEB-INF/lib. How can this be?
> > >
> > > The missing JAR is in each local repository. I do not see this JAR
> when I
> > > run `mvn dependency:tree`, though I see a different (newer) version as
> > > "provided." The missing JAR doesn't seem to matter when the webapp runs
> > (no
> > > problems found so far). Any idea as to why, and what I can (or should?)
> > do
> > > for a consistent build?
> > >
> > > --
> > > "Hell hath no limits, nor is circumscrib'd In one self-place; but where
> > we
> > > are is hell, And where hell is, there must we ever be" --Christopher
> > > Marlowe, *Doctor Faustus* (v. 111-13)
> > >
> >
>
>
> --
> "Hell hath no limits, nor is circumscrib'd In one self-place; but where we
> are is hell, And where hell is, there must we ever be" --Christopher
> Marlowe, *Doctor Faustus* (v. 111-13)
>

Re: What could cause a missing JAR in WEB-INF?

[Thomas Broyer]

Have you tried diffing the effective-pom on the various machines?
How about running with debug logs? Does the waven-war-plugin maybe outputs
why it picks or excludes dependencies from the war?

Le ven. 14 avr. 2023 à 21:34, Thad Humphries  a
écrit :

> I have *war that I've built on 3 different Macs (maven-war-plugin 3.3.2).
> The code is pulled from my local git repo, and the supporting jars are from
> a local Nexus repository. All Macs use the same setup--Amazon Corretto Java
> 11 and Maven 3.9.1. The ~/.m2/settings.xml are identical. Two of the Macs
> produce the same *war (a Mini with 10.15.7 and a MacBook with 12.6.5). The
> third Mac--also a Mini with 10.15.7--is missing one JAR file in
> WEB-INF/lib. How can this be?
>
> The missing JAR is in each local repository. I do not see this JAR when I
> run `mvn dependency:tree`, though I see a different (newer) version as
> "provided." The missing JAR doesn't seem to matter when the webapp runs (no
> problems found so far). Any idea as to why, and what I can (or should?) do
> for a consistent build?
>
> --
> "Hell hath no limits, nor is circumscrib'd In one self-place; but where we
> are is hell, And where hell is, there must we ever be" --Christopher
> Marlowe, *Doctor Faustus* (v. 111-13)
>

Re: Windows Installer / MacOS dmg

[Thomas Broyer]

Doesn't JDK 18 come with jpackage for exactly that use case? Not sure
how/if you can drive it from Maven but you should be able to prepare
everything with dependency:copy-dependencies or the maven-assembly-plugin
and then run jpackage manually to produce the installers.

Le dim. 16 oct. 2022 à 10:27, Vivek Suraiya 
a écrit :

> I have a Netbeans 15 JavaFX (18.0.2 / JDK 18.0.2) project with several
> dependencies from the Maven repository. I wish to create a Windows
> installer and a MacOS dmg including all dependencies and the JRE. Is this
> possible to do?

Re: java.lang.ClassNotFoundException: com.google.common.base.Preconditions

[Thomas Broyer]

IIRC exec:java doesn't fork a new JVM so the java.class.path is the one
from Maven itself. Your dependencies are "only" in a custom classloader.
You might want to try exec:exec with java as the executable.

Le dim. 24 juil. 2022 à 20:46, Siddharth Jain  a écrit :

> we are running into the dreaded ClassNotFoundException in a project. Here
> is the setup. Using JDK 11 and Maven 3.8.5. Trying to create sample test
> project that uses memory-measurer
>  to measure memory.
> First we mvn packaged and installed the memory-measurer artifact into M2
> repository. Then we created a test project in which we add dependency on
> memory-measurer. The project compiles fine but gives error on running (we
> run using mvn exec:java plugin):
>
> Caused by: java.lang.ClassNotFoundException:
> com.google.common.base.Preconditions
> at jdk.internal.loader.BuiltinClassLoader.loadClass
> (BuiltinClassLoader.java:581)
> at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass
> (ClassLoaders.java:178)
> at java.lang.ClassLoader.loadClass (ClassLoader.java:521)
> at objectexplorer.InstrumentationGrabber.checkSetup
> (InstrumentationGrabber.java:20)
> at objectexplorer.InstrumentationGrabber.instrumentation
> (InstrumentationGrabber.java:25)
> at objectexplorer.MemoryMeasurer. (MemoryMeasurer.java:24)
> at com.example.App.main (App.java:20)
> at org.codehaus.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:254)
> at java.lang.Thread.run (Thread.java:834)
>
>
> What have we tried? Here is output of mvn dependency:build-classpath:
>
>
> /Users/xxx/.m2/repository/objectexplorer/memory-measurer/1.0-SNAPSHOT/memory-measurer-1.0-SNAPSHOT.jar:/Users/xxx/.m2/repository/com/google/code/findbugs/jsr305/3.0.2/jsr305-3.0.2.jar:/Users/xxx/.m2/repository/com/google/guava/guava/19.0/guava-19.0.jar:/Users/xxx/.m2/repository/junit/junit/4.11/junit-4.11.jar:/Users/xxx/.m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar
>
> we unpacked guava-19.0.jar in a temp directory and can see
>
> -rw-r--r--  1 xxx  staff  5252 Aug 25  2014
> /Users/xxx/temp/com/google/common/base/Preconditions.class
>
> in it. The next thing we tried is printing
> System.getProperty("java.class.path"). This gives:
>
> /Library/Downloads/apache-maven-3.8.5/boot/plexus-classworlds-2.6.0.jar
>
> above does not contain the classpath calculated by mvn dependency plugin.
> Question 1: Why?
>
> Question 2: When we printed System.getProperty("java.class.path") in
> another working project we got same result. It seems the classpath when
> using mvn exec:java is always
>
> /Library/Downloads/apache-maven-3.8.5/boot/plexus-classworlds-2.6.0.jar
>
> How is the other project able to load classes from above classpath? Why is
> mvn
> exec:java not using correct classpath? How do we fix this?
>
>
> Here 
> is
> output of maven with the -X switch. You can see following debug info:
>
>
> [DEBUG] Adding project dependency artifact: memory-measurer to classpath
> [DEBUG] Adding project dependency artifact: jsr305 to classpath
> *[DEBUG] Adding project dependency artifact: guava to classpath* here
>  is
> pom.xml. would be great if someone could help us out.
>

Re: Where can find a working plugin test example

[Thomas Broyer]

TL;DR: it doesn't use the maven-plugin-testing-harness but
maven-invoker-plugin, and that's what I've been using as well.

Le mar. 28 juin 2022 à 07:59, Martin Höller  a écrit :

> Hi! Stephan!
>
> Some years ago I had a similar problem while developing
> vdldoc-maven-plugin [1]. I found all the necessary information, but it
> was a rather hard search.
>
> Have a look at this plugin's source-code at github [2]. It is a very
> simple plugin which has unit tests, integration-tests, uses checkstyle, pmd
> and findbugs (which should now be replaced by spotbugs). I'd say it could
> be good starting point for you.
>
> hth,
> - martin
>
> [1] http://matinh.github.io/vdldoc-maven-plugin/
> [2] https://github.com/matinh/vdldoc-maven-plugin
>
>
> Am 28. Jun. 2022 schrieb Stephan Wissel:
>
> > Trying to write a plugin following TDD practices.
> > Tried to follow:
> >
> https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/getting-started/index.html
> >
> > which already fails on maven archetype:create (generate works, but
> doesn't
> > create a test case).
> >
> > last published version of
> > org.apache.maven.plugin-testing/maven-plugin-testing-harness
> > was 2014:
> >
> https://search.maven.org/artifact/org.apache.maven.plugin-testing/maven-plugin-testing-harness/3.3.0/jar
> >
> > However there's a 2021
> > com.github.codeteapot.maven.plugin-testing:maven-plugin-testing-harness
> >
> > Where can I find a working example of a plugin-test with contemporary
> > dependencies?
> >
> > Create a nice day!
> > Stephan H. Wissel
> >
> > Phone: +65 96673269
> > Blog  Twitter <
> http://twitter.com/notessensei>
> > LinkedIn  Xing
> > 
>

Re: How does Maven really treat "bundle" packaging type?

[Thomas Broyer]

Le lun. 20 juin 2022 à 20:38, Pawel Veselov  a
écrit :

> TL;DR:
>
> Is there a way, and what is the correct one if there is, to prevent a
> package being downloaded from a particular repository (or lock it to
> being downloaded from a particular one, though I thought the answer to
> that one is "no")?
>

Use a repository manager?
Have everything go through your repo manager (by declaring it as proxying
`*` in your settings.xml), and manage "filters" there to make sure you only
get from Jitpack what you expect to get from it (using Nexus, this is done
through "routing rules", I don't know with Artifactory).
That's the route we've taken to avoid a few supply chain attacks, including
dependency confusion like you're seeing here (even though it's probably not
an "attack")

LR:
>
> Maven 3.8.6, JDK 1.8.
>
> I've run into this strange problem with
> com.github.jsonld-java:jsonld-java:0.13.4
> The package includes fine as a dependency if it is downloaded from
> Maven Central:
> pom.xml: https://pastebin.com/qev5Udp2
> Build output: https://pastebin.com/MzUVqWLt (pending moderation, LMK
> if you want me to attach that)
>
> The package fails to download as a dependency if it is downloaded from
> JitPack:
> pom.xml: https://pastebin.com/7L2rEWPz
> Build output: https://pastebin.com/U3StAtMZ
>
> AFAIU, there are two things that are "wrong" in this entire thing:
> a) Developer declared packaging as "bundle" (I'm not entirely sure
> that's wrong, but I don't see a reason for them to have done so, and
> it seems to be a contributing factor)
> b) JitPack/somebody republished the dependency as a virtual package
> that depends on itself, and broke this entirely.
>
> But what I don't understand is why the Maven's behavior is different
> in these two cases.
>
> NOT WORKING CASE: The package is found on JitPack, Maven is asked to
> get com.github.jsonld-java:jsonld-java:0.13.4 of type "bundle" by an
> explicit dependency statement. There is no such downloadable binary,
> so the entire process fails.
>
> WORKING CASE: The package is found on Central, Maven is asked to get
> com.github.jsonld-java:jsonld-java:0.13.4, without packaging
> specification. The packaging specification in the POM is "bundle". But
> Maven is satisfied with just downloading the JAR
>
> Few questions:
> - How come Maven is OK creating/uploading a package with "bundle"
> packaging, but without a "bundle" file?
> - How does Maven decide to download the .jar when the packaging says
> "bundle" in the POM, and is satisfied with that?
>

This is done through "artifact handlers" (the 'type' from a 'dependency' is
technically unrelated to the 'packaging' from the POM). If your dependency
doesn't declare a 'type', then it defaults to 'jar' (the 'packaging'
selects a lifecycle that determines how to *build* that project,
irrespective of how to consume it)

- Is there a way to find out who published a package on JitPack, to
> get them to fix it? The developer didn't do that, that was done
> without their consent and/or them being made aware of it
>
> Thank you.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Splitting a dependency tree with the assembly plugin

[Thomas Broyer]

How about first building a distribution for each module separately (each in
its own Maven module) and then assemble them into a single distribution?

Le sam. 7 mai 2022 à 18:49, Mark Raynsford
 a écrit :

> Hello!
>
> I'm running into a problem when trying to produce an application
> distribution.
>
> This is the pom.xml file:
>
>
> https://github.com/io7m/eigion/blob/develop/com.io7m.eigion.distribution.example/pom.xml
>
> The module essentially represents two isolated applications that have
> been combined into one Maven module for the purposes of producing a
> distribution zip file. The first application is represented by the
> com.io7m.eigion.launcher.main dependency, and the other is represented
> by the com.io7m.eigion.gui dependency.
>
> I have the following assembly descriptor:
>
>
> https://github.com/io7m/eigion/blob/develop/com.io7m.eigion.distribution.example/src/main/assembly/distribution.xml
>
> What I'm trying to do is:
>
>   * Put com.io7m.eigion.gui and all dependencies of com.io7m.eigion.gui
> into "workbench/modules" in the assembly.
>   * Put all dependencies of com.io7m.eigion.launcher.main into
> "launcher/modules" in the assembly.
>
> This is _mostly_ working, except that it seems that at least one
> transitive dependency of com.io7m.eigion.launcher.main is being left
> out. Specifically, for example, it seems that com.io7m.junreachable.core
> is being left out of "launcher/modules". I _think_ what's happening is
> that because com.io7m.junreachable.core is also transitive dependency
> of com.io7m.eigion.gui, it's being excluded.
>
> Is there perhaps a more intelligent way to achieve what I'm trying to
> achieve?
>
> --
> Mark Raynsford | https://www.io7m.com
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Maven Reactor and plugin "local" dependencies

[Thomas Broyer]

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"
> `mvn clean install` (usually `mvn clean install -Dtest=void`) as very first
> step. Have to add, I tend to work on projects that finish these "quick
> builds" in a matter of minutes at most, not hours :) This "process" works
> for me just fine.
>

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 only includes remote artifacts and I never need to use SNAPSHOTs
(again, because everything can be built in the same invocation without the
need to split things in separate "projects" –like you suggested for the
extension or even annotation processor–, so I never need to 'install'
things locally, or deploy snapshots to a repository), and never need to do
"quick-builds" either. I ask it to build, it builds what it needs to build,
everything Just Works™.
It also has accurate incremental builds, and even a (local or remote, I
only use local) build cache so things don't necessarily have to be rebuilt
when I switch between branches.
This is what I expect from any build tool, and we even start to see such
things coming to Node/NPM!


> But, now that you bring up topic of "branched development", something I
> always hated for very same reason you bring up, I think you will be happy
> to see upcoming changes:
>
>
> https://github.com/apache/maven-resolver/blob/master/src/site/markdown/local-repository.md
>
> (unreleased yet, we plan this for Resolver 1.8.1 and Maven 3.9.0).
>
> All in all I think we both agree, but still: Maven as a project is big
> (huge actually), and volunteers working on it have hard time to catch up,
>

Indeed it's a shame that the project is so underfunded given the many
wealthy companies relying on it!
For my part, I try to avoid Maven if I can, except possibly for very simple
builds. I still have to work with Maven in some projects, I maintain some
Maven plugin and archetypes, and have to deal with Maven as a consumer of
libraries I contribute to (lately having to make tests with artifact
relocation and BOMs)

Am not saying either "maven is the best", but I am convinced "maven can be
> better", MUCH better and we will do it. As a matter of fact, we are already
> doing it, step by step, baby steps :)
>

Yes, and Maven 4 has some good things coming!

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: Maven Reactor and plugin "local" dependencies

[Thomas Broyer]

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 build:
> - an annotation processor
> - a verifier plugin
> - a "user" module that uses those above two within same build
>
> and it works as expected so more feedback or reproducer needed here as
> well.
>

Yes, because annotation-processor comes before
annotation-user in the aggregator POM (it also runs the
whole build, rather than '-pl annotation-user -am', using that you should
see that you need to explicitly add annotation-processor to the project
list on the command line)

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: Maven Reactor and plugin "local" dependencies

[Thomas Broyer]

debug things though.


> But that said, and
> reading your mail and in parallel reading m-compiler-p sources, I already
> see a bug in m-compiler-p and how it resolves annotation processors: if you
> look, it ends up in maven-compat (Maven2 compatibility layer) and does the
> work in "Maven2 way", while you are right, this should work just fine out
> of the box. Filed issue for this bug:
>
> https://issues.apache.org/jira/browse/MCOMPILER-496


Fwiw, as you're looking into this,
https://issues.apache.org/jira/browse/MCOMPILER-272 has been marked fixed
but I believe the fix introduced an unwanted behavior, as I noted in the
pull request at the time:
https://github.com/apache/maven-compiler-plugin/pull/40/files/cc37094621e3e125e02d4d90f0159a6589f6fa18#r630410255

So, your 2nd example (and 2nd paragraph) about the annotation processor is
> IMHO a m-compiler-p bug, and shall be fixed.
>

The same would probably be true for the maven-javadoc-plugin and custom
doclet:
https://maven.apache.org/plugins/maven-javadoc-plugin/examples/alternate-doclet.html
(I'm not saying it has a bug, but it works similarly to m-compiler-p's
annotationProcessorPaths)


> And your 3rd paragraph is a bit too vague for me. Could you, like Florent
> did, create an example project that shows clearly what you want, and shows
> what Maven does not as expected?
>

Actually I think you can see it easily with the exec-maven-plugin (which
won't fork a build):
1. in parent module, declare exec-maven-plugin with skip=true and
mainClass=ignored (this is my other grief wrt the linear lifecycles in
Maven, using execution IDs in the invocations –exec:java@foobar– make it
even worse)
2. in submoduleB, declare:
  
org.codehaus.mojo
exec-maven-plugin
3.0.0

  false
  false
  true
  
test
submoduleA
  
  test.doclet.App


  
test
submoduleA
${project.version}
  

  
3. mvn -pl submoduleB -am exec:java

It fails because Maven cannot resolve submoduleA, because it has not been
"built" in that invocation. You could add the "package" phase to the
invocation and now Maven resolves the submoduleA JAR, but it will also also
package submoduleB (before or after exec:java depending on the order you
pass them on the command-line). In this case, in a small reprocase
generated using a couple of
org.apache.maven.archetypes:maven-archetype-simple archetype:generate
invocations, exec-maven-plugin failed with a NPE when looking up the
executableDependency, which is probably a bug in the plugin, but my point
was to demonstrate issues with the Maven lifecycles, even prior to execute
the plugin's goal.
If you do not want/cannot afford to add the package phase to that
invocation, your only alternative (to my knowledge) is to 'mvn install -pl
submoduleA' prior to 'mvn -pl submoduleB exec:java'.

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: Maven Reactor and plugin "local" dependencies

[Thomas Broyer]

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
> (simplicity).
>
> Q: which one of your commit is your snapshot in your local repository from?
> A: the last one you `mvn install`-ed?
>
> Q: how can you tell?
> A: Your build should be reproducible (
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html) so
> you
> can sha target/XXX.jar and local repo? But if unsure, just `mvn install` :D
>

So you rely on your memory (when was the last time I ran 'mvn install'? did
I switch branch or changed the code since then?) and you end up running
'mvn install' all the time, "just in case".
(checking the sha means that target/XXX.jar is up-to-date with the code
too, i.e. you ran 'mvn package', which brings use back to relying on your
memory)

Also, if you 'git pull' or 'git switch', how can you tell whether you
actually need to rebuild (and re-install) that piece of code? You have to
look at the changed files from the previous state and rely on assumptions
about whether they'll change that thing that you have to 'mvn install' to
make your build work; or I bet you'll actually just blindly 'mvn install'
every time.


> Maven does not require anything to install, or at least, am not getting
> what you are saying.
>

See my other answer (to your other mail), there ARE cases (admittedly few
of them, but still) where you DO have to rely on 'mvn install'.

Note: I'm not here to debate about whether Maven is "good" or "good
enough", better than other tools or not (I made my opinion years ago, I'm
not asking you to change my mind). Maven is a good tool and we owe it many
things, it really helped make the whole Java (and more) development
experience better and inspired many other tools; but it DOES have
limitations, and people have to be aware of them. And I'll stand by what I
said: 'mvn install' is an anti-pattern. Even using one project from another
(a lib you're developing, from some sample project using it) should be
possible without 'mvn install', through an aggregator build (this is mostly
the case, but there are exceptions). In other words, I should be able to
'cd' into a project and 'mvn verify' it and it should Just Work™ without
relying on some "ambient" state such as "when did I last 'mvn install' that
thing? am I actually using the 'correct version' of it?".

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: Maven Reactor and plugin "local" dependencies

[Thomas Broyer]

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 you used
> dependency:copy in the first place) which indicates a bad build smell that
> you should eradicate.
> * You may not have the time… well think of all the time you are wasting
> running "mvn install" when you could get away without going so far along
> the lifecycle.
>
> Can you point me to some "reproducer" project (of ANY of these issues
> mentioned in this 10 year old blog), that
> * will reproduce this with modern Maven, think 3.8.x
> * is NOT broken topologically (cycles), is not using broken (by using
> broken plugins) and developers does have time?


Well, one limitation is with extensions: to use a project providing an
extension (custom lifecycle, whatever), you have to install it first. You
could argue that the project would otherwise be broken topologically (and I
agree!) but there's really no way (or did I miss some new feature?) to do
such things without installing the extension first (with Gradle, in
addition to the buildSrc, you can use a "composite build" where one build
provides plugins for the other, including "settings plugins" –where the
settings.gradle file is also where you declare the included build–; Pants
allows you to have in-repo plugins, it's a no-brainer with Bazel too as
it's just how things work, I can't really tell for SBT but you could at
least put plugins in a project/ and possibly symlink to another project to
mimic an "included build" like Gradle)

Other setups seem to work "by accident"; e.g. a project with 3 submodules:
annotations, processor, whatever; where 'whatever' has a dependency on
'annotations' and uses 'processor' in
maven-compiler-plugin's , the order of the
 in the aggregator POM is crucial to make it work ('processor' has
to come 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
would infer Maven's behavior for reactor ordering as taking the 
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 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 that the
 actually lists dependencies that could come from
the reactor build and that it would take them into account for determining
which modules to build and in which order.

I don't have an actual use case at hand, this is all theoretical based on
my knowledge of how Maven works so correct me if I'm wrong, but using
custom lifecycles, and due to how build lifecycles work in Maven, running a
goal "in a project" (it's never actually "in a project", it's always run in
all projects of the reactor build, and the plugin itself has to detect or
be configured to know in which module to actually run or skip) might only
partially "build" the depended-on modules in such a way that they won't
work when the plugin actually need them.
Let's take a very hypothetical example, a plugin goal that scaffolds things
in a project, so must not trigger the project's lifecycle as that would
possibly break and we don't care (so either the plugin has no @execute, or
it executes an "early" phase such as 'initialize', or maybe
'process-classes' if it scaffolds tests and somehow needs the project's
main code to do that), but will use some dependency to determine what/how
to do its job (so has a plugin dependency, let's say on another module of
the reactor build). If we do 'mvn -pl target-project -am
the-plugin:scaffold -Dwhatever', then the 'scaffolding-config' submodule
declared as a plugin dependency of 'the-plugin' in project 'target-project'
won't be built besides what the plugin's goal @execute declares. So you'd
actually have to first 'mvn install -pl scaffolding-config' and then 'mvn
-pl target-project the-plugin:scaffold -Dwhatever' (note that I haven't
included -am here).
You could argue this is somehow "broken", I wouldn't disagree, but then
don't argue that Maven itself is not somehow "broken by design" or at a
minimum "limited" in its capabilities: there are cases where using "mvn
install" would be *required* to make things work. Either that or not using
Maven for those things, and rather rely on third-party tooling outside
Maven.

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: Maven Reactor and plugin "local" dependencies

[Thomas Broyer]

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 someone
else's commit (you might not have pulled from your git repo, but the
snapshot comes from the origin/master that someone else pushed)

Maven is among the only (modern) build tools requiring you to "install"
part of your project to some widely shared place (shared with all you local
projects) to use it from within itself!


Le jeu. 5 mai 2022 à 21:22, Tamás Cservenák  a écrit :

> 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,
> >
> > TL;DR? https://github.com/fbiville/mvn-plugin-dependency-reactor-issue
> >
> > I recently noticed that, within the big multi-module project of my
> company,
> > a specific module is listed as a dependency to plugins such as Maven
> > Checkstyle plugin or com.mycila:license-maven-plugin.
> >
> > The problem occurs when I try one of these plugins against another
> specific
> > 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 with Maven 3 and 4.
> >
> > The obvious workaround is to install the required module first and then
> run
> > the plugin but I'm trying to get rid of the need for `mvn install`
> > entirely.
> >
> > Is there a particular reason plugin dependencies are not considered by
> > Maven Reactor?
> > Is module-as-plugin-dependency a Maven antipattern?
> >
> > Thanks a lot for your help!
> > Florent
> >
>

Re: What steps will install dependent artifacts in local maven repo

[Thomas Broyer]

Releases are "immutable" in a Maven repository (or at least are expected to
be, and the Central Repository enforces it), so if 3.7.1 is compatible with
JDK 8, it will stay that way.

On Wed, Mar 23, 2022 at 2:40 PM KARR, DAVID  wrote:

> Inline.
>
> > -Original Message-
> > From: Alexander Kriegisch 
> > Sent: Wednesday, March 23, 2022 1:11 AM
> > To: users@maven.apache.org
> > Subject: Re: What steps will install dependent artifacts in local maven
> > repo
> >
> > Some background information, because I happen to know, being an AspectJ
> > committer and the AspectJ compiler being a fork of ECJ, just like
> > GrEclipse is, too:
> >
> > The JDT Core project has decided a while ago - I think for the Eclipse
> > 4.22 (2021-12) release, maybe one release earlier - to drop Java 8
> > build-time support and move on to Java 11+, because other parts of
> > Eclipse are based on Java 11 too and it was getting more and more
> > difficult to keep those libraries out with their Java 11 class files. So
> > now, JDT Core and therefore also recent versions of compilers like ECJ,
> > GrEclipse and AspectJ *had* to migrate to Java 11 as well, because they
> > all depend on JDT Core.
> >
> > Attention, please do not misunderstand: ECJ and e.g. AspectJ can still
> > compile to Java 8 target. I do not know about GrEclipse, but would
> > expect the same. For pure POJOs (no AspectJ or Groovy), those compilers
> > can even create class files for as low as Java 1.3! Javac cannot do
> > that, so you are more flexible than with Javac. The limitation only
> > applies to build time, i.e. you have to run your builds on JVM 11+, even
> > if you compile to target 8.
> >
> > Your error messages therefore come from builds using more recent Eclipse
> > (fork) compiler version, but running on JRE 8. Simply upgrade the build
> > environment on your workstation or Jenkins server to run on JDK 11+,
> > then you should be fine.
>
> We are in the process of migrating from Java 8 to Java 11, but it is not
> going to be immediate.  We can't simply flip a switch.
>
> I determined that groovy-eclipse-batch v3.0.8-01 is the last version that
> was compiled by Java 8.  I need to know it will stay this way.  I also am
> now specifying groovy-eclipse-compiler v3.7.1.  I also hope that will stay
> on Java 8.  Are both of those true?
>
> > David Karr schrieb am 22.03.2022 23:50 (GMT +07:00):
> >
> > > Our org's builds have been using Java 8 for quite a while.  We're
> > starting
> > > to move some builds to Java 11.  We're seeing some builds failing with
> > the
> > > following:
> > > -
> > > Execution default-compile of goal
> > > org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile failed:
> > > An API incompatibility was encountered while executing
> > > org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile:
> > > java.lang.UnsupportedClassVersionError:
> > > org/eclipse/jdt/core/compiler/batch/BatchCompiler has been compiled by
> > a
> > > more
> > > recent version of the Java Runtime (class file version 55.0), this
> > version
> > > of
> > > the Java Runtime only recognizes class file versions up to 52.0
> > > -
> > >
> > > This indicates that the artifact with the BatchCompiler class (ecj)
> > was
> > > compiled with Java 11, but the current JVM is Java 8.
> > >
> > > I'm trying to understand the possible scenarios that could produce
> > this, so
> > > we can mitigate it properly.
> > >
> > > This artifact is specified as a direct dependency of the
> > > "maven-compiler-plugin". It would help to understand exactly which
> > Maven
> > > goals will install plugin dependencies into the local maven repo.  At
> > least
> > > our builds only do "mvn package" or "mvn deploy", depending on what is
> > > being built.
> > >
> > > However, our builds are run on a pool of Jenkins build nodes, and I'm
> > not
> > > certain whether those build nodes are shared with other projects in
> > our
> > > large enterprise. I'm trying to determine that.
> > >
> > > We may determine that because of these issues, we will have to specify
> > a
> > > fresh empty local repository for every build, which will obviously
> > make our
> > > builds take longer.
> > >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: What steps will install dependent artifacts in local maven repo

[Thomas Broyer]

Le mar. 22 mars 2022 à 23:37, Nick Stolwijk  a
écrit :

> Also, org.codehaus.groovy:groovy-eclipse-batch:RELEASE is not in
> Maven Central.



Yes it is:
https://search.maven.org/artifact/org.codehaus.groovy/groovy-eclipse-batch

About the RELEASE version:
https://www.baeldung.com/maven-dependency-latest-version

Re: What steps will install dependent artifacts in local maven repo

[Thomas Broyer]

This is totally unexpected behavior to me: an external artifact whose
content would be different depending on which JDK downloaded it.

Would you mind sharing the maven-compiler-plugin declaration with the ecj
dependency? (to try replicating the issue and understand it)

Le mar. 22 mars 2022 à 19:20, KARR, DAVID  a écrit :

> Self-replying from my alter ego. 
>
> I have verified that if I remove the "ecj" tree from my local repo, then
> build one service with Java 11, with just "mvn package", then run a build
> of a different service with Java 8, it will get the given error.  I can
> verify that the ecj artifact is now reinstalled into my local maven repo.
> What's odd is that when I use "javap" to inspect the BatchCompiler class
> file, it says it is version 50, not 55.
>
> I think I'm heading towards having each build, or at least each build with
> a specific Java version, use a separate localRepository.  That is set in
> the settings.xml, and that path would be local to the build node, not the
> build workspace (obviously, if we intended to use the same tree for all
> Java 8 builds, and similarly one for all Java 11 builds). That means
> coordinating with the people who maintain the build nodes.  Yuck.
>
> > -Original Message-
> > From: David Karr 
> > Sent: Tuesday, March 22, 2022 9:50 AM
> > To: Maven Users List 
> > Subject: What steps will install dependent artifacts in local maven repo
> >
> > Our org's builds have been using Java 8 for quite a while.  We're
> > starting to move some builds to Java 11.  We're seeing some builds
> > failing with the
> > following:
> > -
> > Execution default-compile of goal
> > org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile failed:
> > An API incompatibility was encountered while executing
> > org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile:
> > java.lang.UnsupportedClassVersionError:
> > org/eclipse/jdt/core/compiler/batch/BatchCompiler has been compiled by a
> > more recent version of the Java Runtime (class file version 55.0), this
> > version of the Java Runtime only recognizes class file versions up to
> > 52.0
> > -
> >
> > This indicates that the artifact with the BatchCompiler class (ecj) was
> > compiled with Java 11, but the current JVM is Java 8.
> >
> > I'm trying to understand the possible scenarios that could produce this,
> > so we can mitigate it properly.
> >
> > This artifact is specified as a direct dependency of the "maven-
> > compiler-plugin". It would help to understand exactly which Maven goals
> > will install plugin dependencies into the local maven repo.  At least
> > our builds only do "mvn package" or "mvn deploy", depending on what is
> > being built.
> >
> > However, our builds are run on a pool of Jenkins build nodes, and I'm
> > not certain whether those build nodes are shared with other projects in
> > our large enterprise. I'm trying to determine that.
> >
> > We may determine that because of these issues, we will have to specify a
> > fresh empty local repository for every build, which will obviously make
> > our builds take longer.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

Re: Plugin goal that will trigger "verify"

[Thomas Broyer]

On Thu, Mar 10, 2022 at 5:22 AM Nils Breunese  wrote:

> Thomas Broyer  wrote:
>
> > Le mer. 9 mars 2022 à 23:48, Nils Breunese  a écrit :
> >
> >> The Maven build lifecycle consists of phases [0] and you can bind plugin
> >> goals to phases. As far as I know it doesn’t work the other way around,
> so
> >> you can’t make a plugin goal execute particular phases, which seems to
> be
> >> what you’re asking. It should be the other way around: you can
> associate a
> >> plugin goal with a phase and then when you execute that phase all
> previous
> >> phases will have been executed, and your plugin goal will be executed.
> >
> > This is not entirely true. A mojo can be annotated with @Execute() to
> > execute a lifecycle up to a given phase before the mojo itself is
> executed.
> > That's the difference between jar:jar and jar:jar-no-fork for instance.
>
> Ah, interesting, I didn’t know that. But that can only controlled by the
> Maven plugin developer then.


Indeed (
https://maven.apache.org/developers/mojo-api-specification.html#the-descriptor-and-annotations),
but that was what Steve was asking about, right?

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: Plugin goal that will trigger "verify"

[Thomas Broyer]

Le mer. 9 mars 2022 à 23:48, Nils Breunese  a écrit :

> Steve Hannah  wrote:
>
> > I'm trying to achieve better integration into VSCode with my project
> > archetype. The way that the VSCode maven extension seems to prefer to
> work
> > is for users to explicitly "run" a goal from a plugin of the project.
> >
> > You can see the VSCode instructions for running a JavaFX app as an
> example
> > here:
> >
> https://code.visualstudio.com/docs/java/java-gui#_run-the-javafx-application
> >
> > Basically, the user expands the Maven > Project > Plugins > JavaFX node,
> > then right clicks the "javafx:run" goal, which is defined in the JavaFX
> > maven plugin.
> >
> > In the JavaFX example, that javafx:run goal actually spawns a new process
> > that runs the app, which seems to break debugging.
> >
> > With my own projects, I generally bind my "Run" goal to the "verify"
> phase
> > so that running "mvn verify" will run my project.  This work OK in
> IntelliJ
> > and NetBeans (although I need to do some contortions to make debugging
> > work), but doesn't seem to mesh with VScode's way of doing things.
> >
> > What I would like is to create a custom "run" goal in my plugin so that
> > VSCode can run or debug this goal - and the goal should trigger
> everything
> > up to the "verify" lifecycle - without having to spawn a new process.
> >
> > I've been hitting walls in maven for years now, and I have a feeling that
> > this is not possible.  Can someone either set me straight (i.e. inform me
> > that it is possible), or confirm that, indeed, it is not possible?
>
> The Maven build lifecycle consists of phases [0] and you can bind plugin
> goals to phases. As far as I know it doesn’t work the other way around, so
> you can’t make a plugin goal execute particular phases, which seems to be
> what you’re asking. It should be the other way around: you can associate a
> plugin goal with a phase and then when you execute that phase all previous
> phases will have been executed, and your plugin goal will be executed.
>

This is not entirely true. A mojo can be annotated with @Execute() to
execute a lifecycle up to a given phase before the mojo itself is executed.
That's the difference between jar:jar and jar:jar-no-fork for instance.

>

Re: Local repository accessed by multiple Maven instances - how is it solved ?

[Thomas Broyer]

>From JIRA links, this is apparently fixed by
https://issues.apache.org/jira/browse/MRESOLVER-131, which means you need
to deploy a Redis server.
There apparently also is an Hazelcast-based version:
https://maven.apache.org/resolver/maven-resolver-named-locks/index.html

On Mon, Oct 4, 2021 at 2:32 PM Francois Marot 
wrote:

> Hello all,
>
> I would like clarifications on MNG-2802[*] that seems to be solved. If I
> understand correctly it solves the problem where multiple simultaneous
> Maven executions shared the same local repository.
> I have been keeping for years a bit of code in my Jenkinsfiles ensuring the
> local repos were accessed only by a single jenkins executor at the same
> time, so it seems like I can get rid of this doesn't it ?
> I'd like your input on this because reproducing the bug is difficult so I'd
> like to be sure before simplifying my Jenkinsfile.
>
> Moreover, does anyone know how this problem is solved technically ? Using
> files lock ? Can anybody explain ?
>
> Thanks you and thanks the Maven team for keeping up the good work at such
> pace !
>
> François MAROT
>
>
> * https://issues.apache.org/jira/browse/MNG-2802
>


-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: maven-surefire-plugin jdkToolchain meets forkCount

[Thomas Broyer]

ava.util.concurrent.FutureTask.run(FutureTask.java:266)
> [ERROR] at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [ERROR] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [ERROR] at
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [ERROR] at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [ERROR] at java.lang.Thread.run(Thread.java:748)
> [ERROR] Caused by: java.lang.UnsupportedClassVersionError:
> com/traderoot/common/crypto/clientreference/TestClientToken has been
> compiled by a more recent version of the Java Runtime (class file version
> 53.0), this version of the Java Runtime only recognizes class f
> ile versions up to 52.0
> [ERROR] at java.lang.ClassLoader.defineClass1(Native Method)
> [ERROR] at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
> [ERROR] at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> [ERROR] at
> java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
> [ERROR] at
> java.net.URLClassLoader.access$100(URLClassLoader.java:74)
> [ERROR] at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
> [ERROR] at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
> [ERROR] at java.security.AccessController.doPrivileged(Native
> Method)
> [ERROR] at
> java.net.URLClassLoader.findClass(URLClassLoader.java:362)
> [ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> [ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> [ERROR] at
>
> org.apache.maven.surefire.booter.IsolatedClassLoader.loadClass(IsolatedClassLoader.java:100)
> [ERROR] at
>
> org.apache.maven.surefire.api.util.DefaultScanResult.loadClass(DefaultScanResult.java:136)
> [ERROR] at
>
> org.apache.maven.surefire.api.util.DefaultScanResult.applyFilter(DefaultScanResult.java:100)
> [ERROR] at
>
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider.scanClasspath(JUnitPlatformProvider.java:147)
> [ERROR] at
>
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider.invoke(JUnitPlatformProvider.java:128)
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> [ERROR] at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [ERROR] at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
> [ERROR] at
>
> org.apache.maven.surefire.api.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:167)
> [ERROR] at
>
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:161)
> [ERROR] at
>
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:84)
> [ERROR]     at
>
> org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.runSuitesInProcess(InPluginVMSurefireStarter.java:87)
> [ERROR] ... 16 more
>
> I don't like guessing what is going on here, but i'm not in a position to
> go that extra mile and "Run Maven with -Dmaven.surefire.debug, and attach
> to the running process with a debugger."
>
> In a nutshell my question is "how can I build with a JDK 9 or above using a
> toolchain and without being limited to a single test fork?"
>
> Thanks,
> Delany
>


-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: Attaching dependency-reduced POM to build using Maven Assembly or Shade

[Thomas Broyer]

Well, maven-shade-plugin does "attach" the dependency-reduced POM:
https://github.com/apache/maven-shade-plugin/blob/768092f38b0b1650217642cf10b7b0c381cbf707/src/main/java/org/apache/maven/plugins/shade/mojo/ShadeMojo.java#L1191
At least when you install or deployed, that POM gets installed/deployed
rather than the original one.

Le dim. 25 avr. 2021 à 04:09, Alexander Kriegisch 
a écrit :

> I am sorry if I am asking a question the answer to which might be obious
> to others, but for a long time I have wondered why I do not find any
> examples for the following use case which IMO is probably quite common:
>
>   ** I build an uber JAR containing some module dependencies, possibly
>  also transitive ones. This could be done using Maven Shade or Maven
>  Assembly, maybe even something with nested JARs like One-JAR.
>   ** The built uber JAR replaces the module's original artifact when
>  installed and/or deployed.
>   ** By default, the original POM gets attached to the build. This is
>  undesirable, because the uber JAR no longer depends on those
>  dependencies. They are only needed in the POM during the build as
>  such in order to be able to include them in the uber JAR at all.
>
> My question: How do I automatically create and attach a
> dependency-reduced POM to the build, replacing the original POM?
> Ideally, I would have options to also filter out other POM elements such
> as repositories, but that is optional and not the main scope of this
> question.
>
> Presently, I use Flatten Maven Plugin for this purpose. For certain
> reasons, I am not very happy with it because it requires extra work, it
> mutilates my POMs with regard to formatting and removing things I do not
> wish to be removed, but it works.
>
> I also know that Maven Shade automatically creates a dependency-reduced
> POM if not told otherwise. But that POM is not attached to the build.
> Maybe I could do so using Build Helper, but both Flatten Maven and Build
> Helper seem like crutches, and I cannot help but wonder which built-in
> Maven functionality escaped my attention so far. Is there a canonical
> way to do that, such as resource filtering? Can I even apply that to
> POMs? I feel like I might be doing something phenomenally stupid,
> possibly missing a more straightforward way of solving this problem.
>
> --
> Alexander Kriegisch
> https://scrum-master.de
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Running tests from a test jar

[Thomas Broyer]

Dependencies declared with scope=test in the original project
(google-cloud-storage) won't come in transitively, you'd have to copy/paste
them.

Ideally, if that use case were to be officially supported, the project
would have to publish the tests as a normal JAR at different coordinates,
so it would have all its dependencies with scope compile (or runtime), and
you would get them transitively.

Le mer. 31 mars 2021 à 21:59, Elliotte Rusty Harold  a
écrit :

> I'm attempting to run the tests in a test jar rather than from source,
> for reasons. That is, I set up the pom.xml like so to run the tests
> that are bundled in
> com.google.cloud:google-cloud-storage:test-jar:tests
>
>   
> 
>   
> org.apache.maven.plugins
> maven-surefire-plugin
> 3.0.0-M5
> 
>   
>
> com.google.cloud:google-cloud-storage:test-jar:tests:*
>   
> 
>   
> 
>   
>
> The problem I'm running into is that a lot, though not all,
> dependencies seem to be non-transitive. I have to manually add the
> various dependencies to the dependencies section. Is there any way
> around this?
>
> There's a more complete pom.xml here:
>
>
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/pull/2003/files
>
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Add command-line options to the javadoc plugin?

[Thomas Broyer]

 ?
https://maven.apache.org/plugins/maven-javadoc-plugin/jar-mojo.html#additionalOptions

Though many (all?) options can be set directly through plugin properties.

Le sam. 27 mars 2021 à 02:35, leerho  a écrit :

> I can't find adequate documentation on how to add command line arguments /
> options to the Javadoc plugin. The following does not work:
>
> 
> >   org.apache.maven.plugins
> >   maven-javadoc-plugin
> >   ${maven-javadoc-plugin.version}
> >   
> > 
> >   -J--add-exports=java.base/sun.nio.ch
> > =ALL-UNNAMED
> >
> >
> -J--add-exports=java.base/jdk.internal.ref=ALL-UNNAMED
> > 
> >   
> >   
> > 
> >   attach-javadocs
> >   
> > jar
> >   
> > 
> >   
> > 
>
> This is using JDK11, Maven 3.6.3_1, and Javadoc plugin 3.2.0.
>
> Any help would be appreciated!
>
> Lee.
>

Re: maven-assembly-plugin v3.3.0 - how to modify generated MANIFEST.MF

[Thomas Broyer]

Use the 'archive' property of the assembly plugin itself (not in the
assembly descriptor):
http://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#archive

Le jeu. 18 févr. 2021 à 11:23, Jean-Pierre Urkens
 a écrit :

> Hi all,
>
>
>
> I am trying to generate a ‘jar’ assembly that contains a ‘Main-Class’ in
> the META-INF/MANIFEST.MF. Now it looks like the assembly plugin is
> generating its own (plexus archiver) MANIFEST file with contents:
>
>Manifest-Version: 1.0
>
> Created-By: Plexus Archiver 4.2.1
>
>
>
> My idea was to include via a  my own MANIFEST.MF file specifying
> the Main-Class and ‘append’ this to the generated MANIFEST using the
> ‘file-aggregator’ containerDescriptorHandler in my descriptor file:
>
>
>
>   
>
> 
>
>   file-aggregator
>
>   
>
> .*/MANIFEST.MF
>
> META-INF/MANIFEST.MF
>
>   
>
> 
>
>   
>
>
>
> This didn’t work so I was wondering whether it found my manifest file. So I
> adjusted the above configuration to write to ‘test/
> META-INF/MANIFEST.MF’.
>
> My own manifest file resides under ‘db/MANIFEST.MF’ and should be picked up
> by:
>
>
>
>   
>
> 
>
>   ${project.build.directory}/classes
>
>   
>
>   false
>
>   
>
> db/**
>
>   
>
> 
>
>   
>
>
>
> Now it does generate an ‘test/META-INF/MANIFEST.MF’ but with following
> contents:
>
># Aggregated on Thu Feb 18 11:18:39 CET 2021 from:
>
>
>
> So it looks that the content of my ‘db/MANIFEST.MF’ isn’t included. What am
> I missing? How can I add my own content to the generated manifest file of
> this plugin?
>
>
>
> Tanks for any hints,
>
>
>
> J.P.
>

Re: License - 301 Moved Permanently

[Thomas Broyer]

Well, at a minimum, http:// is redirecting to https:// so that explains the
301.

Le dim. 14 févr. 2021 à 21:13, Anthony Whitford  a
écrit :

> I just noticed that my generated Site isn’t properly including the MIT
> License.
>
> In my pom.xml, I have:
>
>   
> 
>   The MIT License
>   http://www.opensource.org/licenses/MIT
>   repo
> 
>   
>
> And I also have a LICENSE file in the Project’s root.
>
> The url is valid.  However, the generated licenses.html file shows:
>
> Project Licenses
> The MIT License
> [Original text]
> Copy of the license follows:
>
> 301 Moved Permanently
> nginx/1.14.0 (Ubuntu)
>
>
> The [Original text] link works — it points to
> http://www.opensource.org/licenses/MIT <
> http://www.opensource.org/licenses/MIT> — but the “copy of the license”
> is obviously not working.
>
> Note that I am using:
> • Apache Maven 3.6.3
> • JDK 15.0.1
> • The latest maven-project-info-reports-plugin — version 3.1.1
> • running on macOS Big Sur 11.2.1
>
> I double checked the POM documentation here:
> http://maven.apache.org/pom.html#licenses
> However, I do not see a problem.
>
> Do I have a problem with the pom’s license configuration?
>
>

Re: Releasing a subset of the Reactor

[Thomas Broyer]

How about (in addition to disabling the deploy plugin, just in case)
putting those submodules into a profile, enabled by default, but disabled
during release? (e.g. through a "-P !tests" or "-Dit-tests=false" in
 and the appropriate activation for the profile)

On Fri, Feb 5, 2021 at 2:16 PM Andres Almiray  wrote:

> Hi Maarten,
>
> Yup, this is a matter of fact an attempt to configure the Layrry build to
> publish its artifacts to Maven Central and make it happen with a single
> release commit.
>
> I’ve got the deploy plugin configured in such a way they it will skip
> tests and examples. That works. However the release plugin complains about
> duplicate reactor modules (rightly so). I know I can change versions and
> tag manually but I’d rather have it automated hence the use of the release
> plugin.
>
> Perhaps there’s a different way to do this? What I need is:
> - given a subset of the Reactor:
>   - attach sources and javadoc jars (done)
>   - sign artifacts (done)
>   - publish to Maven Central
>  - deploy plugin?
>  - release plugin?
>   - automatic promotion from staging to production at MC.
>
> Any tips to make this happen would be greatly appreciated.
>
> Thanks!
>
> Sent from my primitive tricorder
>
> > On 5 Feb 2021, at 13:17, Maarten Mulders  wrote:
> >
> > Hi Andres,
> >
> > If its just about deploying the modules to a remote repo, you could set
> the skip property of the maven-deploy-plugin. I've applied that trick in a
> Maven plug-in I've made [1]; their integration tests don't need to be in
> Central, but all other modules should. In this scenario, the integration
> tests are versioned (tagged in Git) together with the actual code, but they
> don't get uploaded.
> >
> > HTH,
> >
> > Maarten
> >
> >
> > [1] https://github.com/mthmulders/puml-maven-plugin
> >
> >> On 05/02/2021 13:06, Andres Almiray wrote:
> >> Hello everyone,
> >> Does anyone know if it's possible to release justa  subset of the
> Reactor
> >> when using the maven-release-plugin?
> >> The Layrry build includes a set of modules (examples and integration
> tests)
> >> that should not be part of the release. And added hurdle is that there
> are
> >> "duplicate" modules, that is same groupId:artifactId but different
> version
> >> for a couple of modules (I know, weird) which are needed to test
> Layrry's
> >> capabilities to deal with conflicting module versions.
> >> As it stands right now the release plugin attempts to release the whole
> >> Reactor and croaks when it finds duplicate modules.
> >> I haven't found a *.skip property like other plugins have.
> >> TIA.
> >> Cheers,
> >> Andres
> >> ---
> >> Java Champion; Groovy Enthusiast
> >> http://andresalmiray.com
> >> http://www.linkedin.com/in/aalmiray
> >> --
> >> What goes up, must come down. Ask any system administrator.
> >> There are 10 types of people in the world: Those who understand binary,
> and
> >> those who don't.
> >> To understand recursion, we must first understand recursion.
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: BOM vs Parent inheritance

[Thomas Broyer]

Actually, I'd say those BOMs probably shouldn't declare jackson. The
project's dependencies should be enough, and you explicitly declare the
version you need/want to use.
In the case of the OCI BOM, it seems quite clear that it mistakenly
inherits dependency management from it's parent POM: most BOMs shouldn't
have a parent, or their parent shouldn't include dependency management for
their submodules.

Le jeu. 4 févr. 2021 à 00:56, Rupert Madden-Abbott <
rupert.madden.abb...@gmail.com> a écrit :

> Hi,
>
> I have the following structure in my pom:
>
> My pom <- import oci-java-sdk-bom <- parent = ocj-java-sdk
> ^
> |
> parent = spring-boot-starter-parent
> ^
> |
> parent = spring-boot-dependencies <- import jackson-bom
>
>
> Both jackson-bom and oci-java-sdk have a dependency management section and
> declare jackson-databind and I am also using this dependency in my pom.xml
> without specifying a version.
>
> I have found that the version from oci-java-sdk is used and not the version
> from jackson-bom (via spring boot). I naively expected that anything pulled
> in from my pom's parent would instead take precedence.
>
> Why is this? Is it because the oci-java-sdk is 2 hops from my pom and the
> jackson-bom is 3 hops? Is there anything I can do to control this such that
> the versions defined in my parent "win"?
>
> Where are these rules documented so I can work this out for myself in the
> future?
>
> Are there any tools/plugins that can help say why a given version has been
> selected?
>

Re: Preferred way to execute Maven goals/phases from Maven plugins

[Thomas Broyer]

I'm not familiar with Maven Invoker, but the Maven Invoker Plugin does not
have such code.
It will call setMavenHome only if there's a configured value:
https://github.com/apache/maven-invoker-plugin/blob/dfd3c3680f31cb36ef1c14c18f4ea8b8d6115151/src/main/java/org/apache/maven/plugins/invoker/AbstractInvokerMojo.java#L2104-L2109
See also
https://maven.apache.org/shared/maven-invoker/usage.html#Configuring_the_Maven_Home_Directory:
“You can use the method Invoker.setMavenHome() to specify which Maven
executable it should use. If you don't provide an explicit value for this
setting, the Invoker will automatically try to detect a Maven installation
by evaluating the system property maven.home and the environment variable
M2_HOME.”

On Mon, Nov 2, 2020 at 1:00 PM Nick Stolwijk 
wrote:

> Thanks,
>
> I looked at the Maven Release Plugin and I see that the logic of where
> Maven is installed is not in the Maven-Invoker, but in the release plugin
> [1]. There is some logic on how to 'find' Maven, using environment
> variables like 'maven.home', 'MAVEN_HOME' and 'M2_HOME'. Does this mean
> that the choice of which setting is used and in which order is still the
> responsibility of the calling plugin? Or is there some standard for that?
>
> [1]
>
> https://github.com/apache/maven-release/blob/dbdf3a4a8cb8db51fa73963912555be4f39a89b8/maven-release-manager/src/main/java/org/apache/maven/shared/release/exec/InvokerMavenExecutor.java#L318
>
> With regards,
>
> Nick Stolwijk
>
> ~~~ Try to leave this world a little better than you found it and, when
> your turn comes to die, you can die happy in feeling that at any rate you
> have not wasted your time but have done your best ~~~
>
> Lord Baden-Powell
>
>
> On Mon, Nov 2, 2020 at 12:27 PM Thomas Broyer  wrote:
>
> > Maybe have a look at Maven Invoker:
> > https://maven.apache.org/shared/maven-invoker/
> > (it's what the Maven Invoker Plugin and Maven Release Plugin use)
> >
> > On Mon, Nov 2, 2020 at 11:28 AM Nick Stolwijk 
> > wrote:
> >
> > > Hi folks,
> > >
> > > We are struggling with our buildserver (Jenkins) and the Git-Flow Maven
> > > Plugin[1] with regards to execute the Maven executable to run specific
> > > goals and phases during release (i.e. run versions plugin to change
> > version
> > > or run `mvn verify` to check project).
> > >
> > > The gitflow-m-p uses a flag to set the executable which needs to know
> if
> > it
> > > is on Linux (run mvn) or Windows (run mvn.cmd).
> > >
> > > I was wondering what is the 'right' way to execute Maven from a plugin.
> > > I've taken a look at the Maven Release Plugin and that one uses an
> > internal
> > > Executor framework. I have thought about Toolchain, but I didn't find
> an
> > > example of a toolchain with Maven itself.
> > >
> > > Can anyone enlighten me?
> > >
> > > [1] https://github.com/aleksandr-m/gitflow-maven-plugin
> > >
> > > With regards,
> > >
> > > Nick Stolwijk
> > >
> > > ~~~ Try to leave this world a little better than you found it and, when
> > > your turn comes to die, you can die happy in feeling that at any rate
> you
> > > have not wasted your time but have done your best ~~~
> > >
> > > Lord Baden-Powell
> > >
> >
> >
> > --
> > Thomas Broyer
> > /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> <
> http://xn--nna.ma.xn--bwa-xxb.je/> <
> > http://xn--nna.ma.xn--bwa-xxb.je/>
> >
>


-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: Preferred way to execute Maven goals/phases from Maven plugins

[Thomas Broyer]

Maybe have a look at Maven Invoker:
https://maven.apache.org/shared/maven-invoker/
(it's what the Maven Invoker Plugin and Maven Release Plugin use)

On Mon, Nov 2, 2020 at 11:28 AM Nick Stolwijk 
wrote:

> Hi folks,
>
> We are struggling with our buildserver (Jenkins) and the Git-Flow Maven
> Plugin[1] with regards to execute the Maven executable to run specific
> goals and phases during release (i.e. run versions plugin to change version
> or run `mvn verify` to check project).
>
> The gitflow-m-p uses a flag to set the executable which needs to know if it
> is on Linux (run mvn) or Windows (run mvn.cmd).
>
> I was wondering what is the 'right' way to execute Maven from a plugin.
> I've taken a look at the Maven Release Plugin and that one uses an internal
> Executor framework. I have thought about Toolchain, but I didn't find an
> example of a toolchain with Maven itself.
>
> Can anyone enlighten me?
>
> [1] https://github.com/aleksandr-m/gitflow-maven-plugin
>
> With regards,
>
> Nick Stolwijk
>
> ~~~ Try to leave this world a little better than you found it and, when
> your turn comes to die, you can die happy in feeling that at any rate you
> have not wasted your time but have done your best ~~~
>
> Lord Baden-Powell
>


-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: Maven Plugins & Confusing Versioning

[Thomas Broyer]

(sorry for the delay)

On Sat, Oct 3, 2020 at 5:27 PM Karl Heinz Marbaise 
wrote:

> Hi,
>
> On 03.10.20 11:47, Thomas Broyer wrote:
> > Wait, you mean that you don't even follow your own rules for versions ⁉️
> > where milestones sit between beta and RC versions.
>
> Can you explain which rules you are referencing?
>

I meant those:
https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning
https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java#L356
https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java#L48
and as shown by that command:
$ java -jar /opt/maven/lib/maven-artifact-3.6.3.jar 3.0.0-beta1 3.0.0-M1
3.0.0-RC1 3.0.0
Display parameters as parsed by Maven (in canonical form) and comparison
result:
1. 3.0.0-beta1 == 3-beta-1
   3.0.0-beta1 < 3.0.0-M1
2. 3.0.0-M1 == 3-milestone-1
   3.0.0-M1 < 3.0.0-RC1
3. 3.0.0-RC1 == 3-rc-1
   3.0.0-RC1 < 3.0.0
4. 3.0.0 == 3

The part M... is from our perspective a milestone in direction to a
> particular set of features that has nothing to do with not stable... for

example see https://maven.apache.org/surefire/maven-failsafe-plugin/



I'm for example using maven-release-plugin:3.0.0-M1 in production...
> You can take a look into the CI results
> (
> https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-release/job/master/
> )
> or the tests which are running on them:
>
> https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-release/job/master/lastCompletedBuild/testReport/
>
>
> The question based on that is comming up:
>
> What do you define as "unstable" ? All of those plugins are already
> running very long (I mean very long) in production environments ... so
> of course sometimes people find bugs ...
>
>
> As Enrico alrady mentioned ...we don't release unstable plugins... (but
> it drills down to the question: What is a unstable plugin?)


The question to me is: should anyone use a milestone version? What are the
"guarantees" compared to a "final" version?
If you're saying that there's no reason not to use a milestone in
production, that it's guaranteed to work just as well as a "final" version,
then why isn't it labelled "final"?
When I see a milestone version (or any "prerelease" version), I'm thinking
"OK, they're still working on it (hey, it's not even a release candidate),
let's use the latest "final" release" (in this case 2.5.3;
https://search.maven.org/artifact/org.apache.maven.plugins/maven-release-plugin
).
I also expect that if there are bugs in that latest "final" release that
possibly there could be a "point release" fixing them (2.5.4) before the
next major version is "stable" (3.0.0)
So of course such a "prerelease" could be "stable enough" to be used in
production, but who knows in which ways it could possibly break? or change
in backwards-incompatible ways in a future 3.0.0-M2 or the final 3.0.0?
Only people following the plugin's development closely can know.

So, if the message you want to send is "use that 3.0.something version,
it's absolutely OK for production use (and btw we'll fix 2.5.3 bugs in a
3.0.0-M2, not a 2.5.4)", then tag it as 3.0.0 (or 2.5.4 or 2.6.0), not
3.0.0-M1.
If you want to make it clear that some feature is not "stable" yet (in its
API/configuration, or possibly buggy), then you could add warnings in the
docs and even issue a warning at runtime if it's being used (I know people
don't pay attention to warnings, and I think mostly because Maven output is
quite/too verbose, but still).

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: Maven Plugins & Confusing Versioning

[Thomas Broyer]

Wait, you mean that you don't even follow your own rules for versions ⁉️
where milestones sit between beta and RC versions.

Le sam. 3 oct. 2020 à 09:57, Enrico Olivelli  a écrit :

> Lukas,
> The general rule is that we are not releasing unstable versions so it is
> generally safe and good to upgrade to lasted version.
>
> The 3.x means that the plugin is compatible with Maven 3.x (if you see 2.x
> than it should work with Maven 3. But it was released when the reference
> Maven version was 2.x)
>
> The Mx suffix is only an internal version to the dev team of Maven. We mean
> that it is a milestone in a sense that we would have wanted to deliver a
> feature that is not implemented completely yet.
> You should care about that only of you write extensions that depend of that
> specific plugin.
>
> We are usually cutting versions only from the master branch and the master
> branch is continuously tested against a big matrix of OSs, Maven versions
> and Java version.
>
> I hope that helps
> Enrico
>
> Il Sab 3 Ott 2020, 09:30  ha scritto:
>
> > Hi All & Maven Devs
> >
> >
> >
> > My name is Lukas, I'm a software engineer working at some very little
> > company located in Switzerland (called Quatico).
> >
> > I wanted to let you know that the versioning that is used in (as far as I
> > can see) all Maven Plugins (e.g. Apache Maven Install Plugin 3.0.0-M1) is
> > very confusing .
> >
> > I can see on the corresponding Website (e.g.
> > https://maven.apache.org/plugins/maven-install-plugin/download.cgi ) the
> > these milestone releases are declared to be stable.
> >
> >
> >
> > My company did not upgrade plugin versions basically for some years now
> > because (when just seeing the version itself) decided "Nope, its only a
> > milestone, thus not stable".
> >
> > So in contrast to the maven plugin versions, the community is pretty
> clear
> > about what x.y.z-M1 means: It's a pre-release for early testing purposes
> > (e.g. see you "partner" projects explanation for it here
> > https://en.wikipedia.org/wiki/Software_versioning ).
> >
> >
> >
> > I don't want to complain (I now know the versions are stable) but the
> usage
> > of your new version would probably pike much quicker around the work if
> you
> > followed the "regular" versioning scheme.
> >
> > Why use the Major part (3), then completely ignoring Minor (always 0) and
> > Patch (always 0 as well) parts, to then fall back to Milestones? I cannot
> > see an advantage in it.
> >
> >
> >
> > Hope the input might help!
> >
> >
> >
> > Cheers
> >
> > Lukas
> >
> >
> >
> >
>

Re: How should I represent a library with two configurations in Maven Central?

[Thomas Broyer]

+1
Use version suffixes, and think about deploying Gradle Module Metadata so
Gradle users can see them as variants of one another and more accurately
pick a version:
https://docs.gradle.org/current/userguide/publishing_gradle_module_metadata.html
and e.g. https://github.com/google/guava/pull/3683

Le lun. 21 sept. 2020 à 23:18, Jörg Schaible  a
écrit :

> Hi Alan,
>
> On Sonday, 20. September 2020, 23:50:21 CEST Alan Snyder wrote:
> > I’ve posted a question on StackOverflow that has not yet been answered.
> > Perhaps someone here has an answer?
> >
> > https://stackoverflow.com/q/63906798/1652984?sem=2
> > 
>
> If it is A or B exclusively, use the alternatives as part of the version
> string. See
> - postgres (https://search.maven.org/artifact/org.postgresql/postgresql[1]
> )
> - xstream (
> https://search.maven.org/artifact/com.thoughtworks.xstream/xstream[2] )
>
> Bouncycaste uses the alternative as part of the artifactId:
> - https://search.maven.org/search?q=g:org.bouncycastle[3]
>
> However, I have often to "manage" 3rd party libraries manually that
> reference one of the
> BC artifacts that should not be used together by using exclusions.
>
> Using a classifier is worse, because exclusions do not work on classifiers.
>
> Regards,
> Jörg
>
> 
> [1] https://search.maven.org/artifact/org.postgresql/postgresql
> [2] https://search.maven.org/artifact/com.thoughtworks.xstream/xstream
> [3] https://search.maven.org/search?q=g:org.bouncycastle
>

Re: Excluding source files even if they are referenced

[Thomas Broyer]

On Mon, Sep 14, 2020 at 1:41 PM Alex Gerdov 
wrote:

> Hello,
>
> I was wondering - is it possible to instruct the compiler plug-in to
> exclude source files even if they are referenced directly by other source
> files?
>

It depends what you're trying to do.
You can exclude [1] those files, but then because the maven-compiler-plugin
sets the sourcepath to your source roots, the files will be compiled anyway
if they are referenced by others that are being compiled [2].
You could use -implicit:none in compilerArgs to prevent the corresponding
*.class file from being generated though. So compilation will succeed, but
the output will be "incomplete" (but maybe that's what you want after all).

[1]
https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#excludes
[2] https://blog.ltgt.net/most-build-tools-misuse-javac/

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: does order of dependencies in dependemcymanagement matter?

[Thomas Broyer]

I am *really* not sure about this statement, at least for
dependencyManagement.

For pluginManagement, yes, order doesn't matter. The order in build/plugins
matter, but not pluginManagement/plugins.

For dependencyManagement, if you import BOMs with
importpom, then there could be duplicates and
order matters then (see Question #13 in
http://andresalmiray.com/maven-dependencies-pop-quiz-results/)

On Wed, Jul 8, 2020 at 2:46 PM Tomo Suzuki 
wrote:

> The order does not matter. I usually sort them alphabetically so that I can
> easily find duplicates.
>
> On Wed, Jul 8, 2020 at 02:11 彭宁均  wrote:
>
> > hi,
> > guys!
> > in my team, we use dependencymanagement to manage the version of hundreds
> > dependencies. Now i want to adjust the order of dependencies to make it
> > more clear. So i am wondering does order of dependencies in
> > dependemcymanagement matters?
> > and also, does order of plugins in pluginmanagement matters?
> >
> >
> > thanks!
>
> --
> Regards,
> Tomo
>


-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: How to download zip instead of jar from maven repo...

[Thomas Broyer]

This is not a Maven plug-in either.

A quick Google search surfaced
https://gleclaire.github.io/codenarc-maven-plugin/ though.

Le mar. 7 juil. 2020 à 20:33, LINUS FERNANDES  a
écrit :

> Ok. Thanks.
>
> My mistake, apparently.
>org.codenarc  groupId>  CodeNarc   artifactId>   1.6
>   
>
> I've also had issues with the above.
>
>  failed to get report for org.codenarc:CodeNarc: Failed to parse plugin
> descriptor for org.codenarc:CodeNarc:1.6
> (/root/.m2/repository/org/codenarc/CodeNarc/1.6/CodeNarc-1.6.jar): No
> plugin descriptor found at META-INF/maven/plugin.xml -> [Help 1]
>
> What's this about?
>
> Thanks,
> Linus.
>
>
> On Tue, 7 Jul 2020, 22:20 Thomas Broyer,  wrote:
>
> > This is a Grails plugin, not a Maven plugin.
> > http://grails.org/plugin/codenarc
> >
> > On Tue, Jul 7, 2020 at 5:42 PM LINUS FERNANDES <
> linus.fernan...@gmail.com>
> > wrote:
> >
> > > I'm trying to use the following maven plugin to run static code
> analysis
> > on
> > > groovy scripts.
> > >
> > > 
> > >   org.grails.plugins
> > >   codenarc
> > >   1.6
> > > 
> > >
> > > I added the plugin repositories as below since it's not hosted on the
> > > superPom's repos.
> > >
> > >
> > > 
> > >   grails-plugins
> > >   Grails Plugins Repository
> > >   https://repo.grails.org/grails/plugins
> > > 
> > >   
> > >
> > > However, I encounter an error downloading the dependencies since maven
> > > expects a codenarc:jar file but a zip file is provided instead.
> > >
> > > How do I force Maven to download the zip file instead, preferably
> > > configuring it within the pom?
> > >
> > >
> > > Regards,
> > > Linus.
> > >
> >
> >
> > --
> > Thomas Broyer
> > /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> <
> http://xn--nna.ma.xn--bwa-xxb.je/> <
> > http://xn--nna.ma.xn--bwa-xxb.je/>
> >
>

Re: How to download zip instead of jar from maven repo...

[Thomas Broyer]

This is a Grails plugin, not a Maven plugin.
http://grails.org/plugin/codenarc

On Tue, Jul 7, 2020 at 5:42 PM LINUS FERNANDES 
wrote:

> I'm trying to use the following maven plugin to run static code analysis on
> groovy scripts.
>
> 
>   org.grails.plugins
>   codenarc
>   1.6
> 
>
> I added the plugin repositories as below since it's not hosted on the
> superPom's repos.
>
>
> 
>   grails-plugins
>   Grails Plugins Repository
>   https://repo.grails.org/grails/plugins
> 
>   
>
> However, I encounter an error downloading the dependencies since maven
> expects a codenarc:jar file but a zip file is provided instead.
>
> How do I force Maven to download the zip file instead, preferably
> configuring it within the pom?
>
>
> Regards,
> Linus.
>


-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: Reactor module dependency tree resolution

[Thomas Broyer]

IIUC you should be able to do that using Project#getReferencedProjects(),
you may have to first call Project#getExecutionProject().
Have a look at
https://github.com/tbroyer/gwt-maven-plugin/blob/master/src/main/java/net/ltgt/gwt/maven/AbstractDevModeMojo.java
and
see if it somehow fits your use-case (here, I get all dependency artifacts
to build a classpath for a forked jvm, and possibly replace some of them
with the corresponding reactor project's source roots)

On Fri, Apr 24, 2020 at 2:47 PM Christian Domsch  wrote:

> Hi,
>
> I would like to be able to get access to the reactor module tree. I have a
> specific plugin that is executed for each reactor module and it needs to
> check, if for a predefined set of modules in the reactor (in our case war
> archives that contain a subset of all modules) see if the current module is
> actually contained in that war (directly or via transitive dependencies).
>
> What I tried so far, but isn't working, is using the aether dependency
> resolution mechanism. The reason why it isn't working is fairly obvious:
> checking the transitive dependencies of these war modules, aether tries to
> download all artifacts first and fails because they haven't been build by
> the reactor, yet, and thus are unknown. This makes a lot of sense, but also
> means this way won't help me.
>
> Now, the reactor itself has to be able to calculate those dependencies, as
> it will calculate a certain order of building the modules, depending on how
> those modules depend on each other. This (what I will call) reactor module
> tree is exactly the information I need.
>
> Is there a way to access this information from a plugin? ${reactorProjects}
> does not tell me that. Or am I missing sth very obvious?
>
> Thx,
>
> Christian
>


-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: Overwriting the "central" from settings.xml when importing bom pom files

[Thomas Broyer]

Not a direct answer but what if you use a  rather overriding the
"central" ?
https://maven.apache.org/guides/mini/guide-mirror-settings.html

Le dim. 15 mars 2020 à 18:17, tic01  a écrit :

> Hi team,
>
> When resolving bom artifacts, the following method is invoked -
> org.apache.maven.model.building.DefaultModelBuilder#configureResolver(
> ModelResolver modelResolver, Model model, DefaultModelProblemCollector
> problems, boolean replaceRepositories )
>
> The 'replaceRepositories' parameter is invoked with a value of 'true' which
> means that Maven looks up the lineage of of projects to find a repository.
> This has the effect that if for example you have in your settings.xml a
> repository with the id "central" set to "REPO A" it will replace that with
> repo1.
>
> Is this the desired behavior? Is there a way to tell Maven not to override
> the repositories that I have in my Maven settings.xml as this causes
> unsable
> builds if you are behind a company firewall and must use a middle-man
> (Nexus/Artifactory).
>
> Thanks,
>
> Tomer
>
>
>
>
>
> --
> Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Problem with the maven-compiler-plugin

[Thomas Broyer]

What is it that you think is not working?

(fwiw, javaP -version prints the version of javaP, not the version the
class was compiled with/to; that would be a 51.0 or similar anyway, not a
1.7)

Le ven. 13 mars 2020 à 08:26, Nelligan, Steven M  a
écrit :

> *It appears that the maven-compiler-plugin is not working or I am doing
> something wrong.*
>
>
>
> *I have the following in the POM file.*
>
> 
>
> 
>
> 
>
> org.apache.maven.plugins
>
> maven-compiler-plugin
>
> 3.8.1
>
> 
>
> true
>
> 1.7
>
> 1.7
>
> 1.7
>
> 
>
> 
>
> 
>
> 
>
>
>
>
>
> *MAVEN INFORMATION:*
>
> C:\dev\Projects\accountentry_js22>mvn -version
>
> Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
> 2019-08-27T10:06:16-05:00)
>
> Maven home: C:\Program Files\apache-maven-3.6.2\bin\..
>
> Java version: 1.7.0_80, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk1.7.0_80\jre
>
> Default locale: en_US, platform encoding: Cp1252
>
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"
>
>
>
> *Default JAVA INFORMATION:*
>
> C:\dev\Projects\accountentry_js22>java -version
>
> openjdk version "1.8.0_242"
>
> OpenJDK Runtime Environment Corretto-8.242.08.1 (build 1.8.0_242-b08)
>
> OpenJDK 64-Bit Server VM Corretto-8.242.08.1 (build 25.242-b08, mixed mode)
>
>
>
> *MVN Command:*
>
> mvn clean install –U
>
>
> (see attached mvn_output.txt which contains the maven output)
>
>
>
> *JAVAP returns the following:*
>
>
>
> C:\dev\Projects\accountentry_js22\target\classes\edu\uiuc\fs\accountentry>javaP
> -version AccountContainer.class
>
> 1.8.0_242
>
> Compiled from "AccountContainer.java"
>
> public interface edu.uiuc.fs.accountentry.AccountContainer {
>
>   public abstract void
> setSelectedFundingCode(org.apache.wicket.ajax.AjaxRequestTarget,
> java.lang.String);
>
>   public abstract java.lang.String getSelectedFundingCode();
>
>   public abstract java.lang.String getCollegeCode();
>
>   public abstract java.lang.String getDeptCode();
>
>   public abstract boolean showFSPays();
>
> }
>
>
>
>
>
>
>
> *Steven M Nelligan*
> *APPLICATION DEVELOPER*
>
>
> Facilities and Services
>
> Information Technology Services
> University of Illinois at Urbana-Champaign
> Facilities and Services
> 1501 S. Oak Street | M/C 800
> Champaign, IL 61820
> 217.244.8097 | *other*: 217.244.8097 | snell...@illinois.edu
> www.fs.illinois.edu
>
> [image: facebook]
> [image:
> twitter] [image: instagram]
> [image: youtube]
> 
>
> [image: https://webtools.illinois.edu/webservices/js/ds/signature_logo.png]
> 
>
> *Under the Illinois Freedom of Information Act any written communication
> to or from university employees regarding university business is a public
> record and may be subject to public disclosure.*
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org

Re: build maven project without setting compiler source and target

[Thomas Broyer]

here're version mismatches wich may cause this
> - I'm not sure about that.
> So, as I don't want to set a fixed value (maybe would be 8 if I have to)
> I would rather prefer to disable this settings at all and just let it
> compile with what ever version the system has a JDK of. Or, if it's not
> possible to complete throw it out is there at least a way to not just
> set a specific version but rather only a minimum? So, that a system wich
> has only J8 can use this, but other system with 9, 11, 13 won'T be
> enforced to compile v8 but with their own version?
>
> As I also mentioned else where: I thought IDEs and all their build stuff
> is supposed to make developing easier - but I had so many issues I
> encountered since I started to use it a few days ago I really though of
> go back to basic editor and terminal - wich seems easier (side-note
> about dependency management: yes, sure, it's nice to have a build system
> handle it for you, but as I'm used to gather libs and dependencies
> myself, and many often come in bundles, and manage different and
> matching versions by myself, I got a rather big lib collection used by
> just point my system wide classpath to the lib directory).
>
> So, any thoughts about how to solve that issue? I'm honestly kind of
> lost, not just using Netbeans as a gui wrapper (as one of its devs
> called it on their list) but also get my head around maven as the build
> environment).
>
> Thanks for any help in advance,
>
> Matt
>
> Am 2020-02-17 05:24, schrieb Bernd Eckenfels:
> > Can you show the actual error message and give a concrete project?
> > Normally Maven works with not specifying target/source as long as your
> > JDK is recent enough. (But it's not ways a good idea, it's better to
> > specify the properties (IDEs normally read them)
> >
> >
> > --
> > http://bernd.eckenfels.net
> > 
> > Von: java-cry...@cryptearth.de 
> > Gesendet: Monday, February 17, 2020 4:27:16 AM
> > An: users@maven.apache.org 
> > Betreff: build maven project without setting compiler source and target
> >
> > So as I just got new into using Netbeans someone on its list explained
> > me, that it's just a gui wrapper around maven and it's adviced to get
> > the basics of maven to correctly use netbeans.
> > Ok, so as I just used a simple editor and a terminal it didn't mattered
> > wich version I compiled with or for in the past as I ran the class with
> > the same vm I compiled them with. So, the I thought I could just ommit
> > the setting - but maven just fails with an error that no source/target
> > version was specified. So I had them re-add by re-apply the project
> > settings.
> > Is there a way I could tell the compiler plugin just to ignore the
> > version but also to ignore if it's missing and just compile it with
> > whatever version I ran maven with?
> > It's basically: I use different systems all with different jdk
> > installed
> > - so when just clone the most recent version from github I always have
> > to set the correct version manual as netbeans doesn't seem to be handle
> > that by itself - and I could find an option to just get rid of it at
> > all.
> >
> > Thanks in advance,
> >
> > Matt
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: versioning by hashes to speedup multi-module build (a'la nix package manager)

[Thomas Broyer]

Le dim. 2 févr. 2020 à 17:48, Anton Vodonosov  a
écrit :

> Hello.
>
> In order to speed up the build of a multi-module project, I'd like to
> reuse artifacts of modules that haven't changed.
> Manual versioning is tedious and error-prone.
>
> Is it possible to automatically assign versions to modules computed as a
> hash-of( hash-of(module sources) + hashes of all dependencies)?
>

Please define modules sources?
Hint: you can't, at least not without knowing how all plugins work. Gradle
Enterprise tries to have such knowledge fwiw to solve this exact issue.

Also, you'll probably want to include system properties (or at least Maven
properties) and some environment information (e.g. which JDK) in the hash.

In this approach, every change in code will modify such hash-based version
> of all dependent modules automatically.
>
> This would be similar to Nix package manager.
>
> How to do that in maven?
>

As said above, you could try Gradle Enterprise. Takari had something in the
works too a few years ago.
…or if that's really problematic for you, then migrate to another build
tool, such as Gradle or Bazel.


> Best regards,
> - Anton
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: How to avoid forking in a maven build?

[Thomas Broyer]

In this specific case, what causes the forking is the javadoc:aggregate
goal. That one is meant to be used on the command line. If you want to bind
it to a build phase, you should use javadoc:aggregate-no-fork.
Also, javadoc:aggregate forks a "mvn compile", which will trigger the
frontend:webpack (et al.) because they're bound by default to the
generate-resources phase (which is odd if you ask me). You may want to bind
the frontend plugin's goals to another phase, such as prepare-package.

On Tue, Dec 31, 2019 at 4:04 PM Steinar Bang  wrote:

> This project https://github.com/steinarb/authservice has a lot of
> messages like this in the build output:
>
> [INFO]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> [INFO] Forking Authentication webapp 1.8.0-SNAPSHOT
> [INFO]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> [INFO]
> [INFO] --- maven-resources-plugin:3.1.0:resources (filter-resources) @
> authservice ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 1 resource
> [INFO]
> [INFO]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> [INFO] Forking Authentication webapp definitions bundle 1.8.0-SNAPSHOT
> [INFO]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> [INFO]
> [INFO] --- maven-resources-plugin:3.1.0:resources (filter-resources) @
> authservice.definitions ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /home/sb/workspaces/ws03/authservice/authservice.definitions/src/main/filtered-resources
> [INFO]
> [INFO] --- maven-resources-plugin:3.1.0:resources (default-resources) @
> authservice.definitions ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /home/sb/workspaces/ws03/authservice/authservice.definitions/src/main/resources
> ...
>
> A lot of the forking messages to be repeated, so I worry that it does
> some operations (e.g. the npm build of the frontend) way more times than
> it has to (ie. only once).
>
> Is the forking something that makes the build take longer than it has
> to?  Or is it harmless and nothing worth spending time to fix?
>
> I have tried to figure out who the culprit is. Maybe there are more than
> one culprit...?
>
> I thought maybe my use of the maven-resources-plugin in the parent was
> the cause of the forking.  So I moved the build of a master karaf
> feature repository out of the parent POM and into a module.  But that
> only got rid of the first forking in the quoted text abote.
>
> The full output from "mvn clean install" can be seen at:
>  https://gist.github.com/steinarb/169d179abec47f50d3aa5574ad8d7585
>
> Thanks!
>
>
> - Steinar
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: Configure default execution phase

[Thomas Broyer]

That would reconfigure which phase the mojo is bound to (if any, which is
not the case if the Liquibase plugin) when executed as part of the build
lifecycle; it won't allow you to fork a lifecycle when calling the goal
directly.

Le lun. 23 déc. 2019 à 15:02, Mark Prins  a écrit :

> You should be able to change the default execution phase of a plugin (as
> well as bind a goal to any other phase) by configuring explicit
> executions bound to a phase
>
> see: https://maven.apache.org/guides/mini/guide-default-execution-ids.html
>
> You would need to use an id of "default-update" to override the update
> goal.
>
> -M
>
>
> On 22-12-19 18:04, Stanimir Stamenkov wrote:
> > I'm having a POM like:
> >
> >  
> >  
> >  
> >  
> >  org.liquibase
> >  liquibase-maven-plugin
> >  3.8.3
> >  
> >  ...
> >  
> >  
> >  
> >  
> >  
> >
> > I don't want the plugin executed as part of the build but I want to be
> > able to execute its goals [1] explicitly.  The goals get executed
> > directly (no build phases get triggered), f.e.:
> >
> >  mvn liquibase:update
> >
> > but then it usually (while not necessarily, depending on project
> > configuration) require "process-resources" to be completed, so I have to:
> >
> >  mvn process-resources liquibase:update
> >
> > Is it possible to trigger "process-resources" automatically via plugin
> > configuration in POM (a`la Gradle's dependsOn [2]), or this is just
> > hard-coded in the plugin itself?
> >
> > [1] https://www.liquibase.org/documentation/maven/index.html
> > [2] https://docs.gradle.org/current/userguide/more_about_tasks.html
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Configure default execution phase

[Thomas Broyer]

It's hardcoded in the plugin (and this is why you have things like
sources:jar and sources:jar-no-fork depending on how you need/want to
invoke it)

Le dim. 22 déc. 2019 à 18:04, Stanimir Stamenkov
 a écrit :

> I'm having a POM like:
>
>  
>  
>  
>  
>  org.liquibase
>  liquibase-maven-plugin
>  3.8.3
>  
>  ...
>  
>  
>  
>  
>  
>
> I don't want the plugin executed as part of the build but I want to be
> able to execute its goals [1] explicitly.  The goals get executed
> directly (no build phases get triggered), f.e.:
>
>  mvn liquibase:update
>
> but then it usually (while not necessarily, depending on project
> configuration) require "process-resources" to be completed, so I have to:
>
>  mvn process-resources liquibase:update
>
> Is it possible to trigger "process-resources" automatically via plugin
> configuration in POM (a`la Gradle's dependsOn [2]), or this is just
> hard-coded in the plugin itself?
>
> [1] https://www.liquibase.org/documentation/maven/index.html
> [2] https://docs.gradle.org/current/userguide/more_about_tasks.html
>
> --
> Stanimir
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: A "?"/.m2 folder is created by Maven

[Thomas Broyer]

IIRC, Java's user.home system property does not depend on $HOME but on the
home of the current user as declared in /etc/passwd
If you want to set/change it, you need to set the system property with
-Duser.home=… (with Maven, you'd set it in $MAVEN_OPTS; I think you could
also use $_JAVA_OPTS to set it for each and every JVM)

Le sam. 14 déc. 2019 à 09:28, Jeff MAURY  a écrit :

> What's the value of $HOME
>
> Le sam. 14 déc. 2019 à 08:22, Leira Hua  a écrit :
>
> > I use Nix under Debian. I installed clojure through nix-shell -p clojure.
> > clj successfully started the repl after downloaded some poms from maven.
> > Then I found there is a folder named ‘?’ created under my $HOME. The
> maven
> > cache .m2 is under this ‘?’ folder. I tried leiningen, it is the same.
> >
> > I suppose it should be a Java related issue rather than Clojure. So I
> tried
> > to install Maven and try with mvn. A simple mvn archetype:generate
> created
> > a '?'/.m2 folder under the current folder. mvn clean -X|grep setting
> shows:
> >
> > $ mvn clean -X|grep setting
> > [DEBUG]   Imported: org.apache.maven.settings < plexus.core
> > [DEBUG] Reading global settings from
> >
> >
> /nix/store/jyrx2vh4kg1dhbyil63bclpkfhbq6r2i-apache-maven-3.6.2/maven/conf/settings.xml
> > [DEBUG] Reading user settings from ?/.m2/settings.xml
> >
> >
> > Where is this ‘?’ folder from? Is it expected behavior? How do I get rid
> of
> > it?
> >
> > Here is a screenshot showing the ‘?’ folder under  $HOME:
> > [image: Screenshot from 2019-12-04 18-40-35]
> > <
> >
> https://user-images.githubusercontent.com/39118/70199367-54c8c180-16c6-11ea-9cc7-d3c64a4cf619.png
> > >
> >
> >
> > Thanks,
> >
> > - Leira
> >
>

Re: 2 issues with maven version range

[Thomas Broyer]

On Tue, Nov 26, 2019 at 7:17 PM Karl Heinz Marbaise 
wrote:

> Hi John,
>
> On 24.11.19 20:46, John Patrick wrote:
> > i'm trying to start using maven version range more but having issues
> > with things like guava and also it not excluding version i believe
> > should be excluded.
> >
> > 1) i don't think this is possible but it might be, take a look a
> > google guava, it has a jre and a android version. using maven version
> > range how can i say any newer jre version, or any newer android
> > version?
> >
> > https://search.maven.org/artifact/com.google.guava/guava
> >
> > something like [25,) but only the jre maybe [25*-jre,)
>
>
> Let us start with Guava.
>
> The issue with Guava is that they made the `-jre` part of the version
> number which is from a Maven point of view simply wrong. This should
> have been done via a clas^sifier. Because -jre, -android are specialized
> packages which are valid for only particular environments.
>
>  From the documentation[1]:
> ```
> The classifier distinguishes artifacts that were built from the same POM
> but differ in content. It is some optional and arbitrary string that -
> if present - is appended to the artifact name just after the version
> number.
> As a motivation for this element, consider for example a project that
> offers an artifact targeting JRE 1.5 but at the same time also an
> artifact that still supports JRE 1.4. The first artifact could be
> equipped with the classifier jdk15 and the second one with jdk14 such
> that clients can choose which one to use.
>
> Another common use case for classifiers is to attach secondary artifacts
> to the project's main artifact. If you browse the Maven central
> repository, you will notice that the classifiers sources and javadoc are
> used to deploy the project source code and API docs along with the
> packaged class files.
> ```
> So an android package could simply be namind by using:
>
> g: com.google.guava
> a: guava
> v: 27.1
> classifier: jre
>
> etc.
> classifier: android
>
> Unfortunately they had decided to put this into the version which causes
> the issues. This in result means you can not select the version correctly.
>

Fwiw, and afaict, they did this for 2 reasons:

   - android and jre flavors don't have the same dependencies (checker-qual
   vs checker-compat-qual), so they can't just be differentiated by a
   classifier alone, they need separate POMs, which means different GAVs or
   different versions;
   - you cannot declare that two GAVs conflict with each other; if they had
   separate GAVs, dependencies could transitively bring both flavors, and the
   only way around that (after you detect it) would be to add exclusions.
   Using separate versions means that you only have one flavor at a time in
   your dependency tree, and dependencyManagement can be used to pin the
   version you want to actually use.

See https://github.com/google/guava/issues/2914 and
https://docs.google.com/document/d/1NYGbfz56C0Oh4IGymXjeQUVK4FcRiqDbpc4vGLnDMrY/edit?usp=sharing
(which I found out after writing the above, and didn't read in full yet)

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: POM parent/import relationship visualization

[Thomas Broyer]

Fwiw, you don't need NetBeans to get the effective POM: `mvn
help:effective-pom -Dverbose` should do.
https://maven.apache.org/plugins/maven-help-plugin/effective-pom-mojo.html

On Tue, Oct 29, 2019 at 5:55 PM Andy Feldman  wrote:

> Would `mvn dependency:tree -Dverbose -Dincludes=grpc-api` work in this
> case? The documentation uses it in a very similar situation, to find out
> the transitive dependency path to two different versions of the same
> dependency:
>
> https://maven.apache.org/plugins/maven-dependency-plugin/examples/resolving-conflicts-using-the-dependency-tree.html
>
>
>
> On Mon, Oct 28, 2019 at 6:58 PM Tomo Suzuki 
> wrote:
>
> > Hi Maven users,
> >
> > Do you know any visualization tool to show relationship (import/parent)
> of
> > POMs?
> >
> > Background:
> > Today, I encountered a situation where I had to dig parent/import
> > relationship of multiple POMs. I had to read pom.xml via
> search.maven.org
> > for each POM artifact.
> > Detail:
> > https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1001
> .
> > I wish I can troubleshoot in a better way next time.
> >
> > Regards,
> > Tomo
> >
> > --
> > Regards,
> > Tomo
> >
>


-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: Maven compiler plugin - test compiler arguments with double dash

[Thomas Broyer]

Declare the test-only arguments in an  (
https://maven.apache.org/guides/mini/guide-default-execution-ids.html#Example:_Configuring_compile_and_testCompile_mojos_separately),
and possibly (untested, but theoretically it would work) take advantage of
combine.children="append" (https://maven.apache.org/pom.html#Plugins) to
avoid repeating the plugin-level configuration (compared to the mini-guide
example: put the shared arguments in the plugin-level configuration, and
append the test-only one in the test execution's configuration)

On Wed, Oct 9, 2019 at 2:48 PM Lovro Pandzic 
wrote:

> But this approach also affects production compiler...
> So the full use case is:
> production: -parameters
> test: -parameters --enable-preview
>
> BR,
>
>
> Lovro Pandzic
> Division Lead, Enterprise Zagreb
> lovro.pand...@infobip.com
>
> On 09/10/2019, 14:46, "Karl Heinz Marbaise"  wrote:
>
> Hi,
>
> this is documented on the documentation page[1]
>
> which can be achieved by using the following:
>
> 
>[...]
>
>  [...]
>  
>
>  org.apache.maven.plugins
>  maven-compiler-plugin
>  3.8.1
>  
>
>  --enable-preview
>  wished supplemental option
>
>  
>
>  
>  [...]
>
>[...]
> 
>
> Kind regards
> Karl Heinz Marbaise
>
>
> [1]:
>
> https://maven.apache.org/plugins/maven-compiler-plugin/examples/pass-compiler-arguments.html
>
> On 09.10.19 14:23, Lovro Pandzic wrote:
> > Hello,
> >
> > I'd like to pass -parameters and enable-preview arguments to the
> test compiler but I can't figure out how, the closest I got is:
> >
> > 
> >  
> >  
> > 
> >
> > How can I pass two arguments to the test compiler where one of them
> requires double dash?
> >
> > Best Regards,
> >
> >
> >
> >
> > [
> https://cf-cdn.infobip.com/email_signature/Infobip_logo_vertical_signature.png
> ]<
> https://www.infobip.com?utm_medium=email_source=signature_campaign=reach%20%7C%20email%20%7C%20global%20%7C%20signature_term=all%20%7C%20recepient%20%7C%20mwc19_content=signature
> >
> >
> > Lovro Pandzic
> > Division Lead, Enterprise Zagreb
> >
> > lovro.pand...@infobip.com<mailto:lovro.pand...@infobip.com>
> >
> > [https://cf-cdn.infobip.com/email_signature/line.png]
> >
> >
> >
> > Office: Zadarska 80, 6th floor, 1 Zagreb, Croatia
> > Mobile: +385921001403
> >
> >
> > [https://cf-cdn.infobip.com/email_signature/roccovendor2019.png]<
> https://www.infobip.com/en/media/press-releases/rocco-awards-2019-infobip-rated-1-a2p-sms-messaging-vendor-by-enterprises-m>
>  [https://cf-cdn.infobip.com/email_signature/spacer.png]
> >
> > [https://cf-cdn.infobip.com/email_signature/Facebook.png]<
> https://www.facebook.com/infobip> [
> https://cf-cdn.infobip.com/email_signature/Linkedin.png] <
> https://www.linkedin.com/company/infobip>[
> https://cf-cdn.infobip.com/email_signature/Twitter.png] <
> https://twitter.com/Infobip>  [
> https://cf-cdn.infobip.com/email_signature/Instagram.png] <
> https://www.instagram.com/infobip/> [
> https://cf-cdn.infobip.com/email_signature/Youtube.png] <
> https://www.youtube.com/channel/UCUPSTy53VecI5GIir3J3ZbQ>
> www.infobip.com<
> https://www.infobip.com?utm_medium=email_source=signature_campaign=reach%20%7C%20email%20%7C%20global%20%7C%20signature_term=all%20%7C%20recepient%20%7C%20mwc19_content=signature
> >
> >
> >
> > GSMA Associate Member   /  Mobey Forum Member
> > This message is private and confidential. Any views or opinions
> expressed are solely those of the author and do not necessarily represent
> those of Infobip d.o.o. If you have received this message in error, please
> notify us immediately via email to customer.supp...@infobip.com customer.supp...@infobip.com> or telephone +442032864231.
> >
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>


-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: Same snapshot deploy number for entire build - possible

[Thomas Broyer]

Maybe you'd want to deployAtEnd?
https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#deployAtEnd

On Fri, Sep 13, 2019 at 12:03 PM Dan Tran  wrote:

> Looks like I need to clear thing a little bit
>
> Assume I have a reactor of few hundreds of maven modules and my CI
> build deploys snapshots, first few good builds, each module deployed to
> maven repository have same snapshot number
>
> Once we encounter a build failure at a module,  the snapshot number begins
> to vary and over time, all modules no longer have the same snapshot number
> anymore
>
> To be able to determine a consistent snapshot number at each build,  I
> would like to have an ability the tell deploy maven plugin to use an
> assigned number for all modules.
>
> Possible?
>
> Thanks
>
> -D
>
>
>
>
>
>
> On Thu, Sep 12, 2019 at 11:31 PM Enrico Olivelli 
> wrote:
>
> > Dan,
> > Are you running a single 'mvn deploy' or do you have multiple runs?
> > I have never seen weird behaviours in multi module projects
> >
> > Cheers
> > Enrico
> >
> > Il ven 13 set 2019, 08:19 Dan Tran  ha scritto:
> >
> > > Hello, Maven dev
> > >
> > > any suggestion/thoughts on this issue are very much appreciated
> > >
> > > Regards
> > >
> > > -D
> > >
> > > On Wed, Sep 11, 2019 at 7:06 PM Dan Tran  wrote:
> > >
> > > > Hello Maven Users and Development Team
> > > >
> > > > Currently, artifact deployed as snapshot at Maven repository has the
> > > > following format
> > > >
> > > >  artifactId-version-timestamp-NN
> > > >
> > > > where NN auto-incremented at each maven module and the number varies
> > > >
> > > > Is there a way to use same snapshot NN for the entire multi-module
> > maven
> > > > build?
> > > >
> > > > If I have to implement a solution, would it be as an extension or I
> > have
> > > > to tinker with maven-deploy-plugin?
> > > >
> > > > Very appreciated any advice
> > > >
> > > > -D
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
>


-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: the surefire maven plugin and codehaus

[Thomas Broyer]

On Sat, Jun 29, 2019 at 4:50 PM Tibor Digana  wrote:

> Where do we use dependency with groupId "org.codehaus.mojo"?
>

I wasn't replying to the surefire part of the OP, Tibor; only about
org.codehaus.mojo groupId and whether those are "dead components".

Re: the surefire maven plugin and codehaus

[Thomas Broyer]

 | FIS Investment Systems LLC, UK
> Establishment Registered in England & Wales (No: FC033836/Branch No.
> BR018923), Registered Branch Office: 25 Canada Square, London, E14 5LQ; FIS
> Investment Systems LLC is a limited liability company formed in the USA
> registered on file with the Office of the Delaware Secretary of State,
> Division of Corporations (File No. 0881255), Head Office: 377 E.
> Butterfield Road, Suite 800, Lombard, IL 60148, USA | Calls to and from the
> companies may be recorded for quality purposes. | All of the named
> companies are part of FIS (Fidelity National Information Services, Inc.).
>


-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: Problem with use of enforcer-plugin after upgrading the Apache parent POM (18->21)

[Thomas Broyer]

One of the POMs might need to use `combine.children="append"` on the
 element: https://maven.apache.org/pom.html#Plugins
No idea why that would only manifest during releases thoguh… have you
compared "mvn help:effective-pom" vs "mvn help:effective-pom
-Papache-release,release"?

On Mon, Jun 24, 2019 at 12:23 PM Julian Reschke 
wrote:

> Hi there,
>
> I've found a strange issue (well, strange to me) when I tried to upgrade
> Oak's parent POM from 18 to 21 (details at
> <https://issues.apache.org/jira/browse/OAK-8255>).
>
> The actual change that triggers the issue for us was between version 18
> and 19, which introduces the use of the enforcer plugin to check the
> Maven version
> (<
> https://github.com/apache/maven-apache-parent/commit/35c824cfef4d8ae3ec7234365635e43f57b8e05a#diff-600376dffeb79835ede4a0b285078036
> >,
> <https://issues.apache.org/jira/browse/MPOM-164>).
>
> In Oak, we use the enforcer plugin to check the size of a generated JAR
> file. After updating the parent POM, this check fails (or does not
> happen?) - if and only if when done using "release:prepare".
>
> To reproduce:
>
> - clone https://github.com/apache/jackrabbit-oak
> - update oak-parent/pom.xml to use version 21 instead of 18 of parent pom
> - run mvn:release-prepare -DdryRun=true -Darguments="-DskipTests"
>
> <https://github.com/apache/jackrabbit-oak/blob/trunk/oak-run/pom.xml#L157>
> is the place in oak-run's POM where we use the enforcer plugin.
>
> Are we doing something stupid here that conflicts with the use of the
> enforcer plugin in the Apache parent POM?
>
> Best regards, Julian
>
> ---------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Re: Maven adjusts transitive compile-scope dependency to test-scope

[Thomas Broyer]

There might be a rule in the enforcer plugin (I haven't checked). If one
really wanted to change the dependency scope, he could add an exclusion in
the Y dependency to break the transitivity.

Fwiw, whenever you change your dependencies, it's a good idea to run mvn
dependency:tree and look at the output (possibly diff'ing it with the
output prior to the dependency change).
Maven basically assumes that you take responsibility for the dependencies,
and it only takes the role of a helper resolving the whole tree.

Le mer. 15 mai 2019 07:42, Simon Taddiken  a
écrit :

> In my case, the pom of Y explicitly declares X with scope compile. The
> dependency tree should look something like this:
>
> MyProject <- this is a standalone application, that will not be depended on
> by s/o else
> |- X:test
> |- Y:compile
>\- X:compile
>
> So for MyProject, X is explicitly declared test but X also comes in
> transitively via Y as compile. I do understand that declarations higher in
> the tree are given precedence when it comes to dependency resolution but in
> this case it simply breaks runtime code.
> Of course I did not want to ship MyProject including X when I used X only
> for tests. But now that Y also requires X I need MyProject to ship with X
> in order to work correctly.
>
> I was just wondering whether there is some mechanism like a warning or a
> flag to break the build in such cases, so that they do not go unnoticed.
>
>
> Am Di., 14. Mai 2019 um 22:22 Uhr schrieb Jason Young <
> jason.yo...@procentive.com>:
>
> > Did you declare that Y depends on X at all (via Y's pom.xml) or did it
> > figure that out on its own (via transitive dependencies)?
> >
> > Test scope means it's for testing that one project, thus it's not
> > transitive, e.g. I don't need JUnit for my tests just because
> > SomeAwesomeProject uses JUnit for its tests, and I don't want to ship
> JUnit
> > in my project.
> >
> > On Tue, May 14, 2019 at 2:40 PM Simon Taddiken  >
> > wrote:
> >
> > > Hi everyone,
> > >
> > > I've encountered the following behavior and I'm not quite sure whether
> it
> > > is desirable.
> > > In my project, I have declared a dependency *X* with scope *test*. I
> then
> > > updated the version of a 3rd party dependency *Y*. In its new version,
> > *Y*
> > > suddenly requires the aforementioned dependency *X* as a *compile
> *scoped
> > > dependency.
> > >
> > > In this scenario, maven resolves the scope of *X* to be *test,
> *although
> > it
> > > is now required by *Y* during runtime, causing ClassNotFoundExceptions.
> > By
> > > the very nature of this behavior those mistakes can't even be detected
> in
> > > unit tests because *X* is available on test classpath.
> > >
> > > I have just found out that this behavior seems to be intended (
> > >
> > >
> >
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
> > > )
> > > but I can't really come up with a rationale for this design. Managing
> any
> > > transitive compile scoped dependency down to test scope will almost
> > > certainly cause ClassNotFoundExceptions during runtime.
> > >
> > > Thoughts?
> > >
> >
>

Re: Using maven-dependency-plugin:unpack in "mvn compile" build

[Thomas Broyer]

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" rather than "compile".
If you have users that want to do otherwise, i.e. "mvn processClasses" or
"mvn compile" (or even "mvn test") in a reactor build, then tell them you
rule/assumption, and let them come in with the workaround ;-)

In your specific case though, maybe you should do the unpacking at a later
stage, e.g. prepare-package ?

On Sun, Mar 24, 2019 at 11:51 AM Christofer Dutz 
wrote:

> 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 unpacking (as the
> File reference returned by dependency resolution references the
> target/classes directory)
> - "last phase > package" --> Unpack the content (as the File reference
> returned by dependency resolution references a Jar/war file)
>
> Chris
>
>
> Am 22.03.19, 15:02 schrieb "Maxim Solodovnik" :
>
> Hello Chris,
>
> Maybe true of maven-war-plugin
> can help?
>
> On Fri, 22 Mar 2019 at 20:12, Christofer Dutz <
> christofer.d...@c-ware.de>
> wrote:
>
> > Hi,
> >
> > we are currently having a little problem with our build.
> > A user complained about not being able to build with a “mvn compile”.
> > The reason is that we have one module that builds a web-client
> (bundled as
> > war) and a server module to which the client is copied.
> > We are using the maven-dependency-plugin:unpack to unpack the
> artifact
> > into the server war. This works fine as long as we built to at least
> the
> > “package” phase.
> > If the user builds to something before that, the build fails as the
> > pointer to the client pints to a directory instead of an archive.
> >
> > Is there a way to do some sort of “unpack-or-copy” that copies if
> it’s
> > just a pre-package phase and does the normal unpack if the archives
> have
> > been created.
> >
> > Would be happy to not tell them “just don’t do a `mvn compile` but at
> > least a `mvn package`.
> >
> >
> > Chris
> >
>
>
> --
> WBR
> Maxim aka solomax
>
>
>

Re: Maven plugin with annotations: default lifecycle phase?

[Thomas Broyer]

Adding the plugin won't be enough, you'll have explicitly name the mojo in
an . What defaultPhase does is that you don't have to specify a
 in the .
Actually, you can even list all mojos in the same  even if
they're bound to different default phases:

  …
  …
  …
  

  
mojo1
mojo2
mojo3
  

  


If you'd want the mojo to be automatically bound without even mentioning
it, you'd have to use a specific lifecycle, i.e. a specific packaging;
you'd then add the plugin with true and use your
custom , and your custom lifecycle would then apply.

On Tue, Feb 12, 2019 at 9:40 AM Dirk Olmes  wrote:

> Hi,
>
> I'm creating a Maven plugin using Java Annotations and I'd like my
> plugin to be bound to a default lifecycle phase so I don't have to
> explicitly bind it to a phase in my regular projects.
>
> So far I use
>
> @Mojo(name = "generate", defaultPhase = LifecyclePhase.GENERATE_SOURCES)
> public class MyMojo extends AbstractMojo {}
>
> But that doesn't seem to be enough: just listing the mojo in the build
> section of a test project does not execute the plugin.
>
> My google fu fails me! Help!
>
> -dirk
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Puzzling Aether behaviour

[Thomas Broyer]

Le ven. 21 déc. 2018 20:23, Robert Scholte  a écrit :

> There are a couple of things happening here.
>
> 1. dependencies are checked even though they are downloaded
> This ensures that the build doesn't rely on *your* *local* repository. At
> any time anybody should be able to build the project, it even should be
> possible that you remove your own local repo, so it is important that all
> dependencies are available via a remote repository.
>
> 2. dependencies are verified against their original remote repository.
> Recently I read an article about an interesting case regarding downloads
> of multiple repositories. (sadly I can't find it anymore).
> IIRC what happened is that they noticed a change in behavior of an
> application. After a while they discovered that some third party
> repository was used before Maven Central for downloading dependencies and
> one library was changed in this third party repository. The solution was
> simple: use Maven Central as the primary repository at all time.
>

This is likely the article you're talking about:
https://blog.autsoft.hu/a-confusing-dependency/

This might explain why it is important to not just trust the
> groupId+artifactId+version. The (original) source/repository or
> additional
> kind of checksum is as important.
>
> thanks,
> Robert
>
> On Fri, 21 Dec 2018 13:33:10 +0100, Zoran Regvart 
> wrote:
>
> > Hi Mavenistas,
> > I was recently quite puzzled on why Maven is trying to download a
> > dependency already present in the local repository and I tracked it
> > down to this comment in EnhancedLocalRepositoryManager[1]:
> >
> > "artifact downloaded from remote repository is accepted only
> > downloaded from request repositories"
> >
> > So regardless of the artifact being present in the local repository an
> > attempt is made to download it again if the id of the repository
> > doesn't match the id of the repository stored in
> > `_remote.repositories` file.
> >
> > I think that this will prevent anyone trying to reuse a local
> > repository with artifacts downloaded from unknown/unconfigured
> > repository in an offline build.
> >
> > Can someone shed some light on the rationale behind this?
> >
> > Thanks :)
> >
> > zoran
> >
> > [1]
> >
> https://github.com/eclipse/aether-core/blob/4cf5f7a406b516a45d8bf15e7dfe3fb3849cb87b/aether-impl/src/main/java/org/eclipse/aether/internal/impl/EnhancedLocalRepositoryManager.java#L106-L107
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Running a plugin only once after the whole build pass

[Thomas Broyer]

This needs to be built into the plugin that will do the aggregation. The
mojo needs to be marked as being an "aggregator":
https://maven.apache.org/developers/mojo-api-specification.html

On Mon, Nov 26, 2018 at 12:55 PM Neeraj Mahajan 
wrote:

> Hi ,
>
> I have multi module project and each module produces a  text file after the
> end of package phase. My requirement is to aggregate those text files and
> generate/print a summary from the aggregated text file at the end of maven
> build.
>
> Could you please suggest how I can achieve this in maven build ?
>
> Kind Regards,
> Neeraj Mahajan
>

Re: Fw: Re: Need advice to put my bootstrap template in Maven archetype web app

[Thomas Broyer]

Take the Bootstrap and Images folder out of the WebContent and move them
into src/main/webapp.

I mean: tutorRegister.jsp was in WebContent and you moved it to
src/main/webapp, right? so just do the same things with the rest: the
Bootstrap folder is in WebContent, move it into src/main/webapp (i.e.
src/main/webapp/Bootstrap/…)

On Tue, Nov 6, 2018 at 4:51 PM Karen Goh  wrote:

> I am so sorry but please ignore the last email.
>
> The URL is ok now after I read thru your email again and then looking at
> many images online.
>
> However, the jsp page is still not rendering the Bootstrap template.
>
> I just need you kindly tell me where to put the WebContent which contains
> all the template, css etc.
>
> https://ibb.co/hbF8dV
>
> Thanks in advance.
>
> --- On Tue, 11/6/18, Karen Goh  wrote:
>
> > From: Karen Goh 
> > Subject: Fw: Re: Need advice to put my bootstrap template in Maven
> archetype web app
> > To: t.bro...@gmail.com
> > Date: Tuesday, November 6, 2018, 9:38 PM
> > Hi Thomas,
> >
> > I have not heard back from you so I am
> > writing to you again.
> >
> > Basically, I still can't get the
> > localhost to run the jsp page properly.
> >
> > So, what I did now is re-edit the web
> > deployment assembly
> >
> > https://ibb.co/eJ93Cq
> >
> > Now, another problem appeared :
> >
> > The URL appeared to be like this which
> > differs from what you have mentioned
> >
> > http://localhost:8013/WebApp/WEB-INF/tutorRegister.jsp
> >
> > I am really lost and can't get going
> > with my project so I really hope you could point out how to
> > make it right.
> >
> > Here's my latest attempt :
> >
> > https://ibb.co/g4atCq
> >
> > https://ibb.co/kppH5A
> >
> > I am so sorry to trouble you again but
> > I really hope how should I make the my URL correct.  Do
> > I move all the jsp to above image folder and just below
> > WEB-INF ?
> >
> > Tks & regards,
> > Karen
> >
> > --- On Sun, 11/4/18, Karen Goh 
> > wrote:
> >
> > > From: Karen Goh 
> > > Subject: Re: Need advice to put my
> > bootstrap template in Maven archetype web app
> > > To: "Thomas Broyer" 
> > > Date: Sunday, November 4, 2018,
> > 1:25 PM
> > >
> > >
> > 
> > > On Sat, 11/3/18, Thomas Broyer
> > 
> > > wrote:
> > >
> > >  Subject: Re: Need advice to
> > put my
> > > bootstrap template in Maven
> > archetype web app
> > >  To: "Karen Goh" 
> > >  Date: Saturday, November 3,
> > 2018, 9:21
> > > PM
> > >
> > >
> > >
> > >  On Sat, Nov
> > >  3, 2018 at 1:38 PM Karen Goh
> > 
> > >  wrote:
> > >
> > >
> > >
> > >
> > 
> > >
> > >  On Fri, 11/2/18, Thomas
> > Broyer 
> > >  wrote:
> > >
> > >
> > >
> > >   Subject: Re: Need advice
> > to put my
> > > bootstrap template in
> > >  Maven archetype web app
> > >
> > >   To: "Maven Users List"
> > ,
> > >  "Karen Goh" 
> > >
> > >   Date: Friday, November 2,
> > 2018, 7:37
> > > PM
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >   On Thu, Nov
> > >
> > >   1, 2018 at 5:55 AM Karen
> > Goh
> > >
> > >   
> > > wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >  
> > >
> > >
> > >
> > >   On Tue, 10/30/18, jieryn
> > 
> > >
> > >   wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >Subject: Re: Need advice
> > to put my
> > > bootstrap template
> > >  in
> > >
> > >   Maven archetype web app
> > >
> > >
> > >
> > >To: "Maven Users List"
> > ,
> > >
> > >   karenwo...@yahoo.com
> > >
> > >
> > >
> > >Date: Tuesday, October
> > 30, 2018,
> > > 8:31 PM
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >https://maven.apach

Re: Fw: Re: Need advice to put my bootstrap template in Maven archetype web app

[Thomas Broyer]

013/WebApp/WEB-INF/tutorRegister.jsp
>
> I am really lost and can't get going with my project so I really hope you
> could point out how to make it right.
>
> Here's my latest attempt :
>
> https://ibb.co/g4atCq
>
> https://ibb.co/kppH5A
>
> I am so sorry to trouble you again but I really hope how should I make the
> my URL correct.  Do I move all the jsp to above image folder and just below
> WEB-INF ?
>
> Tks & regards,
> Karen
>
> --- On Sun, 11/4/18, Karen Goh  wrote:
>
> > From: Karen Goh 
> > Subject: Re: Need advice to put my bootstrap template in Maven archetype
> web app
> > To: "Thomas Broyer" 
> > Date: Sunday, November 4, 2018, 1:25 PM
> >
> > 
> > On Sat, 11/3/18, Thomas Broyer 
> > wrote:
> >
> >  Subject: Re: Need advice to put my
> > bootstrap template in Maven archetype web app
> >  To: "Karen Goh" 
> >  Date: Saturday, November 3, 2018, 9:21
> > PM
> >
> >
> >
> >  On Sat, Nov
> >  3, 2018 at 1:38 PM Karen Goh 
> >  wrote:
> >
> >
> >
> > 
> >
> >  On Fri, 11/2/18, Thomas Broyer 
> >  wrote:
> >
> >
> >
> >   Subject: Re: Need advice to put my
> > bootstrap template in
> >  Maven archetype web app
> >
> >   To: "Maven Users List" ,
> >  "Karen Goh" 
> >
> >   Date: Friday, November 2, 2018, 7:37
> > PM
> >
> >
> >
> >
> >
> >
> >
> >   On Thu, Nov
> >
> >   1, 2018 at 5:55 AM Karen Goh
> >
> >   
> > wrote:
> >
> >
> >
> >
> >
> >
> >  
> >
> >
> >
> >   On Tue, 10/30/18, jieryn 
> >
> >   wrote:
> >
> >
> >
> >
> >
> >
> >
> >Subject: Re: Need advice to put my
> > bootstrap template
> >  in
> >
> >   Maven archetype web app
> >
> >
> >
> >To: "Maven Users List" ,
> >
> >   karenwo...@yahoo.com
> >
> >
> >
> >Date: Tuesday, October 30, 2018,
> > 8:31 PM
> >
> >
> >
> >
> >
> >
> >
> >https://maven.apache.org/plugins/maven-war-plugin/usage.html
> >
> >
> >
> >
> >
> >
> >
> >   Hi Jieryn,
> >
> >
> >
> >
> >
> >
> >
> >   Just to clarify, so I have to place
> > the WebContent
> >  folder
> >
> >   which contents all my bootstrap css
> > etc under the
> >  resources
> >
> >   ?
> >
> >
> >
> >
> >
> >
> >
> >   I am confused cos the title is how
> > to WAR plug in where
> >  is
> >
> >   my question is more on the Maven
> > structure directory
> >  usage
> >
> >   for 3rd party bootstrap template.
> >
> >
> >
> >   In Maven, everything is done by
> >
> >   plugins, even the "standard" things.
> > Besides
> >  the
> >
> >   things that are part of the Project
> > Object Model
> >  (sources,
> >
> >   resources, output directory, test
> > sources, test
> >  resources,
> >
> >   test output directory), the
> > "standard layout"
> >  for
> >
> >   Maven projects are actually simply
> > the default
> >
> >   configurations for those plugins.If
> > you want to
> >
> >   build a WAR file for a web app,
> > you'll use
> >
> >
> >  war in your POM,
> >  which
> >
> >   will trigger the plugin bindings for
> > war packaging (
> https://maven.apache.org/ref/3.6.0/maven-core/default-bindings.html#Plugin_bindings_for_war_packaging
> ).
> >
> >   The maven-war-plugin is responsible
> > for packaging the
> >  WAR
> >
> >   file, and by default will take the
> > "web
> >  resources"
> >
> >   from src/main/webapp.In you case,
> > you could
> >
> >   either reconfigure the
> > maven-war-plugin to use WebContent
> >  as
> >
> >   the warSourceDirectory, or move the
> > content of you
> >
> >   WebContent folder into
> > src/main/webapp (so you will
> >  have,
> >
> >   for example, a
> > src/main/webapp/WEB-INF/web.xml file
> >  instead
> >

Re: Need advice to put my bootstrap template in Maven archetype web app

[Thomas Broyer]

On Thu, Nov 1, 2018 at 5:55 AM Karen Goh 
wrote:

>
> 
> On Tue, 10/30/18, jieryn  wrote:
>
>  Subject: Re: Need advice to put my bootstrap template in Maven archetype
> web app
>  To: "Maven Users List" , karenwo...@yahoo.com
>  Date: Tuesday, October 30, 2018, 8:31 PM
>
>  https://maven.apache.org/plugins/maven-war-plugin/usage.html
>
> Hi Jieryn,
>
> Just to clarify, so I have to place the WebContent folder which contents
> all my bootstrap css etc under the resources ?
>
> I am confused cos the title is how to WAR plug in where is my question is
> more on the Maven structure directory usage for 3rd party bootstrap
> template.
>

In Maven, everything is done by plugins, even the "standard" things.
Besides the things that are part of the Project Object Model (sources,
resources, output directory, test sources, test resources, test output
directory), the "standard layout" for Maven projects are actually simply
the default configurations for those plugins.
If you want to build a WAR file for a web app, you'll use
war in your POM, which will trigger the plugin
bindings for war packaging (
https://maven.apache.org/ref/3.6.0/maven-core/default-bindings.html#Plugin_bindings_for_war_packaging).
The maven-war-plugin is responsible for packaging the WAR file, and by
default will take the "web resources" from src/main/webapp.
In you case, you could either reconfigure the maven-war-plugin to use
WebContent as the warSourceDirectory, or move the content of you WebContent
folder into src/main/webapp (so you will have, for example, a
src/main/webapp/WEB-INF/web.xml file instead of WebContent/WEB-INF/web.xml)

See also
https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html


>
>  On
>  Sun, Oct 28, 2018 at 4:37 AM Karen Goh 
>  wrote:
>  >
>  > Hi,
>  >
>  > I have been
>  struggling for 2 days where to put my bootstrap template
>  that comes with pre-build template which includes css, fonts
>  etc. inside my maven web project without success.
>  >
>  > The problem - jsp is
>  not rendering the bootstrap layout.  It was rendering ok
>  before I changed the project structure which meets the Maven
>  project standard structure.
>  >
>  > This is a 3rd party bootstrap template.
>  >
>  > After reading up the
>  maven project structure, I have tried to put it under
>  src/main/resources, tried under src, tried moving around all
>  parts of the directory but to no avail
>  >
>  > I also used the below
>  structure to move my WebContent which included this template
>  but it is still not working
>  >
>  >
> https://stackoverflow.com/questions/15529184/where-to-place-twitter-bootstrap-files-in-a-maven-project
>  >
>  > Here's my pom.xml
>  :
>  >
>  > https://ibb.co/fesnGV
>  >
>  > https://ibb.co/m7GQ3A
>  >
>  >
>  >
>  Here's where my bootstrap ended now (still not working)
>  - where I put the jsp files and WebContent separately.
>  >
>  > https://ibb.co/fKArbV
>  >
>  > Please tell me where
>  should I put the bootstrap template.
>  >
>  > Thank you & regards,
>  > Karen
>  >
>  >
>  >
>  >
>  -
>  > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>  > For additional commands, e-mail: users-h...@maven.apache.org
>  >
>
>  -
>  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>  For additional commands, e-mail: users-h...@maven.apache.org
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: New (unofficial) Maven Plugin: Go Offline Maven Plugin

[Thomas Broyer]

How about, say, maven-compiler-plugin's annotationProcessorPaths?

Le mer. 17 oct. 2018 12:29, Andreas Janning  a
écrit :

> Hello maven users,
>
> I have just released a new open source maven plugin: The Go Offline Maven
> Plugin.
>
> It can be used to download all dependencies and plugins required in a Maven
> build, so the build can be run without an internet connection afterwards.
>
> This is especially relevant with modern CI-Systems like Gitlab and
> Circle-CI that need a consistent local Maven repository in their cache to
> build efficiently.
>
> Optionally, sources of all transitive dependencies can be downloaded as
> well to have them available in your favourite IDE.
>
> Maven already has an official to do this: The maven-dependency-plugin
> go-offline goal. Unfortunately, the go-offline goal currently suffers from
> several drawbacks:
>
> - Multi-Module builds are not supported since the plugin tries to download
> Reactor-Dependencies from the Remote Repository
> - Most parameters simply do not work
> - No option to download dynamic dependencies
>
> The Go Offline Maven Plugin fixes these drawbacks.
>
> The plugin has already been deployed to maven central. Source Code and
> further information can be found on the Github Page:
> https://github.com/qaware/go-offline-maven-plugin
>
> Comments, Bug-Reports and Pull Requests welcome :)
>
> Regards,
>
> Andreas Jannig
> --
>

Re: Attaching Java Agent to Tests Using Custom Plugin

[Thomas Broyer]

Have a look at how JaCoCo does it, as AFAICT it has exactly the same needs:
https://www.eclemma.org/jacoco/trunk/doc/maven.html (source code:
https://github.com/jacoco/jacoco/tree/master/jacoco-maven-plugin/src/org/jacoco/maven
)

TL;DR: prepare-agent goal sets a property that you can then use to
configure Surefire.

On Tue, Oct 16, 2018 at 6:23 PM James Owen  wrote:

> Hi,
>
> I am currently trying to write a custom plugin that does two things
>
>  1. Attach a java agent to the JVM when the tests are running, causing
> some instrumentation to be logged
>  2. Analyze the logged instrumentation and report back to the user
>
> I have the second part working, but I'm completely stumped by the first
> part. My understanding is that applying JVM arguments during tests is
> the responsibility of surefire, using the argLine configuration
> parameters - so I am trying to write a mojo that will add those
> parameters on the fly if they are not already there.
>
> As it stands, I have written a mojo (InjectAgentMojo) that does the
> following:
>
>   * Get the project from a parameter
>   * Look up the surefire plugin using
> project.getPlugin(org.apache.maven.plugins:maven-surefire-plugin)
>   * Create a configuration with the required elements, and attach it
> using setConfiguration
>
> However, this does not seem to have any effect, and the configuration is
> not being used. I am calling the mojo in the INITIALIZE phase of my test
> project, but it seems that the configuration has already been set
> elsewhere by then.
>
> Does anyone have any ideas that would make this possible? Specifically:
>
>   * Is there a way for maven plugins to set the configuration of other
> plugins at runtime?
>   * Is there another way this could be done - writing a plugin for
> surefire or something?
>
> After a couple of days of experimenting/googling, I appear to have hit a
> brick wall.
>
> Thanks in advance for any help.
>
> James Owen
>
>

Re: Running integration tests twice against different webapp configurations

[Thomas Broyer]

Alternatively, if possible, you could possibly run the app with both
configurations in parallel (two executions of jetty-maven-plugin in
pre-integration-test and post-integration-test phase, using different
ports), and run you tests twice, for each app / port (two executions of
failsafe at integration-test phase)

On Fri, Oct 12, 2018 at 8:44 AM Anders Hammar  wrote:

> I'd say you need two modules; one for each IT setup. Each module is a Maven
> project and will then run the integration tests. The actual integration
> test code could then be in a third module and you declare a dependency on
> that artifact.
>
> /Anders
>
> On Thu, Oct 11, 2018 at 11:21 PM Ellis, Scott  >
> wrote:
>
> > Hi,
> >
> > I have a project that builds a webapp and runs integration tests against
> > it using the failsafe plugin and the jetty-maven-plugin.
> >
> > That is, I use the jetty-maven-plugin to start jetty in the
> > pre-integration-test phase, run the tests, then shut jetty down in the
> > post-integration-test phase.
> >
> > Now, my web app can have an entirely different configuration in addition
> > to the existing one, so I need to start jetty with a new config and run a
> > new suite of tests, while maintaining all the existing functionality.
> >
> > So what I really want to do it run these phases twice:
> >
> > pre-integration-test
> > integration-test
> > post-integration-test
> >
> > First I want to run them with the my webapp configured the old way, and
> > then run the same phases again with my webapp configured the new way.
> >
> > Any advice on how to do this? The configurations can be set with system
> > properties. The problem is how to run those phases twice in that order.
> >
> > Thanks for any insight you can offer,
> > Scott
> >
>

Re: JDK Version for new project generated by mvn archetype:generate

[Thomas Broyer]

Either change the artifact (if you can) so it generates a pom.xml with the
appropriate source/target version [1], or indeed change the project pom.xml
(after it's been generated by the archetype)

[1] and possibly a profile for JDK 9+ that uses , assuming the
target is <= 8; otherwise use  instead of /, and
no need for a profile.

On Tue, Sep 11, 2018 at 4:28 PM Bruce Wen  wrote:

> >
> > In either case, you can after the Maven project has been generated change
> > the Java version to a version of your choice.
>
>
> Does that mean I have to do the change *AFTER *the project was generated?
>
> On Tue, Sep 11, 2018 at 1:48 PM Anders Hammar  wrote:
>
> > The archetype is a template which either does explicitly configure
> > maven-compiler-plugin with a Java version. Or if not, the default (for
> the
> > used version of maven-compiler-plugin) value is used.
> >
> > In either case, you can after the Maven project has been generated change
> > the Java version to a version of your choice. To have Eclipse pick up the
> > change I think you need to right click on the project and select
> > Maven->Update project.
> >
> > /Anders
> >
> > On Tue, Sep 11, 2018 at 1:36 PM Bruce Wen  wrote:
> >
> > > >
> > > > It is configured on the maven-compiler-plugin [1].
> > >
> > >
> > > Do you mean archetype depends on maven-compiler-plugin? So, how can I
> > use a
> > > specific JDK version when I create a new project with archetype?
> > >
> > > Bruce Wen
> > >
> > > On Mon, Sep 10, 2018 at 2:20 PM Anders Hammar 
> wrote:
> > >
> > > > The Java version is decided by the archetype you use. It is
> configured
> > on
> > > > the maven-compiler-plugin [1]. If not configured there is a default
> for
> > > > maven-compiler-plugin. The default depends on which version of
> > > > maven-compiler-plugin is used.
> > > >
> > > > When you import in Eclipse this configuration is read to configure
> the
> > > > Eclipse project.
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html
> > > >
> > > > /Anders
> > > >
> > > > On Mon, Sep 10, 2018 at 2:09 PM Bruce Wen 
> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I used Maven 3.3.1. I created a new project with below commands:
> > > > >
> > > > > mvn archetype:generate -DgroupId=my.company.project
> > > > -DartifactId=my-project
> > > > > -DarchetypeArtifactId=maven-archetype-quickstart
> > > -DinteractiveMode=false
> > > > >
> > > > > Then, I imported the generated project into eclipse and found it
> uses
> > > > J2SE
> > > > > -1.5.
> > > > >
> > > > > My question:
> > > > > How is J2SE-1.5 decided?
> > > > > Can we specify JDK version for new project?
> > > > >
> > > > > Thanks!
> > > > > --
> > > > > Bruce Wen (GuangMing)
> > > > >
> > > >
> > >
> > >
> > > --
> > > Bruce Wen (GuangMing)
> > >
> > >
> >
> -
> > > "Undertake not what you cannot perform, but be careful to keep your
> > promise
> > > - George Washington"
> > >
> > >
> >
> -
> > > Internet Email:crest@gmail.com
> > > LinkedIn:cn.linkedin.com/in/wengm
> > > Blog:crest-boy.livejournal.com
> > > MSN:crest-...@hotmail.com
> > >
> >
>
>
> --
> Bruce Wen (GuangMing)
>
> -
> "Undertake not what you cannot perform, but be careful to keep your promise
> - George Washington"
>
> -
> Internet Email:crest@gmail.com
> LinkedIn:cn.linkedin.com/in/wengm
> Blog:crest-boy.livejournal.com
> MSN:crest-...@hotmail.com
>

Re: Could not resolve dependencies error

[Thomas Broyer]

On Wed, Aug 29, 2018 at 8:36 AM Guido van Brakel <
guido.vanbra...@outlook.com> wrote:

> Hi,
>
> We have an issue with Maven not finding a certain dependency, anyone able
> to help this Maven. Keep in mind that I’m quite newbie to Maven, and just
> try run a build
>
> [ERROR] Failed to execute goal on project confidentialservices: Could not
> resolve dependencies for project
> com.digitaslbi.confidential:confidentialservices:war:0.1.0.12: Could not
> find artifact
> nl.confidential.web:confidentialweb-getdataapi-client:jar:1.2.14.0-SNAPSHOT
> -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project confidentialservices: Could not resolve dependencies for
> project com.digitaslbi.confidential:confidentialservices:war:0.1.0.12:
> Could not find artifact
> nl.confidential.web:confidentialweb-getdataapi-client:jar:1.2.14.0-SNAPSHOT.

 […]

> [DEBUG] Repositories (dependencies): [central (
> https://repo.maven.apache.org/maven2, default, releases)]
> [DEBUG] Repositories (plugins) : [central (
> https://repo.maven.apache.org/maven2, default, releases)]
>

 You don't have any snapshot repository declared, which means the
dependency must be available locally (in your
C:\Users\davanbrg\.m2\repository), which implies that it must have been
previously built locally (using "mvn install" from its own project).

Re: Integration testing of command line tools?

[Thomas Broyer]

One approach could be to have a main() overload taking an additional
Environment argument to abstract access to environment variables, system
properties, and standard I/O; and returning an int as the possible
System.exit() value.
That way, you can easily stub the environment for tests.
Your standard main() then simply (and only) call that overload with a
straightforward Environment implementation, and then call System.exit().

Le lun. 20 août 2018 15:59, Mark H. Wood  a écrit :

> When writing integration tests for command-line tools, is there any
> support in Failsafe, jUnit, or elsewhere to fork a process and manage
> its standard IO streams?
>
> Or am I over-designing?  Would one typically write such an integration
> test rather like a unit test, bypassing the command analyzer and just
> calling the appropriate method on an instance created by the test
> suite?  Without stubbing or mocking the underlying code, of course,
> since it's an integration test.
>
> Is there a better place to ask?
>
> --
> Mark H. Wood
> Lead Technology Analyst
>
> University Library
> Indiana University - Purdue University Indianapolis
> 755 W. Michigan Street
> Indianapolis, IN 46202
> 317-274-0749
> www.ulib.iupui.edu
>

Re: maven - pom.xml file

[Thomas Broyer]

What you're looking for is https://maven.apache.org/pom.html (from
https://maven.apache.org/ click "User Center" then "POM Reference")

Le mar. 24 juil. 2018 19:40, Angelo Moreschini 
a écrit :

> How course I found the document at link : "
> http://maven.apache.org/xsd/maven-4.0.0.xsd;
>
> But this doesn't look as a easily readable manual.
> Perhaps  it exists also a rapid guide for this matter...  I look for that
> .. :-)
>
> thank you
>
> Angelo
>
> On Tue, Jul 24, 2018 at 11:07 AM, Angelo Moreschini <
> mrangelo.fed...@gmail.com> wrote:
>
> > Hi,
> >
> > I am new to maven and I would like have a complete reference about the
> way
> > to write myself a pom.xml file.
> >
> > How course I interested to know :
> >
> >- the list of the all elements (  ) that can be used..
> >- Their order in writing them
> >- And how they can be nested...
> >
> > As well it can be strange, I was not able to find this information myself
> > on the web  (it is a reason ?).
> >
> > Regards
> >
> > thank you
> >
> > Angelo Moreschini
> >
> >
> >
> >
> >
>

Re: Distribution management

[Thomas Broyer]

altDeploymentRepository (or alternatively
altReleaseDeploymentRepository/altSnapshotDeploymentRepository) sounds like
THE solution to this problem:
https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#altDeploymentRepository

mvn deploy -DaltDeploymentRepository=company-repo:default:https://…
—or—
mvn release:perform
-Darguments="-DaltDeploymentRepository=company-repo:default:https://…;

Using placeholders in  doesn't buy much… And using
an extension sounds like "why make it simple when it can be complicated" (I
don't deny there are probably situations where this would be a better
choice, but that really sounds like the exception rather than the rule).

On Tue, Jul 10, 2018 at 11:33 AM Matthieu BROUILLARD 
wrote:

> Hi Adam,
>
> 'distributionManagement' is part of the pom not part of settings : maven is
> like that.
>
> If you do not want to expose some company repositories or if those ones are
> often changing then you can:
> - either use placeholders in some predefined `distributionManagement` tags
> (in project or in parent)
> - use `altDeploymentRepository` of maven deploy plugin
> - write a maven core extension that updates dynamically & in memory the POM
> of your projects
>
> Matthieu
>
>
> On Tue, Jul 10, 2018 at 11:09 AM ahardy42 
> wrote:
>
> > Hi maven-users,
> >
> > it seems this issue was last discussed almost 10 years ago but despite
> > reading the docs and the email lists there is still an issue with
> > distribution management that I don't understand.
> >
> > I do not wish to declare our company's internal release and snapshot
> > repositories in pom files which are versioned, and I can't put the xml in
> > the settings.xml.
> >
> > I only see two alternatives:
> >
> >  - I declare the distributionManagement xml for my team in a parent pom
> > which I deploy on an updateable repository where we do not have to
> > increment
> > the version
> >
> >  - I provide everybody with the command line script snippet to do the
> > deploy
> > manually
> >
> > Both of these alternatives have drawbacks.
> >
> > If there is another way of keeping the distributionManagement out of the
> > versioned poms?
> >
> > If not, why don't I understand the paradigm? It makes little sense to me
> > that a change in the environment (the repository URLs) should force a
> > version change in all projects under development.
> >
> > Regards
> > Adam
> >
> >
> >
> > --
> > Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: Java 9 modules for Maven components for Java 9 based pluggins

[Thomas Broyer]

On Thu, Jun 28, 2018 at 5:59 PM Karl Heinz Marbaise 
wrote:

> Hi,
>
> On 28/06/18 12:59, Václav Haisman wrote:
> > Hi.
> >
> > Is there any effort to make Maven Java 9 friendly and provide modules? I
> > have hit some issues when I was trying to compile a 3rd party Maven
> plugin
> > (nashorn-maven-plugin) as Java 9. When I tried to provide it with
> > module-info.java I got stuck on errors like this:
> >
> > [ERROR] error: the unnamed module reads package org.apache.maven.plugin
> > from both maven.core and maven.plugin.api
> > [ERROR] error: module maven.plugin.annotations reads package
> > org.apache.maven.plugin from both maven.plugin.api and maven.core
> > [ERROR] error: module maven.plugin.api reads package
> > org.apache.maven.plugin from both maven.plugin.api and maven.core
> > [ERROR] error: module maven.model reads package org.apache.maven.plugin
> > from both maven.plugin.api and maven.core
> > [ERROR] error: module maven.core reads package org.apache.maven.plugin
> from
> > both maven.plugin.api and maven.core
>
> Can you please show your pom file or a reference to a github/bitbucket
> project...cause the error message implies there is something cause you
> seemed to have dependencies to maven.plugin.api  and maven.core which
> usually does not happen in a usual java project...
>

You probably missed “I was trying to compile a 3rd party Maven plugin
(nashorn-maven-plugin) as Java 9” from the original message.

Re: Release a snapshot version

[Thomas Broyer]

It looks like you just want to deploy your snapshot to a repository; in
that case you'll want to simply "mvn deploy", without even using the
maven-release-plugin (for the reasons Karl Heinz gave)

Le mer. 27 juin 2018 18:30, Ravindranatha Panikar, Renjith <
rr...@allstate.com> a écrit :

> I am planning to use maven release plugin for automating the release of
> our application.
> There can be two types of releases.
>
>Normal Release:
>  Current code should be tagged.
>  Pom.xml should get updated to
> 'next-version-SNAPSHOT'.
>  Artifacts should be public to
> remote repository.
>
>SNAPSHOT Release: it can contain one or more hot fixes
> which we would like to release on an immediate basis.
>  Tagging is not
> required here.
>   Pom.xml should not
> be updated.
>  Artifacts should be
> published to remote repository with name 'ProjectName-
> next-version-SNAPSHOT'.jar'
>
> I know maven-release-plugin can perform the 'Normal Release'. But is there
> any way I can handle the 'SNAPSHOT release'?
>

Re: mvn dependency:purge-local-repository

[Thomas Broyer]

On Fri, Jun 15, 2018 at 5:45 PM Karen Goh 
wrote:

> Hi,
>
> I run into a problem in my Spring Boot Web project and then there's an
> advice following this URL :
>
> https://github.com/spring-projects/spring-boot/issues/12398
>
> But, when I run mvn dependency:purge-local-repository, I get another error
> :
>
> Unknown lifecycle phase "mvn". You must specify a valid lifecycle phase or
> a goal in the format : or
> :[:]:. Available
> lifecycle phases are: validate, initialize, generate-sources,
> process-sources, generate-resources, process-resources, compile,
> process-classes, generate-test-sources, process-test-sources,
> generate-test-resources, process-test-resources, test-compile,
> process-test-classes, test, prepare-package, package, pre-integration-test,
> integration-test, post-integration-test, verify, install, deploy,
> pre-clean, clean, post-clean, pre-site, site, post-site, site-deploy. ->
> [Help]
>
> I hope someone can tell you how to run mvn
> dependency:purge-local-repository in Eclipse Oxygen.
>

"mvn" is the command-line tool for running Maven. When running Maven from
within Eclipse, you only specify the arguments through the dialog box. In
"target" (iiuc, haven't used Eclipse for years), you'd then put only
"dependency:purge-local-repository".

HTH

Re: maven-license plugin's license-list

[Thomas Broyer]

No, AFAICT, it's the list of all licences known to the plugin, irrespective
of "applicability" and/or your dependencies.

On Tue, May 22, 2018 at 5:20 PM Désilets, Alain <
alain.desil...@nrc-cnrc.gc.ca> wrote:

> This may sound a bit nit-picky, but I need to be 100% about this...
>
>
> I am using the maven-license plugin to figure out under which Open Source
> license (if any) under which I have to license my code.
>
>
> I am running the 'license-list' goal, and it produces a report that looks
> like this:
>
>
> =
>
> [INFO] Available licenses :
>
>
>  * agpl_v3 : GNU Affero General Public License (AGPL) version 3.0
>
>  * apache_v2   : Apache License version 2.0
>
>  * bsd_2   : BSD 2-Clause License
>
>  * bsd_3   : BSD 3-Clause License
>
>  * cddl_v1 : COMMON DEVELOPMENT AND DISTRIBUTION LICENSE (CDDL)
> Version 1.0
>
> etc..
>
> =
>
>
> I am ASSUMING that this is a list of all the alternative licenses that I
> could use to distribute my code under. In other words, this is the
> INTERSECTION (as opposed to the UNION) of the licenses that are compatible
> with each of the individual third party modules, correct? Can someone
> please confirm?
>
>
> Thanks again for bearing with me. The word "available licenses" is just a
> bit too ambiguous for my taste and I couldn't find anywhere a more precise
> explanation of what is meant by that.
>
>
>
>

Re: javadoc:jar and generated sources

[Thomas Broyer]

Be careful in your testing: javadoc:javadoc forks a lifecycle at
'generate-sources' phase (and javadoc:aggregate at 'compile' phase),
whereas javadoc:jar does not!
So running 'mvn javadoc:jar' alone indeed won't run your protoc plugin,
which won't add the generated sources as a compile source root. Running
'mvn generate-sources javadoc:jar' would work differently; and obviously
binding javadoc:jar to a phase in your build (after generate-sources phase,
default  being 'package') and running 'mvn package' should then work the
same.

Le mar. 13 mars 2018 18:57, Laird Nelson  a écrit :

> I am finding that the sourcepath for javadoc:jar (when run as part of the
> release profile) is different from the sourcepath for javadoc:javadoc in my
> project that involves (protoc-) generated sources.
>
> (The net effect is that at release time, everything works fine up until
> release:perform, which fails (!) during the attach-javadocs execution I've
> configured following the documentation (
>
> https://maven.apache.org/plugin-developers/cookbook/attach-source-javadoc-artifacts.html#Configuring_Maven_Javadoc_Plugin
> )
> ).
>
> I have a  stanza centralizing my maven-javadoc-plugin
> configuration that does not mention sourcepath in any way.
>
> mvn help:effective-pom -Prelease shows exactly what I would expect, and no
> additional maven-javadoc-plugin configuration.
>
> Somehow, the sourcepath for javadoc:javadoc has the generated-sources
> directory in it; the sourcepath for javadoc:jar does not.
>
> Here is the pluginManagement section (it's quite ordinary):
>
> 
>   maven-javadoc-plugin
>   3.0.0-M1
>   
> -missing
>   
> 
>
> When I run mvn -X javadoc:javadoc and inspect the options file, I see this:
>
> -sourcepath
> '/Users/ljnelson/Projects/frob/src/main/java:
>
> */Users/ljnelson/Projects/frob/target/generated-sources/protobuf/java:/Users/ljnelson/Projects/frob/target/generated-sources/protobuf/grpc-java*
> :/Users/ljnelson/Projects/frob/src/main/javadoc'
>
> When I run mvn -X javadoc:jar and inspect the options file, I see only
> this:
>
> -sourcepath
>
> '/Users/ljnelson/Projects/frob/src/main/java:/Users/ljnelson/Projects/frob/src/main/javadoc'
>
> The javadoc:jar goal outputs a bunch of warnings.  When I run it locally
> (mvn javadoc:jar), they show up as warnings.  When it is run as part of the
> maven-release-plugin's perform goal, it fails the build.
>
> I'm at a loss as to how to go about fixing this.  Is it, perhaps, the job
> of the plugin in charge of generating the sources to do something here?
>
> Best,
> Laird
>

Re: Running tomcat maven plugin in a multi modules project

[Thomas Broyer]

Oh great, thanks for the heads up! (I had asked for this years ago and then
they moved to Eclipse and I lost track)

Le sam. 13 janv. 2018 23:24, Olivier Lamy <ol...@apache.org> a écrit :

> Hi,
> Well to be fair Jetty Maven Plugin has now this feature as well...
>
> On 14 January 2018 at 03:25, Thomas Broyer <t.bro...@gmail.com> wrote:
>
> > On Sat, Jan 13, 2018 at 3:20 PM Thomas Broyer <t.bro...@gmail.com>
> wrote:
> >
> > > Tomcat Maven plugin has built-in support for reactors, so run it at
> root
> > > rather than within the web submodule (possibly with "-pl web -am"). It
> > will
> > > automatically compile all (needed) submodules and launch Tomcat, and
> with
> > > auto-deploy will automatically reload the webapp to pickup changes in
> any
> > > submodule.
> > >
> >
> > From https://tomcat.apache.org/maven-plugin-2.2/run-mojo-features.html
> > > NOTE If you have a multi module Maven project and use Maven3,
> > > you don't need to install all modules before using the run goal, just
> > > use tomcat6/7:run from the root module and the plugin will auto
> > > detect the build output directory from various modules and replace
> > > dependencies with those directories in the webapp classloader.
> >
> > (too bad there's been no new release for 4 years though, this is probably
> > one of the best thought-out Maven plugin out there in terms of usability
> > wrt multi-module projects, and without being "hackish"; without that,
> > people keep having to install all their snapshots into their local repo
> and
> > rebuilding them over and over again, if only to make sure they're the
> ones
> > for the correct commit / code state)
> >
> >
> > > Le sam. 13 janv. 2018 03:33, Sigmond Hola <sigmund@gmail.com> a
> > > écrit :
> > >
> > >> I have a multi-module project like this:
> > >>
> > >> ROOT:pom
> > >> --- web:war
> > >> --- domain:jar
> > >> --- service:jar
> > >> --- dao:jar
> > >>
> > >> And i configure tomcat7-maven-plugin in pom.xml of module *web *so
> that
> > I
> > >> can using tomcat:run to run this web application.
> > >>
> > >> But if I change something in other module, for example, add a new
> entity
> > >> class in module domain, I have to install the ROOT to local repo first
> > >> before I run tomcat:run within module web, otherwise a error: cannot
> > find
> > >> symbol will be reported if I run tomcat:run directly.
> > >>
> > >> So how can I install other modules first before I run tomcat:run
> within
> > >> module web if I change something in other modules?
> > >>
> > >> Thanks in advance.
> > >>
> > >> Best regards.
> > >>
> > >
> >
>
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

Re: Running tomcat maven plugin in a multi modules project

[Thomas Broyer]

On Sat, Jan 13, 2018 at 3:20 PM Thomas Broyer <t.bro...@gmail.com> wrote:

> Tomcat Maven plugin has built-in support for reactors, so run it at root
> rather than within the web submodule (possibly with "-pl web -am"). It will
> automatically compile all (needed) submodules and launch Tomcat, and with
> auto-deploy will automatically reload the webapp to pickup changes in any
> submodule.
>

>From https://tomcat.apache.org/maven-plugin-2.2/run-mojo-features.html
> NOTE If you have a multi module Maven project and use Maven3,
> you don't need to install all modules before using the run goal, just
> use tomcat6/7:run from the root module and the plugin will auto
> detect the build output directory from various modules and replace
> dependencies with those directories in the webapp classloader.

(too bad there's been no new release for 4 years though, this is probably
one of the best thought-out Maven plugin out there in terms of usability
wrt multi-module projects, and without being "hackish"; without that,
people keep having to install all their snapshots into their local repo and
rebuilding them over and over again, if only to make sure they're the ones
for the correct commit / code state)


> Le sam. 13 janv. 2018 03:33, Sigmond Hola <sigmund@gmail.com> a
> écrit :
>
>> I have a multi-module project like this:
>>
>> ROOT:pom
>> --- web:war
>> --- domain:jar
>> --- service:jar
>> --- dao:jar
>>
>> And i configure tomcat7-maven-plugin in pom.xml of module *web *so that I
>> can using tomcat:run to run this web application.
>>
>> But if I change something in other module, for example, add a new entity
>> class in module domain, I have to install the ROOT to local repo first
>> before I run tomcat:run within module web, otherwise a error: cannot find
>> symbol will be reported if I run tomcat:run directly.
>>
>> So how can I install other modules first before I run tomcat:run within
>> module web if I change something in other modules?
>>
>> Thanks in advance.
>>
>> Best regards.
>>
>

Re: Running tomcat maven plugin in a multi modules project

[Thomas Broyer]

Tomcat Maven plugin has built-in support for reactors, so run it at root
rather than within the web submodule (possibly with "-pl web -am"). It will
automatically compile all (needed) submodules and launch Tomcat, and with
auto-deploy will automatically reload the webapp to pickup changes in any
submodule.

Le sam. 13 janv. 2018 03:33, Sigmond Hola  a écrit :

> I have a multi-module project like this:
>
> ROOT:pom
> --- web:war
> --- domain:jar
> --- service:jar
> --- dao:jar
>
> And i configure tomcat7-maven-plugin in pom.xml of module *web *so that I
> can using tomcat:run to run this web application.
>
> But if I change something in other module, for example, add a new entity
> class in module domain, I have to install the ROOT to local repo first
> before I run tomcat:run within module web, otherwise a error: cannot find
> symbol will be reported if I run tomcat:run directly.
>
> So how can I install other modules first before I run tomcat:run within
> module web if I change something in other modules?
>
> Thanks in advance.
>
> Best regards.
>

Re: using includes in maven-source-plugin induces sources are not found anymore

[Thomas Broyer]

maven-assembly-plugin would likely be less ugly. Have you tried that?

Le jeu. 2 nov. 2017 22:26, MAISONOBE Luc  a écrit :

> Hi,
>
> MAISONOBE Luc  a écrit :
>
> > Hervé BOUTEMY  a écrit :
> >
> >> Hi,
> >
> > Hi Hervé,
> >
> >>
> >> AFAIK, reading the plugin source code, there is no feature to add files
> that
> >> are not in compile source root: this will require a new feature.
> >>
> >> Did you try adding a secondary source root, using
> build-helper:add-source?
> >
> > I just tried it, thanks for the suggestion. It doesn't work.
> > The LICENSE.txt and NOTICE.txt files live in the root directory,
> > alongside the pom. So this implies adding the full project in the
> > source tree. It creates huge problems has there are java files
> > underneath (in src/main/java, and src/test/java).
> >
> > I also tried maven-resource-plugin, but it also adds full directories,
> > not single files.
> >
> >
> > I did understood why my source disappeared. The default pattern **/*.java
> > is added only if combined includes is empty. I also understood the
> > pattern is eveluated with respect to the source tree, not the project
> > root.
> >
> > So adding something like:
> >
> >   
> >  **/*.java
> >  something-else
> >   
> >
> > should probably work... as long as something else is in the sources tree.
> >
> > I tried to use ../../../LICENSE.txt to go upward, but
> > it doesn't work either.
>
> I finally managed to do what I wanted. The solution involved:
>
>- using maven-antrun-plugin to:
> + create a directory
> ${project.build.outputDirectory}/license-and-notice-placeholder
> + copy LICENSE.txt from top directory to the created directory
> + copy NOTICE.txt from top directory to the created directory
>- using build-helper-maven-plugin to add this directory to the
> sources directories
>- use maven-source-plugin with includes set to:
> + **/*.java
> + LICENSE.txt
> + NOTICE.txt
>
> All three plugins are run only in a profile and they are bound to
> package phase.
>
> This works, but it is really ugly.
>
> best regards,
> Luc
>
> >
> > best regards,
> > Luc
> >
> >>
> >> Regards,
> >>
> >> Hervé
> >>
> >> Le jeudi 2 novembre 2017, 11:54:58 CET Luc Maisonobe a écrit :
> >>> Hi all,
> >>>
> >>> I am using maven-souce-plugin in a profile, in order to generate the
> >>> sources jar. As this sources jar is in a sense a source distribution
> >>> (even if it is intended only for IDE completion use), it should
> >>> include the LICENSE.txt and NOTICE.txt files that are present at
> >>> the top level of the project.
> >>>
> >>> So my pom looks as follows:
> >>>
> >>> 
> >>>  release
> >>>
> >>>
> >>>   
> >>>org.apache.maven.plugins
> >>>maven-source-plugin
> >>>3.0.1
> >>>
> >>>  
> >>>LICENSE.txt
> >>>NOTICE.txt
> >>>  
> >>>
> >>>
> >>>  
> >>>create-source-jar
> >>>
> >>>  jar
> >>>
> >>>package
> >>>  
> >>>
> >>>  
> >>>
> >>>  
> >>> 
> >>>
> >>> When I run "mvn -Prelease package", I get the following error:
> >>>
> >>> [INFO] --- maven-source-plugin:3.0.1:jar (create-source-jar) @ orekit
> ---
> >>> [INFO] No sources in project. Archive not created.
> >>>
> >>>
> >>> If I remove the ... part, the source jar
> >>> is created nominally, as the sources are in the standard src/main/java
> >>> directory.
> >>>
> >>> It seems to me that adding the ... somehow hides
> >>> or clears the regular list of source files. I would have expected that
> >>> includes adds to this list.
> >>>
> >>> I have tried to add the path to the sources in a third ,
> >>> alongside the LICENSE and NOTICE ones, using either
> >>> {$project.buid.sourceDirectory} or hard-coded paths, but nothing works,
> >>> or at least I did not find the correct include statement.
> >>>
> >>> How can I put these two extra files into the source jar and still have
> >>> the sources too?
> >>>
> >>> best regards,
> >>> Luc
> >>>
> >>> -
> >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: 

Re: Strange NoSuchMethodError in plugin, any idea?

[Thomas Broyer]

Actually, from last comment [1], it looks more like a corrupt POM.

Thanks for the suggestions anyway.

[1]
https://github.com/tbroyer/gwt-maven-plugin/issues/95#issuecomment-335513263

On Tue, Oct 10, 2017 at 7:54 PM Robert Scholte <rfscho...@apache.org> wrote:

> My guess would be a corrupt jar
>
> Robert
>
> On Tue, 10 Oct 2017 15:51:34 +0200, Thomas Broyer <t.bro...@gmail.com>
> wrote:
>
> > Hi all,
> >
> > A net.ltgt.gwt.maven:gwt-maven-plugin user reported to me today [1] that
> > after updating the plugin from the latest release to the latest snapshot,
> > he faces a NoSuchMethodError on
> > org.codehaus.plexus.util.StringUtils.isBlank(Ljava/lang/String;)Z.
> > Between
> > the two tested versions, I updated org.codehaus.plexus:plexus-utils from
> > 3.0.21 to 3.1.0 [2], but that method has been present in plexus-utils
> > unchanged for 10 years [3].
> >
> > Anyone has an idea what happens? And/or how to debug it? (I suggested
> > running Maven with debug logs and look at how Maven populates the class
> > realm for the plugin)
> >
> > [1]
> >
> https://github.com/tbroyer/gwt-maven-plugin/issues/95#issuecomment-335448533
> > [2]
> >
> https://github.com/tbroyer/gwt-maven-plugin/compare/1.0-rc-8...92d27f6#diff-600376dffeb79835ede4a0b285078036
> > [3]
> >
> https://github.com/codehaus-plexus/plexus-utils/blame/ac81ee2dfc757a27d3e7a5315a65822f3033ec00/src/main/java/org/codehaus/plexus/util/StringUtils.java#L202
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Strange NoSuchMethodError in plugin, any idea?

[Thomas Broyer]

Hi all,

A net.ltgt.gwt.maven:gwt-maven-plugin user reported to me today [1] that
after updating the plugin from the latest release to the latest snapshot,
he faces a NoSuchMethodError on
org.codehaus.plexus.util.StringUtils.isBlank(Ljava/lang/String;)Z. Between
the two tested versions, I updated org.codehaus.plexus:plexus-utils from
3.0.21 to 3.1.0 [2], but that method has been present in plexus-utils
unchanged for 10 years [3].

Anyone has an idea what happens? And/or how to debug it? (I suggested
running Maven with debug logs and look at how Maven populates the class
realm for the plugin)

[1]
https://github.com/tbroyer/gwt-maven-plugin/issues/95#issuecomment-335448533
[2]
https://github.com/tbroyer/gwt-maven-plugin/compare/1.0-rc-8...92d27f6#diff-600376dffeb79835ede4a0b285078036
[3]
https://github.com/codehaus-plexus/plexus-utils/blame/ac81ee2dfc757a27d3e7a5315a65822f3033ec00/src/main/java/org/codehaus/plexus/util/StringUtils.java#L202

Re: Maven Extension Idea: iJar support

[Thomas Broyer]

See https://melix.github.io/javaone-2017-max-incremental/ for how Gradle
does it (and so it uses it not only for incremental compilation, but also
compilation avoidance).
Bazel's ijars are a similar mechanism to avoid unnecessary work.

On Wed, Oct 4, 2017 at 5:19 PM Thomas Broyer <t.bro...@gmail.com> wrote:

> AFAIK, the ijar (for "interface jar") is a standard JAR, with standard
> *.class files *except* that the method bodies and private members have been
> stripped out (and timestamps are normalized too). That way, if you change a
> method implementation, or a private member (add/remove private field or
> method, change private method signature, add/remove private inner class),
> the resulting ijar won't change. Any *.java compiled against such a *.class
> would produce the exact same *.class, so by checking the ijar checksum you
> can determine whether a dependency has changed in a way that would require
> recompiling the code. You'd however use the "normal" jar checksum to
> determine whether to re-run tests (Maven unconditionally re-runs tests, but
> neither Bazel nor Gradle, they avoid re-running them if the inputs haven't
> changed), as implementation matters in determining the outcome (whether the
> tests pass or fail).
>
> On Wed, Oct 4, 2017 at 4:27 PM Russell Gold <russell.g...@oracle.com>
> wrote:
>
>> Does this iJar have more information than a regular JAR? If not, what is
>> the benefit? If so, where is this information coming from?
>>
>> The closest thing I can think of is the new Java 9 module system, which
>> defines what is visible; presumably, that information would be useful in
>> such a determination.
>>
>> > On Oct 4, 2017, at 12:38 AM, Farid Zakaria <farid.m.zaka...@gmail.com>
>> wrote:
>> >
>> > I was combing through Bazel <https://bazel.build> (google's build
>> tool) and
>> > found a concept called iJar
>> > <https://github.com/bazelbuild/bazel/tree/master/third_party/ijar>
>> > iJar is basically a stripped out version of the Jar removing everything
>> but
>> > the public method signatures (very stripped out byte code jar).
>> >
>> > Their build tool uses iJars in determining if upstream dependencies can
>> be
>> > skipped to be rebuilt. The idea being: if the interface (iJar) of the
>> > current project hasn't changed (SHA), there's no need to rebuild
>> upstream
>> > dependencies since any possible method they'd have used did not change.
>> >
>> > My guess is this would be a good way to speed up "-amd"
>> > (also-make-dependents) by quickly stopping the build based on the iJar.
>> >
>> > Could this be done as a maven extension?
>> >
>> > Farid Zakaria
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>

Re: Maven Extension Idea: iJar support

[Thomas Broyer]

AFAIK, the ijar (for "interface jar") is a standard JAR, with standard
*.class files *except* that the method bodies and private members have been
stripped out (and timestamps are normalized too). That way, if you change a
method implementation, or a private member (add/remove private field or
method, change private method signature, add/remove private inner class),
the resulting ijar won't change. Any *.java compiled against such a *.class
would produce the exact same *.class, so by checking the ijar checksum you
can determine whether a dependency has changed in a way that would require
recompiling the code. You'd however use the "normal" jar checksum to
determine whether to re-run tests (Maven unconditionally re-runs tests, but
neither Bazel nor Gradle, they avoid re-running them if the inputs haven't
changed), as implementation matters in determining the outcome (whether the
tests pass or fail).

On Wed, Oct 4, 2017 at 4:27 PM Russell Gold  wrote:

> Does this iJar have more information than a regular JAR? If not, what is
> the benefit? If so, where is this information coming from?
>
> The closest thing I can think of is the new Java 9 module system, which
> defines what is visible; presumably, that information would be useful in
> such a determination.
>
> > On Oct 4, 2017, at 12:38 AM, Farid Zakaria 
> wrote:
> >
> > I was combing through Bazel  (google's build tool)
> and
> > found a concept called iJar
> > 
> > iJar is basically a stripped out version of the Jar removing everything
> but
> > the public method signatures (very stripped out byte code jar).
> >
> > Their build tool uses iJars in determining if upstream dependencies can
> be
> > skipped to be rebuilt. The idea being: if the interface (iJar) of the
> > current project hasn't changed (SHA), there's no need to rebuild upstream
> > dependencies since any possible method they'd have used did not change.
> >
> > My guess is this would be a good way to speed up "-amd"
> > (also-make-dependents) by quickly stopping the build based on the iJar.
> >
> > Could this be done as a maven extension?
> >
> > Farid Zakaria
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Where does shaded JAR get its POM?

[Thomas Broyer]

AFAIK, as soon as you use a  in a dependency, the transitive
dependencies from its POM aren't used (actually, Maven might even not
download the POM at all in this case); so you should be OK using
shaded.
Note however that, this shaded JAR still depends on Guava, SLF4J API and
Immutables, so you'll have to add explicit dependencies on those.

On Mon, Sep 4, 2017 at 7:36 AM Sander Verhagen 
wrote:

> Hi list,
>
>
> Different microservices at one company often have some shared
> infrastructure, such as for Service Discovery. I'm looking to use the
> awesome Consul Client for Java (
> https://github.com/OrbitzWorldwide/consul-client), and build a library
> that our various (Maven-based Java) microservices can use. In order to make
> our library not too invasive in terms of dependency resolution, I like the
> idea of using Consul Client's "shaded JAR". I believe shaded JARs weren't
> really meant to be consumed by other Maven projects. But this may be a
> reasonable exception. But when you look at the output of such project (like
> here:
> https://repo1.maven.org/maven2/com/orbitz/consul/consul-client/0.16.3/),
> you'll see a POM file with all the original dependencies, oblivious to the
> shading. Is there any known pattern of dealing with that? Like: "POM
> classifiers" - I know, I made that up. I also know there's an option to
> generate a "dependency reduced POM", but what good does that do if I can't
> depend on it? Should this project be generating two separate artifacts?
>
> (P.S.: I can certainly file an issue with the Consul Client project, but I
> want to be more helpful than that, and offer a concrete suggestion or a PR.)
>
> Thanks, Sander.
>
>
>
> Sander Verhagen
> [  san...@sanderverhagen.net  ]
>
>

Re: There must be a better way.

[Thomas Broyer]

m-shade-p takes the current project artifact as its input [1], so you can
configure it in the m-jar-p:
https://maven.apache.org/plugins/maven-jar-plugin/examples/manifest-customization.html

[1]
https://github.com/apache/maven-plugins/blob/maven-shade-plugin-3.1.0/src/main/java/org/apache/maven/plugins/shade/mojo/ShadeMojo.java#L404

On Wed, Aug 30, 2017 at 1:31 PM Daniel Persson <mailto.wo...@gmail.com>
wrote:

> Hi, Thomas.
>
> You're probably right. Sadly I can't find in the documentation how to add
> the main class and version information into your manifest file using the
> shade plugin.
>
> Best regards
> Daniel
>
> On Wed, Aug 30, 2017 at 1:24 PM, Daniel Persson <mailto.wo...@gmail.com>
> wrote:
>
> > Hi, Robert.
> >
> > I think I know what is happening here. The shaded jar replaces the
> > original jar the last thing that is done in the execution.
> > Sadly it's done only for the regular jar. Not the jar-with-dependencies
> > one.
> >
> > And yes I've updated the versions in the new build file. So assembly
> > plugin and shade plugin both run with 3.1.0.
> >
> > Best regards
> >
> > Daniel
> >
> > On Wed, Aug 30, 2017 at 12:15 PM, Thomas Broyer <t.bro...@gmail.com>
> > wrote:
> >
> >> You're using both m-assembly-p's jar-with-dependencies and m-shade-p,
> >> could
> >> it be a conflict between them? (or possibly you don't look at the
> correct
> >> JAR)
> >> If you use m-shade-p, you don't need m-assembly-p's
> jar-with-dependencies;
> >> m-shade-p does the same thing, better, and does more (class renaming,
> >> merging service resources, etc.)
> >>
> >> On Wed, Aug 30, 2017 at 11:54 AM Daniel Persson <mailto.wo...@gmail.com
> >
> >> wrote:
> >>
> >> > Hi Robert.
> >> >
> >> > Thank you for the prompt response.
> >> >
> >> > I've tried that transformer and I also tried to use this
> >> >
> >> >  >> >
> >> > implementation="org.apache.maven.plugins.shade.resource.Appe
> >> ndingTransformer">
> >> >
> >> >
> META-INF/services/javax.imageio.spi.ImageReaderSpi
> >> > 
> >> >
> >> > Sadly it doesn't work for me.
> >> >
> >> > The result is always the same. The first service file is the only one
> >> that
> >> > will be present in the output.
> >> >
> >> > So what I want to accomplice is that the output has a ImageReaderSpi
> >> file
> >> > that has content from all the jar files individual ImageReaderSpi in
> my
> >> > project.
> >> >
> >> > jai-imageio-jpeg2000:
> >> > com.github.jaiimageio.jpeg2000.impl.J2KImageReaderSpi
> >> >
> >> > jai-imageio-core:
> >> > com.github.jaiimageio.impl.plugins.wbmp.WBMPImageReaderSpi
> >> > com.github.jaiimageio.impl.plugins.bmp.BMPImageReaderSpi
> >> > com.github.jaiimageio.impl.plugins.pcx.PCXImageReaderSpi
> >> > com.github.jaiimageio.impl.plugins.pnm.PNMImageReaderSpi
> >> > com.github.jaiimageio.impl.plugins.raw.RawImageReaderSpi
> >> > com.github.jaiimageio.impl.plugins.tiff.TIFFImageReaderSpi
> >> >
> >> > and so on.
> >> >
> >> > Expected output:
> >> > com.github.jaiimageio.jpeg2000.impl.J2KImageReaderSpi
> >> > com.github.jaiimageio.impl.plugins.wbmp.WBMPImageReaderSpi
> >> > com.github.jaiimageio.impl.plugins.bmp.BMPImageReaderSpi
> >> > com.github.jaiimageio.impl.plugins.pcx.PCXImageReaderSpi
> >> > com.github.jaiimageio.impl.plugins.pnm.PNMImageReaderSpi
> >> > com.github.jaiimageio.impl.plugins.raw.RawImageReaderSpi
> >> > com.github.jaiimageio.impl.plugins.tiff.TIFFImageReaderSpi
> >> >
> >> > Actual output:
> >> > com.github.jaiimageio.jpeg2000.impl.J2KImageReaderSpi
> >> >
> >> > Best regards
> >> >
> >> > Daniel
> >> >
> >> > On Wed, Aug 30, 2017 at 11:24 AM, Robert Scholte <
> rfscho...@apache.org>
> >> > wrote:
> >> >
> >> > > On Wed, 30 Aug 2017 08:52:45 +0200, Daniel Persson <
> >> > mailto.wo...@gmail.com>
> >> > > wrote:
> >> > >
> >> > > Hi, everyone.
> >> > >>
> >> > >> I maintain a java tool that uses all the image libraries under the
> >> sun.
> >> > >

Re: There must be a better way.

[Thomas Broyer]

You're using both m-assembly-p's jar-with-dependencies and m-shade-p, could
it be a conflict between them? (or possibly you don't look at the correct
JAR)
If you use m-shade-p, you don't need m-assembly-p's jar-with-dependencies;
m-shade-p does the same thing, better, and does more (class renaming,
merging service resources, etc.)

On Wed, Aug 30, 2017 at 11:54 AM Daniel Persson 
wrote:

> Hi Robert.
>
> Thank you for the prompt response.
>
> I've tried that transformer and I also tried to use this
>
> 
> implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
>
> META-INF/services/javax.imageio.spi.ImageReaderSpi
> 
>
> Sadly it doesn't work for me.
>
> The result is always the same. The first service file is the only one that
> will be present in the output.
>
> So what I want to accomplice is that the output has a ImageReaderSpi file
> that has content from all the jar files individual ImageReaderSpi in my
> project.
>
> jai-imageio-jpeg2000:
> com.github.jaiimageio.jpeg2000.impl.J2KImageReaderSpi
>
> jai-imageio-core:
> com.github.jaiimageio.impl.plugins.wbmp.WBMPImageReaderSpi
> com.github.jaiimageio.impl.plugins.bmp.BMPImageReaderSpi
> com.github.jaiimageio.impl.plugins.pcx.PCXImageReaderSpi
> com.github.jaiimageio.impl.plugins.pnm.PNMImageReaderSpi
> com.github.jaiimageio.impl.plugins.raw.RawImageReaderSpi
> com.github.jaiimageio.impl.plugins.tiff.TIFFImageReaderSpi
>
> and so on.
>
> Expected output:
> com.github.jaiimageio.jpeg2000.impl.J2KImageReaderSpi
> com.github.jaiimageio.impl.plugins.wbmp.WBMPImageReaderSpi
> com.github.jaiimageio.impl.plugins.bmp.BMPImageReaderSpi
> com.github.jaiimageio.impl.plugins.pcx.PCXImageReaderSpi
> com.github.jaiimageio.impl.plugins.pnm.PNMImageReaderSpi
> com.github.jaiimageio.impl.plugins.raw.RawImageReaderSpi
> com.github.jaiimageio.impl.plugins.tiff.TIFFImageReaderSpi
>
> Actual output:
> com.github.jaiimageio.jpeg2000.impl.J2KImageReaderSpi
>
> Best regards
>
> Daniel
>
> On Wed, Aug 30, 2017 at 11:24 AM, Robert Scholte 
> wrote:
>
> > On Wed, 30 Aug 2017 08:52:45 +0200, Daniel Persson <
> mailto.wo...@gmail.com>
> > wrote:
> >
> > Hi, everyone.
> >>
> >> I maintain a java tool that uses all the image libraries under the sun.
> >> And
> >> they all expose the javax.imageio.spi.ImageReaderSpi service.
> >>
> >> Because it's hard to actually merge all the service definition files
> I've
> >> opted to merge them manually and add them into my META-INF/services
> >> directory.
> >>
> >
> > What's so hard?
> > Have you tried using https://maven.apache.org/plugi
> > ns/maven-shade-plugin/examples/resource-transformers.html#Se
> > rvicesResourceTransformer ?
> >
> > Robert
> >
> >
> >> Then I use maven shade plugin to exclude this file from all packages and
> >> then add it back with resources definition.
> >>
> >> This works 25% of the time and other times I have to open the jar file
> and
> >> replace this file manually. Because this is a manual step I forget to do
> >> this in some releases so I really hope there is a better way to do this.
> >>
> >> I've added the build definition part of the pom file to the link below.
> >>
> >> https://pastebin.com/bGy3bvm0
> >>
> >> Hope you have a creative solution to this problem. And thank you for a
> >> great tool that really simplified our build process.
> >>
> >> Best regards
> >> Daniel
> >>
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: Auditing version ranges

[Thomas Broyer]

Maven Enforcer Plugin's Require Upper Bound Dependencies might be enough
for your use-case (also notice there's a Require Release Dependencies rule
to prohibit snapshot dependencies)
http://maven.apache.org/enforcer/enforcer-rules/requireUpperBoundDeps.html

Le mar. 15 août 2017 12:06, Mark Raynsford 
a écrit :

> Hello.
>
> I've recently been considering moving to byte-for-byte reproducible
> builds of my software packages. It seems fairly easy to get there via
> plugins such as the reproducible-build-maven-plugin [0] as long as the
> build isn't otherwise unreproducible, but one thing that I am unsure of
> is whether or not it's possible to detect and fail the build if a
> (transitive) dependency is using version ranges.
>
> For example, if I declare a dependency on a package P and P declares a
> dependency on Q using a version range, then my build is effectively
> nondetermimistic (because a new version of Q may appear at any time).
> As a consumer of P, I may be totally unaware of Q and therefore won't
> know to override the versions of Q in my own dependencyManagement
> section.
>
> Is there a plugin that can reject the use of version ranges anywhere in
> the transitive dependency tree?
>
> I'm currently using scijava's plugin to reject snapshot versions [1],
> and am using the dependency plugin to fail builds with undeclared
> dependencies.
>
> [0] https://github.com/Zlika/reproducible-build-maven-plugin
> [1] https://github.com/scijava/scijava-maven-plugin
>
> --
> Mark Raynsford | http://www.io7m.com
>

Re: If anyone ever wanted to download a bunch of deps specified in a Maven POM for an Ant build

[Thomas Broyer]

Wouldn't have dependency:copy-dependencies helped here rather than
sed/grep/wget? (maybe not, devil is in the details and I just skimmed
through your script)
https://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html

Le dim. 11 juin 2017 20:53, Paul Hammant  a écrit :

> If your 'current directory' is a Maven checkout, I have a Python script
> that will download the dependencies into a libs/ folder. Well,
> libs/compile/ libs/test/ etc - one subfolder per scope.
>
> See here:
>
> https://github.com/paul-hammant/spring-jetty-integrationtest-ant-example/blob/master/mavdl.py
>
> I asked a question on Stackoverflow then answered it myself when my bash
> skills fell short of a bash one-liner for the same: -
> https://stackoverflow.com/questions/44390253
>
> In the case of my demo project 'spring-jetty-integrationtest-ant-example' I
> checked all the jars into Git again, like it was still the early 2000's :)
>
> - Paul
>

Re: dependency:analyze controversial result

[Thomas Broyer]

activemq-all, as its name suggests, bundles third-party dependencies in its
JAR (rather than declaring them as dependencies), and it happens to include
slf4j:
http://grepcode.com/snapshot/repo1.maven.org/maven2/org.apache.activemq/activemq-all/5.11.1
So I suppose, the first run finds slf4j classes in activemq-all so it marks
the slf4j dependency as "unused declared".
Do not ever use "uberjars" as dependencies, and report it upstream if it
comes as a transitive dependency of a third party (and in the meantime,
exclude the transitive dependency and add the proper non-uberjar
dependencies instead).

On Wed, May 17, 2017 at 10:14 AM Kristof Meixner <
kristof.meix...@fatlenny.net> wrote:

> Hi!
>
> Maybe I was too unclear about the specific problem.
>
> I've got a project that has org.slf4j:slf4j-api:1.7.12 as dependency as it
> uses the Logger in the Java code. The
> dependency is declared in POM but comes also as a transitive dependency.
>
> When running 'dependency:analyze' it is marked as 'unused declared'. When
> I remove the dependency from the POM, and run
> 'dependency:analyze' again it is marked as 'used undeclared'. Furthermore,
> in the first case suddenly another dependency
> [1] is marked as 'used undeclared' although it is never used directly.
>
> Best regards
> Kristof
>
> [1] org.apache.activemq:activemq-all:5.11.1
>
> On 05/16/2017 08:13 PM, Alexander Kriegisch wrote:
> > Maybe because
> >
> >   a) your project uses dependencies which were never declared explicitly
> >  in any of your POMs and
> >   b) at least some of your modules have dependencies declared which are
> >  not actually used in your code?
> >
> > What do you think?
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Continuous Delivery with Maven now possible?

[Thomas Broyer]

How about everybody read their mail?
(see below)

On Thu, May 4, 2017 at 6:10 PM Curtis Rueden  wrote:

> Hi Dan, Karl & everyone,
>
> > See Karl's Blog
>
> Link, please?
>
[…]

> > > > On 03/05/17 20:39, Dan Tran wrote:
> > > >
> > > >> Hi
> > > >>
> > > >> I have been experimenting with suggestion from Karl [1] with small
> > multi
> > > >> module maven project.

[…]

> > > >> [1]
> > > >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> > > >> t-a-version-in-it/
>

Re: Gentoo packaging / reproducibility of Maven-based Java projects

[Thomas Broyer]

Disclaimer: I don't know Gentoo.

On Mon, Mar 20, 2017 at 4:19 PM Curtis Rueden  wrote:

>
> The main question I have is about Maven plugins: since Maven builds do some
> bootstrapping, but Gentoo builds are not supposed to download things from
> the network, it means we might need a pre-baked Maven local repository
> containing all commonly used plugins at various release versions? If so,
> that would be unfortunate. I was hoping for some insight from others here.
>

Well, either the POM declares explicit versions, or those from the
super-pom are used (if declared there; and those versions then depend on
the version of Maven itself), or a warning is issued and IIRC Maven will
use the LATEST version.
So AFAICT you could know exactly what Maven plugins are needed (modify the
POMs to specify a version if fall into the 2 former cases above), and
package them similarly to the other dependencies.

There would still be problems with:
 * plugins that will fetch dependencies as needed. Surefire is one of them,
dynamically fetching the appropriate "provider" depending on which testing
framework is used in the build (JUnit 3, JUnit 4, JUnit 4.7+, TestNG); also
the maven-compiler-plugin when using , and
probably many others, not necessarily "exotic" plugins. Those would have to
be "discovered" by building the project first and then adapting the Gentoo
build to add the appropriate dependencies (what I mean here is that those
dependencies can't be extracted automatically from the POMs, at least
without knowing the specifics of each plugin)
 * plugins that access the network during the build
 * plugins that don't lead to reproducible builds

Re: [Help] Force maven[-surefire] to run in parallel

[Thomas Broyer]

Hi,

On Wed, Mar 15, 2017 at 2:11 PM Luis Henrique de Souza Melo <
l...@cin.ufpe.br> wrote:

> Hi,
>
> I am a student at the Federal University of Pernambuco, and our group is
> having some issues with Maven to run some tests in a huge amount of
> projects.
>
> We plan to run all theses open-source projects tests in parallel and in
> sequential using its own maven. However, we cannot change every pom.xml
> from every module and/or project main pom.xml manually.
>
> Is there any way to force maven and/or surefire to run in parallel using a
> command line argument, like: mvn test --parallel 3 -fae
> Or even in sequential mode would help us like: mvn test --sequential -fae
>

All parallelism-related properties can be set using "user properties",
which means you can set them from the command line (if they haven't been
set explicitly in the POMs); e.g. for forkCount [1] you can call Maven as
"mvn -DforkCount=2 test" to set the forkCount property to 2. If the
properties have been set in the POM, if they have been set using a property
value (e.g. ${some.property}) then you can override
the property from the command line (i.e. "mvn -Dsome.property=2 test"). If
the properties have been set with hard-coded values (e.g.
1) then you have no other choice than to edit the
POMs.

And then you can tell Maven to parallelize the build with -T.

Actually, everything seems to be described in the Surefire documentation [2]

[1]
https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#forkCount

[2]
https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html

Re: Possible to use maven API to get another projects binaries ?

[Thomas Broyer]

Le mar. 7 mars 2017 12:49, Tushar Kapila  a écrit :

> So is my best bet to make a OS Process, collect the output and parse
> the text to get files created like the following maven run snippet:
>
>
>
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
>
> [INFO]
> [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ CmdLineCalc ---
> [INFO] Building jar:
>
> /Users/dev1/u/w/github/tgkprog/mavenSampleCalcCmdLineProject/CmdLineCalc/target/CmdLineCalc-1.jar
> [INFO] META-INF/maven/s2n.sample.calc.cmdLine/CmdLineCalc/pom.xml
> already added, skipping
> [INFO] META-INF/maven/s2n.sample.calc.cmdLine/CmdLineCalc/pom.properties
> already added, skipping
> [INFO]
> 
> [INFO] BUILD SUCCESS
> [INFO]
> 
> [INFO] Total time: 1.659 s
> [INFO] Finished at: 2017-03-07T15:46:32+05:30
> [INFO] Final Memory: 16M/212M
> [INFO]
> 
>
> ---
>
> if I see a BUILD SUCCESS, then work back a few lines to find jars, wars,
> etc?
>

No, you should use Maven's API to get that information accurately. What I
meant is that you can't know it without running the build.