Which is exactly why I was asking. I want to learn about real-world use
cases which would require such a thing, not be just nice to have.
Over-engineering POMs does not make them more readable or maintainable.

Alexander Kriegisch
https://scrum-master.de


Mikael Åsberg schrieb am 16.02.2023 um 13:03:
> I use runtime scope a lot, but personally can't recall having needed
> the equivalent of a test-runtime scope myself (or, more likely, I
> could get away with test compile scope even though the dependency was
> only needed at test runtime). But just because I haven't needed it
> doesn't mean there are no legit circumstances.
> 
> On Thu, Feb 16, 2023 at 12:57 PM Alexander Kriegisch
> <alexan...@kriegisch.name> wrote:
>>
>> For a test, does it really matter to make the dependency test-scoped?
>>
>> Mikael Åsberg schrieb am 16.02.2023 um 12:35:
>>> Because there exists <scope>runtime</scope>, but no test only runtime scope
>>>
>>> On Thu, Feb 16, 2023 at 12:22 PM Alexander Kriegisch
>>> <alexan...@kriegisch.name> wrote:
>>>>
>>>> I would be more interested first in why this should be necessary at all.
>>>> What is the use case that would not be covered by declaring a regular
>>>> test-scoped dependency in the module?
>>>> --
>>>> Alexander Kriegisch
>>>> https://scrum-master.de
>>>>
>>>>
>>>> Olivier Lamy schrieb am 16.02.2023 um 11:58:
>>>>> On Thu, 16 Feb 2023 at 20:52, Olivier Lamy <ol...@apache.org> wrote:
>>>>>>
>>>>>> On Thu, 16 Feb 2023 at 20:07, Delany <delany.middle...@gmail.com> wrote:
>>>>>>>
>>>>>>> Hi Stephane,
>>>>>>>
>>>>>>> You can do like this
>>>>>>>
>>>>>>>         <plugin>
>>>>>>>           <artifactId>maven-surefire-plugin</artifactId>
>>>>>>>           <version>3.0.0-M9</version>
>>>>>>>           <dependencies>
>>>>>>>             <dependency>
>>>>>>>               <groupId>org.apache.commons</groupId>
>>>>>>>               <artifactId>commons-email</artifactId>
>>>>>>>               <version>1.5</version>
>>>>>>>             </dependency>
>>>>>>>           </dependencies>
>>>>>>>         </plugin>
>>>>>>
>>>>>> this will add dependencies to the surefire plugin itself.
>>>>>> I guess Stephane wants to add to the jvm running the tests?
>>>>>>
>>>>>> additionalClasspathElement expect a full path to a directory or a file
>>>>>> to be added to the classpath
>>>>>>
>>>>>> should work with something such but you need to assume commons-email
>>>>>> has been resolved locally as a dependency.
>>>>>> <additionalClasspathElement>${settings.localRepository}/org/apache/commons/commons-email/1.5/commons-email-1.5.jar</additionalClasspathElement>
>>>>>>
>>>>>> another solution is to use dependency:copy to copy the commons-email
>>>>>> dependency somewhere in ./target and use this path (see
>>>>>> https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html)
>>>>>>
>>>>>
>>>>> a real example here :)
>>>>> https://github.com/apache/maven-surefire/blob/master/surefire-providers/common-junit48/pom.xml
>>>>>
>>>>>> hth
>>>>>> Olivier
>>>>>>
>>>>>>>
>>>>>>> On Thu, 16 Feb 2023 at 11:25, Stephane Passignat <passig...@hotmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Is it possible to add a maven artifact as an 
>>>>>>>> additionalClasspathElement ?
>>>>>>>>
>>>>>>>> I tried this syntax, inspired by the exclusion mechanism, but it's not
>>>>>>>> working.
>>>>>>>>
>>>>>>>> <build>
>>>>>>>>     <plugins>
>>>>>>>>        <plugin>
>>>>>>>>           <groupId>org.apache.maven.plugins</groupId>
>>>>>>>>           <artifactId>maven-surefire-plugin</artifactId>
>>>>>>>>           <version>3.0.0-M9</version>
>>>>>>>>           <configuration>
>>>>>>>>              <additionalClasspathElements>
>>>>>>>>
>>>>>>>> <additionalClasspathElement>org.apache.commons:commons-email:1.5</additionalClasspathElement>
>>>>>>>>              </additionalClasspathElements>
>>>>>>>>           </configuration>
>>>>>>>>        </plugin>
>>>>>>>>     </plugins>
>>>>>>>> </build>
>>>>>>>>
>>>>>>>>
>>>>>>>> thank you
>>>>>>>>
>>>>>>>> Stéphane
>>>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Reply via email to