Allow removing elements such as dependencies via pomElement list

[rpatrick00]

I have a situation where I am using the Maven assembly plugin to build a zip installer for my software. At a certain point in my continuous delivery pipeline, I am only promoting the zip installer artifact and its associated POM. All of the artifacts used to construct the zip file are declared as dependencies in the original POM but once the ZIP file is published, it no longer technically depends on these artifacts since it includes them inside the zip file. My downstream jobs are using the maven-dependency-plugin's unpack goal to unzip the zip file for my acceptance tests. Unfortunately, these downstream jobs that are pulling the zip file from the repo are also unnecessarily downloading all of the individual artifacts into the local Maven repo due to the dependencies listed in the zip file's POM.

As such, I would like to be able to do the following and remove the dependencies section altogether:

    <configuration>
      <updatePomFile>true</updatePomFile>
      <pomElements>
        <dependencies>flatten</dependencies>
        <repositories>flatten</repositories>
      </pomElements>
    </configuration>

I tried this and, as I sort of expected, it does not remove the dependencies section from the flattened POM. Would it be possible to add this feature? I understand that this is a somewhat unusual request but it would really help me out.

[hohwille]

Sorry, to say so but what you are demanding is a hack. Simply use maven-dependency-plugin and do not miss-use project dependencies to solve your problem.

[hohwille]

I close this as wontfix. Feel free to give valid arguments if you want to convince me for a reopen...

[hohwille]

To clarify: dependencies is supported in pomElements. However flatten means that the value is taken from the minimum pom. There is no ElementHandling like remove.

[rpatrick00]

Do whatever you like, but I don't see how what I am requesting is any more of a hack than this entire flatten plugin itself. I don't see how I am "misusing project dependencies" by declaring that the project that uses the Maven assembly plugin to assemble a zip file depends on artifacts that get put inside the zip file. The build portion of the project does depend on these artifacts that the Maven assembly descriptor is pulling into the zip via <dependencySet> elements. I was simply hoping to use the flatten plugin to create the "runtime POM" that gets published to Artifactory--just like I use it for every other type of artifact--and strip out these build-time dependencies.

Could I hack around this limitation? Sure I can. For that matter, I can fork your code and make it do what I want but that wasn't the point of my request. No worries, I certainly know how to solve the problem myself...

[hohwille]

Do whatever you like, but I don't see how what I am requesting is any more of a hack than this entire flatten plugin itself.

I did not want to upset you. And somehow you are right. This plugin was only invented because of a lack in maven itself. The idea is to show how maven should actually work in the future and this is (partially) considered for the next major release of maven (if and when ever this may show up). The main story and demand is that there is the configuration of a maven project at build time that should be separated from what is actually deployed to a maven repository for others to consume the artefact. Hence, dynamic aspects as variables and build-time driven profiles should be resolved. Also, test scope dependencies are internal information not relevant for artefact consumers. Further internal aspects for the build such as build and reporting sections are not relevant for the consumption of artefacts. However, some projects would consider the distribution management and scm as internal and others will require this to be available in the flattened POM in the repository. OSSRH also requires some of these sections that others want to strip. Additionally, people also want to deploy BOMs and these must contain dependencyManagement and other informations including test scoped dependencies as they are more or less a re-useable development artefact. All these demands more or less lead the flatten-maven-plugin to become a configurable Swiss army knife even though this was never intended. The dependency section of a POM is declaring the dependencies required when using the artefact. That is one of the major contracts of maven itself. If you want to build a ZIP file containing other artefacts there is no need to use the dependency section. You can also use dependency plugin and list the artifacts to include in the ZIP as configuration of that plugin to get the same result. Removing the dependencies from the POM is therefore not an intended use-case of flatten-maven-plugin.

Feel free to discuss on the mailing list (mojohaus at google groups) and suggest this. If others agree, I wont be in the way.

[rpatrick00]

I am not upset but if you don't want to upset people, I would suggest keeping your "value judgments" of other people's ideas, coding styles, etc. to yourself and not sharing them on such a public forum.

If I understand you correctly, you are suggesting that I change my zip file project from using dependencies and the assembly plugin's <dependencySet> mechanism to use the dependency plugin's copy goal to manually copy all of the files to a temporary location myself and then use the assembly plugin's <FileSet> to include them in the assembly.

If I understand correctly, then I believe that doing this I would lose all of the benefits of my top-level POM's <dependencyManagement> section for controlling the versions that I use in all phases of the project--including what gets put into the zip installer. If that is the case, that makes this a non-starter. This is a large commercial software project that I am developing for my employer's customers with a large number of moving parts so trying to keep the dependency plugin's copy goal in sync with the <dependencyManagement> section is a non-starter. If I missed something, please explain.

In my opinion, your interpretation of the Maven dependencies is incomplete. Software projects depend on things in various phases of their lifecycle. Sometimes, you only need something to compile the code, other times, you only need it for tests, and yet other times you need them only at runtime. Maven's compile-scoped dependencies are assumed to be needed at runtime too. In my case, the dependencies are really compile-time only, somewhat like the "provided" scope, though I doubt that switching the dependencies' scopes to provided will do what I want.

[hohwille]

Thanks for the explanation. I see your use-case more clear now.

I doubt that switching the dependencies' scopes to provided will do what I want.

Why not? You could also consider setting them optional. But I have to agree that this also ends up as a "hack" so I will reconsider your initial demand. Maybe we will really add an ElementHandling called remove that would solve this easily.

[jochenw]

I suggest that @rpatrick00 could use a different mechanism for generating his POM. XSLT comes to mind, although I would personally prefer something different, like a Groovy script. If so, one could extend the flatten plugin to use that POM, rather than a version it generates itself.

[rpatrick00]

Why would I do that? For my use case, I simply need a simple POM with a the basic information (GAV and packaging type). The only things that needs to be "filled in" are the GroupId and version (which it inherits from the parent POM). If there is a mechanism to give the flatten plugin an alternate POM for processing, I can just create a static POM to feed to the flatten plugin...no need to pull in more complexity to generate anything..

[rpatrick00]

> I doubt that switching the dependencies' scopes to provided will do what I want.
Why not? You could also consider setting them optional.

I was simply guessing that the assembly plugin might ignore the dependencies if the scope is set to provided (or optional).

[hohwille]

I reopen as this is actually so easy to fix...

[hohwille]

I did not add ITs or extra documentation for this special feature but with the next release you can do this for your intention:

<pomElements>
  <dependencies>remove</dependencies>
</pomElements>

[rpatrick00]

Thanks!

[hohwille]

Release is prepared. You are welcome to test and vote: https://groups.google.com/forum/#!topic/mojohaus-dev/kHVNoyGvK5o