Hi, ok, project.getProjectReferences() is exactly what I need. Thank you Thomas for the hint and thank you Karl for answering, too. I will remember these mechanisms.
Regards, Christian Am Fr., 24. Apr. 2020 um 15:41 Uhr schrieb Christian Domsch < [email protected]>: > OK, something I missed to explain: this subtree of patched libraries per > patched webmodule would be serialized into a json string and embedded into > every patched library. This then could be read by the monitoring tool for > checking the installation. Why every patched library? Because I cannot > ensure that the place where I put this information in, isn't the one who is > missing, so I want to put that information "everywhere", if that makes > sense. > > Am Fr., 24. Apr. 2020 um 15:37 Uhr schrieb Christian Domsch < > [email protected]>: > >> Hi, >> >> ok, more detail. Our application is in the end defined by mainly three >> war modules. These contain all the jars that we build ourselves (modules in >> the reactor) plus all dependencies from outside (irrelevant for what I want >> to do). We also have a patch building process that does not build the >> complete tree of all modules, but a defined subset. We still use the >> mentioned war modules as collection points to assemble everything that was >> build into what I will now call the patched war modules. >> >> Now, we have a monitoring tool for our running application that is able >> to tell apart which jar files that are in the classpath are patched and >> which are not (simple property in the MANIFEST). What we would like to do >> is check, if a complete patch delivery (consisting of all the jars that >> have been patched) is installed correctly. In order to do that >> automatically, while building the patches, I need to know all the modules >> that have been patched. This in itself is ${reactorProjects) minus some >> logistical modules in the reactor needed for the building process, but >> since these are known they can be easily filtered out. >> >> My issue right now is that this monitoring needs to know the amount of >> patches per webmodule, not all of them. Let's say library-a is only used by >> webmodule-1 and not webmodule-2. If I would use the complete set of patched >> libraries, the tool would always show a failed installation for >> webmodule-2, because it checks for library-a to be there, but it doesn't >> belong there. >> >> So, this is why I want to traverse the dependency graph for >> webmodule-1 and -2 and check for each module in the reactor in which >> webmodules these are included, while building the complete set of patches. >> >> I will take a look into Project.#referencedProjects and also >> session.#projectDependencyGraph. I think those sound like good starting >> points. >> >> Kind regards, >> >> Christian >> >> >> Am Fr., 24. Apr. 2020 um 15:09 Uhr schrieb Karl Heinz Marbaise < >> [email protected]>: >> >>> Hi, >>> >>> On 24.04.20 14:47, Christian Domsch wrote: >>> > Hi, >>> > >>> > I would like to be able to get access to the reactor module tree. I >>> have a >>> > specific plugin that is executed for each reactor module and it needs >>> to >>> > check, if for a predefined set of modules in the reactor (in our case >>> war >>> > archives that contain a subset of all modules) see if the current >>> module is >>> > actually contained in that war (directly or via transitive >>> dependencies). >>> >>> Can you explain more in detail what the use case is? If an artifact is >>> part of a war? Why would like to check that? Can be seen in the war >>> module? >>> >>> > >>> > What I tried so far, but isn't working, is using the aether dependency >>> > resolution mechanism. The reason why it isn't working is fairly >>> obvious: >>> > checking the transitive dependencies of these war modules, aether >>> tries to >>> > download all artifacts first and fails because they haven't been build >>> by >>> > the reactor, yet, and thus are unknown. This makes a lot of sense, but >>> also >>> > means this way won't help me. >>> > >>> > Now, the reactor itself has to be able to calculate those >>> dependencies, as >>> > it will calculate a certain order of building the modules, depending >>> on how >>> > those modules depend on each other. This (what I will call) reactor >>> module >>> > tree is exactly the information I need. >>> >>> The reactor is the part which contains the parents/modules and order of >>> building the modules...this can be accessed via: >>> >>> @Parameter(defaultValue = "${session}", required = true, readonly = true) >>> MavenSession session; >>> >>> By using the above session you could: >>> * session.getProjectDependencyGraph().getSortedProjects(); >>> >>> The sortedProjects is exactly the order of the reactor .. >>> >>> >>> If you like to know the dependencies you have to go via dependency >>> resolution in your plugin: >>> >>> Something like: >>> >>> @Mojo(name = "xxx", defaultPhase = LifecyclePhase.PRE_INTEGRATION_TEST, >>> requiresDependencyResolution = ResolutionScope.RUNTIME, threadSafe >>> = true) >>> >>> The important part is: >>> requiresDependencyResolution = ResolutionScope.RUNTIME >>> >>> which you now gives you the option to access the dependencies: >>> >>> project.getArtifacts(); >>> >>> where mvnProject: >>> >>> @Parameter(defaultValue = "${project}", required = true, readonly = >>> true) >>> private MavenProject project; >>> >>> Kind regards >>> Karl Heinz Marbaise >>> >>> > >>> > Is there a way to access this information from a plugin? >>> ${reactorProjects} >>> > does not tell me that. Or am I missing sth very obvious? >>> > >>> > Thx, >>> > >>> > Christian >>> > >>> >>> >>>
