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 >> > >> >> >>
