Re: [VOTE] Require Java 17 for Maven 4

[Mark Eggers]

+1 (nonbinding)

On 2/27/2024 11:30 PM, Benjamin Marwell wrote:

Hi Maven Devs/Users/Committers and PMC members!

After several discussions on the mailing lists, I would like to
start a vote in favour of setting the minimal Java bytecode target
of Maven-Core 4 to 17 and hence require Java 17 for Maven 4.

This is a procedural majority vote [1*]:
You can also vote with fractions and negative votes are not vetoes.

Please also notice:
* Maven 3 will stay at Java 8 no matter what.
* We may raise Maven 4 to JDK 21 later if we feel like it (depending
on the release date).
   This is not part of this vote.
* The linked PR is not part of this vote (this is not a code vote).
   But you may take a look at it to understand the intended change.

PR: https://github.com/apache/maven/pull/1430

Maven-Parent will not be raised with this vote, the other PR is not
part of this vote.

Please refrain from starting discussions in this thread, but do
include a reasoning on downvotes and feel free to start a new
discussion on the mailing list, or comment on the existing ones.

---

Vote open for 72 hours:

[ ] +1 (set JDK17 min version for Maven 4.x)
[ ] +0
[ ] -1 (please include reasoning)

---

- Ben

[1*]: https://www.apache.org/foundation/voting.html

-
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: maven debugging frustrations

[Mark Eggers]

I think the first two will help you compare what's working to what's not 
working.


The -X does generate a LOT of output. Use -l [filename] to catch it.

When you start reading it, you'll be able to ignore a lot of the chatter.

You can also set slf4j logging options on the command line to help 
things out. Check the following article:


https://www.baeldung.com/maven-logging

You might also play around with mvnDebug and attach an IDE to it. I've 
not tried this. The default port is 8000. It appears that you would then 
be able to set break points, etc.


. . . just my two cents
/mde/
On 12/19/2023 2:16 PM, mark.yagnatin...@barclays.com.INVALID wrote:

Thanks, I've heard of all three; the first two don't seem like they'd help here.
The third tends to spew junk and not useful stuff

-Original Message-
From: Mark Eggers 
Sent: Tuesday, December 19, 2023 5:11 PM
To: users@maven.apache.org
Subject: Re: maven debugging frustrations


CAUTION: This email originated from outside our organisation - 
its_toas...@yahoo.com.INVALID Do not click on links, open attachments, or 
respond unless you recognize the sender and can validate the content is safe.
Some commands that might help you get started:

What are you using to build the artifact

mvn help:effective-pom
mvn help:effective-pom -Dverbose

What artifacts are being brought in
--
mvn dependency:tree
mvn dependency:tree -Dverbose

Debug output
--
mvn -X package

I'm sure that there are more, but this might get you started.

. . . just my two cents
/mde/

On 12/19/2023 1:56 PM, mark.yagnatin...@barclays.com.INVALID 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/15t5z4LpKs5nXMa3HxmPT?h=ISgjwiKtVs_26S9D5WklDpkGWg5FN4KBfDXNiomU8xw==https://www.cib.barclays/disclosures/web-and-email-disclaimer.html.

For important disclosures, please see: 
https://clicktime.symantec.com/15t5uE9XsFQC7Qk7kQNEq?h=GqPl7-MY2KIl75o5H8ob4oRWV5EdZOb-0TiUB8Oz1g8==https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html
 regarding marketing commentary from Barclays Sales and/or Trading desks, who are active 
market participants; 
https://clicktime.symantec.com/15t5ejZgVQMQsaGM7jAny?h=TSMoSLWLMSCFVE_msBvk3E-bNX152eJ1jQtsfE-VVu0==https://www.cib.barclays/disclosures/barclays-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/15t5ZuNQ2nfpTdSRaAmeM?h=skuGBe0-9p6Q6bKdLkfmjGMNe-r_OrCz4yP_Du-cGJI==http://publicresearch.barclays.com.
__
 If you are incorporated or operating in Australia, read
these important disclosures: 
https://clicktime.symantec.com/15t5jZkxx231HX6GfHZwb?h=59l9AYOa74derd2shOK9ydN_NsfU5EV4DDyy0lC20Qk==https://www.cib.barclay

Re: maven debugging frustrations

[Mark Eggers]

Some commands that might help you get started:

What are you using to build the artifact

mvn help:effective-pom
mvn help:effective-pom -Dverbose

What artifacts are being brought in
--
mvn dependency:tree
mvn dependency:tree -Dverbose

Debug output
--
mvn -X package

I'm sure that there are more, but this might get you started.

. . . just my two cents
/mde/

On 12/19/2023 1:56 PM, mark.yagnatin...@barclays.com.INVALID 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://www.cib.barclays/disclosures/web-and-email-disclaimer.html.

For important disclosures, please see: 
https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html 
regarding marketing commentary from Barclays Sales and/or Trading desks, who 
are active market participants; 
https://www.cib.barclays/disclosures/barclays-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: http://publicresearch.barclays.com.
__
If you are incorporated or operating in Australia, read these important 
disclosures: 
https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__
For more details about how we use personal information, see our privacy notice: 
https://www.cib.barclays/disclosures/personal-information-use.html.
__




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

Re: Excluding artifact from project-info-reports dependency report

[Mark Eggers]

I'll have to think about how this works and the ramifications. Off the 
top of my head, I'm not sure how packaging the artifact as a JAR would help.


We make use of overlays, and then override the content in the project 
that depends on the WAR by utilizing Maven's WAR overlays. Basically, 
the first WAR component wins. The downstream project may override the 
dependency simply by having a file with the same name in the same web 
application location.


I might be able to use the dependency plugin and unpack the JAR contents 
in the correct place (and order). I'll think about that.


What I was hoping for is something like the following:



 dependencies
 dependencies
  
   
  
   arifactId



. . . . other reports . . . .


However, that doesn't seem to be available.

Of course, then you wouldn't be able to tell of that WAR dependency had 
updates. Hmm.


Thanks for replying.

Mark
/mde/

On 12/19/2023 3:32 AM, Nils Breunese wrote:

Can’t these resources be packaged in plain JARs and added as a regular 
dependency to the applications that require them, instead of using WAR overlays?

Nils.


Op 19 dec 2023, om 06:53 heeft Mark Eggers  het 
volgende geschreven:

I have several artifacts that consist of WAR archives with no server component.

In other words, there are only HTML, CSS, JS, JSP, images, fonts, etc.files in 
these artifacts. There are no servlets, listeners, POJOs, resources, etc. in 
these artifacts.

These artifacts are used as overlays in other projects to keep common 
components managed.

When a dependency report is run using these artifacts, there is an error along 
the lines of:

[ERROR] Artifact groupId:artifactId:war:version caused IOException:

[FILE_LOCATION]/classes  (The system cannot find the file specified)

-- stack trace --

Well this is obvious, since the WAR artifacts used as an overlay have no 
WEB-INF/classes directories.

Is there a way to exclude these artifacts  from dependency checking for 
projects that consume them? Or do I just live with the error messages in 
site:site (the site builds correctly).

I'm using maven-project-info-reports-plugin 3.5.0 with a variety of Maven 
versions (3.6.3, 3.9.6), and a variety of JDKs (8, 11, 17).

Any ideas would be greatly appreciated.

Thanks in advance,

Mark
/mde/

-
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

Excluding artifact from project-info-reports dependency report

[Mark Eggers]

I have several artifacts that consist of WAR archives with no server 
component.


In other words, there are only HTML, CSS, JS, JSP, images, fonts, 
etc.files in these artifacts. There are no servlets, listeners, POJOs, 
resources, etc. in these artifacts.


These artifacts are used as overlays in other projects to keep common 
components managed.


When a dependency report is run using these artifacts, there is an error 
along the lines of:


[ERROR] Artifact groupId:artifactId:war:version caused IOException:

[FILE_LOCATION]/classes  (The system cannot find the file specified)

-- stack trace --

Well this is obvious, since the WAR artifacts used as an overlay have no 
WEB-INF/classes directories.


Is there a way to exclude these artifacts  from dependency checking for 
projects that consume them? Or do I just live with the error messages in 
site:site (the site builds correctly).


I'm using maven-project-info-reports-plugin 3.5.0 with a variety of 
Maven versions (3.6.3, 3.9.6), and a variety of JDKs (8, 11, 17).


Any ideas would be greatly appreciated.

Thanks in advance,

Mark
/mde/

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

Re: maven-checkstyle-plugin using project dependencies?

[mark]

Op 15-12-2023 om 18:01 schreef David Hoffer:

Is it possible to configure maven-checkstyle-plugin to use one of the
project's modules as the source of the checkstyle XML file?

E.g. I have the plugin configured like this:


 org.apache.maven.plugins
 maven-checkstyle-plugin
 ${maven-checkstyle-plugin.version}
 
 
 com.puppycrawl.tools
 checkstyle
 10.12.3
 
 
 com.bs.arm.a2dl
 a2dl-build-tools
 ${project.version}
 
 
 
 a2dl/google_checks.xml
 true
 true
 false
 
 
 
 verify-checkstyle
 verify
 
 check
 
 
 



The problem is the plugin is looking in my .m2 folder or Maven proxy server
for this dependency.

  
 com.bs.arm.a2dl
 a2dl-build-tools
 ${project.version}
  

But it doesn't exist there yet as its a module of my/this project so its
one of the modules in the Maven build reactor.  Is it possible to configure
the plugin to use the project modules for this?


You could try adding it as a (test) scoped dependency to the project as 
well so the reactor knows when to build it.




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

Re: how to log exact HTTP request and response maven sends over the wire?

[mark]

Op 30-10-2023 om 16:14 schreef mark.yagnatin...@barclays.com.INVALID:

I have to edit the file?  There's no way to set this from command line?


You can set them as properties on the Maven commandline eg.
-Dorg.slf4j.simpleLogger.log.org.apache.maven.wagon.providers.http.httpclient=debug 



like here:
https://github.com/B3Partners/tailormap-api/blob/205fbe509d3498292f39654f5abe351a256725f7/.github/workflows/owasp-dependency-check.yml#L33

-M

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

Re: Feedback sought

[Mark Derricutt]

Tangential topic - a while ago there was a thread/discussion about 
adopting something like spotless/palantir-java-format for automated 
formatting.


Whilst a massive change to the code base, which can (potentially) cause 
horrors for open branches/PRs unless rebased with care and also 
reformatted - but also quite useful /once/ adopted, as such concerns as 
the above largely disappear, and any wonky/horrible formatting that 
comes up is often more a smell that maybe the code should be cleaner, or 
split up more.


I don't recall any definitive decision being made either way, the topic 
just seemed to stalemate (at least as far as I saw).


Palantir/spotless does at least require JDK 11+ I believe so that's a 
big blocker, at least as far as the build JDK goes.


Mark (with 2cents)

On 15/10/23 3:10 pm, Joseph Kesselman wrote:
My experience is that they can actually be useful in expressing things 
like preferred code formatting style in importable/executable form. 

Re: [ANN] Apache Maven 4.0.0-alpha-7 released

[Mark Derricutt]

 On 29/06/2023 at 3:16:24 PM, Guillaume Nodet  wrote:

> Maven 4.0.0-alpha-7 is available via https://maven.apache.org/download.cgi
>


Interesting - I noticed over the weekend that under 4.0.0-alpha-7 surefire
isn’t picking up any of my Junit 5 tests, but maven 3.9.4 is.

I haven’t had a chance to look into this yet - but I wondered if anyone
else had seen anything similar?


-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Working around "Can't compile test sources when main sources are missing a module descriptor"

[Mark Raynsford]

(Re-sent using correct address!)

Hello!

I recently started a discussion thread on the JUnit 5 repos detailing a
problem I'd been running into on a lot of projects:

  https://github.com/junit-team/junit5/discussions/3370

Long story short: In my projects, for various reasons, I put all of the
tests in one module rather than having a src/test/java in each. This
works fine, except for the fact that I have to maintain duplicate module
descriptors in the src/main/java and src/main/test directories of the
*.tests module, and I also have to maintain a shadow package hierarchy
in src/main/java filled with empty classes (one for each exported
package).

I'm about to start experimenting with putting test sources in
src/main/java in the *.tests module, but I'm slightly nervous about
doing this. It's quite an obvious divergence from Maven's conventions
(although arguably putting all tests in a *.tests module might be
considered one too [although the conventions were chosen before
Java platform modules existed!]). I'm not clear on how all of the tools
might misbehave if tests aren't in the source directory they're expected
to be in.

I realized I'm really only doing this because the Maven Compiler plugin
produces the error above if I don't have module descriptors in both
directories:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.11.0:testCompile
(default-testCompile) on project com.io7m.idstore.tests: Execution
default-testCompile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.11.0:testCompile
failed: Can't compile test sources when main sources are missing a
module descriptor -> [Help 1]

Is there perhaps a better way to get the Compiler plugin to ignore
src/main/java and just compile the tests?

-- 
Mark Raynsford | https://www.io7m.com



pgp0cfaNm2HEt.pgp
Description: OpenPGP digital signature

Maven Plugin Validation: Questions and Improvements

[Mark Symons (Fujitsu)]

Using Maven 3.9.2,  we see the following style of output:

Plugin validation issues were detected in 14 plugin(s)

* org.apache.maven.plugins:maven-compiler-plugin:3.8.1
* org.codehaus.mojo:rpm-maven-plugin:2.2.0
* 

I believe that it would be useful for the output to include information on the 
latest version of each plugin.  In the example above, maven-compiler-plugin is 
out of date and rpm-maven-plugin 2.2.0 is the latest version available. Having 
the latest version information displayed in context makes it a wee bit easier 
to decide what to do first about warnings...  specifically, update those that 
are out of date.  And updating maven-compiler-plugin gets rid of the warning.

