I went with a defensive action only and set the PR to ready for review which is more consistent with the current codebase (https://github.com/apache/maven-resolver-ant-tasks/pull/139). I'm am open to implementing support for only a nested pom in the deploy without requiring a declared project pom using the pom task but I think that should be a feature request in that case, not a bug fix.

Regards,

Per

On 11/7/25 00:07, Per Nyfelt wrote:
"Global" pom (I should probably have called it a project pom instead) means a pom that is registered and available by refId anywhere in the build. I.e. using the pom task you can register it in a a target, or at the top level and it will be then be available anywhere else (i.e. similar to a property). "Nested" pom is when the pom entry in overridden only in a particular task and has no "global" side effects. In the case I tried to give as an example we can have a project pom registered but for some reason we want to actually deploy another pom. We have several examples of this in the ant.xml test here: https://github.com/apache/maven-resolver-ant-tasks/blob/maven-resolver-ant-tasks-1.6.0/src/test/resources/ant/Deploy/ant.xml with some slight variations.

However, the scenario that the bug report highlighted was not considered before (hence the NPE) i.e. in this case we don't have a project/"global" pom since we don't do any dependency management, installs etc. we just have a case where a jar file was produced that we wish to deploy. I think both ways to look at this situation is justifiable i.e.

1. A pom must be registered, if an override is attempted when there is no project/"global" pom then we abort with a clear message about the issue.

2. I also think it is OK to view it as "i don't need a project pom (since i am not using any of the other tasks), I just want to deploy my jar and I want to define what pom to describe that artifact in my deploy task".

I think it entirely possible to implement either of these but since i have no strong opinion on which one would be best i wanted to ask for some guidance before continuing with a fix.

I hope I managed to make it clearer.

Best regards,

Per

On 11/6/25 21:03, Tamás Cservenák wrote:
Howdy,

Per, thank you for looking into this!

Could you explain what "global POM" and what "nested POM" is in this case?

Thanks
T

On Thu, Nov 6, 2025 at 8:29 PM Per Nyfelt <[email protected]> wrote:
Hi,

Tamas asked me to take a look at this bug report:
https://github.com/apache/maven-resolver-ant-tasks/issues/138

It highlights an issue I hope to get some advice on.

The essence of the issue is whether we should enforce a "global pom" or
not. Today we allow overriding it in the deploy task e.g:

<target name="testDeployOverrideGlobalPom" depends="setUp"> <repo:pom file="${project.dir}/dummy-pom.xml"/> <repo:deploy remotereporef="distrepo"> <pom file="${project.dir}/other-pom.xml"/> </repo:deploy> </target>

But if the user ONLY specifies the pom as a nested element inside the
deploy e.g:

<target name="testDeployNoGlobalPom" depends="setUp">
<repo:deploy> <repo:artifact file="${artifact.file}"> <repo:pom file="${project.dir}/dummy-pom.xml"/> </repo:artifact> </repo:deploy> </target>

Then we throw an NPE on  line 133 of the AbstractDistTask (because there
is no global pom).

I have reproduced the error in a test here:
https://github.com/apache/maven-resolver-ant-tasks/pull/139

The question is if we should

1. Allow this usage (fix the NPE issue)

2. Not allow this and throw a BuildException stating that a global pom
must be registered before an override is specified.

What do you think?

Regards,

Per
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to