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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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