Working around "Can't compile test sources when main sources are missing a module descriptor"
(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
Re: Splitting a dependency tree with the assembly plugin
> 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
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
Hello! I'm running into a problem when trying to produce an application distribution. This is the pom.xml file: https://github.com/io7m/eigion/blob/develop/com.io7m.eigion.distribution.example/pom.xml The module essentially represents two isolated applications that have been combined into one Maven module for the purposes of producing a distribution zip file. The first application is represented by the com.io7m.eigion.launcher.main dependency, and the other is represented by the com.io7m.eigion.gui dependency. I have the following assembly descriptor: https://github.com/io7m/eigion/blob/develop/com.io7m.eigion.distribution.example/src/main/assembly/distribution.xml What I'm trying to do is: * Put com.io7m.eigion.gui and all dependencies of com.io7m.eigion.gui into "workbench/modules" in the assembly. * Put all dependencies of com.io7m.eigion.launcher.main into "launcher/modules" in the assembly. This is _mostly_ working, except that it seems that at least one transitive dependency of com.io7m.eigion.launcher.main is being left out. Specifically, for example, it seems that com.io7m.junreachable.core is being left out of "launcher/modules". I _think_ what's happening is that because com.io7m.junreachable.core is also transitive dependency of com.io7m.eigion.gui, it's being excluded. Is there perhaps a more intelligent way to achieve what I'm trying to achieve? -- Mark Raynsford | https://www.io7m.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Book recommendation
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: Scratching my head over repositories ...
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
More module-related Javadoc issues
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
Finding out what the versions plugin did
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
Jar plugin: Per-entry compression settings?
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: Copying dependencies (including reactor modules)
'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?
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?
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?
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?
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?
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?
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
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
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)
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)
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)
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)
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: How to create a site/doxia plugin?
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?
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?
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?
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?
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: Writing own plugin: The parameter annotation - does it work?
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: New JDK 9 module chasing tool (was: Getting a list of "to be modularized" dependencies in topological order?)
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?)
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?
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?
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
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
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: Overriding the site plugin
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
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
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: Auditing version ranges
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
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
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
On 2017-06-29T19:38:40 +0200 Karl Heinz Marbaisewrote: > 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
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