hpi:run uses wrong jpi/hpl from .jenkins-hpl-map #415
Conversation
jgreffe
changed the title
| @@ -43,6 +43,7 @@ | |||
| import org.apache.maven.project.ProjectDependenciesResolver; | |||
| import org.apache.maven.shared.transfer.artifact.resolve.ArtifactResolver; | |||
| import org.apache.maven.shared.transfer.artifact.resolve.ArtifactResolverException; | |||
| import org.apache.tools.ant.Project; | |||
| private File getRootBasedir(MavenProject mavenProject) { | ||
| if (mavenProject.getParent() == null || | ||
| mavenProject.getParent().getBasedir() == null || | ||
| !mavenProject.getBasedir().getAbsolutePath() | ||
| .contains(mavenProject.getParent().getBasedir().getAbsolutePath())) { | ||
| return mavenProject.getBasedir(); | ||
| } | ||
| return getRootBasedir(mavenProject.getParent()); | ||
| } |
There was a problem hiding this comment.
this does not appear to be correct. There is no guarantee that a parent in of any submodule in a build is in the reactor, or parent structure.
For more reading check the difference between an aggregator project and a parent. It is possible to be both an aggregator and a parent, but it is not required.
There was a problem hiding this comment.
you could look at the current maven session and what modules are in it.
or you could possibly use the maven.multiModuleProjectDirectory property.
| <module>sub-module1</module> | ||
| <module>sub-module2</module> | ||
| <module>sub-module3</module> | ||
| <module>sub-module4</module> | ||
| <module>sub-module5</module> | ||
| <module>sub-module6</module> | ||
| <module>sub-module7</module> | ||
| <module>sub-module8</module> | ||
| <module>sub-module9</module> | ||
| <module>sub-module10</module> |
There was a problem hiding this comment.
do you really need 10 modules to validate this?
There was a problem hiding this comment.
It's an arbitrary number of modules, could be less, but we may have it working by chance even without the fix.
| # under the License. | ||
| # | ||
|
|
||
| invoker.goals=-ntp clean install hpi:run -Djetty.skip=true -DskipTests |
There was a problem hiding this comment.
this obviously works - but how come? hpi:run would normally run forever - does it terminate as there is no console?
There was a problem hiding this comment.
Property -Djetty.skip=true avoids the jetty server to run, we don't start any infinite process.
There was a problem hiding this comment.
Not the right fix I think. Fails to diagnose the essential problem: that the *.properties file is randomly sorted, rather than chronologically.
Probably it would suffice to just invert the map, so that it is from id to file, so that mvn install on a new checkout would overwrite previous entries of the same GAV. I cannot recall why it was in the current order to begin with.
| if (src.getAbsolutePath().contains(rootBasedir.getAbsolutePath())) { | ||
| getLog().info("Copying snapshot dependency Jenkins plugin " + src); | ||
| } else { | ||
| getLog().warn("Copying snapshot dependency Jenkins plugin " + src + " from outside the current root base dir " + rootBasedir); |
There was a problem hiding this comment.
This should not be a warning; it is perfectly normal.
Did you just mean to use -pl to select a submodule to run?
One reason I remember now: in the normal case that the snapshot version changes (in the case of core or a plugin using An alternative scheme which would address JENKINS-70329 simply while avoiding an ever-growing file might be to write out directory / GAV pairs in reverse chronological order (implies using some format other than Another solution would be to invert the map but use GA rather than GAV as the key, and include the version in the value alongside the file path. It is after all unlikely that you would switch back and forth between projects using different versions of the same snapshot dependency and expect |
https://issues.jenkins.io/browse/JENKINS-70329
Check if the resolved
the.hplfrom/Users/xxx/.jenkins-hpl-mapare contained within the current maven root project.If not, logs a WARN instead of an INFO.