Is there are reason why the above might be a pain to implement?   If  others 
agree that this would have then I will log an improvement issue in JIRA.

I also used the verbose output...

* org.codehaus.mojo:rpm-maven-plugin:2.2.0
Declared at location(s):
  * xxx
Used in module(s):
  * yyy
Plugin issue(s):
  * Plugin is a Maven 2.x plugin, which will be not supported in Maven 4.x
  * Plugin depends on plexus-container-default, which is EOL

Does "will be not supported in Maven 4.x" mean that the plugin will not work in 
4.0.0, or that there might be problems? (with the possibility of breakage as 
future 4.x releases become available).

So plexus-container-default is EOL.What replaces it?

I am happy to log an issue for the warnings in the rpm-maven-plugin GitHub 
repo...  but I do like to provide as much information as possible in order to 
help with triage.

For another plugin (sonar-maven-plugin:3.9.1.2184), I see:

* Plugin depends on the deprecated Maven 2.x compatibility layer, which may not 
be supported in Maven 4.x

May?   This sounds a bit vague.  Does the plugin need to be fixed sooner rather 
than later?


Mark Symons
Software Security Specialist, UK Delivery
Fujitsu
Langley Gate, Swindon Road, Kington Langley, Chippenham, SN15 5SE
UK
Tel: +44 (0) 7917 747950
Email: mark.sym...@fujitsu.com
Web: https://www.fujitsu.com/uk/



Unless otherwise stated, this email has been sent from Fujitsu Services Limited 
(registered in England No 96056); Fujitsu EMEA PLC (registered in England No 
2216100) both with registered offices at: Lovelace Road, Bracknell, Berkshire 
RG12 8SN; PFU (EMEA) Limited, (registered in England No 1578652) registered 
offices at: Belmont, Belmont Road, Uxbridge, England, UB8 1HE and Fujitsu 
Research of Europe Ltd (registered in England No. 4153469) 4th Floor, Building 
3, Hyde Park Hayes, 11 Millington Road, Hayes, UB3 4AZ.

This email is only for the use of its intended recipient. Its contents are 
subject to a duty of confidence and may be privileged. Fujitsu does not 
guarantee that this email has not been intercepted and amended or that it is 
virus-free.

Re: Splitting a dependency tree with the assembly plugin

[Mark Raynsford]

> On 2022-05-07T20:42:51 +0200
> Thomas Broyer  wrote:
> 
> How about first building a distribution for each module separately (each in
> its own Maven module) and then assemble them into a single distribution?  

I eventually went with this model. One application produces a
distribution zip, and the distribution model unpacks the distribution
and re-packs it with the contents of the other application. I've had to
introduce profiles in order to avoid breaking the build if assemblies
are skipped.

-- 
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: Splitting a dependency tree with the assembly plugin

[Mark Raynsford]

On 2022-05-07T20:42:51 +0200
Thomas Broyer  wrote:

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

Hello!

That might be an option, although I'm not sure how the modules and
dependencies would need to be arranged.

-- 
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

Splitting a dependency tree with the assembly plugin

[Mark Raynsford]

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: Determine Maven Dependencies after a build

[Mark Derricutt]

On 16/04/2022 at 3:09:09 AM, "Creager, Greg" 
wrote:

> Is there a drawback to simply running resolve-ranges before official
> builds to ensure the pom has static versions? That seems like it would
> resolve having published poms with version ranges in production.
> mvn versions:resolve-ranges -DprocessParent=true
>

On the surface that may seem like a good approach, but what we found along
time ago, this led to:


   - The build you’re running on local dev machines, and ci servers, and on
   whatever machine does the release - may not actually be the same versions
   that were tested.
   - One concrete issue we saw early on what a spring related dependency
   that we had locked down, but that dependency itself had an open range
   dependency on spring with something like [2.0.0,] - when spring 3 was
   released, those dependencies got pulled into a build that then broke. This
   was on an associates project, but we had similar issues that tripped up
   runtime dependencies in our OSGi environment.
   - Rather than a giant multi-module project, we have multi-repos - so
   when it came to doing a hot fix of the distribution/packing, we’d take the
   bill of materials that was used in the version we’re replacing, and resolve
   ONLY a newer version of the sub-modules we’re replacing - for example:


import company:company.distribution:111-ga1;

allow unlocked /^.company:the-patched-artifact$/;


Also on that patched artefact, we’d change that import to same released
version and resolve the used dependencies specifically to what’s being
replaced in production. It’s a small amount of ceremony but it has served
to minimise the surface area of change for retesting.

The downside of forcing [] versions and no transitives, does mean
occasionally we end up with a large amount of re-releasing modules that
only contain dependency version updates, often that’s only needed if major
versions have changed, or minor versions of API specific artifacts.

One thing I have been considering adding to this was also recording the
checksums of the artifacts resolved, to help mitigate
any potential side chain attacks.




-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: Determine Maven Dependencies after a build

[Mark Derricutt]

 I don’t believe there currently is a way for this is native maven.

We ended up writing a custom tool/mojo for resolution management using a
DSL like:

repository https://repo1.maven.org/maven2/ as central;

resolve highest org.antlr:antlr4-maven-plugin:[4.10,5.0.0) via central;

locked org.antlr:antlr4-maven-plugin:4.10;


Which tracks the repositories to check, a range to resolve, and what was
resolved/locked  ( also tracking deprecated/blacklisted dependencies ).

These pom.deps files get attached as artifacts and can be subsequently
imported in downstream repos:

repository https://nexus.az1.smxk8s.net/repository/maven-public-group;

import groupId:artifact.bill-of-materials:3.3.150;

locked org.antlr:antlr4-maven-plugin:4.10;


>From here, the actual pom.xml files are rewritten with
[4.10] references - locking the build to a specific,
locked range version ( for extra banality we also automatically add
 on * to prevent transitive dependencies.

This definitely has problems, but also have benefits and certainly made hot
fixes much easier to handle when we had different deployments staggered
into production between customer sites.

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree


On 14/04/2022 at 6:25:47 AM, "Creager, Greg" 
wrote:

> I am trying to reproduce a build that was done a week ago. Our maven pom
> files use range in many places ([1.0,1.1), when I go look at the pom of the
> published project, it just shows the range, not the actual version chosen:
>
> Published pom:
> 
>   com.hp.cp.dfe.shared
>   common-types
>   [1.0,1.1)
> 
>
>
> How do I determine exact versions of dependencies used in a prior build?
> In Apache ivy the published ivy.xml shows the exact version chosen, I was
> expecting maven to have the same and I am assuming I just am not using the
> right util.
>

Re: Maven Book recommendation

[Mark Raynsford]

On 2022-01-29T09:14:08 +
Mantas Gridinas  wrote:

> Looking at github's advanced search you can come up with the following list
> of repositories that use maven as its build tool
> 
> https://github.com/search?q=extension%3Axml+filename%3Apom=Code
> 
> But it seems that if you include filtering repositories by star count, the
> search breaks and instead returns repositories only by star count.

Curtis Rueden's never-ending work on scijava is an excellent example of
keeping tons of projects sane and consistent with a shared parent pom:

  https://github.com/scijava/

His work was a direct influence over the primogenitor pom that I use in
over a hundred projects:

  https://github.com/io7m/primogenitor

-- 
Mark Raynsford | https://www.io7m.com



pgpyLTts6pT3Q.pgp
Description: OpenPGP digital signature

Re: [ANN] Maven Resolver 1.7.1 released

[Mark Derricutt]

Interesting - updating to this version from 1.7.0 in my own plugin now
yields an NPE when creating a RepositorySystem - guess I know one thing I’m
working on this week :)

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Release Notes - Maven Resolver - Version 1.7.1

>
> ** Bug
> * [MRESOLVER-96] - Dependency Injection fails after upgrading to
> Maven 3.6.2
>
>

Re: pvn package command dependencies error

[Mark H. Wood]

On Tue, May 04, 2021 at 12:29:20PM +0200, Benjamin Marwell wrote:
> you need to use https URLs in your repositories. http URLs are now
> blocked by default.
> That should resolve the issue you are having.

He can't.  The problem is with a transitive dependency of Solr 4.10.4
and is in Solr's POM.  This is a known problem for DSpace:

  https://stackoverflow.com/q/66962265/2916377

It was activated by a recent Maven upgrade which blocks unencrypted
repository accesses by default.

> You should take a look at your $HOME/.m2/settings.xml, as well as
> potential occurrences of repository tags in your pom.xml files.

That won't help in this case, since the problem lies in a necessarily
ancient version of a third-party dependency.  One could either
override the block in .m2/settings.xml or manually acquire a copy of
the restlet artifact and install it in one's local repository (perhaps
using 'mvn install:install-file').

There are breaking changes in newer releases of Solr which won't be
accounted for in DSpace until the next major release (which should
come soon).  Moving to a newer Solr release is a rather involved
process due to those changes, and I don't know of anyone who has done
it with a released version of DSpace.

-- 
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


signature.asc
Description: PGP signature

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

[Mark Eggers]

For executable JARs I do this as well.

Sometimes for simpler projects, I'll add:

   true
   lib/

to the JAR plugin. I use the assembly plugin to place everything in its 
proper place.


That way I can just ship a tar.gz or zip file with all of the bits. 
Unzip / untar the archive and run java -jar jarfile.jar.


Tweaks can be made to account for a bin directory, a home directory on 
which to base both logging and classpath starting points, etc. That way 
you can put the shell / cmd / bat file in the path, set up a location to 
find other jars, and keep logging in a reasonable place.


. . . just my two cents
/mde/

On 4/25/2021 3:24 AM, Mantas Gridinas wrote:

I second this approach. It's much more simple, maintainble and you retain
the ability to monkeypatch production deployments. You can later chain it
into assembly plugin to produce an archive that contains your launch
scripts, dependencies, configurations, and perhaps even the JDK itself. 

If

youre against having launchscripts, you can write classpath into manifest
via archive plugin.

I doubt that uberjars should be used as dependencies at all considering
they usually suffer from split package issue. If yours doesnt, it probably
uses some special classloader, which makes runtime much more complex than
it needs to be.

On Sun, Apr 25, 2021, 12:45 Jim N  wrote:


there's nothing that really painlessly replaced the first
maven fatjar since it became outmoded.

that said, i use dependency plugin to dump a lib/ dir even for reactor
builds, and then a shell script that uses that classpath syntax to load a
directory at a time.

this happens with maven exec anyways, just less fragile.

sometimes shade chokes on a manifest glitch and in practice fixing that is
less efficient than a robust lib/ dir

in the parent-most pom if the levels go deeper, verbatim from the
dependency plugin docs, is
```!xml
 
 
 maven-dependency-plugin
 
 
 install
 
 copy-dependencies
 
 

${project.build.directory}/lib
 
 
 
 
```
in bin/ of the top level i have the tiniest specific bash runner, easily
ported to windows as well.

```!bash
#!/usr/bin/env bash

set -fx
JDIR=$(dirname $0)/../apprunner
exec java  -classpath "$JDIR/target/*:$JDIR/target/lib/*"
  ${EXECMAIN:=apprunner.MyMain} "$@"
```

often it's a helpful thing to keep these shell scripts handy to record
variaous -XX and -D parameters in the comments or at run time.








OpenPGP_signature
Description: OpenPGP digital signature

Re: Scratching my head over repositories ...

[Mark Raynsford]

On 2021-04-22T18:38:24 +0200
Tamás Cservenák  wrote:
>
> So, IMO, bite the bullet, and continue publishing to Central. Yes, is a
> process, is slow and has many problems, but is still the best way to go. At
> least for your users.

Publish your PGP key. Then, add this:

  https://github.com/io7m/primogenitor/blob/develop/pom.xml#L1035

... and deploying to Central is literally just:

  $ mvn -Dio7m.release=true deploy

The main problem is that the nexus-staging-maven-plugin isn't free
software. The reason for this escapes me.

-- 
Mark Raynsford | https://www.io7m.com



pgp4wztCiOmM9.pgp
Description: OpenPGP digital signature

Re: Scratching my head over repositories ...

[V. Mark Lehky]

I think you should be able to define your repo to take precedence over
Maven Central.

>From documentation


Remote repository URLs are queried in the following order for
artifacts until one returns a valid result:
1. effective settings:
1A. Global settings.xml
1B. User settings.xml
2. local effective build POM:
2A. Local pom.xml
2B. Parent POMs, recursively
2C. Super POM
3. effective POMs from dependency path to the artifact.

