[ 
https://issues.apache.org/jira/browse/MDEPLOY-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Szervanszky updated MDEPLOY-201:
--------------------------------------
    Description: 
There appears to be a bug with the deployAtEnd feature when the maven project 
includes
a parent module which is not part of the build.
Eg: Includes a release parent pom with some standard config.

The bug is that the code is using the size of the reactorProjects list and this 
includes
the parent which isn't in the build process. This is causing the code to not 
perform any
deployments at the end because it is expecting to see another module in the 
build
sequence so that READYPROJECTSCOUNTER matches the size of the reactorList and 
this never
happens.

A potential solution to this is to look at the MavenSession and get the top 
level project
which started the build. Then getting the index position of the top level 
project in the
reactorList and subtracting it from the total size of the reactorList will give 
the
correct number of expected build modules.

We have tested these 
[changes|https://github.com/omnidavesz/maven-plugins/commit/658861bf716dfbc10f5341e5579fbc63ec06c865]
 locally and the solution appears to work.
But are currently unsure as to how the testing is done for this project.

  was:
There appears to be a bug with the deployAtEnd feature when the maven project 
includes
a parent module which is not part of the build.
Eg: Includes a release parent pom with some standard config.

The bug is that the code is using the size of the reactorProjects list and this 
includes
the parent which isn't in the build process. This is causing the code to not 
perform any
deployments at the end because it is expecting to see another module in the 
build
sequence so that READYPROJECTSCOUNTER matches the size of the reactorList and 
this never
happens.

A potential solution to this is to look at the MavenSession and get the top 
level project
which started the build. Then getting the index position of the top level 
project in the
reactorList and subtracting it from the total size of the reactorList will give 
the
correct number of expected build modules.

We have tested these 
[changes|https://github.com/omnidavesz/maven-plugins/blob/trunk/maven-deploy-plugin/src/main/java/org/apache/maven/plugin/deploy/DeployMojo.java]
 locally and the solution appears to work.
But are currently unsure as to how the testing is done for this project.


> deployAtEnd issue for multi-module projects
> -------------------------------------------
>
>                 Key: MDEPLOY-201
>                 URL: https://issues.apache.org/jira/browse/MDEPLOY-201
>             Project: Maven Deploy Plugin
>          Issue Type: Bug
>          Components: deploy:deploy
>    Affects Versions: 2.8.1, 2.8.2
>            Reporter: David Szervanszky
>
> There appears to be a bug with the deployAtEnd feature when the maven project 
> includes
> a parent module which is not part of the build.
> Eg: Includes a release parent pom with some standard config.
> The bug is that the code is using the size of the reactorProjects list and 
> this includes
> the parent which isn't in the build process. This is causing the code to not 
> perform any
> deployments at the end because it is expecting to see another module in the 
> build
> sequence so that READYPROJECTSCOUNTER matches the size of the reactorList and 
> this never
> happens.
> A potential solution to this is to look at the MavenSession and get the top 
> level project
> which started the build. Then getting the index position of the top level 
> project in the
> reactorList and subtracting it from the total size of the reactorList will 
> give the
> correct number of expected build modules.
> We have tested these 
> [changes|https://github.com/omnidavesz/maven-plugins/commit/658861bf716dfbc10f5341e5579fbc63ec06c865]
>  locally and the solution appears to work.
> But are currently unsure as to how the testing is done for this project.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to