Re: Maven adjusts transitive compile-scope dependency to test-scope
There might be a rule in the enforcer plugin (I haven't checked). If one really wanted to change the dependency scope, he could add an exclusion in the Y dependency to break the transitivity. Fwiw, whenever you change your dependencies, it's a good idea to run mvn dependency:tree and look at the output (possibly diff'ing it with the output prior to the dependency change). Maven basically assumes that you take responsibility for the dependencies, and it only takes the role of a helper resolving the whole tree. Le mer. 15 mai 2019 07:42, Simon Taddiken a écrit : > In my case, the pom of Y explicitly declares X with scope compile. The > dependency tree should look something like this: > > MyProject <- this is a standalone application, that will not be depended on > by s/o else > |- X:test > |- Y:compile >\- X:compile > > So for MyProject, X is explicitly declared test but X also comes in > transitively via Y as compile. I do understand that declarations higher in > the tree are given precedence when it comes to dependency resolution but in > this case it simply breaks runtime code. > Of course I did not want to ship MyProject including X when I used X only > for tests. But now that Y also requires X I need MyProject to ship with X > in order to work correctly. > > I was just wondering whether there is some mechanism like a warning or a > flag to break the build in such cases, so that they do not go unnoticed. > > > Am Di., 14. Mai 2019 um 22:22 Uhr schrieb Jason Young < > jason.yo...@procentive.com>: > > > Did you declare that Y depends on X at all (via Y's pom.xml) or did it > > figure that out on its own (via transitive dependencies)? > > > > Test scope means it's for testing that one project, thus it's not > > transitive, e.g. I don't need JUnit for my tests just because > > SomeAwesomeProject uses JUnit for its tests, and I don't want to ship > JUnit > > in my project. > > > > On Tue, May 14, 2019 at 2:40 PM Simon Taddiken > > > wrote: > > > > > Hi everyone, > > > > > > I've encountered the following behavior and I'm not quite sure whether > it > > > is desirable. > > > In my project, I have declared a dependency *X* with scope *test*. I > then > > > updated the version of a 3rd party dependency *Y*. In its new version, > > *Y* > > > suddenly requires the aforementioned dependency *X* as a *compile > *scoped > > > dependency. > > > > > > In this scenario, maven resolves the scope of *X* to be *test, > *although > > it > > > is now required by *Y* during runtime, causing ClassNotFoundExceptions. > > By > > > the very nature of this behavior those mistakes can't even be detected > in > > > unit tests because *X* is available on test classpath. > > > > > > I have just found out that this behavior seems to be intended ( > > > > > > > > > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope > > > ) > > > but I can't really come up with a rationale for this design. Managing > any > > > transitive compile scoped dependency down to test scope will almost > > > certainly cause ClassNotFoundExceptions during runtime. > > > > > > Thoughts? > > > > > >
Re: Maven adjusts transitive compile-scope dependency to test-scope
In my case, the pom of Y explicitly declares X with scope compile. The dependency tree should look something like this: MyProject <- this is a standalone application, that will not be depended on by s/o else |- X:test |- Y:compile \- X:compile So for MyProject, X is explicitly declared test but X also comes in transitively via Y as compile. I do understand that declarations higher in the tree are given precedence when it comes to dependency resolution but in this case it simply breaks runtime code. Of course I did not want to ship MyProject including X when I used X only for tests. But now that Y also requires X I need MyProject to ship with X in order to work correctly. I was just wondering whether there is some mechanism like a warning or a flag to break the build in such cases, so that they do not go unnoticed. Am Di., 14. Mai 2019 um 22:22 Uhr schrieb Jason Young < jason.yo...@procentive.com>: > Did you declare that Y depends on X at all (via Y's pom.xml) or did it > figure that out on its own (via transitive dependencies)? > > Test scope means it's for testing that one project, thus it's not > transitive, e.g. I don't need JUnit for my tests just because > SomeAwesomeProject uses JUnit for its tests, and I don't want to ship JUnit > in my project. > > On Tue, May 14, 2019 at 2:40 PM Simon Taddiken > wrote: > > > Hi everyone, > > > > I've encountered the following behavior and I'm not quite sure whether it > > is desirable. > > In my project, I have declared a dependency *X* with scope *test*. I then > > updated the version of a 3rd party dependency *Y*. In its new version, > *Y* > > suddenly requires the aforementioned dependency *X* as a *compile *scoped > > dependency. > > > > In this scenario, maven resolves the scope of *X* to be *test, *although > it > > is now required by *Y* during runtime, causing ClassNotFoundExceptions. > By > > the very nature of this behavior those mistakes can't even be detected in > > unit tests because *X* is available on test classpath. > > > > I have just found out that this behavior seems to be intended ( > > > > > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope > > ) > > but I can't really come up with a rationale for this design. Managing any > > transitive compile scoped dependency down to test scope will almost > > certainly cause ClassNotFoundExceptions during runtime. > > > > Thoughts? > > >
Re: Concurrency issue while running Maven on Jenkins host
There was one more email with the same problem.
We are talking about this problem, global repo:
'$COMPANY_JENKINS_HOME.m2/repository/executor_$EXECUTOR_NUMBER'
Our build creates pwd() + "/.m2" in the job, and the scm checkouts git repo
to "./build" directory.
No issue then!
The Jenkinsfile should use relative paths and then it is transferable to
any new machines and any time.
Cheers
Tibor17
On Tue, May 14, 2019 at 3:13 PM Francois MAROT
wrote:
> Sorry, seems my previous message missed the copy pasted content ! Here it
> is:
>
>pipeline {
> agent { node { label paramsMap.agentParam } }// the build will
> only run on nodes (ie slaves) indicated
>
> environment {
> // To prevent simultaneous job working in the same Maven local
> repo, we use per-executor local repo (more details here:
>
> http://maven.40175.n5.nabble.com/Not-able-to-read-jars-in-repo-intermittently-td5928990.html#a5928997
> )
> MAVEN_CMD = "mvn -U --batch-mode
> ${paramsMap.activateParallelBuild ? '-T 1C' : ''} " +
> "-Dmaven.repo.local=${isUnix() ?
> '$COMPANY_JENKINS_HOME.m2/repository/executor_$EXECUTOR_NUMBER' :
> '%COMPANY_JENKINS_HOME%.m2\\repository\\executor_%EXECUTOR_NUMBER%'} " +
> "-s ${isUnix() ? '$MAVEN_SETTINGS_XML' :
> '%MAVEN_SETTINGS_XML%'} "
> JAVA_TOOL_OPTIONS = "${env.JAVA_TOOL_OPTIONS == null ? '' :
> env.JAVA_TOOL_OPTIONS} -Djava.io.tmpdir=${env.WORKSPACE}/target/"
> }
> ...
>
>
>
> --
> Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
Re: Maven adjusts transitive compile-scope dependency to test-scope
Did you declare that Y depends on X at all (via Y's pom.xml) or did it figure that out on its own (via transitive dependencies)? Test scope means it's for testing that one project, thus it's not transitive, e.g. I don't need JUnit for my tests just because SomeAwesomeProject uses JUnit for its tests, and I don't want to ship JUnit in my project. On Tue, May 14, 2019 at 2:40 PM Simon Taddiken wrote: > Hi everyone, > > I've encountered the following behavior and I'm not quite sure whether it > is desirable. > In my project, I have declared a dependency *X* with scope *test*. I then > updated the version of a 3rd party dependency *Y*. In its new version, *Y* > suddenly requires the aforementioned dependency *X* as a *compile *scoped > dependency. > > In this scenario, maven resolves the scope of *X* to be *test, *although it > is now required by *Y* during runtime, causing ClassNotFoundExceptions. By > the very nature of this behavior those mistakes can't even be detected in > unit tests because *X* is available on test classpath. > > I have just found out that this behavior seems to be intended ( > > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope > ) > but I can't really come up with a rationale for this design. Managing any > transitive compile scoped dependency down to test scope will almost > certainly cause ClassNotFoundExceptions during runtime. > > Thoughts? >
Maven adjusts transitive compile-scope dependency to test-scope
Hi everyone, I've encountered the following behavior and I'm not quite sure whether it is desirable. In my project, I have declared a dependency *X* with scope *test*. I then updated the version of a 3rd party dependency *Y*. In its new version, *Y* suddenly requires the aforementioned dependency *X* as a *compile *scoped dependency. In this scenario, maven resolves the scope of *X* to be *test, *although it is now required by *Y* during runtime, causing ClassNotFoundExceptions. By the very nature of this behavior those mistakes can't even be detected in unit tests because *X* is available on test classpath. I have just found out that this behavior seems to be intended ( https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope) but I can't really come up with a rationale for this design. Managing any transitive compile scoped dependency down to test scope will almost certainly cause ClassNotFoundExceptions during runtime. Thoughts?
Re: Concurrency issue while running Maven on Jenkins host
Sorry, seems my previous message missed the copy pasted content ! Here it is:
pipeline {
agent { node { label paramsMap.agentParam } }// the build will
only run on nodes (ie slaves) indicated
environment {
// To prevent simultaneous job working in the same Maven local
repo, we use per-executor local repo (more details here:
http://maven.40175.n5.nabble.com/Not-able-to-read-jars-in-repo-intermittently-td5928990.html#a5928997
)
MAVEN_CMD = "mvn -U --batch-mode
${paramsMap.activateParallelBuild ? '-T 1C' : ''} " +
"-Dmaven.repo.local=${isUnix() ?
'$COMPANY_JENKINS_HOME.m2/repository/executor_$EXECUTOR_NUMBER' :
'%COMPANY_JENKINS_HOME%.m2\\repository\\executor_%EXECUTOR_NUMBER%'} " +
"-s ${isUnix() ? '$MAVEN_SETTINGS_XML' :
'%MAVEN_SETTINGS_XML%'} "
JAVA_TOOL_OPTIONS = "${env.JAVA_TOOL_OPTIONS == null ? '' :
env.JAVA_TOOL_OPTIONS} -Djava.io.tmpdir=${env.WORKSPACE}/target/"
}
...
--
Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