On Thu, 22 Apr 2021 at 09:24, Tommy Svensson  wrote:
>
> Hello fellow maven fans,
>
> A very long time ago I released a package to maven central. That was such a 
> pain that when Bintray came I  switched to Bintray (the best and simplest 
> service I've ever used! Really sad to see it gone). Now that Bintray is no 
> more I realized that I can publish my packages on my own web server and point 
> it out as a repository in pom. So far so good.
>
> I'm now having a problem building a maven project using one of my own tools: 
> CodeLicenseManager. I'm using version 2.2.1 which is available in my web 
> server repository. But maven still fails to find this dependency. It finds 
> the others in the same repo without any problem, but not this.
>
> I have come to the realisation that this is because CodeLicenceManager also 
> exists in maven central, but latest version there is 2.1.1 and I'm asking for 
> 2.2.1. But since maven is finding CodeLincenseManager in maven central, it is 
> not looking at other repos for this version.
>
> So now my question is: Is there a way to force maven  to look in all repos 
> when version is not available but artifact is ? Or is the only way out of 
> this to change the name or group of the artifact ?
>
> Best Regards,
> Tommy Svensson
>

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

Re: [maven-failsafe-plugin] run suites in parallel using maven failsafe

[V. Mark Lehky]

I will not be able to look at this today, but I will hopefully get
back to this within the next week.

If I get this working, I definitely will be able to contribute back.
Can you suggest where would be the best place to add docs about this?

On Tue, 13 Apr 2021 at 00:40, Tibor Digana  wrote:
>
> Hi,
>
> threadCountSuites is related to JUnit4 Suite, see this:
> https://github.com/junit-team/junit4/wiki/Aggregating-tests-in-suites
>
> threadCountClasses is related to the typical classes, see this example:
> https://github.com/junit-team/junit4/wiki/Assertions
>
> Parallel packages do not exist, but you can make the same if you write a
> Suite of Suites, example:
> SuiteMainTest has (SuiteATest, SuiteBTest) where SuiteATest has
> SomeStoryTest, AnotherStoryTest and SuiteBTest has DifferentStoryTest,
> OtherStoryTest
> and use this configuration parallel=suites, threadCountSuites=2,
> test=SuiteMainTest.
> This would work as you want to.
>
> It would nice to write an example in our documentation. If you want to
> participate in the open source, you can open a pullrequest in GitHub.
>
>
> Cheers
> Tibor
>
> On Mon, Apr 12, 2021 at 8:48 PM V. Mark Lehky  wrote:
>
> > I am trying to run my tests in parallel, and I have a use-case
> > different from all others that I have been able to find.
> >
> > My tests are laid out pretty straight-forward, something like the
> > following:
> >
> > src/test/java/
> > +-features.areaA
> > | +-SomeStory.java
> > | +-AnotherStory.java
> > | ...
> > +-features.areaB
> > | +-DifferentStory.java
> > | +-OtherStory.java
> > | ...
> > ...
> >
> > The tests are written using serenity-bdd, which is a wrapper for
> > selenium, and the test manager is junit4.
> >
> > Each "area" represents some discreet area of the application under
> > test. Tests within one area cannot run in parallel as they would
> > clobber the data they are using. However, tests between different
> > areas can certainly run in parallel as there are no collisions.
> >
> > I tried to configure my maven-failsafe-plugin according to the
> > documentation (
> > https://maven.apache.org/surefire/maven-failsafe-plugin/examples/fork-options-and-parallel-execution.html
> > ).
> > Using parallel=suites and any one of threadCount=4,
> > threadCountSuites=4, or useUnlimitedThreads=true, results in only one
> > test being run at a time.
> >
> > Is my understanding of "suites" wrong in the context of Failsafe
> > plugin? Is it possible to parallelize tests so that entire packages
> > are fed into VM threads one at a time, but classes within one package
> > run sequentially?
> >
> > ty
> >
> > -
> > 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

[maven-failsafe-plugin] run suites in parallel using maven failsafe

[V. Mark Lehky]

I am trying to run my tests in parallel, and I have a use-case
different from all others that I have been able to find.

My tests are laid out pretty straight-forward, something like the following:

src/test/java/
+-features.areaA
| +-SomeStory.java
| +-AnotherStory.java
| ...
+-features.areaB
| +-DifferentStory.java
| +-OtherStory.java
| ...
...

The tests are written using serenity-bdd, which is a wrapper for
selenium, and the test manager is junit4.

Each "area" represents some discreet area of the application under
test. Tests within one area cannot run in parallel as they would
clobber the data they are using. However, tests between different
areas can certainly run in parallel as there are no collisions.

I tried to configure my maven-failsafe-plugin according to the
documentation 
(https://maven.apache.org/surefire/maven-failsafe-plugin/examples/fork-options-and-parallel-execution.html).
Using parallel=suites and any one of threadCount=4,
threadCountSuites=4, or useUnlimitedThreads=true, results in only one
test being run at a time.

Is my understanding of "suites" wrong in the context of Failsafe
plugin? Is it possible to parallelize tests so that entire packages
are fed into VM threads one at a time, but classes within one package
run sequentially?

ty

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

Re: Maven internal company component sharing best practices

[Mark Eggers]

On 4/12/2021 11:11 AM, Alexander Kriegisch wrote:

IMO you are right, David.

I would suggest your colleagues follow your idea in order to avoid the concerns you raised. You have such nice, independent single-module apps now. Why sacrifice that and pruposefully killing modularisation by doing what your colleague(s) suggested? I am sure they have their reasons for suggesting it. But if the main reason is just avoiding to create another Git repository, I would argue that where they see a quick and easy way of extracting a common component or low-hanging fruit, I see a Pyrrhic victory in the making. Sorry for being judgemental here with limited contextual 
knowledge, but to me the situation looks quite clear: You are right, they 
are wrong. Sometimes it is as simple as that. If you want to extract the component, do it right or don't do it. If you do it wrong, the whole team 
will regret it very soon and come to the team manager to ask for something like a "refactoring sprint" (if you happen to have a Scrum-like framework in place).


Regards



I agree with this as well.

We have a bunch of lightweight (no more than 6 modules) end projects. 
Anytime we start to see commonality across multiple projects, we 
refactor to create a new dependency. We then just add that dependency to 
the projects that require it. If the dependency is ubiquitous, we can 
add it to our internal parent pom with dependency management.


We have at least one senior developer who likes clumping projects 
together. This has occasionally made releases challenging. Different 
parties have different release schedules / requirements, and when you 
bundle things together you can have priority conflicts.


However you can convince developers not to do this, I think is a good thing.

We do build against snapshots, which is something I'm trying to 
discourage. It makes downstream projects potentially unstable. Also, 
sometimes a developer will forget to test a project before a build 
system release, and the release will fail due to a SNAPSHOT dependency. 
It hasn't happened in a while, but it is an annoying event.


This type of structure makes management of competing releases easier 
(each release uses its required dependency). Yes, you have to release a 
dependency before releasing a downstream project if the dependency is 
needed. However, that won't impact other customer-facing downstream 
projects.


It also makes deploying a minor release that was built to satisfy 
another project's dependency into production much less likely. This is a 
good thing.


It does make tracking a large number of projects that use different 
minor releases of a dependency challenging. We're working on an 
automated system to track that so we can eventually archive old 
releases. We should probably have an EOL policy to facilitate that as 
well  - add that to my list of things to do.


. . . just my two cents
/mde/



OpenPGP_signature
Description: OpenPGP digital signature

Re: GitHub Actions yml

[mark]

Op 14-02-2021 om 04:05 schreef Anthony Whitford:

However, I would ideally also like to see workflows for running Site (and 
SCM-Publish to GitHub Pages)


there's a generic publishing action you can use to push some directory 
into a gh-pages branch: 
https://github.com/JamesIves/github-pages-deploy-action


haven't used it, but here's an example: 
https://github.com/jeremylong/DependencyCheck/blob/main/.github/workflows/release.yml#L242


also does some other nifty things re releases

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

Re: Version ranges: bug or feature

[mark]

You may be able to configure/improve this by setting up your 
repositories (eg the updatePolicy and type of artifacts) see 
https://maven.apache.org/pom.html#repositories


-M



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

Re: Resource plugin - LifecycleExecutionException - Input length = 1

[Mark Prins]

Op wo 12 aug. 2020 om 21:47 schreef Tobias :

>
>
> Failed to execute goal
> org.apache.maven.plugins:maven-resources-plugin:3.2.0:testResources
> (default-testResources) on project XXX: Input length = 1
>
> See [2] below for a more detailed stack trace.
>
> Do you know what goes wrong and how this can be fixed?
>
>
I ran into this as well, after updating the list of "
nonFilteredFileExtensions" this seems to be fixed, see eg.
https://github.com/B3Partners/brmo/pull/901/files

run "mvn -X process-test-resources" to get the list of filtered files


-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.

mismatch between maven-release-plugin site and available artifacts

[Mark Prins]

There is a mismatch between the published site and the available artifact.

https://maven.apache.org/maven-release/maven-release-plugin/index.html 
lists 3.0.0-M2 published 2020-04-07 as the current release, but it 
cannot be downloaded from eg. 
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-release-plugin/


can anyone resolve this?

TIA, Mark

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

Re: Maven moving to the next level: the build/consumer pom

[Mark Derricutt]

Love the work here - I'll definitely be keen on trying this out and see how it 
interacts with our tiles-maven-plugin.

Regarding this "reactor" bit tho - just because a module is in the reactor, 
doesn't always mean it has the same parent - the version of the dependency 
could be elided if the parent version matched AND that dependency is part of 
the reactor.

However, I have seem people use reactors purely as build-coordinators, and not 
always used. I'd much rather seeing them stay - esp. if using version ranges ( 
we force [] ranges for instance ).

Mark

On 24/06/20, 9:20 AM, "Matthieu BROUILLARD"  wrote:

> dependencies that are part of the reactor don't need a version anymore
What is meant here ? Is it that in a multimodule project a dependency from
a module to another of the same multimodule does not need the version ? For
example when having an api and impl in the same multimodule, the impl will
not require the version of the api?

More module-related Javadoc issues

[Mark Raynsford]

Hello!

The jgrapht project is currently having issues with Javadoc generation
when executing the javadoc:jar target in isolation:

  https://github.com/jgrapht/jgrapht/pull/938

The symptom is very odd:

Loading source file
/home/jvs/open/d-michail/jgrapht/jgrapht-core/src/main/java/module-info.java...
1 error
error: module not found: org.jgrapht.core

In other words, the plugin is claiming not to be able to find the
module in the source file that contains the module descriptor!

I'm not seeing anything suspicious in the generated argsfile, options
file. Could somebody who knows the plugin a little better please
assist?

-- 
Mark Raynsford | https://www.io7m.com



pgprJjH9iYo60.pgp
Description: OpenPGP digital signature

Re: missing dependency version

[mark]

looks like you got a html document instead of a pom file as a response

On 2020-03-12 20:00, Rune Gellein wrote:

Hi,
I was have just moved to using the maven resolver ant task and I am now
getting this error:
/org.apache.maven.model.building.ModelBuildingException: 4 problems were
encountered while building the effective model for com.sun.xml.ws:rt:2.3.1
[FATAL] Non-parseable POM
C:\Users\me\m\org\glassfish\jaxb\jaxb-bom\2.3.1\jaxb-bom-2.3.1.pom: end tag
name  must match start tag name  from line 5 (position: TEXT seen
...\r\n... @6:8)  @
C:\Users\me\m\org\glassfish\jaxb\jaxb-bom\2.3.1\jaxb-bom-2.3.1.pom, line 6,
column 8
[ERROR] 'dependencies.dependency.version' for
org.glassfish.jaxb:jaxb-runtime:jar is missing. @
[ERROR] 'dependencies.dependency.version' for org.jvnet.staxex:stax-ex:jar
is missing. @
[ERROR] 'dependencies.dependency.version' for javax.xml.bind:jaxb-api:jar is
missing. @/

This worked when I used the old maven ant task.  I can also see this gets
resolved correctly when using maven directly in the Intellij IDE.  So have I
missed something when using the resolver ant task?



--
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




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

Re: Best Practice for distributing test utilities?

[Mark Prins]

refactor foo to a multimodule one with the test utilities as an artifact 
and one with the code + tests for original foo, you can then depend on 
the test module with scope test in the main module and keep everything 
in source repo making it easy to stay in sync


On 12-03-2020 14:55, Andreas Sewe wrote:

Hi,

I am struggling to figure out what the Maven Way is for distributing
test utils.

Say I have a project "foo" along with some unit tests for it. Moreover,
I have some utilities that help in testing "foo" (e.g., test data
builders or test fixtures). These utilities are used by the unit tests
for "foo", but may also be useful to projects depending on "foo" (e.g.,
a FooTestDataBuilder that produces Foo instances could also be used in
the tests of a dependent project "bar").

The question is where to place these test utilities and how to depend on
them.

1. I could follow the "guide to using attached tests" [1], place the
test utilizes in foo/src/test/java, and attach the test-jar to "foo".
Then, a dependent project "bar" could depend on the test-jar in its test
scope. Alas, as the test scope is not transitive, I would need to
declare all test-dependencies of "foo" again in "bar", even though I may
not even use them directly (e.g., if the FooTestDataBuilder uses them
only internally).

2. I could split "foo" into three projects: "foo", "foo-test-utils", and
"foo-tests", with the latter depending on both "foo-test-utils" and
"foo-tests". A project "bar" would then simply depend on "foo" in
compile scope and "foo-test-utils" in test scope. This would make all
dependencies explicit, but would result in some oddities, e.g.,
foo-tests/src/main/java being empty, as all tests need to be placed in
tests/src/test/java to be picked up by Surefire.

3. I could split "foo" into just two projects, "foo" and "foo-testing".
foo-testing/src/main/java would the contain the test utilities for
"foo", whereas foo-testing/src/test/java would contain the actual tests.
This is again somewhat odd, as the tests in foo-testing/src/test/java
are not testing "foo-testing" but "foo".

4. Option 4 is the most natural way, but unfortunately it doesn't work,
because it introduces a cyclic dependency: Have "foo" and
"foo-test-utils" and let the tests of "foo" depend on "foo-test-utils".

Am I missing something? In particular, why is [1] apparently the
recommended approach, even though it requires you to duplicate
dependency information?

Any suggestions are greatly appreciated.

Best wishes,

Andreas

[1] 




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

Re: Configure default execution phase

[Mark Prins]

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: is there a maven plugin to identify ancient pom dependencies

[Mark Prins]

On 21-12-19 21:02, Maarten Mulders wrote:
Maybe this can help you: 
https://github.com/portofrotterdam/versiondebt-plugin
As far as I can see, it doesn't allow you to configure "what is old". It 
does tell you how old dependencies are.


not really; it seems that it uses the "last modified" from a 
URLConnection to the artifact in a repository, so unlikely to provide a 
date related to the time of release. it will be unreliable in any 
situation that a maven proxy is used.


see:
https://github.com/portofrotterdam/versiondebt-plugin/blob/e500e2d2a1fce4eb350633c7515b04107dae42d6/versiondebt-maven-plugin/src/main/java/com/portofrotterdam/versiondebt/VersiondebtMojo.java#L218-L229


Important disclaimer at the end of the page: it isn't maintained on a 
regular basis.


Cheers,

Maarten

On December 21, 2019 at 18:50, Enrico Olivelli wrote:


Something like this:
https://www.mojohaus.org/versions-maven-plugin/display-dependency-updates-mojo.html 



Hope that helps
Enrico

Il sab 21 dic 2019, 18:31 mark  ha scritto:

On 2019-12-20 13:39, Marlow, Andrew wrote:
Hello everyone,

I am using the owasp maven dependency plugin to tell me when I am
using components that have CVEs. That's great. I was wondering if
there was something similar that would tell me when I am using very
old components (where the judgement about what is old is configurable,
e.g number of years, months etc).

never seen one, it would be hard without querying the source repository
for the release tag/branch for the moment the release was cut (which is
problematic in case a minimal release pom is in use. The current pom
does not have this/a timestamp for this and you cannot use the file date.

I guess you could look at the date of the (class) files inside the
artifact (jar) to determine build/release date, not sure how that would
work out with shaded dependencies or provided manifest files

-M

*Andrew Marlow*

Software Engineer Specialist, Apex

38^th Floor, 25 Canada Square,

Canary Wharf, London E14 5LQ

*T*:  020-8081-2367 / 07966-451-521
*E*: andrew.mar...@fisglobal.com <mailto:andrew.mar...@fisglobal.com>

*FIS | Advancing the way the world pays, banks and invests(tm) *

cid:image004.png@01D542DF.1DA72090
<https://www.facebook.com/FIStoday>cid:image005.png@01D542DF.1DA72090
<https://twitter.com/FISGlobal>cid:image008.png@01D542DF.1DA72090
<https://www.linkedin.com/company/fis>

The information contained in this message is proprietary and/or
confidential jadajadajada...


-
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: is there a maven plugin to identify ancient pom dependencies

[mark]

On 2019-12-20 13:39, Marlow, Andrew wrote:


Hello everyone,

I am using the owasp maven dependency plugin to tell me when I am 
using components that have CVEs. That’s great. I was wondering if 
there was something similar that would tell me when I am using very 
old components (where the judgement about what is old is configurable, 
e.g number of years, months etc).




never seen one, it would be hard without querying the source repository 
for the release tag/branch for the moment the release was cut (which is 
problematic in case a minimal release pom is in use. The current pom 
does not have this/a timestamp for this and you cannot use the file date.


I guess you could look at the date of the (class) files inside the 
artifact (jar) to determine build/release date, not sure how that would 
work out with shaded dependencies or provided manifest files



-M


*Andrew Marlow*

Software Engineer Specialist, Apex

38^th Floor, 25 Canada Square,

Canary Wharf, London E14 5LQ

*T*:  020-8081-2367 / 07966-451-521
*E*: andrew.mar...@fisglobal.com 

*FIS | Advancing the way the world pays, banks and invests™ *

cid:image004.png@01D542DF.1DA72090 
cid:image005.png@01D542DF.1DA72090 
cid:image008.png@01D542DF.1DA72090 



The information contained in this message is proprietary and/or 
confidential jadajadajada...

Re: Augment pom dependencies information with custom ones

[Mark H. Wood]

On Thu, Dec 05, 2019 at 09:04:17PM +0200, Anton Tanasenko wrote:
> If you have control over report generation, what you can do is add xml
> processing instructions into your pom files that your plugin can later
> parse out of the xml without interfering with existing pom model.
> M2Eclipse uses that approach to add some metadata to plugin executions.
> Here's [1] the code pointer that performs the parsing from maven model.
> 
> [1]
> https://github.com/eclipse/m2e-core/blob/master/org.eclipse.m2e.core/src/org/eclipse/m2e/core/internal/lifecyclemapping/AnnotationMappingMetadataSource.java#L168

It might be even easier than that.  Could one not write an XSL
transform to combine the POM with a document containing named
dependencies and your rationales, to produce such a report?

But it would be nicer if the schema and the dependency plugin were
extended to permit the documentation that was requested.  And it does
seem in line with Maven's purpose as a "project...comprehension tool."

Another approach, which wouldn't require releasing a new version of
the POM schema, would be if Maven had an option to politely ignore
elements in other namespaces instead of killing the build with an
ERROR.  Then a POM document could be augmented for processing by other
tools (such as a slightly different XSL transform).

-- 
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


signature.asc
Description: PGP signature

Re: Maven Release Plugin Message Format

[Mark Prins]

don' t recall any commits like that, generally I see that the last commit
in a tag is "[maven-release-plugin] prepare release

..."
and in my master branch I see "[maven-release-plugin] prepare release
..."
and then "[maven-release-plugin] prepare for next development iteration

"

looking at
https://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html
there
seems to be no option to do what you want.
-M

Op do 31 okt. 2019 om 09:12 schreef Scott Rossillo :

> We're using the maven-release-plugin and all our tags end up looking like:
>
> vX.Y.Z copy for tag vX.Y.Z
>
> With git "copy for tag" is pretty nonsensical. Preferably, the message
> would be "Release X.Y.Z". I looked at the source code and see the actual
> tagging is delegated to another package, org.apache.maven.shared.release.
>
> Anyway, is there a way to override the commit message and if not, which
> component should a ticket be file or suggested change be recommended to?
>
> Best,
>
> Scott
>


-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.

Re: POM parent/import relationship visualization

[Mark Eggers]

On 10/29/2019 9:01 AM, Tomo Suzuki wrote:
> Hi Marco,
> 
> Thank you for response. NetBeans' "Effective" almost worked. It showed the
> problematic artifact "grpc-api:1.24.0", which I was looking for, and showed
> it's from "grpc-bom". Great. But I also want to see where this grpc-bom
> coming from.
> 
> [image: image.png]
> 
> Regards,
> Tomo
> 

There is also a graph layout for poms in NetBeans as well. It shows
parent-child relationships of dependencies, and will show if a single
dependency has multiple parents.

Unfortunately, the graph zoom functionality seems to be missing in 11.1
of the IDE. It was there in 8.2. I haven't downloaded 11.2 yet (almost
released) to see if the graph zoom functionality has made it back in. If
not, I should probably open up an enhancement request.

. . . just my two cents
/mde/




signature.asc
Description: OpenPGP digital signature

Re: Quicker local maven builds article

[Mark H. Wood]

On Tue, Oct 22, 2019 at 09:34:46PM +0100, Paul Hammant wrote:
> Maven's XML is too element normal for my liking.  Attributes where
> appropruate would be good.

Yes.  But changing now would be quite a wrench, even with tools to
translate the old dialect to the new.  A lot of other code also
understands POM documents nowadays.

> Also deps and GAVs needs a shakeup, IMO:
> 
> 
>   
>  com.thoughtworks.xstream:xsteam:1.4.3
>   
>   
> org.junit:junit:4.12
> org.seleniumhq.selenium:selenium-java:3.14159
>   

Please, no.  
perhaps.

> Not being able to grep for specific GAVs is a critical flaw.

Wrong tool.  grep is for text, not structured documents.  Try XQuery.



But this is wandering away from "how can we avoid rebuilding unchanged
stuff?"

-- 
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


signature.asc
Description: PGP signature

Finding out what the versions plugin did

[Mark Raynsford]

Hello!

Is there a machine-readable way I can find out what the Versions plugin
did after I've executed it? I'm writing a CI task that tries to
periodically update the dependencies of a project.

Essentially, the task does this:

$ mvn clean verify
$ mvn -DallowMajorUpdates=false \
  versions:use-latest-releases \
  versions:update-properties
$ mvn clean verify

If the second "clean verify" execution succeeds, then we assume that
all the new dependency versions are fine. The task then goes on to
commit the pom.xml changes.

The problem: I'd like to retrieve the list of dependencies that were
updated (their previous and current versions) so that I can produce a
nice commit message and changelog entry. I can't seem to get this
information out of the plugin.

I've seen the documentation for the dependency-updates-report goal, so
I tried doing this:

$ mvn clean verify
$ mvn \
  -DallowMajorUpdates=false \
  -DdependencyUpdatesReportFormats=xml
  -DoutputDirectory=. \
  versions:dependency-updates-report \
  versions:use-latest-releases \
  versions:update-properties
$ mvn clean verify

But this just doesn't appear to produce any output. Am I doing
something wrong?

Is there some better way to do this?

-- 
Mark Raynsford | http://www.io7m.com



pgpxfNYhIx3l_.pgp
Description: OpenPGP digital signature

Re: Surefire plugin with multi-release?

[Mark Derricutt]

Well this escalated quickly :) Now to find some time to look at this.

I'll pull the plugin code later

On 6 Apr 2019, at 19:52, Tibor Digana wrote:

> Mark, do not forget to update documentation with certain usecase(s).
> Configure your tool (prefer IntelliJ IDEA) with code style, see the
> instructions in
> https://maven.apache.org/developers/conventions/code.html#
> IntelliJ_IDEA_4.5.2B
> and download https://maven.apache.org/developers/maven-idea-codestyle.xml


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Surefire plugin with multi-release?

[Mark Derricutt]

On 5 Apr 2019, at 6:29, Robert Scholte wrote:

> If you want to test the jar, you must use the failsafe plugin (or bind 
> surefire to the integration-test phase)

Can/could failsafe take a toolchain id as config, then you could configure 
additional executions using each toolchain you wanted?


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Jar plugin: Per-entry compression settings?

[Mark Raynsford]

Hello.

I have a jar file that contains a lot of resources and class files that
compress well, and also a few resources that not only don't compress
well but that I'd actually like to be able to mmap() by parsing the jar
and mapping those sections of the file into memory.

Being able to mmap(), however, is pretty much dependent on those
particular resources not being compressed.

It seems as though the jar plugin only allows me to turn compression on
or off for the entire archive. Is there any way I can specify that I
want everything compressed except for a few specific entries?

-- 
Mark Raynsford | http://www.io7m.com



pgpdRRzzmqrUO.pgp
Description: OpenPGP digital signature

Re: Is specifying direct dependencies a good practice?

[Mark H. Wood]

On Thu, Jan 10, 2019 at 09:14:45AM -0500, Mark H. Wood wrote:
> I try always to declare all direct dependencies, regardless of whether
> they are also transitive dependencies (today).
> 
> One reason for this is that it improves the documentation of the
> project.  Not only does it provide useful information to reporting
> tools driven by Maven, but you can learn useful things about a project
> by just reading the POM.
> 
> Another reason is that I'm uncomfortable relying on the inclusion of
> direct dependencies by happenstance.  An upgraded dependency, which
> *was* pulling in another direct dependency but does no more, can break
> the build in a way that is quite avoidable.

A third reason is that it gives you a chance to specify what versions
of your dependencies are used, instead of letting other dependencies
set (and change!) those versions.  Use with caution:  there may be
strong reasons for those other dependencies to require the versions
that they do.

If you have an assembly composed from multiple complex projects, you
may be able to harmonize versions of shared dependencies instead of
ending up with multiple versions of the same artifact and wondering
which one is used.

-- 
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


signature.asc
Description: PGP signature

Re: Is specifying direct dependencies a good practice?

[Mark H. Wood]

On Thu, Jan 10, 2019 at 04:51:17PM +0800, 林自均 wrote:
> I feel a bit uncomfortable with using the classes in transitive
> dependencies. For example, my project A depends on other project B, and
> project B depends on project C. When I directly use the classes of projects
> C in my project A, I expected that Maven would throw a warning on it, since
> project B may someday remove or update the version of the dependency of
> project C. However, it complains nothing. It makes me wonder what's Maven's
> recommendation for such scenario. After reading the tutorial on
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html,
> I still couldn't find out what Maven suggests.
> 
> When I use a class in my project, is it a better practice to specify the
> project containing the class as a direct dependency, or just let the
> transitive dependency do its job? What's the catch? Thanks!

I try always to declare all direct dependencies, regardless of whether
they are also transitive dependencies (today).

One reason for this is that it improves the documentation of the
project.  Not only does it provide useful information to reporting
tools driven by Maven, but you can learn useful things about a project
by just reading the POM.

Another reason is that I'm uncomfortable relying on the inclusion of
direct dependencies by happenstance.  An upgraded dependency, which
*was* pulling in another direct dependency but does no more, can break
the build in a way that is quite avoidable.

-- 
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


signature.asc
Description: PGP signature

Re: Copying dependencies (including reactor modules)

[Mark Raynsford]

'Ello.

On 2018-12-06T03:29:43 -0700
matteosilv  wrote:

> This is the exact same behavior i need to acomplish, but i can't do it after
> package phase, because i need the dependencies (excluding the ones that are
> projects in my multi-module build) in a specific folder in order to run a
> development server.

As part of a test suite?

> It's pretty weird imho, that, when excluding a groupId, the plugin still
> tries to download dependencies with that groupId, even if later it is going
> to exclude them!

Which plugin are you referring to here?

-- 
Mark Raynsford | http://www.io7m.com



pgpnNMdWjnKkc.pgp
Description: OpenPGP digital signature

Re: Username/password not sent for altDeploymentRepository?

[Mark Raynsford]

On 2018-11-04T23:16:31 +0100
"Mirko Friedenhagen"  wrote:

> Maybe you run into 
> https://issues.apache.org/jira/plugins/servlet/mobile#issue/MDEPLOY-244. 
> maven-deploy-Plugin 3.0x has a slightly different syntax for specifying 
> alt*Repositories.
> 

Ouch! Yes, that would explain it. I did notice something odd in the
output of mvn -X:

[DEBUG] Using transporter WagonTransporter with priority -1.0 for 
https://packages.example.com/repository/example-releases
[DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for 
https://packages.example.com/repository/example-releases
Uploading to example-releases::default: 
https://packages.example.com/repository/example-releases/com/io7m/testartifact/com.io7m.testartifact/0.0.1/com.io7m.testartifact-0.0.1.jar
 ^^^

Notice that suspicious space after "default". Given MDEPLOY-244, it
looks as though "example-releases::default" is being treated as the
repository ID (and therefore isn't finding credentials in settings.xml).

-- 
Mark Raynsford | http://www.io7m.com



pgpkRSUoQ1UQL.pgp
Description: OpenPGP digital signature

Re: Username/password not sent for altDeploymentRepository?

[Mark Raynsford]

I've been completely unable to get this work. It seems like
altDeploymentRepository just doesn't pick up credentials for whatever
reason.

I've instead taken this approach: In my organization-wide POM, I've
added a profile:



  io7m-alternate-repository
  

  io7m.useAlternateRepository

  
  

  ${io7m.repository.releases.id}
  ${io7m.repository.releases.url}


  ${io7m.repository.snapshots.id}
  ${io7m.repository.snapshots.url}

  


I then deploy with:

$ mvn \
  -Dio7m.useAlternateRepository=true
   \
  -Dio7m.repository.releases.id=example-releases
   \ 
  
-Dio7m.repository.releases.url=https://packages.example.com:8443/repository/example-releases/
\
  -Dio7m.repository.snapshots.id=example-snapshots  
   \ 
  
-Dio7m.repository.snapshots.url=https://packages.example.com:8443/repository/example-snapshots/
  \
  clean deploy 

I have a  element in settings.xml that supplies credentials for
repositories with ids "example-releases" and "example-snapshots" and
the credentials are picked up correctly by the deploy plugin.

-- 
Mark Raynsford | http://www.io7m.com



pgpxFdu1Tdhlc.pgp
Description: OpenPGP digital signature

Re: Username/password not sent for altDeploymentRepository?

[Mark Raynsford]

On 2018-11-04T12:30:32 +
Mark Raynsford  wrote:
> 
> 2018-11-04 12:14:16,266 [qtp367589601-760] INFO  
> org.apache.archiva.security.ArchivaServletAuthenticator [] - Authorization 
> Denied [ip=10.2.4.1,permission=archiva-upload-repository,repo=arc7-releases] 
> : no matching permissions
> 2018-11-04 12:14:19,359 [qtp367589601-760] INFO  
> org.apache.archiva.security.ArchivaServletAuthenticator [] - Authorization 
> Denied [ip=10.2.4.1,permission=archiva-upload-repository,repo=arc7-releases] 
> : no matching permissions
> 2018-11-04 12:14:52,504 [qtp367589601-761] INFO  
> org.apache.archiva.security.ArchivaServletAuthenticator [] - Authorization 
> Denied [ip=10.2.4.1,permission=archiva-upload-repository,repo=arc7-releases] 
> : no matching permissions
> 2018-11-04 12:14:55,567 [qtp367589601-760] INFO  
> org.apache.archiva.security.ArchivaServletAuthenticator [] - Authorization 
> Denied [ip=10.2.4.1,permission=archiva-upload-repository,repo=arc7-releases] 
> : no matching permissions

That should have read "example-releases" - pasted the wrong set of
lines. The error is the same, however.

-- 
Mark Raynsford | http://www.io7m.com



pgpsKmMygReXR.pgp
Description: OpenPGP digital signature

Username/password not sent for altDeploymentRepository?

[Mark Raynsford]

Hello!

As is probably obvious from my other questions, I'm currently setting up
a local repository manager (Apache Archiva in this instance) used to
deploy internal releases (things that won't make it to Central), and to
act as a proxy for Central for my local network.

Archiva appears to be set up correctly, I can log in to the admin
interface and upload artifacts via that without issue. However, I seem
to be unable to deploy via "mvn deploy". I'm using a profile to use the
repository manager conditionally, because *most* of the time I want to
deploy directly to Central. I don't want to add the address of the
repository manager to each project pom, because that information is
strictly internal. My ~/.m2/settings.xml file looks like this:


http://maven.apache.org/SETTINGS/1.0.0; 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd;>
  

  example
  

  example-releases
  Example Releases
  https://packages.example.com/repository/example-releases/
  default

  


  example-deploy
  

example-releases::default::https://packages.example.com/repository/example-releases/
  

  
  
example
  
  

  packages.example.com
  https://packages.example.com/repository/releases/
  external:*

  
  

  example-releases
  io7m
  

  


When I call "mvn -P example-deploy", Maven correctly tries to deploy
via the https://packages.example.com/repository/example-releases/ repos
instead of Central, but it seems like it refuses to send a username and
password. I get a 401 error from Archiva. The Archiva logs mention:

2018-11-04 12:14:16,266 [qtp367589601-760] INFO  
org.apache.archiva.security.ArchivaServletAuthenticator [] - Authorization 
Denied [ip=10.2.4.1,permission=archiva-upload-repository,repo=arc7-releases] : 
no matching permissions
2018-11-04 12:14:19,359 [qtp367589601-760] INFO  
org.apache.archiva.security.ArchivaServletAuthenticator [] - Authorization 
Denied [ip=10.2.4.1,permission=archiva-upload-repository,repo=arc7-releases] : 
no matching permissions
2018-11-04 12:14:52,504 [qtp367589601-761] INFO  
org.apache.archiva.security.ArchivaServletAuthenticator [] - Authorization 
Denied [ip=10.2.4.1,permission=archiva-upload-repository,repo=arc7-releases] : 
no matching permissions
2018-11-04 12:14:55,567 [qtp367589601-760] INFO  
org.apache.archiva.security.ArchivaServletAuthenticator [] - Authorization 
Denied [ip=10.2.4.1,permission=archiva-upload-repository,repo=arc7-releases] : 
no matching permissions

Is there some way to verify that the username and password really is
(or isn't being sent)? Is there something I've set up incorrectly here?

I've had no problems to date deploying to Central, so I'm surprised
that I'm having problems here.

Just so we're clear: I'm deploying to /repository/example-releases, as
this is a repository that holds local releases, but I'm downloading
artifacts via /repository/releases as this is a repository group that
contains a proxy for Central.

-- 
Mark Raynsford | http://www.io7m.com



pgpF52OiH7a5s.pgp
Description: OpenPGP digital signature

Re: Specifying a deployment repository *only* by ID?

[Mark Raynsford]

On 2018-11-04T00:24:46 +0100
"Mirko Friedenhagen"  wrote:

> Hello Mark,
> 
> you may put the property in a profile of your settings.xml and just call „mvn 
> -P releases deploy“ given the profile is called releases.

Ah, yes, thank you! Didn't think of that.

-- 
Mark Raynsford | http://www.io7m.com



pgpWsls838Yvb.pgp
Description: OpenPGP digital signature

Specifying a deployment repository *only* by ID?

[Mark Raynsford]

Hello.

If I want to deploy to a different repository, I can use the
http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#altDeploymentRepository
property:

  $ mvn deploy 
-DaltDeploymentRepository=releases::default::https://packages.example.com/repository/releases

This is cumbersome, because I've already provided that URI and layout
in the ~/.m2/settings.xml file. I'd much rather do:

  $ mvn deploy -DaltDeploymentRepository=releases

Is there some way I can achieve this without putting anything in the
project's pom.xml?

-- 
Mark Raynsford | http://www.io7m.com



pgpAWK9xkbulN.pgp
Description: OpenPGP digital signature

Re: PSA: You can't push POMs with child.inherit.append.path attributes to Maven Central yet

[Mark Raynsford]

On 2018-11-01T23:55:43 +0100
Hervé BOUTEMY  wrote:

> Hi,
> 
> Ah, I forgot about Nexus staging checks...

I did too. :)

Actually didn't occur to me that Nexus would be doing a full evaluation
of the POM. I had sort of assumed that they'd just be parsing it and
looking for the presence of elements (using an XPath tool or something
similar).

> I also forgot to merge MNG-6059 [1], which changes the attributes names for 
> more flexibility on scm urls.
> 
> Looks like Maven 3.6.0 is not fully ready for this feature, will require 
> 3.6.1 
> to have a definitive solution: sorry for the mistakes, and eager to see more 
> user tests to detect such issues earlier in the future

It was slightly poor timing on my part. I was incredibly busy
throughout the entire 3.6.0 release and only had time to test one
plugin. I should be more available for 3.6.1.

-- 
Mark Raynsford | http://www.io7m.com



pgpBcBmaWTAm9.pgp
Description: OpenPGP digital signature

PSA: You can't push POMs with child.inherit.append.path attributes to Maven Central yet

[Mark Raynsford]

Hello!

Ran into a problem today whilst trying to push artifacts to Central
that happened to use the new MNG-5951 attributes.

See: http://blog.io7m.com/2018/11/01/you-cannot-put-that-there.xhtml
See: https://issues.apache.org/jira/browse/MNG-5951
See: https://issues.sonatype.org/browse/MVNCENTRAL-4085

Just letting everyone know that they'll run into this until Sonatype do
whatever updates are required.

--
Mark Raynsford | http://www.io7m.com



pgpcmKfhuQ2lX.pgp
Description: OpenPGP digital signature

Re: Copying dependencies (including reactor modules)

[Mark Raynsford]

I've put together a small plugin to address this issue:

https://github.com/io7m/halite

-- 
Mark Raynsford | http://www.io7m.com



pgpX3tqYJgKgO.pgp
Description: OpenPGP digital signature

Re: Copying dependencies (including reactor modules)

[Mark Raynsford]

OK, so I've apparently run into a dead end with this (which I find
pretty mind-blowing - this should be utterly trivial to accomplish).

The maven-dependency-plugin approach would work, except that it'll fail
due to trying to resolve reactor modules from the repository - even if
those modules are explicitly excluded via the various configuration
properties.

The maven-assembly-plugin approach would presumably work, except that
the plugin really requires various bits of POM configuration to work. I
attempted to patch the plugin to accept an output directory and a
descriptor file via properties, but it seems that the output directory
in particular is not so easy to override (it defaults to
${project.build.outputDirectory} and adding a property to override that
appears not to work).

Am I really going to have to write a whole new plugin just to get the
transitive closure of jar files that make up a given project?

-- 
Mark Raynsford | http://www.io7m.com



pgpghZ4GFiOXs.pgp
Description: OpenPGP digital signature

Re: Copying dependencies (including reactor modules)

[Mark Raynsford]

On 2018-10-21T22:27:28 +0200
mark  wrote:
> 
> I'd look into a packaging plugin like m-assembly-p with a "dir" format 
> and not a dependency gathering plugin because project artifacts are not 
> dependencies
> 
> https://maven.apache.org/plugins/maven-assembly-plugin/

'Ello.

Thanks for the suggestion. Unfortunately, the Assembly plugin seems to
be a no-go because it's not possible to specify a descriptor file on
the command line via a property. It has to be specified in a POM file
somewhere.

-- 
Mark Raynsford | http://www.io7m.com



pgpBYdXApyxhF.pgp
Description: OpenPGP digital signature

Re: Copying dependencies (including reactor modules)

[mark]

On 10/21/18 8:02 PM, Mark Raynsford wrote:

Hello.

I'd like to, for an arbitrary project (in other words, a project for
which I cannot edit the pom.xml files), copy the project's artifacts
and the project's dependency artifacts into a directory.

The maven-dependency-plugin copy-dependencies goal *nearly* does this,
but it'll fail as soon as it's asked to copy an artifact from the
reactor. For example, if I pick one of my projects at random and run:

$ cd git/com.github/io7m/jregions
$ mvn dependency:copy-dependencies -DincludeScope=runtime \
   -DoutputDirectory=/tmp/out/


I'd look into a packaging plugin like m-assembly-p with a "dir" format 
and not a dependency gathering plugin because project artifacts are not 
dependencies


https://maven.apache.org/plugins/maven-assembly-plugin/



--
Disclaimer;
This message is just a reflection of what I thought at the time of 
sending. The message may contain information that is not intended for 
you or that you don't understand.

Copying dependencies (including reactor modules)

[Mark Raynsford]

out.

I'm not opposed to writing a custom plugin to do this, but I'd prefer
to avoid that if possible.

-- 
Mark Raynsford | http://www.io7m.com



pgpwWYQEXKzs9.pgp
Description: OpenPGP digital signature

Re: [ANN] Apache Maven Install Plugin Version 3.0.0-M1 Released

[Mark Derricutt]

On 2 Oct 2018, at 4:32, Karl Heinz Marbaise wrote:

>  * [MINSTALL-118] - MavenProject with only attachments must have packaging 
> "pom"

Ik, this just hit me with the `karaf-assembly` packaging - and seemingly not 
setting a main file it seems.

Time to go lock that install plugin back down, and raise a ticket for Karaf.

Mark


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Not a chance to show conflicts in dependency tree?

[Mark Prins]

On 11-09-18 10:56, Nicolas Peifer wrote:

Hi,

I'm trying to show dependency conflicts using "mvn dependency:tree 
-Dverbose -Dincludes=commons-collections" as described in the 
documentation[1]. Unfortunately, this gives the following error:


"Verbose not supported since maven-dependency-plugin 3.0"

I tested it with Maven 3.3.9 and 3.5.4. Does anyone know a solution 
(apart from downgrading the plugin)?


verbose probably needs a value, also see the note: 
https://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html#verbose


Using a different or specific version is as easy as specifying that (eg. 
2.10):

"mvn org.apache.maven.plugins:maven-dependency-plugin:2.10:tree"

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

Integration testing of command line tools?

[Mark H. Wood]

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


signature.asc
Description: PGP signature

Re: Announcing OSSIndex plugins for Apache Maven: Scan your dependencies for known vulnerabilities

[Mark Derricutt]

On 26 Jul 2018, at 12:55, Brian Fox wrote:

> Find the Maven Plugin docs here:
> https://sonatype.github.io/ossindex-maven/maven-plugin/

This looks awesome! One nit pick tho - the XML plugin definition has a bad 
`` on the `` line.

Will be interesting to see how the results compare to the OWASP dependency 
checker.

Cheers
Mark


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: repository element was not specified in the POM inside distributionManagement element or in -DaltDeploymentRepository=id::layout::url parameter ->

[Mark Prins]

On 30-06-18 16:39, Karen Goh wrote:

Hi expert,

I used maven build and run goal : deploy to see how my spring framework project 
run but I got the above error.


There is this stackoverflow person which has similar problem as mine:

https://stackoverflow.com/questions/27153024/repository-element-was-not-specified-in-the-pom-inside-distributionmanagement-el/39439911


So, I read up the below:
https://maven.apache.org/pom.html#Distribution_Management

My question is since I am doing this on a stand alone basis and do not need to 
share the POM denpendencies, how do I get rid of this message?

you seem confused as to what "mvn deploy" actually does, it places an 
artifact in a repository, see: 
https://maven.apache.org/plugins/maven-deploy-plugin/

if that is not what you want then using mvn install should suffice.


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

Re: How to create a site/doxia plugin?

[Mark Raynsford]

On 2018-07-02T13:55:20 +0200
Peter Nabbefeld  wrote:

> Hello,
> 
> I haven't ever written a maven plugin. But, as I'm not satisfied with 
> the doxia plugins available, I'd like to write my own. So, how would I 
> have to write a doxia plugin?

Here's a plugin I wrote last year and still use to the present day:

  https://github.com/io7m/minisite/

It produces sites that look like this:

  https://www.io7m.com/software/junreachable/

The com.io7m.minisite.core module is independent of Maven, and the
com.io7m.minisite.maven_plugin module implements the actual plugin (by
taking data from the current Maven project and passing it to the core).

One thing you will need to do is unbind the existing Maven site plugin
from the lifecycle in any project that actually uses your plugin
(assuming that you bind your own site plugin to the "site" phase of the
build). Here's an example of how to do this:

  https://github.com/io7m/primogenitor/blob/develop/pom.xml#L908

-- 
Mark Raynsford | http://www.io7m.com



pgpM45UDaunEa.pgp
Description: OpenPGP digital signature

Re: Accessing licenses/license as POM properties?

[Mark Raynsford]

This seems to be a bug or something not quite right with the
bnd-maven-plugin. I've filed an issue:
https://github.com/bndtools/bnd/issues/2454

Plugins like the maven-jar-plugin (and evidently the
maven-bundle-plugin) appear to do the right thing, but the
bnd-maven-plugin seems not to. Strangely, other expressions (like
${project.description}) are expanded properly, but more complex
expressions aren't.

-- 
Mark Raynsford | http://www.io7m.com



pgpFjONIzyHYR.pgp
Description: OpenPGP digital signature

Re: Accessing licenses/license as POM properties?

[Mark Raynsford]

On 2018-05-19T14:35:25 +0200
Andreas Sewe <s...@st.informatik.tu-darmstadt.de> wrote:
>
> Maybe it depends on the Maven version (here: 3.5.2)? Try to clone the
> above Github repository, do a "mvn clean verify" and check what "unzip
> -p
> bundles/com.ctrlflow.aer.client.dto/target/com.ctrlflow.aer.client.dto-2.0.2-SNAPSHOT.jar
> META-INF/MANIFEST.MF" outputs for you.

I'm on 3.5.2:

Apache Maven 3.5.2 (NON-CANONICAL_2017-10-25T13:09:52+03:00_root; 
2017-10-25T11:09:52+01:00)
Maven home: /opt/maven
Java version: 10.0.1, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-10-openjdk
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.16.4-1-arch", arch: "amd64", family: "unix"

Your bundles have the correct manifest entries on my system:

  Bundle-License: https://www.eclipse.org/legal/epl-v10.html;description
 ="Eclipse Public License"

> Also, check what "mvn help:effective-pom" produces on your project vs.
> my project.

The effective POM for my project shows the unexpanded
${project.licenses[0]} text.

I feel like I might be running into a bug here... Going to attempt to
produce a repro case and submit an issue to the tracker.

-- 
Mark Raynsford | http://www.io7m.com



pgpEqdLJo6A61.pgp
Description: OpenPGP digital signature

Re: Accessing licenses/license as POM properties?

[Mark Raynsford]

On 2018-05-18T16:50:56 +0100
org.apache.maven.u...@io7m.com wrote:

> On 2018-05-18T17:01:52 +0200
> Andreas Sewe <s...@st.informatik.tu-darmstadt.de> wrote:
>
> > here's what I use as an  for the maven-bundle-plugin to
> > generate a Bundle-License line in my MANIFEST.MF:
> >   
> > > ${project.licenses[0].url};description="${project.licenses[0].name}"
> > > 
> > 
> > Works like a charm, as long as you have exactly one license.  
> 
> Looks good, thanks!
> 
> You're also using it for the exact same reason I'd be using it. :)

Spoke a bit too soon. I'm using the bnd-maven-plugin, but I don't think
that changes anything. I have:


  biz.aQute.bnd
  bnd-maven-plugin
  ${io7m.bnd-maven-plugin.version}
  

  


Unfortunately, the resulting bundle manifest is:

  Bundle-Description  Contract checking  
  Bundle-License  ${project.licenses[0].name}  

It seems that the array reference isn't being expanded. If I specify
${project.licenses}, I instead get:

  Bundle-License  [org.apache.maven.model.License@3eba57a7]

... which is clearly the result of calling toString() on something
that hasn't overridden it. Point is that the project.licenses property
is definitely present, it's just that I'm unable to access any of the
elements.

--
Mark Raynsford | http://www.io7m.com



pgp8naM0lCYGF.pgp
Description: OpenPGP digital signature

Accessing licenses/license as POM properties?

[Mark Raynsford]

Hello.

Is there a way to access the contents of the  element as POM
properties? I'd like to reference the URL of the first license element
in a plugin execution, but there doesn't appear to be a
${pom.license.url} or anything similar.

-- 
Mark Raynsford | http://www.io7m.com



pgppgAgtlZLqn.pgp
Description: OpenPGP digital signature

Re: site with file copy

[Mark Prins]

On 03-05-18 08:03, Philipp Kraus wrote:

Hello,

I’m using „mvn site“ command to build for my project the project website as 
HTML code,
During the site goal is running I need to copy some files into the target/site 
directory, how can I do this?
I need to copy some single files to the output director, but only on the site 
goal.


You could use the anrun plugin during the (pre-)site phase or stick the 
files into src/site/resources/ (with optional directories) so the site 
plugin picks them up.


-Mark

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

Re: How to hide internal build details from deployed pom.xml ?

[Mark Prins]

You can deploy artifacts using a custom, cleaned up pom that doesn't have a
build section

-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.

Re: Writing own plugin: The parameter annotation - does it work?

[Mark Raynsford]

On 2018-04-16T09:26:08 +0200
<g.h...@aurenz.de> wrote:
>
> Until then proper Maven Plug-in testing is not possible using JUnit - 
> especially not if it is in the IDE (Eclipse+M2E) and not during the Maven 
> build.
> 

I came to the same conclusion (at least with the plain testing
harness). I switched to takari-plugin-testing, which seems to have been
written at least in part as a reaction to the fact that nothing else
worked properly.

I have a very small project that can serve as an example of how to use
it:

  https://github.com/io7m/minisite

Take a look at the com.io7m.minisite.tests module. Primarily the
MinSiteMojoTest class, and the takari plugin execution in the tests
module pom. I can attest that it does work from inside the IDE, but you
may need to run an initial build to run the plugin's testProperties
goal (Eclipse & M2E may be able to do this for you these days, I'm not
sure).

-- 
Mark Raynsford | http://www.io7m.com



pgpjIFyPlMKZV.pgp
Description: OpenPGP digital signature

Re: maven release plugin

[Mark Derricutt]

On 1 Mar 2018, at 23:18, Matthew Broadhead wrote:

> Thanks Mark.  looks easy enough.  i may try a maven plugin first though as i 
> like the idea of maven controlling all the git pushes etc

I tend to NOT let maven do the git pushes, for the cases we're doing releases 
on a hot fix, or a support branch - where there is no release branch, and not 
necessarily any back merging, we've found it's easier to just let maven do the 
release on the current branch, and leave any branching/merging to an outside 
force.

On hot fix/support branches we just do a standard `mvn release:prepare 
release:perform`.

Mark


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: maven release plugin

[Mark Derricutt]

On 1 Mar 2018, at 2:56, Ben Tatham wrote:

> Sounds like you're using gitflow (master, develop, feature/* branches).  If
> so, we use the jgitflow-maven-plugin instead of maven-release-plugin, which
> handles these transitions and the inherent conflicts caused by the maven
> versioning.
>
> Unfortunately, the maintainer is no longer working on it (and says he's not
> even working in java anymore), but it still works well.

For my own git-flow based releases I have the following `git-mvnrelease` script 
I have on the path:

```shell
#!/bin/sh
if ! git diff-index --quiet HEAD --; then
echo "Git is dirty, clean up your mess!"
exit 1
fi

VERSION=`xml sel -N x="http://maven.apache.org/POM/4.0.0; -t -v 
"/x:project/x:version" pom.xml`
BASEVERSION=${VERSION%-SNAPSHOT}
ARTIFACTID=`xml sel -N x="http://maven.apache.org/POM/4.0.0; -t -v 
"/x:project/x:artifactId" pom.xml`

echo "Removing non-scm files..."
git clean -fdi

echo "Checking master branch for updates..."
git checkout master
git pull origin master

git flow release start $BASEVERSION && mvn release:prepare release:perform && 
git flow release finish -n $BASEVERSION && git push origin && git push origin 
--tags
```

This first checks my working directory is clean, just for safety, extracts the 
pom.xml version for use in branch/tag names.  Switches to my `master` branch 
and makes sure it's up to date, then does a batch release/push.

I don't think I've ever had any issues with maven versioning, unless the 
version number as part of the release/merge has changed to something unexpected.

YMMV
Mark


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: New JDK 9 module chasing tool (was: Getting a list of "to be modularized" dependencies in topological order?)

[Mark Raynsford]

On 2018-02-24T09:47:02 +1000
Paul King <paul.king.as...@gmail.com> wrote:

> Looks good.
> 
> A small bit of feedback.  I tried using it on a project (Groovy) with
> an "all" artifact that has no jar - just references other jars. Even
> when I specified "pom" it tried to look for the jar
> artifact. Despite the error stacktrace it continued and still seemed
> to produce the correct result. I don't know whether it's possible to
> reduce such noise.

Interesting. Could you file a bug?

There's a known problem in that if the root project you're analyzing
isn't in Maven Central, you will see a (harmless) error stacktrace as
the resolver tries to resolve it from Central. There's an easy fix for
this, I just haven't done it yet. 

-- 
Mark Raynsford | http://www.io7m.com



pgpK7CmSPCotl.pgp
Description: OpenPGP digital signature

New JDK 9 module chasing tool (was: Getting a list of "to be modularized" dependencies in topological order?)

[Mark Raynsford]

I've published a plugin here:

https://github.com/io7m/modulechaser

It produces a standalone XHTML report detailing the modularization
status of the transitive dependencies of any project you point it at.
The status table is presented in reverse-topological order; start
bugging maintainers at the top first and work downwards. :)

