You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was looking at the plugin's Mojos (but specifically at the Execute one) and I've noticed they use requiresDependencyResolution = TEST. Why do these Mojos require dependency resolution in all cases?
The execute goal bound to generate-sources fails in my multi-module project using Eclipse Tycho, because some modules might not be already built. Wouldn't requiresDependencyCollection be a better alternative?
The important difference is that this annotation will not resolve the files for the dependencies, i.e. the artifacts associated with a Maven project can lack a file. As such, this annotation is meant for mojos that only want to analyze the set of transitive dependencies, in particular during early lifecycle phases where full dependency resolution might fail due to projects which haven't been built yet
The text was updated successfully, but these errors were encountered:
The requiresDependencyResolution = TEST configuration simply means when executing this mojo make sure to resolve the dependencies of the project in context to the scope of TEST.
This allows use of gmaven:execute on projects and allow it to resolve the classes which are defined in src/java/test. The requiresDependencyCollection flag only makes the information about dependencies available but wouldn't allow the invocation to resolve those classes.
The intent was to allow the gmaven:execute goal here to use main/test classes from the context in whatever groovy script execution.
I was looking at the plugin's Mojos (but specifically at the
Execute
one) and I've noticed they userequiresDependencyResolution = TEST
. Why do these Mojos require dependency resolution in all cases?The
execute
goal bound togenerate-sources
fails in my multi-module project using Eclipse Tycho, because some modules might not be already built. Wouldn'trequiresDependencyCollection
be a better alternative?The text was updated successfully, but these errors were encountered: