You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Thai Le <ln...@gmail.com> on 2022/09/28 19:32:03 UTC
How to share the same modules between different profiles
Hello,
I have an aggregator pom with 70 modules to be built.
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>company</groupId>
<artifactId>packaging-pom</artifactId>
<version>1</version>
<packaging>pom</packaging>
<modules> 70 modules listed here </modules>
</project>
Recently we are introducing pact testing into our build pipeline so I made
2 profiles. One is for running pact consumer test which excludes all the
unit tests ending with *Test and only includes the consumer test. The other
one is for running pact provider tests which excludes all unit tests and
pact consumer tests so that only pact provider tests can run. The 2
profiles should be applied to all the 70 modules. One way to do that is to
put the modules inside each profile thus the modules are duplicated.
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>company</groupId>
<artifactId>packaging-pom</artifactId>
<version>1</version>
<packaging>pom</packaging>
<profiles>
<profile>
<id>consumer-pact-test</id>
*<modules> 70 modules listed here </modules>*
<build>...</build>
</profile>
<profile>
<id>provider-pact-test</id>
*<modules> 70 modules listed here </modules>*
<build>...</build>
</profile>
</profiles>
</project>
Imagine if I had to add 10 more profiles. Is there other ways to share the
same modules between multiple profiles without duplicating them ?
Regards
Thai Le
Re: How to share the same modules between different profiles
Posted by Arnaud bourree <ar...@gmail.com>.
Hi,
Your pom module inherit from your own pom parent which will inherit from
sprint boot-starter.
Regardes,
Arnaud
Le ven. 30 sept. 2022, 16:52, Thai Le <ln...@gmail.com> a écrit :
> Thank you, this makes sense to me now that I added the profiles to all the
> pom of the modules. Most of our modules are inherited from
> spring-boot-starter so it is not possible to add the profiles there.
>
> Thai Le
>
> On Fri, 30 Sept 2022 at 02:26, Arnaud bourree <ar...@gmail.com>
> wrote:
>
> > Hi,
> >
> > Your pom agregator doesn't need to be aware about testing profiles, its
> job
> > is only agregating.
> > The 70 poms should have a parent pom (bom) within your testing profile.
> >
> > Regardes,
> >
> > Arnaud
> >
> > Le jeu. 29 sept. 2022, 00:06, Delany <de...@gmail.com> a
> écrit
> > :
> >
> > > Shouldn't matter. Please give full pom.
> > > Delany
> > >
> > > On Wed, 28 Sep 2022, 23:15 Thai Le, <ln...@gmail.com> wrote:
> > >
> > > > Thanks for your input. That's the first thing I tried. Unfortunately,
> > if
> > > I
> > > > do that none of the modules recognized the profiles.
> > > >
> > > > On Wed, Sep 28, 2022, 17:08 Delany <de...@gmail.com>
> wrote:
> > > >
> > > > > Why did you duplicate modules in the profiles? Just leave them
> under
> > > > > project.
> > > > > Delany
> > > > >
> > > > >
> > > > > On Wed, 28 Sep 2022, 21:32 Thai Le, <ln...@gmail.com> wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > I have an aggregator pom with 70 modules to be built.
> > > > > > <project>
> > > > > > <modelVersion>4.0.0</modelVersion>
> > > > > > <groupId>company</groupId>
> > > > > > <artifactId>packaging-pom</artifactId>
> > > > > > <version>1</version>
> > > > > > <packaging>pom</packaging>
> > > > > > <modules> 70 modules listed here </modules>
> > > > > > </project>
> > > > > > Recently we are introducing pact testing into our build pipeline
> > so I
> > > > > made
> > > > > > 2 profiles. One is for running pact consumer test which excludes
> > all
> > > > the
> > > > > > unit tests ending with *Test and only includes the consumer test.
> > The
> > > > > other
> > > > > > one is for running pact provider tests which excludes all unit
> > tests
> > > > and
> > > > > > pact consumer tests so that only pact provider tests can run.
> The 2
> > > > > > profiles should be applied to all the 70 modules. One way to do
> > that
> > > is
> > > > > to
> > > > > > put the modules inside each profile thus the modules are
> > duplicated.
> > > > > > <project>
> > > > > > <modelVersion>4.0.0</modelVersion>
> > > > > > <groupId>company</groupId>
> > > > > > <artifactId>packaging-pom</artifactId>
> > > > > > <version>1</version>
> > > > > > <packaging>pom</packaging>
> > > > > >
> > > > > > <profiles>
> > > > > > <profile>
> > > > > > <id>consumer-pact-test</id>
> > > > > > *<modules> 70 modules listed here </modules>*
> > > > > > <build>...</build>
> > > > > > </profile>
> > > > > >
> > > > > > <profile>
> > > > > > <id>provider-pact-test</id>
> > > > > > *<modules> 70 modules listed here </modules>*
> > > > > > <build>...</build>
> > > > > > </profile>
> > > > > >
> > > > > > </profiles>
> > > > > > </project>
> > > > > > Imagine if I had to add 10 more profiles. Is there other ways to
> > > share
> > > > > the
> > > > > > same modules between multiple profiles without duplicating them ?
> > > > > >
> > > > > > Regards
> > > > > >
> > > > > > Thai Le
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
> --
> Where there is will, there is a way
>
Re: How to share the same modules between different profiles
Posted by Thai Le <ln...@gmail.com>.
Thank you, this makes sense to me now that I added the profiles to all the
pom of the modules. Most of our modules are inherited from
spring-boot-starter so it is not possible to add the profiles there.
Thai Le
On Fri, 30 Sept 2022 at 02:26, Arnaud bourree <ar...@gmail.com>
wrote:
> Hi,
>
> Your pom agregator doesn't need to be aware about testing profiles, its job
> is only agregating.
> The 70 poms should have a parent pom (bom) within your testing profile.
>
> Regardes,
>
> Arnaud
>
> Le jeu. 29 sept. 2022, 00:06, Delany <de...@gmail.com> a écrit
> :
>
> > Shouldn't matter. Please give full pom.
> > Delany
> >
> > On Wed, 28 Sep 2022, 23:15 Thai Le, <ln...@gmail.com> wrote:
> >
> > > Thanks for your input. That's the first thing I tried. Unfortunately,
> if
> > I
> > > do that none of the modules recognized the profiles.
> > >
> > > On Wed, Sep 28, 2022, 17:08 Delany <de...@gmail.com> wrote:
> > >
> > > > Why did you duplicate modules in the profiles? Just leave them under
> > > > project.
> > > > Delany
> > > >
> > > >
> > > > On Wed, 28 Sep 2022, 21:32 Thai Le, <ln...@gmail.com> wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > I have an aggregator pom with 70 modules to be built.
> > > > > <project>
> > > > > <modelVersion>4.0.0</modelVersion>
> > > > > <groupId>company</groupId>
> > > > > <artifactId>packaging-pom</artifactId>
> > > > > <version>1</version>
> > > > > <packaging>pom</packaging>
> > > > > <modules> 70 modules listed here </modules>
> > > > > </project>
> > > > > Recently we are introducing pact testing into our build pipeline
> so I
> > > > made
> > > > > 2 profiles. One is for running pact consumer test which excludes
> all
> > > the
> > > > > unit tests ending with *Test and only includes the consumer test.
> The
> > > > other
> > > > > one is for running pact provider tests which excludes all unit
> tests
> > > and
> > > > > pact consumer tests so that only pact provider tests can run. The 2
> > > > > profiles should be applied to all the 70 modules. One way to do
> that
> > is
> > > > to
> > > > > put the modules inside each profile thus the modules are
> duplicated.
> > > > > <project>
> > > > > <modelVersion>4.0.0</modelVersion>
> > > > > <groupId>company</groupId>
> > > > > <artifactId>packaging-pom</artifactId>
> > > > > <version>1</version>
> > > > > <packaging>pom</packaging>
> > > > >
> > > > > <profiles>
> > > > > <profile>
> > > > > <id>consumer-pact-test</id>
> > > > > *<modules> 70 modules listed here </modules>*
> > > > > <build>...</build>
> > > > > </profile>
> > > > >
> > > > > <profile>
> > > > > <id>provider-pact-test</id>
> > > > > *<modules> 70 modules listed here </modules>*
> > > > > <build>...</build>
> > > > > </profile>
> > > > >
> > > > > </profiles>
> > > > > </project>
> > > > > Imagine if I had to add 10 more profiles. Is there other ways to
> > share
> > > > the
> > > > > same modules between multiple profiles without duplicating them ?
> > > > >
> > > > > Regards
> > > > >
> > > > > Thai Le
> > > > >
> > > >
> > >
> >
>
--
Where there is will, there is a way
Re: Modular path vs. class path determination
Posted by Ceki Gülcü <ce...@qos.ch>.
Hello Martin, Olivier,
Since I posted on this thread, I have abandoned the idea of integration
testing in the same Maven module. Instead, for module X, white-box
testing is still done within X/src/test/ and integration testing done in
a new and separate module X-blackbox which is also Jigsaw/JPMS modular.
This approach is a lot less painful than in-single-module testing.
--
Ceki Gülcü
Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
On 10/17/2022 1:27 PM, Martin Desruisseaux wrote:
> Le 17/10/2022 à 12:33, Olivier Lamy a écrit :
>
>> I wanted to have some opinions on what sort of configurations we could
>> add but this didn't get much attention :)
>> (https://issues.apache.org/jira/browse/SUREFIRE-2097) Maybe nobody
>> really cares of jpms...
>>
> On my side I do care a lot about JPMS. But I got the feeling that Maven
> model is not well suited to JPMS, which caused me to stop following JPMS
> issues on Maven and look for other build solution.
>
> The difficulty I have with JPMS in Maven is that I would like to break
> the "one Maven module = one JPMS module" relationship. Instead I would
> like "one Maven module = one compilation unit", i.e. a single call to
> javac, javadoc or other java tools, which may itself comprise many JPMS
> module.
>
> Martin
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Modular path vs. class path determination
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 17/10/2022 à 12:33, Olivier Lamy a écrit :
> I wanted to have some opinions on what sort of configurations we could
> add but this didn't get much attention :)
> (https://issues.apache.org/jira/browse/SUREFIRE-2097) Maybe nobody
> really cares of jpms...
>
On my side I do care a lot about JPMS. But I got the feeling that Maven
model is not well suited to JPMS, which caused me to stop following JPMS
issues on Maven and look for other build solution.
The difficulty I have with JPMS in Maven is that I would like to break
the "one Maven module = one JPMS module" relationship. Instead I would
like "one Maven module = one compilation unit", i.e. a single call to
javac, javadoc or other java tools, which may itself comprise many JPMS
module.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Modular path vs. class path determination
Posted by Olivier Lamy <ol...@apache.org>.
On Sat, 1 Oct 2022 at 01:22, Ceki Gülcü <ce...@qos.ch> wrote:
>
>
> Hello all,
>
> The logback is attempting to migrate to Junit 5. As a consequence of
> this migration, a handful of tests that were previously successful, now
> fail.
>
> For example, the ch.qos.logback.classic.net.DilutedSMTPAppenderTest
> recently failed with the following error:
>
> java.lang.NoClassDefFoundError: jakarta/mail/internet/AddressException
>
> During surefire execution, the j.m.i.AddressException class is not
> found. It is part of jakarta-mail.jar. I believe this artifact is on the
> module path but somehow is not resolved.
>
> Anyway, upgrading org.assertj:assertj-core from l.7.1 to 3.23.1 seems to
> help. Don't ask me why...
>
> I am also puzzled by the fact that many JMPS modularized artifacts are
> placed on the class path instead of the module path when the tests are run.
well maybe the problem is some are on module path and some others on
the class path..
when migrating the Jetty project from surefire M5 to M7 I had a lot of
jpms issues because some logic changed especially in this part.
I wanted to have some opinions on what sort of configurations we could
add but this didn't get much attention :)
(https://issues.apache.org/jira/browse/SUREFIRE-2097)
Maybe nobody really cares of jpms...
>
> Anyway, I think I may have stumbled upon a bug in Maven or the surefire
> plugin. Indeed, when I run mvn install from within the logback-classic
> module, the DilutedSMTPAppenderTest mentioned above succeeds.
>
> However, when I run it as
>
> mvn install -Dtest=ch.qos.logback.classic.net.DilutedSMTPAppenderTest
>
> the test fails with the following exception
>
> [ERROR]
> ch.qos.logback.classic.net.DilutedSMTPAppenderTest.testTriggeringPolicy
> Time elapsed: 0.001 s <<< ERROR!
> java.lang.NoClassDefFoundError: jakarta/mail/internet/AddressException
> at
> ch.qos.logback.classic@1.4.2-SNAPSHOT/ch.qos.logback.classic.net.DilutedSMTPAppenderTest.setUp(DilutedSMTPAppenderTest.java:41)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>
> [cut]...
> Caused by: java.lang.ClassNotFoundException:
> jakarta.mail.internet.AddressException
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 74 more
>
>
> Comparing the command line of the two executions, the 'mvn install'
> execution has jakarta-mail-api on the module-path, whereas the 'mvn test
> -D=..." has jakarta-mail-api on the class-path.
>
> If you wish to confirm this, I have created tag 'possible_mvn_issue'
> in the logback repository on github .
>
> https://github.com/qos-ch/logback/releases/tag/possible_mvn_issue
>
> Let me know if this merits the creation of a Jira issue.
>
> Your feedback would be most appreciated.
>
> --
> Ceki Gülcü
>
> Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Modular path vs. class path determination
Posted by Ceki Gülcü <ce...@qos.ch>.
Hello all,
The logback is attempting to migrate to Junit 5. As a consequence of
this migration, a handful of tests that were previously successful, now
fail.
For example, the ch.qos.logback.classic.net.DilutedSMTPAppenderTest
recently failed with the following error:
java.lang.NoClassDefFoundError: jakarta/mail/internet/AddressException
During surefire execution, the j.m.i.AddressException class is not
found. It is part of jakarta-mail.jar. I believe this artifact is on the
module path but somehow is not resolved.
Anyway, upgrading org.assertj:assertj-core from l.7.1 to 3.23.1 seems to
help. Don't ask me why...
I am also puzzled by the fact that many JMPS modularized artifacts are
placed on the class path instead of the module path when the tests are run.
Anyway, I think I may have stumbled upon a bug in Maven or the surefire
plugin. Indeed, when I run mvn install from within the logback-classic
module, the DilutedSMTPAppenderTest mentioned above succeeds.
However, when I run it as
mvn install -Dtest=ch.qos.logback.classic.net.DilutedSMTPAppenderTest
the test fails with the following exception
[ERROR]
ch.qos.logback.classic.net.DilutedSMTPAppenderTest.testTriggeringPolicy
Time elapsed: 0.001 s <<< ERROR!
java.lang.NoClassDefFoundError: jakarta/mail/internet/AddressException
at
ch.qos.logback.classic@1.4.2-SNAPSHOT/ch.qos.logback.classic.net.DilutedSMTPAppenderTest.setUp(DilutedSMTPAppenderTest.java:41)
at
java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
at java.base/java.lang.reflect.Method.invoke(Method.java:578)
[cut]...
Caused by: java.lang.ClassNotFoundException:
jakarta.mail.internet.AddressException
at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
... 74 more
Comparing the command line of the two executions, the 'mvn install'
execution has jakarta-mail-api on the module-path, whereas the 'mvn test
-D=..." has jakarta-mail-api on the class-path.
If you wish to confirm this, I have created tag 'possible_mvn_issue'
in the logback repository on github .
https://github.com/qos-ch/logback/releases/tag/possible_mvn_issue
Let me know if this merits the creation of a Jira issue.
Your feedback would be most appreciated.
--
Ceki Gülcü
Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
Re: How to share the same modules between different profiles
Posted by Arnaud bourree <ar...@gmail.com>.
Hi,
Your pom agregator doesn't need to be aware about testing profiles, its job
is only agregating.
The 70 poms should have a parent pom (bom) within your testing profile.
Regardes,
Arnaud
Le jeu. 29 sept. 2022, 00:06, Delany <de...@gmail.com> a écrit :
> Shouldn't matter. Please give full pom.
> Delany
>
> On Wed, 28 Sep 2022, 23:15 Thai Le, <ln...@gmail.com> wrote:
>
> > Thanks for your input. That's the first thing I tried. Unfortunately, if
> I
> > do that none of the modules recognized the profiles.
> >
> > On Wed, Sep 28, 2022, 17:08 Delany <de...@gmail.com> wrote:
> >
> > > Why did you duplicate modules in the profiles? Just leave them under
> > > project.
> > > Delany
> > >
> > >
> > > On Wed, 28 Sep 2022, 21:32 Thai Le, <ln...@gmail.com> wrote:
> > >
> > > > Hello,
> > > >
> > > > I have an aggregator pom with 70 modules to be built.
> > > > <project>
> > > > <modelVersion>4.0.0</modelVersion>
> > > > <groupId>company</groupId>
> > > > <artifactId>packaging-pom</artifactId>
> > > > <version>1</version>
> > > > <packaging>pom</packaging>
> > > > <modules> 70 modules listed here </modules>
> > > > </project>
> > > > Recently we are introducing pact testing into our build pipeline so I
> > > made
> > > > 2 profiles. One is for running pact consumer test which excludes all
> > the
> > > > unit tests ending with *Test and only includes the consumer test. The
> > > other
> > > > one is for running pact provider tests which excludes all unit tests
> > and
> > > > pact consumer tests so that only pact provider tests can run. The 2
> > > > profiles should be applied to all the 70 modules. One way to do that
> is
> > > to
> > > > put the modules inside each profile thus the modules are duplicated.
> > > > <project>
> > > > <modelVersion>4.0.0</modelVersion>
> > > > <groupId>company</groupId>
> > > > <artifactId>packaging-pom</artifactId>
> > > > <version>1</version>
> > > > <packaging>pom</packaging>
> > > >
> > > > <profiles>
> > > > <profile>
> > > > <id>consumer-pact-test</id>
> > > > *<modules> 70 modules listed here </modules>*
> > > > <build>...</build>
> > > > </profile>
> > > >
> > > > <profile>
> > > > <id>provider-pact-test</id>
> > > > *<modules> 70 modules listed here </modules>*
> > > > <build>...</build>
> > > > </profile>
> > > >
> > > > </profiles>
> > > > </project>
> > > > Imagine if I had to add 10 more profiles. Is there other ways to
> share
> > > the
> > > > same modules between multiple profiles without duplicating them ?
> > > >
> > > > Regards
> > > >
> > > > Thai Le
> > > >
> > >
> >
>
Re: How to share the same modules between different profiles
Posted by Thai Le <ln...@gmail.com>.
Here is my aggregator pom (taking out other 67 modules)
------------------------------------------------------------
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>cnp</groupId>
<artifactId>packaging-pom</artifactId>
<version>1</version>
<packaging>pom</packaging>
<modules>
<module>60000-demo-service/demo-service</module>
<module>60002-service1/service1</module>
<module>60003-service2/service2</module>
</modules>
<profiles>
<profile>
<id>consumer-pact-test</id>
<build>
<plugins>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.22.2</version>
<executions>
<execution>
<!-- This must match the maven execution ID defined in
the build config to override-->
<id>default-test</id>
<phase>test</phase>
<goals>
<goal>test</goal>
</goals>
<configuration>
<!-- Donot run any normal unit test -->
<excludes>
<exclude>**/Test*.java</exclude>
<exclude>**/*Test.java</exclude>
<exclude>**/*Tests.java</exclude>
<exclude>**/*TestCase.java</exclude>
</excludes>
<!-- Only run consumer pact test-->
<includes>
<include>**/*CPT</include>
</includes>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
<profile>
<id>provider-pact-test</id>
<build>
<plugins>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.22.2</version>
<executions>
<execution>
<!-- This must match the maven execution ID defined in
the build config to override-->
<id>default-test</id>
<phase>test</phase>
<goals>
<goal>test</goal>
</goals>
<configuration>
<!-- Donot run any normal unit test -->
<excludes>
<exclude>**/Test*.java</exclude>
<exclude>**/*Test.java</exclude>
<exclude>**/*Tests.java</exclude>
<exclude>**/*TestCase.java</exclude>
</excludes>
</configuration>
</execution>
<execution>
<phase>integration-test</phase>
<goals>
<goal>test</goal>
</goals>
<configuration>
<excludes>
<exclude>**/Test*</exclude>
<exclude>**/*Test</exclude>
<exclude>**/*Tests</exclude>
<exclude>**/*TestCase</exclude>
</excludes>
<includes>
<include>**/*PPT</include>
</includes>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<version>3.0.0-M1</version>
<configuration>
<skip>true</skip>
</configuration>
<inherited>false</inherited>
</plugin>
<plugin>
<groupId>au.com.dius.pact.provider</groupId>
<artifactId>maven</artifactId>
<version>4.1.17</version>
<inherited>true</inherited>
</plugin>
</plugins>
</build>
</project>
------------------------------------------------------------
With this pom, if i run:
mvn --activate-profiles provider-pact-test -Dpackbroker.scheme=http
-Dpactbroker.host=localhost -Dpactbroker.port=9292
-Dpactbroker.auth.username=pact_workshop
-Dpactbroker.auth.password=pact_workshop
-Dpact.provider.version="7.0.36-$(git rev-parse --short HEAD)" -f
all-modules-pom.xml verify
then i see all the unit test (end with *Test) running:
[image: image.png]
If i run
mvn --activate-profiles provider-pact-test -Dpackbroker.scheme=http
-Dpactbroker.host=localhost -Dpactbroker.port=9292
-Dpactbroker.auth.username=pact_workshop
-Dpactbroker.auth.password=pact_workshop
-Dpact.provider.version="7.0.36-$(git rev-parse --short HEAD)" --projects
cn:demo-service --also-make -f all-modules-pom.xml verify
i see the unit tests ran and at the end, i got thiw warning
[WARNING] The requested profile "provider-pact-test" could not be activated
because it does not exist.
this show that the profiles defined at aggregator are not passed down to
the module.
The only way i am able to make it work is to add the profiles to all the
poms of the modules.
On Wed, 28 Sept 2022 at 18:06, Delany <de...@gmail.com> wrote:
> Shouldn't matter. Please give full pom.
> Delany
>
> On Wed, 28 Sep 2022, 23:15 Thai Le, <ln...@gmail.com> wrote:
>
> > Thanks for your input. That's the first thing I tried. Unfortunately, if
> I
> > do that none of the modules recognized the profiles.
> >
> > On Wed, Sep 28, 2022, 17:08 Delany <de...@gmail.com> wrote:
> >
> > > Why did you duplicate modules in the profiles? Just leave them under
> > > project.
> > > Delany
> > >
> > >
> > > On Wed, 28 Sep 2022, 21:32 Thai Le, <ln...@gmail.com> wrote:
> > >
> > > > Hello,
> > > >
> > > > I have an aggregator pom with 70 modules to be built.
> > > > <project>
> > > > <modelVersion>4.0.0</modelVersion>
> > > > <groupId>company</groupId>
> > > > <artifactId>packaging-pom</artifactId>
> > > > <version>1</version>
> > > > <packaging>pom</packaging>
> > > > <modules> 70 modules listed here </modules>
> > > > </project>
> > > > Recently we are introducing pact testing into our build pipeline so I
> > > made
> > > > 2 profiles. One is for running pact consumer test which excludes all
> > the
> > > > unit tests ending with *Test and only includes the consumer test. The
> > > other
> > > > one is for running pact provider tests which excludes all unit tests
> > and
> > > > pact consumer tests so that only pact provider tests can run. The 2
> > > > profiles should be applied to all the 70 modules. One way to do that
> is
> > > to
> > > > put the modules inside each profile thus the modules are duplicated.
> > > > <project>
> > > > <modelVersion>4.0.0</modelVersion>
> > > > <groupId>company</groupId>
> > > > <artifactId>packaging-pom</artifactId>
> > > > <version>1</version>
> > > > <packaging>pom</packaging>
> > > >
> > > > <profiles>
> > > > <profile>
> > > > <id>consumer-pact-test</id>
> > > > *<modules> 70 modules listed here </modules>*
> > > > <build>...</build>
> > > > </profile>
> > > >
> > > > <profile>
> > > > <id>provider-pact-test</id>
> > > > *<modules> 70 modules listed here </modules>*
> > > > <build>...</build>
> > > > </profile>
> > > >
> > > > </profiles>
> > > > </project>
> > > > Imagine if I had to add 10 more profiles. Is there other ways to
> share
> > > the
> > > > same modules between multiple profiles without duplicating them ?
> > > >
> > > > Regards
> > > >
> > > > Thai Le
> > > >
> > >
> >
>
--
Where there is will, there is a way
Re: How to share the same modules between different profiles
Posted by Delany <de...@gmail.com>.
Shouldn't matter. Please give full pom.
Delany
On Wed, 28 Sep 2022, 23:15 Thai Le, <ln...@gmail.com> wrote:
> Thanks for your input. That's the first thing I tried. Unfortunately, if I
> do that none of the modules recognized the profiles.
>
> On Wed, Sep 28, 2022, 17:08 Delany <de...@gmail.com> wrote:
>
> > Why did you duplicate modules in the profiles? Just leave them under
> > project.
> > Delany
> >
> >
> > On Wed, 28 Sep 2022, 21:32 Thai Le, <ln...@gmail.com> wrote:
> >
> > > Hello,
> > >
> > > I have an aggregator pom with 70 modules to be built.
> > > <project>
> > > <modelVersion>4.0.0</modelVersion>
> > > <groupId>company</groupId>
> > > <artifactId>packaging-pom</artifactId>
> > > <version>1</version>
> > > <packaging>pom</packaging>
> > > <modules> 70 modules listed here </modules>
> > > </project>
> > > Recently we are introducing pact testing into our build pipeline so I
> > made
> > > 2 profiles. One is for running pact consumer test which excludes all
> the
> > > unit tests ending with *Test and only includes the consumer test. The
> > other
> > > one is for running pact provider tests which excludes all unit tests
> and
> > > pact consumer tests so that only pact provider tests can run. The 2
> > > profiles should be applied to all the 70 modules. One way to do that is
> > to
> > > put the modules inside each profile thus the modules are duplicated.
> > > <project>
> > > <modelVersion>4.0.0</modelVersion>
> > > <groupId>company</groupId>
> > > <artifactId>packaging-pom</artifactId>
> > > <version>1</version>
> > > <packaging>pom</packaging>
> > >
> > > <profiles>
> > > <profile>
> > > <id>consumer-pact-test</id>
> > > *<modules> 70 modules listed here </modules>*
> > > <build>...</build>
> > > </profile>
> > >
> > > <profile>
> > > <id>provider-pact-test</id>
> > > *<modules> 70 modules listed here </modules>*
> > > <build>...</build>
> > > </profile>
> > >
> > > </profiles>
> > > </project>
> > > Imagine if I had to add 10 more profiles. Is there other ways to share
> > the
> > > same modules between multiple profiles without duplicating them ?
> > >
> > > Regards
> > >
> > > Thai Le
> > >
> >
>
Re: How to share the same modules between different profiles
Posted by Thai Le <ln...@gmail.com>.
Thanks for your input. That's the first thing I tried. Unfortunately, if I
do that none of the modules recognized the profiles.
On Wed, Sep 28, 2022, 17:08 Delany <de...@gmail.com> wrote:
> Why did you duplicate modules in the profiles? Just leave them under
> project.
> Delany
>
>
> On Wed, 28 Sep 2022, 21:32 Thai Le, <ln...@gmail.com> wrote:
>
> > Hello,
> >
> > I have an aggregator pom with 70 modules to be built.
> > <project>
> > <modelVersion>4.0.0</modelVersion>
> > <groupId>company</groupId>
> > <artifactId>packaging-pom</artifactId>
> > <version>1</version>
> > <packaging>pom</packaging>
> > <modules> 70 modules listed here </modules>
> > </project>
> > Recently we are introducing pact testing into our build pipeline so I
> made
> > 2 profiles. One is for running pact consumer test which excludes all the
> > unit tests ending with *Test and only includes the consumer test. The
> other
> > one is for running pact provider tests which excludes all unit tests and
> > pact consumer tests so that only pact provider tests can run. The 2
> > profiles should be applied to all the 70 modules. One way to do that is
> to
> > put the modules inside each profile thus the modules are duplicated.
> > <project>
> > <modelVersion>4.0.0</modelVersion>
> > <groupId>company</groupId>
> > <artifactId>packaging-pom</artifactId>
> > <version>1</version>
> > <packaging>pom</packaging>
> >
> > <profiles>
> > <profile>
> > <id>consumer-pact-test</id>
> > *<modules> 70 modules listed here </modules>*
> > <build>...</build>
> > </profile>
> >
> > <profile>
> > <id>provider-pact-test</id>
> > *<modules> 70 modules listed here </modules>*
> > <build>...</build>
> > </profile>
> >
> > </profiles>
> > </project>
> > Imagine if I had to add 10 more profiles. Is there other ways to share
> the
> > same modules between multiple profiles without duplicating them ?
> >
> > Regards
> >
> > Thai Le
> >
>
Re: How to share the same modules between different profiles
Posted by Delany <de...@gmail.com>.
Why did you duplicate modules in the profiles? Just leave them under
project.
Delany
On Wed, 28 Sep 2022, 21:32 Thai Le, <ln...@gmail.com> wrote:
> Hello,
>
> I have an aggregator pom with 70 modules to be built.
> <project>
> <modelVersion>4.0.0</modelVersion>
> <groupId>company</groupId>
> <artifactId>packaging-pom</artifactId>
> <version>1</version>
> <packaging>pom</packaging>
> <modules> 70 modules listed here </modules>
> </project>
> Recently we are introducing pact testing into our build pipeline so I made
> 2 profiles. One is for running pact consumer test which excludes all the
> unit tests ending with *Test and only includes the consumer test. The other
> one is for running pact provider tests which excludes all unit tests and
> pact consumer tests so that only pact provider tests can run. The 2
> profiles should be applied to all the 70 modules. One way to do that is to
> put the modules inside each profile thus the modules are duplicated.
> <project>
> <modelVersion>4.0.0</modelVersion>
> <groupId>company</groupId>
> <artifactId>packaging-pom</artifactId>
> <version>1</version>
> <packaging>pom</packaging>
>
> <profiles>
> <profile>
> <id>consumer-pact-test</id>
> *<modules> 70 modules listed here </modules>*
> <build>...</build>
> </profile>
>
> <profile>
> <id>provider-pact-test</id>
> *<modules> 70 modules listed here </modules>*
> <build>...</build>
> </profile>
>
> </profiles>
> </project>
> Imagine if I had to add 10 more profiles. Is there other ways to share the
> same modules between multiple profiles without duplicating them ?
>
> Regards
>
> Thai Le
>