A report produced for:

  https://github.com/io7m/universe

... Looks like this:

  https://ataxia.io7m.com/2018/02/23/modules.xhtml

The project has had minimal testing, so there are likely to be issues.
It more or less delegates all of the actual work to the various Maven
dependency analysis code. Please let me know if it chokes on anything
you'd consider to be reasonable.

I'm still waiting to be able to push this to Central - I've run into
what appears to be a compatibility issue with the version of libgpg used
on Maven Central. I've filed a ticket with Sonatype and am just waiting
for them to upgrade their infrastructure. Until that happens, you'll
have to clone and "mvn install" this yourself. Sorry!

-- 
Mark Raynsford | http://www.io7m.com



pgpltlP_VR_C6.pgp
Description: OpenPGP digital signature

Re: Getting a list of "to be modularized" dependencies in topological order?

[Mark Raynsford]

On 2018-02-20T18:29:10 +0100
"Robert Scholte" <rfscho...@apache.org> wrote:

> When running Maven with Java9+ and running 'mvn dependency:resolve' on  
> your project, you'll see all the module names and if these modules are  
> automatic modules.
> It is a list, not a tree, but that's probably the closest you can get  
> right now.
> 

OK, thanks.

I think I need to write a plugin!

-- 
Mark Raynsford | http://www.io7m.com



