Re: [DISCUSS] Maven Dependency Plugin
Like a couple of other folks 90% of my usage is dependency:analyze and dependency:tree. Other goals I barely notice. On Thu, Mar 21, 2024 at 12:06 PM Tamás Cservenák wrote: > > Howdy, > > I'd would be interested in how users and devs are using > maven-dependency-plugin: > https://maven.apache.org/plugins/maven-dependency-plugin/ > > I collected some basic questions I'd like to have answered (but feel free > to add more info!): > - which goals are "must have" for you > - which goals are "I never touched" for you (or, "I really don't need" or > "never used" or "shrug") > - what is missing? > > Thanks > T -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Surefire plain text reports
Please don't. I totally use that and expect them to be there without any extra markup or systems. Plain text, FTW. On Fri, Nov 18, 2022 at 8:23 AM Slawomir Jaranowski wrote: > > Hi, > > By default Surefire generate plain text reports which is stored in > target/surefire-reports/yourTestName.txt > > It can be disabled by using the "useFile" parameter. > > Question - Does somebody use such reports? > I'm thinking about removing those at all and saving some CO2 :-) > > What do you think? > > -- > Sławomir Jaranowski -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Running tests from a test jar
I'm attempting to run the tests in a test jar rather than from source, for reasons. That is, I set up the pom.xml like so to run the tests that are bundled in com.google.cloud:google-cloud-storage:test-jar:tests org.apache.maven.plugins maven-surefire-plugin 3.0.0-M5 com.google.cloud:google-cloud-storage:test-jar:tests:* The problem I'm running into is that a lot, though not all, dependencies seem to be non-transitive. I have to manually add the various dependencies to the dependencies section. Is there any way around this? There's a more complete pom.xml here: https://github.com/GoogleCloudPlatform/cloud-opensource-java/pull/2003/files -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Dependency Analyzer Plugin 1.11.3 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Dependency Analyzer Plugin, version 1.11.3 This plugin analyzes the dependencies of a project for undeclared and unused artifacts. https://maven.apache.org/shared/maven-dependency-analyzer/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-dependency-analyzer 1.11.3 You can download the appropriate sources etc. from the download page: https://maven.apache.org/shared/maven-dependency-analyzer/download.cgi Release Notes - Maven Shared Components - Version maven-dependency-analyzer-1.11.3 Improvement [MSHARED-949] - dependency:analyze should recommend narrower scope where possible Task [MSHARED-948] - Update link to Jira Dependency upgrade [MSHARED-932] - Remove JMock dependency Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Dependency Analyzer Plugin 1.11.2 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Dependency Analyzer Plugin, version 1.11.2 This plugin analyzes the dependencies of a project for undeclared and unused artifacts. https://maven.apache.org/shared/maven-dependency-analyzer/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-dependency-analyzer 1.11.2 You can download the appropriate sources etc. from the download page: https://maven.apache.org/shared/maven-dependency-analyzer/download.cgi Release Notes - Maven Dependency Analyzer Plugin - Version 1.11.2 Bug [MSHARED-792] - Maven Dependency Analyzer ignores Java 8 type annotations on local variables Improvement [MSHARED-879] - make build Reproducible Dependency upgrade [MSHARED-810] - Support Java 12 [MSHARED-868] - Upgrade plexus-component-metadata to 2.1.0 [MSHARED-870] - Upgrade asm to 8.0.1 Enjoy, -The Apache Maven team - 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
The XML handling code in this work is running into some common design
flaws in the JDK XML classes, in particular in the Factories class.
First, you probably shouldn't use SAXParserFactory or SAXParser at
all. They were added to the JDK to support SAX 1.0, and haven't been
needed for since SAX 2 was released (about 20 years ago). Modern code
should use XMLReader and XMLReaderFactory instead.
If you do stick with SAXParser, it's important to call
setNamespaceAware(true), since it's false by default, a legacy of its
use with the non-namespace supporting SAX 1.
On Mon, Jun 22, 2020 at 5:18 PM Robert Scholte wrote:
>
> Hi,
>
> One of my long standing wishes has made it to the master branch of Maven: the
> support for build/consumer pom.
> With this we can finally start improving the pom without breaking the Maven
> eco system.
>
> Up until now the pom.xml has been distributed (installed/deployed) as is to
> both local and remote repositories.
> The good thing is that is it fast and there is no magic.
> However, it sometimes implies adding redundant information and it also blocks
> any chance of improvement for Maven
>
> The challenge is to make it possible to have an locally an improved "build"
> pom while distributing a model 4.0.0 compatible "consumer" pom.
>
> The whole architecture of Maven was built upon an immutable pom.xml, so it
> took a while to split this, but I managed to solve this.
> And to confirm that it works, some transformations have been added for the
> next Maven release
> The local pom it still model 4.0.0 compatible, but some redundant elements
> are not required anymore.
> - in case the is located at its relativePath (default: ../pom.xml),
> the version can be removed. groupId and artifactId are still required to
> ensure it is being matched with the right parent.
>
> - dependencies that are part of the reactor don't need a version anymore
> These are implemented steps to get from the file model to the raw model,
> where the required versions are added.
>
> When distributing the pom, the previous transformations are done, but also:
> - cifriendly placeholders in versions (${sha1}, ${revision}, ${changelist})
> will be resolved.
> - from will be removed
> - from will be removed
> These cleanups are context aware, if they appear in some configuration, they
> won't be touched.
> One of our integration-tests[1] demonstrates how new poms in a multimodule
> project might look like.
>
> Even though the latter steps look quite small (removing elements with
> relative paths), it should give us enough feedback about the whole process.
>
> The status is that it is ready to be embedded in supporting tools like IDEs.
> We should give them time to work on this and share feedback.
> It might require some adjustments in Maven to improve user experience.
>
> In the meantime we need to work on plugins that will have impact by these
> changes.
> Most significant is are signing maven plugins such as the maven-gpg-plugin,
> which needs to work with the distributed pom instead of the local pom.
> Also all packaging plugin that can include the pom.xml and pom.properties in
> their archive should switch to the distributed pom.
> The maven-shade-plugin was marked as well, but at first glance this looks
> fine.
> In the end all our plugins must be verified, just to be sure.
> So there's enough to work on.
>
> In general I avoid giving timelines about how fast a new release will be
> available.
> Due to the overhead, the small amount of available time of the few volunteers
> working on Maven, I prefer to have a worth set of changes.
> In this case the impact of the changes can be huge, and I want to have enough
> faith that we won't introduce irreversible mistakes.
> Don't expect a new official release in the 3 next months, however we might
> have alpha or beta releases.
>
> There is a wiki page that explains this topic in more detail[2]
> It is still a draft, as there are still parts where we need to reach
> consensus.
> This page is intended as a base for discussions by Maven developers, users
> and related projects, such as IDEs, Repository Managers, CI Servers, etc.
>
> Looking forward for any feedback,
>
> Robert Scholte
> Apache Maven project
>
> [1]
> https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6656-buildconsumer
> [2] https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Programmatic access to enforcer plugin
There exists a very large group of open source libraries, some my organization owns and a few we don't. It is not currently possible to find a convergent set of versions for these libraries, and it's hard to collect a set of versions that doesn't hit no such method errors and other serious incompatibilities. I want to generate a list of the version conflicts across all these libraries, and then create an ordered list of the dependency upgrades that need to be patched in and shipped so we can publish a BOM of versions that at least work together, even if they're not necessarily all the latest version. Then I want to keep publish newer versions of the BOM as new versions of the dependencies ship. We can't afford to simply fail the build of all the components on the first convergence error. We tried that and it became quickly obvious that none of them would or could build if we did. This is going to be a multistep fix. I'm considering whether it may be necessary to drop deeper down the stack and write my own code to check for dependency convergence. I actually have some existing Aether code that queries the repos for a complete dependency graph. Unfortunately parts of it depend on M2E which I don't want to use for this project. So I would need to rewrite those lines to use org.apache.maven instead. If anyone has sample code that queries repos for dependencies without M2E, that would also be helpful. On Thu, Jul 19, 2018 at 4:08 PM, Karl Heinz Marbaise wrote: > Hi, > > can explain more in detail what you like to achieve? Best would be based on > an example... > > Apart from that maven-enforcer is intended to check for rules which if > someone violates the defined rules...not really intended to make a report > ?... > > > Kind regards > Karl Heinz Marbaise > > > On 19/07/18 20:13, Elliotte Rusty Harold wrote: >> >> Short of forking the project, is any sort of programmatic API for the >> Maven enforcer plugin available? E.g. I'd like to point a rule at a >> dependency coordinates and get a report back in a somewhat more >> structured form than System.out.println. >> >> Has anyone done something like this? Are there any docs better than >> reading the source code? Thanks. >> > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Programmatic access to enforcer plugin
Short of forking the project, is any sort of programmatic API for the Maven enforcer plugin available? E.g. I'd like to point a rule at a dependency coordinates and get a report back in a somewhat more structured form than System.out.println. Has anyone done something like this? Are there any docs better than reading the source code? Thanks. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Reading dependencyManagement element with resolver
Using the Maven resolver, is there an API hiding somewhere to read the dependencyManagement element from a pom and return the list of dependencies being managed? That is, something short of just parsing the XML with XOM or equivalent. I figure something inside Maven Resolver must be doing that, but I can't find it. P.S. The Maven resolver git repo at https://git-wip-us.apache.org/repos/asf/maven-resolver.git/ seems to have gone 404. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
