Re: Reactor module dependency tree resolution
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 <
land...@gmail.com>:
> 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 <
> land...@gmail.com>:
>
>> 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 <
>> khmarba...@gmx.de>:
>>
>>> 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,
>>>
Re: Reactor module dependency tree resolution
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 <
land...@gmail.com>:
> 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 <
> khmarba...@gmx.de>:
>
>> 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
Re: Reactor module dependency tree resolution
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 <
khmarba...@gmx.de>:
> 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
> >
>
>
>
Re: Reactor module dependency tree resolution
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
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Reactor module dependency tree resolution
IIUC you should be able to do that using Project#getReferencedProjects(),
you may have to first call Project#getExecutionProject().
Have a look at
https://github.com/tbroyer/gwt-maven-plugin/blob/master/src/main/java/net/ltgt/gwt/maven/AbstractDevModeMojo.java
and
see if it somehow fits your use-case (here, I get all dependency artifacts
to build a classpath for a forked jvm, and possibly replace some of them
with the corresponding reactor project's source roots)
On Fri, Apr 24, 2020 at 2:47 PM 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).
>
> 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.
>
> 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
>
--
Thomas Broyer
/tɔ.ma.bʁwa.je/