pgpnV5jDHQGmK.pgp
Description: OpenPGP digital signature

Getting a list of "to be modularized" dependencies in topological order?

[Mark Raynsford]

Hello.

I'm trying to get to the (possibly masochistic) position of having all
of my projects (and therefore by extension, all dependencies of all of
my projects) fully modularized. That is, every artifact in the
dependency tree should have a module-info.class file in it.

Part of the reason for doing this is that jlink can't work with
automatic modules.

What I would like to be able to do is, for an arbitrary Maven project,
get a list of all of the (transitive) dependencies of the project that
are currently either automatic modules, or not modules at all. Then,
the list needs to be sorted topologically (so that dependencies on the
leaves of the tree are listed first). This lets me know the most
efficient order in which to update dependencies.

Is there a plugin available that can do this? I've not been able to
find anything.

-- 
Mark Raynsford | http://www.io7m.com


pgpHiLcTokQg2.pgp
Description: OpenPGP digital signature

Re: Inserting a single module-info after shading

[Mark Raynsford]

On 2018-02-03T13:43:18 +
Mark Raynsford <org.apache.maven.u...@io7m.com> wrote:
>
> It seems like I'd need to compile the module-info.java against a fake
> source directory (to stop the compiler complaining that the module is
> empty) and then insert the resulting module-info.class file into the
> shaded jar file afterwards. This seems fairly ugly though. Is there a
> better way?

Actually, ignore my question!

I have hacked together something using the truezip-maven-plugin and
a separate compiler plugin execution to compile a module-info.java
file as described.

Unfortunately, the resulting jar doesn't run when executed as a modular
jar, presumably due to internal classloading and reflection hacks on the
part of the Maven and Resolver APIs:

Exception in thread "main"
com.io7m.resolver.internal.org.eclipse.aether.resolution.ArtifactResolutionException:
Could not transfer artifact com.google.guava:guava:jar:null from/to
central (https://repo.maven.apache.org/maven2/):
java.lang.IllegalAccessException: class
com.io7m.resolver.internal.org.apache.http.impl.client.CloseableHttpResponseProxy
(in module com.io7m.resolver) cannot access class
com.sun.proxy.jdk.proxy1.$Proxy0 (in module jdk.proxy1) because module
jdk.proxy1 does not export com.sun.proxy.jdk.proxy1 to module
com.io7m.resolver

I suspect this approach simply cannot work.

-- 
Mark Raynsford | http://www.io7m.com



pgpg9qmV0DPdW.pgp
Description: OpenPGP digital signature

Inserting a single module-info after shading

[Mark Raynsford]

Hello!

I'm trying to embed and relocate some dependencies in a jar file with
the maven-shade-plugin. I have a trivial example here that does this:

  https://github.com/io7m/resolver-shade-example

The compilation produces a com.io7m.resolver-0.0.1-embedded.jar file
containing most of the dependencies except for a couple that I'd like
the user to provide (logback, slf4j). All of the included dependencies
are relocated to a package starting with "com.io7m.resolver.internal".

The problem: I now want to insert a module-info.java file that exports
only the com.io7m.resolver package (hiding the internal packages). I
can't put this file in the source tree itself because then the IDE will
complain endlessly that I've not "required" the external dependency
packages. This is correct, but the compiler obviously can't know that
by the time the jar is produced, all of those external packages will
actually be internal to the module (due to shading) and therefore
"requires" clauses are not... required.

What's the recommended way to deal with this? The intended final
module-info.java file is pretty trivial:

  module com.io7m.resolver {
requires org.slf4j;
exports com.io7m.resolver;
  }

It seems like I'd need to compile the module-info.java against a fake
source directory (to stop the compiler complaining that the module is
empty) and then insert the resulting module-info.class file into the
shaded jar file afterwards. This seems fairly ugly though. Is there a
better way?

-- 
Mark Raynsford | http://www.io7m.com



pgp60bNlL2pJb.pgp
Description: OpenPGP digital signature

Re: maven-war-plugin addClasspath useless, because it cannot add absolute paths

[Mark Prins]

2018-01-25 11:43 GMT+01:00 Basin Ilya :

> Hi List.
> As far as I know, Class-Path in MANIFEST.MF of a .war file is only useful
> when you need to add jars that are not in WEB-INF/lib and not provided by
> the container.
>

this really depends on the classloader of the container running the war and
the way it is configured.


> But can maven add paths that are absolute or relative? I tried this:
>
>
>nah
>nah
>1.0.0
>system
>/C:/1/ccc.jar
>true
>
>
>
>

Optional dependencies are not required at runtime and should not be
expected to be part of the war


> ...
> 
> org.apache.maven.plugins
> maven-war-plugin
> 
>   
> 
>   true
> 
>   
>
> The Class-Path was indeed added to MANIFEST.MF, but not the "ccc.jar".
>

makes sense to me.


-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.

Re: Avoid guava version conflict with hbase by shading

[Mark Prins]

On 21-01-18 08:21, Debraj Manna wrote:

Mark

One more query if some other dependency (let's say elasticsearch for
example) leaks its usage of guava then it may happen I end up again with
two incompatible versions of guava. What is the recommended way of handling
this?


You would need to find and settle on a guava version that is compatible 
between all the versions or get the other projects to release updated 
versions or make a version by yourself (of hbase or elasticsearch or...) 
that is compatible


-M


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

Re: Avoid guava version conflict with hbase by shading

[Mark Prins]

That's the idea, you cannot otherwise control which classes or which
version of guava are loaded by the classloader at runtime.

Op 20 jan. 2018 14:55 schreef "Debraj Manna" <subharaj.ma...@gmail.com>:

Ok. But then I think I have to change the import of guava in all the places
in my code?

On Sat, Jan 20, 2018 at 1:44 PM, Mark Prins <mc.pr...@gmail.com> wrote:

> You could try shading the new guava to a different package and use that in
> your code.
> E.g. jena-shaded-guava does that
>
> Op 20 jan. 2018 09:02 schreef "Debraj Manna" <subharaj.ma...@gmail.com>:
>
> > Mark
> >
> > hbase and hadoop is using the old guava. Is there a way I can use the
> > latest guava in my code and let hadoop and hbase use the old guava.
> >
> > On 20-Jan-2018 1:19 PM, "Mark Prins" <mc.pr...@gmail.com> wrote:
> >
> > > It seems that the guava versions are not API compatible, so shading is
> > > unlikely to help. You will need to downgrade to a compatible version
of
> > > guava or get the other projects to upgrade.
> > > -M
> > >
> > > Op 20 jan. 2018 07:51 schreef "Debraj Manna" <subharaj.ma...@gmail.com
> >:
> > >
> > > I have posted more details in stackoverflow
> > > <https://stackoverflow.com/questions/48140339/guava-23-5-
> > > conflict-with-hbase-testing-util-1-2>.
> > > I could not add all the details here because of size limitation.
> > >
> > > In a project I am using Guava 23.5 but some of the dependencies
> (hadoop &
> > > hbase) are using old Guava 14. This is causing an exception during
> > runtime
> > >
> > > As mentioned here <https://www.elastic.co/blog/
> to-shade-or-not-to-shade>
> > I
> > > tried to shade the Hbase dependency in a new module named shadedcdh.
> > > pom.xml
> > > looks like below
> > >
> > > ?xml version="1.0" encoding="UTF-8"?>
> > >
> > > http://maven.apache.org/POM/4.0.0;
> > >  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> > >  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> > > http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> > > 
> > > main
> > > com.vnera
> > > 0.001-SNAPSHOT
> > > 
> > > 4.0.0
> > >
> > > shaded-cdh
> > > jar
> > >
> > > 
> > > 
> > > org.apache.hbase
> > > hbase-testing-util
> > > 1.2.0-cdh5.7.0
> > > 
> > > 
> > > org.apache.hadoop
> > > hadoop-client
> > > ${hadoop.version}
> > > 
> > > 
> > > org.apache.hadoop
> > > hadoop-common
> > > ${hadoop.version}
> > > 
> > > 
> > > org.apache.hbase
> > > hbase-client
> > > 
> > > 1.2.0-cdh5.7.0
> > > 
> > > 
> > >
> > > 
> > > 
> > > 
> > > org.apache.maven.plugins
> > > maven-shade-plugin
> > > 2.4.1
> > > 
> > > 
> > > package
> > > 
> > > shade
> > > 
> > > 
> > > 
> > > 
> > > com.google.common pattern>
> > >
> > > shaded.com.google.common
> > > 
> > > 
> > > 
> > >  > > implementation="org.apache.maven.plugins.shade.resource.
> > > ManifestResourceTransformer"
> > > />
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >
> > > 
> > > 
> > > cloudera
> > > https://repository.cloudera.com/artifactory/
> > > cloudera-repos/
> > > 
> > > 
> > > 
> > > 
> > >
> > > I excluded hbase and hadoop dependency from my project and added
> > > shadedcdh as dependency. But this is still giving me the same
> > > exception. The dependency tree I have posted in the stackoverflow. I
> > > could not post here because of size limitation. Can someone let me
> > > know how can I avoid the conflict?
> > >
> >
>

Re: Avoid guava version conflict with hbase by shading

[Mark Prins]

You could try shading the new guava to a different package and use that in
your code.
E.g. jena-shaded-guava does that

Op 20 jan. 2018 09:02 schreef "Debraj Manna" <subharaj.ma...@gmail.com>:

> Mark
>
> hbase and hadoop is using the old guava. Is there a way I can use the
> latest guava in my code and let hadoop and hbase use the old guava.
>
> On 20-Jan-2018 1:19 PM, "Mark Prins" <mc.pr...@gmail.com> wrote:
>
> > It seems that the guava versions are not API compatible, so shading is
> > unlikely to help. You will need to downgrade to a compatible version of
> > guava or get the other projects to upgrade.
> > -M
> >
> > Op 20 jan. 2018 07:51 schreef "Debraj Manna" <subharaj.ma...@gmail.com>:
> >
> > I have posted more details in stackoverflow
> > <https://stackoverflow.com/questions/48140339/guava-23-5-
> > conflict-with-hbase-testing-util-1-2>.
> > I could not add all the details here because of size limitation.
> >
> > In a project I am using Guava 23.5 but some of the dependencies (hadoop &
> > hbase) are using old Guava 14. This is causing an exception during
> runtime
> >
> > As mentioned here <https://www.elastic.co/blog/to-shade-or-not-to-shade>
> I
> > tried to shade the Hbase dependency in a new module named shadedcdh.
> > pom.xml
> > looks like below
> >
> > ?xml version="1.0" encoding="UTF-8"?>
> >
> > http://maven.apache.org/POM/4.0.0;
> >  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> >  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> > http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> > 
> > main
> > com.vnera
> > 0.001-SNAPSHOT
> > 
> > 4.0.0
> >
> > shaded-cdh
> > jar
> >
> > 
> > 
> > org.apache.hbase
> > hbase-testing-util
> > 1.2.0-cdh5.7.0
> > 
> > 
> > org.apache.hadoop
> > hadoop-client
> > ${hadoop.version}
> > 
> > 
> > org.apache.hadoop
> > hadoop-common
> > ${hadoop.version}
> > 
> > 
> > org.apache.hbase
> > hbase-client
> > 
> > 1.2.0-cdh5.7.0
> > 
> > 
> >
> > 
> > 
> > 
> > org.apache.maven.plugins
> > maven-shade-plugin
> > 2.4.1
> > 
> > 
> > package
> > 
> > shade
> > 
> > 
> > 
> > 
> > com.google.common
> >
> > shaded.com.google.common
> > 
> > 
> > 
> >  > implementation="org.apache.maven.plugins.shade.resource.
> > ManifestResourceTransformer"
> > />
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >
> > 
> > 
> > cloudera
> > https://repository.cloudera.com/artifactory/
> > cloudera-repos/
> > 
> > 
> > 
> > 
> >
> > I excluded hbase and hadoop dependency from my project and added
> > shadedcdh as dependency. But this is still giving me the same
> > exception. The dependency tree I have posted in the stackoverflow. I
> > could not post here because of size limitation. Can someone let me
> > know how can I avoid the conflict?
> >
>

Re: Avoid guava version conflict with hbase by shading

[Mark Prins]

It seems that the guava versions are not API compatible, so shading is
unlikely to help. You will need to downgrade to a compatible version of
guava or get the other projects to upgrade.
-M

Op 20 jan. 2018 07:51 schreef "Debraj Manna" :

I have posted more details in stackoverflow
.
I could not add all the details here because of size limitation.

In a project I am using Guava 23.5 but some of the dependencies (hadoop &
hbase) are using old Guava 14. This is causing an exception during runtime

As mentioned here  I
tried to shade the Hbase dependency in a new module named shadedcdh. pom.xml
looks like below

?xml version="1.0" encoding="UTF-8"?>

http://maven.apache.org/POM/4.0.0;
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>

main
com.vnera
0.001-SNAPSHOT

4.0.0

shaded-cdh
jar



org.apache.hbase
hbase-testing-util
1.2.0-cdh5.7.0


org.apache.hadoop
hadoop-client
${hadoop.version}


org.apache.hadoop
hadoop-common
${hadoop.version}


org.apache.hbase
hbase-client

1.2.0-cdh5.7.0






org.apache.maven.plugins
maven-shade-plugin
2.4.1


package

shade




com.google.common

shaded.com.google.common














cloudera
https://repository.cloudera.com/artifactory/cloudera-repos/





I excluded hbase and hadoop dependency from my project and added
shadedcdh as dependency. But this is still giving me the same
exception. The dependency tree I have posted in the stackoverflow. I
could not post here because of size limitation. Can someone let me
know how can I avoid the conflict?

Re: Package failed

[Mark Prins]

2017-10-31 10:27 GMT+01:00 Oleg Lempert :

> Hi
> I running project with option / -Dmaven.test.skip=true
>

this hint is just for the compiler/surefire/failsafe plugin, but does not
mean that dependency resolution will not happen for this artifact because
in fact it will (and fail)
perhaps you could change the scope to optional instead
-m


> I have dependency : project *Auth *depend on *persistence*
>
> from auth pom.xml:
>
>   
> ${groupId}
> persistence
> ${project.version}
> 
> 
> ${groupId}
> persistence
> ${project.version}
> test-jar
> test
> 
> the package task failed  :
> [ERROR] Failed to execute goal on project auth: Could not resolve
> dependencies for project com.emc.cloud_dr:auth:jar:1.0-SNAPSHOT: Failure
> to
> find com.emc.cloud_dr:persistence:jar:tests:1.0-SNAPSHOT in
>
> but I suppose that /persistence-tests:jar /would not in use cause  *
> test*
> Please help me to understand why is it failed ?
>
>
>
>
> --
> 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
>
>


-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.

Re: Overriding the site plugin

[Mark Raynsford]

On 2017-10-15T17:02:19 +
Mark Raynsford <org.apache.maven.u...@io7m.com> wrote:
>
> Er, to clarify, I mean that I'd like to execute a new plugin entirely,
> not just a different version of the maven-site-plugin. I realized after
> I sent the message that it could be interpreted more than one way...

Managed to answer my own question. It turns out that I want to disable
an existing binding of a plugin to a lifecycle phase, and then run my
own plugin after that. As an example:

  

  
org.apache.maven.plugins
maven-site-plugin
3.6

  
default-site
none
  

  

  
org.apache.maven.plugins
maven-clean-plugin
3.0.0

  
default-site

  clean

site
  

  

  

This would disable the execution of the maven-site-plugin by setting
phase to "none", and then run the maven-clean-plugin instead. I just
use the maven-clean-plugin as an example, it'd obviously work with any
other plugin.

-- 
Mark Raynsford | http://www.io7m.com



pgpEfyTTmDVmR.pgp
Description: OpenPGP digital signature

Re: Overriding the site plugin

[Mark Raynsford]

On 2017-10-15T16:54:15 +
Mark Raynsford <org.apache.maven.u...@io7m.com> wrote:
>
> Basically, I'd like to type "mvn site" and get my own plugin instead of
> the existing maven-site-plugin.

Er, to clarify, I mean that I'd like to execute a new plugin entirely,
not just a different version of the maven-site-plugin. I realized after
I sent the message that it could be interpreted more than one way...

-- 
Mark Raynsford | http://www.io7m.com



pgpVFAyUyGkfb.pgp
Description: OpenPGP digital signature

Overriding the site plugin

[Mark Raynsford]

Hello.

When one types "mvn site", it seems that the site plugin that's included
with the local Maven install is executed (which then runs all of the
reports and so on).

Is it possible to override this plugin (in other words, replace it with
something else) on a per-project basis?

Basically, I'd like to type "mvn site" and get my own plugin instead of
the existing maven-site-plugin.

-- 
Mark Raynsford | http://www.io7m.com



pgpG1XBXAEXa4.pgp
Description: OpenPGP digital signature

Re: failsafe: proper shutdown on failure

[Mark Prins]

On 02-10-17 12:12, Veit Guna wrote:

Hi.

I'm using maven failsafe 2.20.1 to setup my test environment (redis, via 
fabric8/docker-maven-plugin) before ITs using pre-integration-test and shut it down on 
post-integration-test. It works just fine when tests are succeeding or failing 
"normally". But when failing "hard" like this:

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-failsafe-plugin:2.18.1:integration-test 
(default) on project crs-it: Execution default of goal 
org.apache.maven.plugins:maven-failsafe-plugin:2.18.1:integration-test failed: 
There was an error in the forked process
[ERROR] org.testng.TestNGException:

Due to some class not found exceptions,

or just executing:

mvn clean verify -Dit.test=nonExistingTest

It seems that post-integration-test phase isn't executed properly then, leaving 
my docker container still running.


I think the build is halted after the failure, so no further phases are 
processed. Using "-fae" (fail-at-end) may help, but I may be wrong.


Mark

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

Re: When time do we need to delete .m2/repository

[Mark Derricutt]

On 15 Sep 2017, at 20:29, Baptiste Mathus wrote:

> So, yes, using dependency:purge-local-repository can help that use
> case/issue, but again IMO it's not worth it: just wipe out everything and
> redownload.

My release alias I use sets -Dmaven.repo.local=/tmp/maven-release-repository 
for every release, this way I ensure my dependencies/transitives/plugins or 
anything are all fresh, accessible, and not polluted by local builds.

/tmp gets blown away anytime I restart - sure it makes release builds a little 
bit slower, but knowing everything required to build is still available, is a 
slight comfort ( esp. from some bad experiences of a corrupt local nexus server 
and having try and source some older artefact builds ).



---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Auditing version ranges

[Mark Raynsford]

On 2017-08-15T13:23:17 +
Thomas Broyer <t.bro...@gmail.com> wrote:

> 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

Thanks, didn't see that one. I'll give it a shot.

-- 
Mark Raynsford | http://www.io7m.com


pgpx3h6jMru7m.pgp
Description: OpenPGP digital signature

Auditing version ranges

[Mark Raynsford]

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


pgpMS8Kfc0KU6.pgp
Description: OpenPGP digital signature

Re: Maven not getting latest artefact after deploy:deploy-file

[Mark Prins]

On 03-08-17 17:57, Mehul Sanghvi wrote:

I will do my best to illustrate with as simple an example as I can.
Hopefully I don't miss anything by simplifying it.


Project-A:
com.my.dept
dept-artefact
11.3.0.1.0-SNAPSHOT

The above is uploaded to Nexus using deploy:deploy-file


Project-B depends on Project-A artefact and so has the following in its POM
file.


   
 com.my.dept
 dept-artefact
 11.3.0.1.0-SNAPSHOT
   




Nexus is setup to keep the latest 5 versions of the SNAPSHOTS.
So I see the following before the upload:

com/my/dept/dept-artefact/11.3.0.1.0-SNAPSHOT/dept-artefact-11.3.0.1.0--5-all.zip
com/my/dept/dept-artefact/11.3.0.1.0-SNAPSHOT/dept-artefact-11.3.0.1.0--4-all.zip
com/my/dept/dept-artefact/11.3.0.1.0-SNAPSHOT/dept-artefact-11.3.0.1.0--3-all.zip
com/my/dept/dept-artefact/11.3.0.1.0-SNAPSHOT/dept-artefact-11.3.0.1.0--2-all.zip
com/my/dept/dept-artefact/11.3.0.1.0-SNAPSHOT/dept-artefact-11.3.0.1.0--1-all.zip

I have not shown the POM file and the MD5 and SHA1 files above, but they
also exist with similar names.

Now when I run Project-A, and it deploys a new build of the artefact to
Nexus, then from the above list of files the -1-all.zip file gets deleted,
  and a -6-all.zip file is added, which is the latest version.

When a build of Project-B is triggered, it will pick up the -5-all.zip
rather than the -6-all.zip.  I have to manually update
the metadata in order for Project-B to pick up the latest snapshot.


this reads like a bug in Nexus, or maybe it can't keep up.
there is no way to control nexus from mvn deploy unless you use a nexus 
specific plugin or extension.
You may want to look into using an up-2-date Nexus, current is 
2.14.5-02 and upgrading is only 10mins work





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

Re: Excessive "checking for updates" on Travis CI

[Mark Raynsford]

Apologies if that came off as rude, it wasn't intended to be. Upon
re-reading it, I think it came off as a bit harsh.

M


pgppS5LvgbIs9.pgp
Description: OpenPGP digital signature

Re: Excessive "checking for updates" on Travis CI

[Mark Raynsford]

On 2017-06-29T19:38:40 +0200
Karl Heinz Marbaise  wrote:

> HI,
> 
> first you are using version ranges...that's the reason for that...
> 
> Simple recommendation I can give is:  Don't use version ranges...
> 
> 

Hello.

I maintain ~70 projects with complex interdependencies (this graph
shows a subset of them):

  https://raw.githubusercontent.com/io7m/universe/master/io7m.png

If I don't use version ranges, then when I update one dependency, I get
to update a ton of other packages too. I make frequent releases. Without
version ranges, my day would quickly be consumed by
version-number-incrementing busy work across a large number of packages
instead of getting actual development work done.

I make strong guarantees about API compatibility with my own packages,
including using japicmp to analyze the bytecode to ensure that I follow
semantic versioning correctly. Therefore, I use version ranges, and
have been for years.

Is there something else I could be doing?

M


pgpOYDjUHgnE8.pgp
Description: OpenPGP digital signature

Excessive "checking for updates" on Travis CI

[Mark Raynsford]

Hello.

I use the free Travis CI service to build my various projects on each
commit. I have a project that has a rather large number of modules (~90)
and upon building each module, I see lots of this in the log:

[INFO] artifact com.io7m.junreachable:com.io7m.junreachable.core: checking for 
updates from sonatype
[INFO] artifact com.io7m.junreachable:com.io7m.junreachable.core: checking for 
updates from sonatype-apache
[INFO] artifact com.io7m.jequality:com.io7m.jequality.core: checking for 
updates from sonatype
[INFO] artifact com.io7m.jequality:com.io7m.jequality.core: checking for 
updates from sonatype-apache
[INFO] artifact com.io7m.jnull:com.io7m.jnull.core: checking for updates from 
sonatype
[INFO] artifact com.io7m.jnull:com.io7m.jnull.core: checking for updates from 
sonatype-apache
[INFO] artifact com.io7m.junreachable:com.io7m.junreachable.core: checking for 
updates from sonatype
[INFO] artifact com.io7m.junreachable:com.io7m.junreachable.core: checking for 
updates from sonatype-apache
[INFO] artifact com.io7m.jtensors:com.io7m.jtensors.core: checking for updates 
from sonatype
[INFO] artifact com.io7m.jtensors:com.io7m.jtensors.core: checking for updates 
from sonatype-apache
[INFO] artifact it.unimi.dsi:fastutil: checking for updates from sonatype
[INFO] artifact it.unimi.dsi:fastutil: checking for updates from sonatype-apache
[INFO] artifact com.io7m.jnull:com.io7m.jnull.core: checking for updates from 
sonatype
[INFO] artifact com.io7m.jnull:com.io7m.jnull.core: checking for updates from 
sonatype-apache
[INFO] artifact com.io7m.mutable.numbers:com.io7m.mutable.numbers.core: 
checking for updates from sonatype
[INFO] artifact com.io7m.mutable.numbers:com.io7m.mutable.numbers.core: 
checking for updates from sonatype-apache
[INFO] artifact com.io7m.jtensors:com.io7m.jtensors.storage.bytebuffered: 
checking for updates from sonatype
[INFO] artifact com.io7m.jtensors:com.io7m.jtensors.storage.bytebuffered: 
checking for updates from sonatype-apache
[INFO] artifact com.io7m.jnull:com.io7m.jnull.core: checking for updates from 
sonatype
[INFO] artifact com.io7m.jnull:com.io7m.jnull.core: checking for updates from 
sonatype-apache
[INFO] artifact com.io7m.mutable.numbers:com.io7m.mutable.numbers.core: 
checking for updates from sonatype
[INFO] artifact com.io7m.mutable.numbers:com.io7m.mutable.numbers.core: 
checking for updates from sonatype-apache
[INFO] artifact com.io7m.jnull:com.io7m.jnull.core: checking for updates from 
sonatype
[INFO] artifact com.io7m.jnull:com.io7m.jnull.core: checking for updates from 
sonatype-apache
[INFO] artifact com.io7m.junreachable:com.io7m.junreachable.core: checking for 
updates from sonatype
[INFO] artifact com.io7m.junreachable:com.io7m.junreachable.core: checking for 
updates from sonatype-apache
[INFO] artifact com.io7m.ieee754b16:com.io7m.ieee754b16.core: checking for 
updates from sonatype
[INFO] artifact com.io7m.ieee754b16:com.io7m.ieee754b16.core: checking
for updates from sonatype-apache

Note that not only are these artifacts being checked redundantly (because
an artifact may be checked at least once per module), they're also being
checked multiple times in the same plugin execution!

You can see an example of a build log here:

  https://api.travis-ci.org/jobs/248453940/log.txt

I'm actually starting to hit the 4mb log file size limit on Travis due
to the sheer amount of output produced.

The project's source code, for the curious, is here:

  https://github.com/io7m/r2

Is there some way to get these redundant checks to stop? Failing that,
is there a way to get Maven to shut up about it?

M


pgpI6ScSuvePM.pgp
Description: OpenPGP digital signature

Questions about

[Mark H. Wood]

I just got bitten by "activeByDefault doesn't mean what everyone
thinks it means."  OK, that's the way it is.  But I have some
questions:

o  Real-world use case for the current behavior?

o  Is there some reason why the meaning of
 
   !NAME
 
   is not documented in the POM reference?

o  Where *is* it documented?  Lots of people seem to know about it.

-- 
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


signature.asc
Description: PGP signature

Maven 3.5.0 and the versions plugin

[Mark Eggers]

Folks,

I'm working on upgrading an environment to maven 3.5.0. With
prerequisites in pom.xml, I get the expected message:

   [WARNING] The project org.mdeggers:CSEquity:war:1.0-SNAPSHOT
   uses prerequisites which is only intended for maven-plugin projects
   but not for non maven-plugin projects. For such purposes you should
   use the maven-enforcer-plugin. See
   https://maven.apache.org/enforcer/enforcer-
   rules/requireMavenVersion.html

I then remove the prerequisites tag and replace it with the
appropriately configured enforcer plugin. The project builds cleanly.

However, one of the things that we do in Jenkins is run a series of mvn
versions:display--updates (plugins, dependencies) and mail the
results to developers.

When I run mvn versions:display-plugin-updates, I get the expected
output as well as the following:

   [WARNING] Project does not define minimum Maven version, default is:
   2.0

   [ERROR] Project does not define required minimum version of Maven.
   [ERROR] Update the pom.xml to contain
   [ERROR] 
   [ERROR]   3.0
   [ERROR] 

Is there a way to resolve this? Should I file an issue with the maven
versions plugin?

. . . just my two cents
/mde/



signature.asc
Description: OpenPGP digital signature